Network Working Group T. Burbridge
Internet-Draft P. Eardley
Intended status: Informational British Telecom
Expires: April 24, 2014 M. Bagnulo
Universidad Carlos III de Madrid
J. Schoenwaelder
Jacobs University
October 21, 2013
Information Model for Large-Scale Measurement Platforms (LMAP)
draft-burbridge-lmap-information-model-01
Abstract
This Information Model applies to the Measurement Agent within a
Large-Scale Measurement Platform. As such it outlines the
information that is (pre-)configured on the MA or exists in
communications with a Controller or Collector within an LMAP
framework. The purpose of such an Information Model is to provide a
protocol and device independent view of the MA that can be
implemented via one or more Control and Report protocols.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2014.
Copyright Notice
Burbridge, et al. Expires April 19, 2014 [Page 1]
Internet-Draft LMAP IM October 2013
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LMAP Information Model . . . . . . . . . . . . . . . . . . . . 3
2.1. Information Structure . . . . . . . . . . . . . . . . . . 4
2.2. Pre-Configuration Information . . . . . . . . . . . . . . 5
2.3. Configuration Information . . . . . . . . . . . . . . . . 5
2.4. Instruction Information . . . . . . . . . . . . . . . . . 6
2.5. Logging Information . . . . . . . . . . . . . . . . . . . 9
2.6. Status Information . . . . . . . . . . . . . . . . . . . . 10
2.7. Reporting Information . . . . . . . . . . . . . . . . . . 11
2.8. Channels . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.9. Timing Information . . . . . . . . . . . . . . . . . . . . 13
2.9.1. Periodic Timing . . . . . . . . . . . . . . . . . . . 14
2.9.2. Calendar Timing . . . . . . . . . . . . . . . . . . . 14
2.9.3. One-Off Timing . . . . . . . . . . . . . . . . . . . . 15
2.9.4. Immediate Timing . . . . . . . . . . . . . . . . . . . 15
2.9.5. Timing Randomness . . . . . . . . . . . . . . . . . . 15
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
6. Informative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Burbridge, et al. Expires April 19, 2014 [Page 2]
Internet-Draft LMAP IM October 2013
1. Introduction
A large-scale measurement platform is a collection of components that
work in a coordinated fashion to perform measurements from a large
number of vantage points. The main components of a large-scale
measurement platform are the Measurement Agents (hereafter MAs), the
Controllers and the Collectors.
The MAs are the elements actually performing the measurements. The
MAs are controlled by one or more Controllers and the Collectors
gather the results generated by the MAs. In a nutshell, the normal
operation of a large-scale measurement platform starts with the
Controller instructing a set of MAs to perform a set of measurements
at a certain point in time. The MAs execute the instructions from
the Controller and once they have done so they report the results of
the measurements to the Collector. The overall framework for a Large
Measurement platform and the terminology used in this document is
described in detail in [I-D.ietf-lmap-framework].
A large-scale measurement platform involves basically three
protocols, namely, a Control protocol between the Controller(s) and
the MAs, a Report protocol between the MAs and the Collector(s) and
several measurement protocols between the MAs used to actually
perform the measurements. In addition the some information is
required to be provisioned to the MA prior to any comunication with
the Controller.
This document defines the information model for both the Control and
the Report protocol along with pre-configuration information that is
required before communicating with the Controller, broadly named as
the LMAP Information Model (or LMAP IM for short). The measurement
protocols are out of the scope of this document.
As defined in [RFC3444], the LMAP IM defines the concepts involved in
a large-scale measurement platform at a high level of abstraction,
independently of any specific implementation or actual protocol used
to exchange the information. It is expected that the proposed
information model can be used with different protocols in different
measurement platform architectures and across different types of MA
device (e.g. home gateway, smartphone, PC, router etc.).
2. LMAP Information Model
Burbridge, et al. Expires April 19, 2014 [Page 3]
Internet-Draft LMAP IM October 2013
2.1. Information Structure
The information described herein relates to the information stored,
received or transmitted by a Measurement Agent as described within
the LMAP framework [I-D.ietf-lmap-framework]. As such, some subsets
of this information model are applicable to the measurement
Controller, Collector and systems that pre-configure the Measurement
Agent. The information described in these models will be transmitted
across the protocols and interfaces between the Measurement Agent and
such systems according to a Data Model.
For clarity the information model is divided into six sections:
1. Pre-Configuration Information. Information pre-configured on the
Measurement Agent prior to any communication with other
components of the LMAP architecture, specifically detailing how
to register with a Controller
2. Configuration Information. Information delivered to the MA on
registration with a Controller or updated during a later
communication, in particular detailing how to retrieve
measurement and reporting instruction information from a
Controller along with information specifically about the MA
3. Instruction Information. Information that is received by the MA
from the Controller pertaining to the measurement and reporting
configuration. This includes measurement configuration, report
channel configuration, measurement schedules and measurement
suppression information
4. Logging Information. Information transmitted from the MA to the
Controller detailing the results of any configuration operations
along with error and status information from the operation of the
MA
5. Status Information. Information on the general status and
capabilities of the MA. For example, the set of measurements
that are supported on the device
6. Reporting Information. Information transmitted from the MA to
the Collector including measurement results and the context in
which they were conducted
In addition the MA may hold further information not described herein,
and which may be optionally transferred to or from other systems
including the Controller and Collector. One example of information
in this category is subscriber or line information that may be
reported by the MA as optional fields in the reporting communication
Burbridge, et al. Expires April 19, 2014 [Page 4]
Internet-Draft LMAP IM October 2013
to the Collector.
2.2. Pre-Configuration Information
This information is the minimal information that needs to be pre-
configured to the MA in order for it to successfully communicate with
a Controller during the registration process.
This pre-configuration information needs to include an URL of the
Controller where configuration information can be retrieved along
with the security information required for the communication
including the certificate of the Controller (or the certificate of
the Certification Authority which was used to issue the certificate
for the Controller) as well as the timing for that communication.
All this is expressed as the Configuration Channel. In addition to
the Configuration Channel information, the MA's security information
is configured which can be either a certificate and a private key or
a password, depending on the security solution used.
Detail of the information model elements:
1. MA MAC: MAC Address
2. Configuration Channel: Channel
3. MA Certificate: Certificate (optional)
4. MA ID: random UUID (optional)
5. MA password: string (optional)
The detail of the Channel object is described later since it is
common to several parts of the information model.
2.3. Configuration Information
During registration or at any later point at which the MA contacts
the Controller, the choice of Controller and details for the timing
of communication with the Controller can be changed. For example the
pre-configured Controller may be replaced with a specific Controller
that is more appropriate to the MA device type, location of
characteristics of the network (e.g. access technology type or
broadband product). The initial communication timing object may also
be replaced with one more relevant to routine communications between
the MA and the Controller.
In addition the MA will be given further items of information that
relate specifically to the MA rather than the measurements it is to
Burbridge, et al. Expires April 19, 2014 [Page 5]
Internet-Draft LMAP IM October 2013
conduct or how to report results. The assignment of an ID to the MA
is mandatory. Optionally a Group ID may also be given which
identifies a group of interest to which that MA belongs. For example
the group could represent an ISP, broadband product, technology,
market classification, geographic region, or a combination of
multiple such characteristics. Where the Measurement Group ID is set
an additional flag (the Report MA ID flag) is required to control
whether the Measurement Agent ID is to be reported. This allows the
MA to remain anonymous which may be particularly useful to prevent
tracking of mobile MA devices.
The configuration information will also contain information about
different communication channels that the MA will have with different
elements of the infrastructure. Each channel specifies a URL,
security information and timing information for the communication.
Detail of the additional information model elements:
1. Measurement Agent ID: UUID
2. Measurement Group ID (optional): String
3. Report MA ID flag (optional): Boolean
4. Instruction Channel: Channel (DISCUSSION: shouldn't we split this
into 4 different channels i.e. the Measurement Task Configuration
channel, the Report Channel channel, the Measurement Schedules
channel and the Measurement Suppression channel?)
5. Status Channel: Channel
6. Logging Channel: Channel
2.4. Instruction Information
The Instruction information model has four sub-elements:
1. Measurement Task Configurations: Set
2. Report Channels: Set
3. Measurement Schedules: Set
4. Measurement Suppression: Object
Conceptually each Measurement Task Configuration defines the
parameters of a Measurement Task that the Measurement Agent (MA) may
perform at some point in time. It does not by itself actually
Burbridge, et al. Expires April 19, 2014 [Page 6]
Internet-Draft LMAP IM October 2013
instruct the MA to perform them at any particular time (this is done
by a Measurement Schedule).
Example: A Measurement Task Configuration may configure a single
Measurement Task for measuring UDP latency. The Measurement Task
Configuration could define the destination port and address for
the measurement as well as the duration, internal packet timing
strategy and other parameters (for example a stream for one hour
and sending one packet every 500 ms). It may also define the
output type and possible parameters (for example the output type
can be the 95th percentile mean) where the measurement task
accepts such parameters. It does NOT define when the task starts
(this is defined by the Measurement Schedule element), so it does
not by itself instruct the MA to actually perform this measurement
task.
The Measurement Task Configuration will include a local short name
for reference by the Measurement Schedule, along with a registry
entry [I-D.bagnulo-ippm-new-registry] that defines the Measurement
Task. The MA itself will resolve the registry entry to a local
executable program. In addition the Measurement Task is specialised
through a set of configuration Options. The nature and number of
these Options will depend upon the Measurement Task and will be
defined in the Measurement Task Registry. In addition the
Measurement Task Configuration may optionally also be given a
Measurement Cycle ID. The purpose of this ID is to easily identify a
set of measurement results that have been produced by Measurement
Tasks with comparable Options. This ID is manually incremented when
an Option change is implemented which could mean that two sets of
results should not be directly compared.
A Report Channel defines how to report results to a single Collector.
Several Report Channels can be defined to enable results to be split
or duplicated across different report intervals or destinations.
E.g. a single Collector may have three Report Channels, one reporting
hourly, another reporting daily and a third on which to send
immediate results for on-demand measurement tasks. The details of
the Channel element is described later as it is common to several
objects.
A Measurement Schedule contains the instruction from the Controller
to the MA to execute a single or repeated series of Measurement
Tasks. Each Measurement Schedule contains basically three elements:
a reference to a list of Measurement Task Configuration, a reference
to a set of one or more Report Channels, and a timing object for the
schedule. The schedule basically states what measurement task to
run, how to report the results, and when to run the measurement task.
Multiple measurement tasks in the list will be executed in order with
Burbridge, et al. Expires April 19, 2014 [Page 7]
Internet-Draft LMAP IM October 2013
minimal gaps. Note that the Controller can instruct the MA to report
to several Collectors by specifying several Report Channels.
Example: a Measurement Schedule references a single Measurement Task
Configuration for the UDP latency defined in the previous example.
It references the Report Channel in the previous example to send
results immediately as available to the specified Collector. The
timing is specified to run the configured Measurement Task
Configuration every hour at 23 minutes past the hour.
Measurement Suppression information is used to over-ride the
Measurement Schedule and stop measurements from the MA for a defined
or indefinite period. While conceptually measurements can be stopped
by simply removing them from the Measurement Schedule, splitting out
separate information on Measurement Suppression allows this
information to be updated on the MA on a different timing cycle or
protocol implementation to the Measurement Schedule.
The goal when defining these four different elements is to allow each
part of the information model to change without affecting the other
three elements. For example it is envisaged that the Report Channels
and the set of Measurement Tasks Configurations will be relatively
static. The Measurement Schedule on the other hand is likely to be
more dynamic as the measurement panel and test frequency are changed
for various business goals. Another example is that measurements can
be suppressed with a Measurement Suppression command without removing
the existing Measurement Schedules that would continue to apply after
the Measurement Suppression expires or is removed. In terms of the
Controller-MA communication this can reduce the data overhead. It
also encourages the re-use of the same standard Measurement Task
Configurations and Reporting Channels to help ensure consistency and
reduce errors.
Definition of the information model elements:
1. Measurement Task Configurations: Set
1. Measurement Task Configuration: Object
1. Task Name (used for referral from the Measurement
Schedules): String
2. Registry Entry: URN
3. Options: Set (optional)
1. Interface name (reference by name to one of the
Interfaces defined in the Status information): String
Burbridge, et al. Expires April 19, 2014 [Page 8]
Internet-Draft LMAP IM October 2013
4. Measurement Cycle ID: String (optional)
2. Report Channels: Set
1. Report Channel: Channel
3. Measurement Schedules: Set
1. Measurement Schedule: Object
1. Schedule Name: String
2. Measurement Task Configuration Names (reference by Name
to one of the measurement tasks defined in the
Measurement Task Configuration set): List
1. Task Name: String
3. Report Channel Names (reference by Name to one of the
measurement tasks defined in the Measurement Task
Configuration set): Set
1. Channel Name: String
4. Measurement Timing: Timing
4. Measurement Suppression: Object (optional)
1. Start: datetime
2. End: datetime
3. Set of Measurement Task Configuration Names (optional -
default all)
1. Task Name: String
2.5. Logging Information
The MA will report back success/failure and status information to the
Controller. These messages will fall into a number of different
categories:
1. Success/failure messages in response to information updates from
the Controller. For example:
* "Report Channel 'hourly db" configured"
Burbridge, et al. Expires April 19, 2014 [Page 9]
Internet-Draft LMAP IM October 2013
* "Measurement Schedule does not conform to schema, Row 211"
2. Status updates from the operation of the MA. For example:
* "out of memory: cannot record result"
* "Collector 'collector.example.com' not responding"
Each log message will have the following Information model elements:
1. Log Time: datetime
2. Log Event: Object
2.6. Status Information
In addition to the information reported by the MA through the logging
information, the MA will hold further status information that can be
retrieved by a Controller. One category of additional information
that has not been defined in earlier sections is the availability of
Measurement Tasks on that MA.
MA Status information model elements:
1. MA ID: String
2. MA Device: String
3. MA hardware: String (optional)
4. MA firmware: String (optional)
5. MA software: String (optional)
6. MA Interfaces: set
1. If name: String
2. If type: String (one of eth, wlan, TBC)
3. If speed: Integer (expressed in Mbps)
4. Link Layer Address: String
5. IP address: Set
1. Protocol: String (one of v4, v6)
Burbridge, et al. Expires April 19, 2014 [Page 10]
Internet-Draft LMAP IM October 2013
2. Address: String
6. Gateway: Set (optional)
1. Protocol: String (one of v4, v6)
2. Address: String
7. DNS server: Set (optional)
1. Protocol: String (one of v4, v6)
2. Address: String
7. Last Measurement: datetime
8. Last Report: datetime
9. Last Instruction: datetime
10. Last Configuration: datetime
11. Supported Measurements: Set
1. Registry Entry: URN
2. Version: String (optional)
2.7. Reporting Information
At a point in time specific by the Report Channel, the MA will
communicate a set of measurement results to the Collector. These
measurement results should be communicated within the context in
which they were collected.
The report is structured hierarchically to avoid repetition of
report, Measurement Agent and Measurement Task Configuration
information. The report starts with the timestamp of the report
generation on the MA and details about the MA including the optional
Measurement Agent ID and Group ID (controlled by the Configuration
Information). In addition optional further MA context information
can be included at this point such as the line sync speed or ISP and
product if known by the MA.
After the MA information the results are reported grouped into the
different Measurement Tasks. Each Task starts with replicating the
Measurement Task Configuration information before the result headers
(titiles for data columns) and the result data rows.
Burbridge, et al. Expires April 19, 2014 [Page 11]
Internet-Draft LMAP IM October 2013
Information model elements:
1. Report Date: datetime
2. Measurement Agent ID: String (optional)
3. Measurement Group ID: String (optional)
4. MA Context: Set (optional)
1. Context Item: Object
5. Measurement Task: Set
1. Measurement Task Configuration: Object
2. Result Headers: List
1. Column Name: String
3. Result Data: List
1. Result Row: Object
1. Measurement Time: datetime
2. Cross-traffic: Integer (optional)
3. Result Columns: List
1. Column Data
2.8. Channels
A Channel defines a communication channel between the MA and other
element of the measurement framework i.e. with the Collector to
report results back, to Controller to retrieve Instructions or other
information exchanged between the parties. Several Channels can be
defined to enable results to be split or duplicated across different
report intervals or destinations. E.g. a single Collector may have
three Report Channels, one reporting hourly, another reporting daily
and a third on which to send immediate results for on-demand
measurement tasks.
Each Channel contains the details of the target (including location
and security information such as the certificate), and the timing for
the communication i.e. when to establish the communication. The
certificate can be the digital certificate associated to the FQDN in
Burbridge, et al. Expires April 19, 2014 [Page 12]
Internet-Draft LMAP IM October 2013
the URL or it can be the certificate of the Certification Authority
that was used to issue the certificate for the FQDN of the target URL
(which will be retrieved later on using a communication protocol such
as SSL). The Channel can use the same timing information object as a
Measurement Schedule and the Controller Communication Timing defined
earlier. There are several options, such as immediately after the
results are obtained or at a given interval or calendar based cycle).
As with the Measurement task Configuration, each Channel is also
given a local short name by which it can be referenced from a
Measurement Schedule or other elements.
Example: A Channel using for reporting results may specify that
results are to be sent to the URL
(https://collector.foo.org/report/), using the appropriate digital
certificate to establish a secure channel. The Channel specifies
that the results are to be sent immediately as available and not
batched.
Channel: Object
1. Channel Name (used for referral from other objects ): String
2. Target: URL
3. Certificate: X.509 Certificate
4. Communication Timing: Timing
2.9. Timing Information
The Timing information object used throughput the information models
can take one of four different forms:
1. Periodic. Specifies a start, end and interval time in
milliseconds
2. Calendar: Specifies a calendar based pattern - e.g. 22 minutes
past each hour of the day on weekdays
3. One Off: A single instance occurring at a specific time
4. Immediate: Should occur as soon as possible
Optionally each of the first three options may also specify a
randomness that should be evaluated and applied separately to each
indicated event.
Burbridge, et al. Expires April 19, 2014 [Page 13]
Internet-Draft LMAP IM October 2013
2.9.1. Periodic Timing
Information model elements:
1. 1. Timing Name: String
2. 2. Start: datetime (optional)
3. 3. End: datetime (optional)
4. 4. Interval: Integer (in milliseconds)
5. 5. Randomness: Timing Randomness (optional)
2.9.2. Calendar Timing
Information model elements:
1. Timing Name: String
2. Start: datetime (optional)
3. End: datetime (optional)
4. Months: Set (optional - default [1-12])
1. Month: Integer
5. Weekdays: Set (optional - default [Mon-Sun])
1. Weekday: String (one off Mon, Tue, Wed, Thu, Fri, Sat Sun)
6. Days: Set (optional - default [1-31])
1. Day: Integer
7. Hours: Set (optional - default [1-24])
1. Hour:Integer
8. Minutes: Set (optional - default [1-60])
1. Minute: Integer
9. Seconds: Set (optional - default [1-60])
1. Second: Integer
Burbridge, et al. Expires April 19, 2014 [Page 14]
Internet-Draft LMAP IM October 2013
10. Randomness: Timing Randomness (optional)
2.9.3. One-Off Timing
Information model elements:
1. Time: datetime
2. Randomness: Timing Randomness (optional)
2.9.4. Immediate Timing
The immediate timing object has no further information elements. The
measurement or report is simply to be done as soon as possible.
2.9.5. Timing Randomness
The Timing randomness object specifies a random distribution that can
be applied to any scheduled execution event such as a measurement or
report. The intention it to be able to spread the load on the
Controller, Collector and network in an automated manner for a large
number of Measurement Agents. The randomness is expressed as a
distribution (e.g. Poison, Normal, Uniform etc.) along with the
spread over which the distribution should be applied. In additional
optional upper and lower bounds can be applied to control extreme
spread of timings.
Information model elements:
1. Distribution: String
2. Upper Cut: Integer (optional)
3. Lower Cut: Integer (optional)
4. Spread: Integer
3. IANA Considerations
This document makes no request of IANA .
Note to RFC Editor: this section may be removed on publication as an
RFC.
Burbridge, et al. Expires April 19, 2014 [Page 15]
Internet-Draft LMAP IM October 2013
4. Security Considerations
This Information Model deals with information about the control and
reporting of the Measurement Agent. There are broadly two security
considerations for such an Information Model. Firstly the
Information Model has to be sufficient to establish secure
communication channels to the Controller and Collector such that
other information can be sent and received securely. The second
consideration is that no mandated information items pose a risk to
confidentiality or privacy given such secure communication channels.
For this latter reason items such as the MA context and MA ID are
left optional and can be excluded from some deployments. This would,
for example, allow the MA to remain anonymous and for information
about location or other context that might be used to identify or
track the MA to be ommitted or blurred.
5. Acknowledgements
6. Informative References
[I-D.bagnulo-ippm-new-registry]
Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
A. Morton, "A registry for commonly used metrics",
draft-bagnulo-ippm-new-registry-00 (work in progress),
January 2013.
[I-D.ietf-lmap-framework]
Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A framework for large-scale
measurement platforms (LMAP)",
draft-ietf-lmap-framework-00 (work in progress),
October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444,
January 2003.
Burbridge, et al. Expires April 19, 2014 [Page 16]
Internet-Draft LMAP IM October 2013
Authors' Addresses
Trevor Burbridge
British Telecom
Adastral Park, Martlesham Heath
Ipswich, IP5 3RE
UK
Phone:
Fax:
Email:
URI:
Philip Eardley
British Telecom
Adastral Park, Martlesham Heath
Ipswich, IP5 3RE
UK
Phone:
Fax:
Email:
URI:
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid, 28911
Phone:
Fax:
Email:
URI:
Juergen Schoenwaelder
Jacobs University
Phone:
Fax:
Email:
URI:
Burbridge, et al. Expires April 19, 2014 [Page 17]