Network Working Group T. Burbridge Internet-Draft P. Eardley Intended status: Standards Track British Telecom Expires: August 18, 2014 M. Bagnulo Universidad Carlos III de Madrid J. Schoenwaelder Jacobs University Bremen February 14, 2014 Information Model for Large-Scale Measurement Platforms (LMAP) draft-ietf-lmap-information-model-00 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 August 18, 2014. Copyright Notice Burbridge, et al. Expires August 18, 2014 [Page 1] Internet-Draft LMAP Information Model February 2014 Copyright (c) 2014 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. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. LMAP Information Model . . . . . . . . . . . . . . . . . . . . 4 3.1. Information Structure . . . . . . . . . . . . . . . . . . 4 3.2. Pre-Configuration Information . . . . . . . . . . . . . . 5 3.3. Configuration Information . . . . . . . . . . . . . . . . 6 3.4. Instruction Information . . . . . . . . . . . . . . . . . 7 3.5. MA to Controller Information . . . . . . . . . . . . . . . 11 3.6. Capability and Status Information . . . . . . . . . . . . 13 3.7. Reporting Information . . . . . . . . . . . . . . . . . . 14 3.8. Channels . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.9. Timing Information . . . . . . . . . . . . . . . . . . . . 16 3.9.1. Periodic Timing . . . . . . . . . . . . . . . . . . . 17 3.9.2. Calendar Timing . . . . . . . . . . . . . . . . . . . 17 3.9.3. One-Off Timing . . . . . . . . . . . . . . . . . . . . 18 3.9.4. Immediate Timing . . . . . . . . . . . . . . . . . . . 18 3.9.5. Timing Randomness . . . . . . . . . . . . . . . . . . 18 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Burbridge, et al. Expires August 18, 2014 [Page 2] Internet-Draft LMAP Information Model February 2014 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 Controller(s) and the Collector(s). The MAs are the elements actually performing the measurements. The MAs are controlled by exactly one Controller at a time 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 one or more MAs to perform a set of one or more Measurement Tasks at a certain point in time. The MAs execute the instructions from a Controller, and once they have done so, they report the results of the measurements to one or more Collectors. The overall framework for a Large Measurement platform as 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 a Controller and the MAs, a Report protocol between the MAs and the Collector(s) and several measurement protocols between the MAs and Measurement Peers (MPs), used to actually perform the measurements. In addition some information is required to be provisioned in the MA prior to any communication with the initial 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, independent 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 devices (e.g., home gateway, smartphone, PC, router). The definition of an Information Model serves a number of purposes: 1. To guide the standardisation of one or more Control and Report protocol and data model implementations Burbridge, et al. Expires August 18, 2014 [Page 3] Internet-Draft LMAP Information Model February 2014 2. To enable high-level inter-operability between different Control and Report protocols by facilitating translation between their respective data models such that a Controller could instruct sub- populations of MAs using different protocols 3. To from agreement of what information needs to be held by an MA and passed over the Control and Report interfaces and support the functionality described in the LMAP framework 4. Enable existing protocols and data models to be assessed for their suitability as part of a large-scale measurement system 2. Notation This document use an adaptation of the C-style struct notation to define the fields (names/values) of the objects of the information model. An optional field is enclosed by [ ], and an array is indicated by two numbers in angle brackets, >, where m indicates the minimal number of values, and n is the maximum. The symbol * for n means no upper bound. 3. LMAP Information Model 3.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 (i.e., the Controller, Collector and Measurement Peers), specifically detailing how to communicate with an initial Controller and whether the device is enabled to participate as an MA. 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 Burbridge, et al. Expires August 18, 2014 [Page 4] Internet-Draft LMAP Information Model February 2014 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. MA to Controller 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. Capability and 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 to a Collector. It should also be noted that the MA may be in communication with other management systems which may be responsible for configuring and retrieving information from the MA device. Such systems, where available, can perform an important role in transferring the pre- configuration information to the MA or enabling/disabling the measurement functionality of the MA. The Information Model is divided into sub-sections for a number of reasons. Firstly the grouping of information facilitates reader understanding. Secondly, the particular groupings chosen are expected to map to different protocols or different transmissions within those protocols. 3.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. Burbridge, et al. Expires August 18, 2014 [Page 5] Internet-Draft LMAP Information Model February 2014 This pre-configuration information needs to include a URL of the initial 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 Instruction Channel. As part of the Instruction Channel, 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. The MA may already be pre-configured with an MA ID, or may use a Device ID in the initial Controller contact before it is assigned an MA ID. The Device ID may be a MAC address or some other device identifier expressed as a URN. Detail of the information model elements: object { ma-channel-obj ma-instruction-channel; ma-channel-obj ma-ma-to-controller-channel; [urn ma-device-id;] [uuid ma-agent-id;] } ma-preconfig-obj; The detail of the Channel object is described later since it is common to several parts of the information model. 3.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 (as captured by the Instruction Channel information object). For example the pre- configured Controller may be replaced with a specific Controller that is more appropriate to the MA device type, location or characteristics of the network (e.g. access technology type or broadband product). The initial communication timing object may 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 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 Burbridge, et al. Expires August 18, 2014 [Page 6] Internet-Draft LMAP Information Model February 2014 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 also to be reported. The reporting of a Group ID without the MA ID allows the MA to remain anonymous, which may be particularly useful to prevent tracking of mobile MA devices. Optionally an MA can also be configured to stop Measurement Tasks if the Controller is unreachable. This can be used as a fail-safe to stop Measurement Tasks being conducted when there is doubt that the Instruction Information is still valid. This is simply represented as a number of failed communication attempts before Measurement Tasks are suspended. The appropriate number of failed attempts will depend on the timing of the Instruction Channel and the duration for which the system is willing to tolerate continued operation with potentially stale Instruction Information. Detail of the additional information model elements: object { uuid ma-agent-id; ma-channel-obj ma-instruction-channel; [string ma-group-id;] [boolean ma-report-ma-id-flag;] [int ma-instruction-channel-failure-threshold;] } ma-config-obj; 3.4. Instruction Information The Instruction information model has four sub-elements: 1. Measurement Task Configurations 2. Report Channels 3. Measurement Schedules 4. Measurement Suppression 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 instruct the MA to perform them at any particular time (this is done by a Measurement Schedule). Burbridge, et al. Expires August 18, 2014 [Page 7] Internet-Draft LMAP Information Model February 2014 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. Alternatively multiple Report Channels can be used to send Measurement Task results to different Collectors. 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 two elements: a reference to a list of Measurement Task Configuration and a timing object for the schedule. The schedule basically states what measurement task to run, how to report the results per Measurement Task Configuration, and when to run the measurement task. Multiple measurement tasks in the list will be executed in order with minimal gaps. Note that the Controller can instruct the MA to report to several Collectors by specifying several Report Channels. Burbridge, et al. Expires August 18, 2014 [Page 8] Internet-Draft LMAP Information Model February 2014 Each Measurement Task Configuration named in the Measurement Schedule can be allocated to independent Report Channels, giving flexibility to report different Measurement Tasks to different Collectors or on different timings. Furthermore, as each Measurement Task may have multiple data outputs, these outputs can each be assigned to different Report Channels. For example a Measurement Task might report routine results hourly via the Broadband PPP interface, but also output emergency conditions immediately via a GPRS channel. 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. It is also considered that it will be easier for a human operator to implement a temporary explicit suppression rather than having to move to a reduced Schedule and then roll-back at a later time. The explicit Suppression instruction message is able to simply enable/disable all Measurement Tasks as well as having fine control on which Tasks are suppressed. Suppression of both specified Measurement Tasks Configurations and Measurement Schedules is supported. Support for disabling specific Measurement Task Configurations allows malfunctioning or mis-configured Measurement Tasks or Measurement Task Configurations that have an impact on a particular part of the network infrastructure (e.g., a particular Measurement Peer) to be targetted. Support for disabling specific Measurement Schedules allows for particularly heavy cycles or sets of less essential Measurement Tasks to be suppressed quickly and effectively. Unsuppression is achieved through either overwriting the Measurement Suppression information (e.g. changing 'enabled' to False) or through the use of an End time such that the Measurement Suppression will no longer be in effect beyond this time. 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 Burbridge, et al. Expires August 18, 2014 [Page 9] Internet-Draft LMAP Information Model February 2014 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: object { ma-task-obj ma-tasks<0..*>; ma-channel-obj ma-report-channels<0..*>; ma-schedule-obj ma-schedules<0..*>; ma-suppression-obj ma-suppression; } ma-instruction-obj; object { string ma-task-name; urn ma-task-registry; string ma-task-options<0..*>; [string ma-task-cycle-id;] } ma-task-obj; object { string ma-schedule-name; ma-sched-task-obj ma-schedule-tasks<0..*>; ma-timing-obj ma-schedule-timing; } ma-schedule-obj; object { string ma-schedule-task-name; ma-sched-report-obj ma-schedule-task-reports<0..*>; } ma-sched-task-obj; object { [int ma-schedule-task-filter;] // default: all string ma-schedule-task-report-channel-name; } ma-sched-report-obj; Burbridge, et al. Expires August 18, 2014 [Page 10] Internet-Draft LMAP Information Model February 2014 object { boolean ma-suppression-enabled; [datetime ma-suppression-start;] // default: immediate [datetime ma-suppression-end;] // default: indefinite [string ma-suppression-task-names<0..*>;] // default: all tasks if // ma-suppression-task-names is empty [string ma-suppression-schedule-names<0..*>;] // default: all schedules if // ma-suppression-schedule-names is empty } ma-suppression-obj; 3.5. MA to Controller Information The MA may report on the success or failure of Configuration or Instruction communications from the Controller. In addition further operational logs may be produced during the operation of the MA and updates to capabilities may also be reported. Reporting this information is achieved simply and flexibly in exactly the same manner as any Measurement Task. We make no distinction between a Measurement Task conducting an active or passive network measurement and one which solely retrieves static information from the MA such as logging information. One or more logging tasks can be programmed or configured to capture subsets of the MA to Controller Information. These logging tasks are then executed by Measurement Schedules (if not permanently running) and the resultant data assigned to the MA to Controller Channel. The type of MA to Controller Information will fall into three different categories: 1. Success/failure/warning messages in response to information updates from the Controller. Failure messages could be produced due to some inability to receive or parse the Controller communication, or if the MA is not able to act as instructed. For example: * "Measurement Schedules updated OK" * "Unable to parse JSON" * "Missing mandatory element: Measurement Timing" * "'Start' does not conform to schema - expected datetime" * "Date specified is in the past" Burbridge, et al. Expires August 18, 2014 [Page 11] Internet-Draft LMAP Information Model February 2014 * "'Hour' must be in the range 1..24" * "Schedule A refers to non-existent Measurement Task Configuration" * "Measurement Task Configuration X registry entry Y not found" * "Updated Measurement Task Configurations do not include M used by Measurement Schedule N" 2. Operational updates from the MA. For example: * "Out of memory: cannot record result" * "Collector 'collector.example.com' not responding" * "Unexpected restart" * "Suppression timeout" * "Failed to execute Measurement Task Configuration H" 3. Status updates from the MA. For example: * "Interface added: eth3 " * "Supported measurements updated" * "New IP address on eth0: xxx.xxx.xxx.xxx" This Information Model document does not detail the precise format of logging information since it is to a large extend protocol and measurement task specific. However, some common information can be identified. MA Logging information model elements: object { uuid ma-log-agent-id; datetime ma-log-event-time; code ma-log-code; string ma-log-description; } ma-log-obj; Burbridge, et al. Expires August 18, 2014 [Page 12] Internet-Draft LMAP Information Model February 2014 3.6. Capability and Status Information The MA will hold Capability Information that can be retrieved by a Controller. Capabilities include the interface details available to Measurement Tasks and Reports as well as the set of Measurement Tasks that are actually installed or available on the MA. Status information includes the times that operations were last performed such as contacting the Controller or producing Reports. MA Status information model elements: object { uuid ma-agent-id; urn ma-device-id; string ma-hardware; string ma-firmware; string ma-software; ma-interface-obj ma-interfaces<0..*>; datetime ma-last-measurement; datetime ma-last-report; datetime ma-last-instruction; datetime ma-last-configuration; ma-capability-obj ma-supported-measurements<0..*>; } ma-status-obj; object { string ma-interface-name; string ma-interface-type; int ma-interface-speed; // mbps string ma-link-layer-address; ip-address ma-interface-ip-addresses<0..*>; [ip-address ma-interface-gateways<0..*>;] [ip-address ma-interface-dns-servers<0..*>;] } ma-interface-obj; object { urn ma-measurement-id; [string ma-measurement-version;] } ma-capability-obj; Burbridge, et al. Expires August 18, 2014 [Page 13] Internet-Draft LMAP Information Model February 2014 3.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. It should be noted that Collectors can be implemented by many types of devices and systems, including the MA itself. In this manner data from Measurement Tasks can (also) be stored locally on the MA and used as input by other Measurement Tasks. This facilitates using a first Measurement Task to control the operation of a later Measurement Task (such as probing available line speed) and also to allow local processing of data to output alarms (e.g. when performance drops from earlier levels). 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 Measurement Task starts with replicating the Measurement Task Configuration information before the result headers (titles for data columns) and the result data rows. The result data rows may optionally include an indication of the cross-traffic (e.g., the total number of octets of non-measurement traffic passing through the interfaces used by a Measurement Task during the measurement period). The datetime format used for all elements in the information model (i.e., Report Date and Measurement Time in the Reporting Information) MUST conform to RFC 3339 [RFC3339] and ISO8601. Information model elements: object { datetime ma-report-date; [uuid ma-report-agent-id;] [string ma-report-group-id;] ma-context-obj ma-report-context<0..*>; ma-report-task-obj ma-report-tasks<0..*>; } ma-report-obj; Burbridge, et al. Expires August 18, 2014 [Page 14] Internet-Draft LMAP Information Model February 2014 object { ma-task-obj ma-report-task-config; string ma-report-task-column-headers<0..*>; ma-result-row-obj ma-report-task-rows<0..*>; } ma-report-task-obj; object { datetime ma-report-result-time; [int ma-report-result-cross-traffic;] data ma-report-result-values<0..*>; } ma-result-row-obj; The ma-context-obj, which covers things like line speed or the device type, is not further detailed here. 3.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 the URL or it can be the certificate of the Certification Authority that was used to issue the certificate for the FQDN (Fully Qualified Domain Name) 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. As for Measurement Tasks, multiple interfaces are also supported. For example the Controller could choose to receive some results over GPRS. This is especially useful when such results indicate the loss of connectivity on a different network interface. Burbridge, et al. Expires August 18, 2014 [Page 15] Internet-Draft LMAP Information Model February 2014 Facility is also provided for the Controller to choose whether to receive empty reports where there is no Measurement Task information. In some cases this may be desirable to monitor the health of the measurement system. 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. object { string ma-channel-name; url ma-channel-target; certificate ma-channel-certificate; ma-timing-obj ma-channel-timing; [string ma-channel-interface-name;] [boolean ma-channel-connect-always;] // default: false // (only connect when data is pending) } ma-channel-obj; 3.9. Timing Information The Timing information object used throughout 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. The datetime format used for all elements in the information model (i.e., Report Date and Measurement Time in the Reporting Information) MUST conform to RFC 3339 [RFC3339] and ISO8601. Burbridge, et al. Expires August 18, 2014 [Page 16] Internet-Draft LMAP Information Model February 2014 object { [string ma-timing-name;] union { ma-periodic-obj ma-timing-periodic; ma-calendar-obj ma-timing-calendar; ma-one-off-obj ma-timing-one-off; ma-immediate-obj ma-timing-immediate; } [ma-randomness-obj ma-timing-randomness;] } ma-timing-obj; 3.9.1. Periodic Timing Information model elements: object { [datetime ma-periodic start;] // default: immediate [datetime ma-periodic-end;] // default: indefinite int ma-periodic-interval; // milliseconds } ma-periodic-obj; 3.9.2. Calendar Timing Calendar Timing supports the routine execution of Measurement Tasks at specific times and/or on specific dates. It can support more flexible timing than Periodic Timing since the Measurement Task execution does not have to be uniformly spaced. For example a Calendar Timing could support the execution of a Measurement Task every hour between 6pm and midnight on weekdays only. Calendar Timing is also required to perform measurements at meaningful instances in relation to network usage (e.g., at peak times). If the optional timezone offset is not supplied then local system time is assumed. This is essential in some use cases to ensure consistent peak-time measurements as well as supporting MA devices that may be in an unknown timezone or roam between different timezones (but know their own timezone information such as through the mobile network). Information model elements: Burbridge, et al. Expires August 18, 2014 [Page 17] Internet-Draft LMAP Information Model February 2014 object { [datetime ma-calendar-start;] // default: immediate [datetime ma-calendar-end;] // default: indefinite [int ma-calendar-months<0..*>;] // default: 1-12 [days ma-calendar-weekdays<0..*>;] // default: all [int ma-calendar-hours<0..*>;] // default: 0-23 [int ma-calendar-minutes<0..*>;] // default: 0-59 [int ma-calendar-seconds<0..*>;] // default: 0-59 [int ma-calendar-timezone-offset;] // default: system timezone offset } ma-calendar-obj; 3.9.3. One-Off Timing Information model elements: object { datetime ma-one-off-time; } ma-one-off-obj; 3.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. object { // empty } ma-immediate-obj; 3.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: object { string ma-randomness-distribution; [int ma-randomness-lower-cut;] [int ma-randomness-upper-cut;] int ma-randomness-spread; Burbridge, et al. Expires August 18, 2014 [Page 18] Internet-Draft LMAP Information Model February 2014 } ma-randomness-obj; 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. 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. Additionally, any mechanisms that the Network Operator or other device administrator employs to pre-configure the MA must also be secure to protect unauthorized parties from modifying pre-configuration information. 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 omitted or blurred. 6. Acknowledgements The notation was inspired by the notation used in the ALTO protocol specification. Philip Eardley, Trevor Burbridge, Marcelo Bagnulo and Juergen Schoenwaelder work in part on the Leone research project, which receives funding from the European Union Seventh Framework Programme [FP7/2007-2013] under grant agreement number 317647. 7. References Burbridge, et al. Expires August 18, 2014 [Page 19] Internet-Draft LMAP Information Model February 2014 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. 7.2. 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-01 (work in progress), July 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-03 (work in progress), January 2014. [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003. Authors' Addresses Trevor Burbridge British Telecom Adastral Park, Martlesham Heath Ipswich, IP5 3RE United Kingdom Philip Eardley British Telecom Adastral Park, Martlesham Heath Ipswich, IP5 3RE United Kingdom Burbridge, et al. Expires August 18, 2014 [Page 20] Internet-Draft LMAP Information Model February 2014 Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid, 28911 Spain Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 Bremen, 28759 Germany Burbridge, et al. Expires August 18, 2014 [Page 21]