Internet Engineering Task Force (IETF) T. Burbridge Request for Comments: 8193 P. Eardley Category: Standards Track BT ISSN: 2070-1721 M. Bagnulo Universidad Carlos III de Madrid J. Schoenwaelder Jacobs University Bremen August 2017 Information Model for Large-Scale Measurement Platforms (LMAPs)
AbstractThis Information Model applies to the Measurement Agent within an LMAP framework. As such, it outlines the information that is configured or preconfigured on the Measurement Agent 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 Measurement Agent that can be implemented via one or more Control and Report Protocols. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8193.
Copyright Notice Copyright (c) 2017 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. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. LMAP Information Model . . . . . . . . . . . . . . . . . . . 6 4.1. Preconfiguration Information . . . . . . . . . . . . . . 10 4.1.1. Definition of ma-preconfig-obj . . . . . . . . . . . 11 4.2. Configuration Information . . . . . . . . . . . . . . . . 12 4.2.1. Definition of ma-config-obj . . . . . . . . . . . . . 13 4.3. Instruction Information . . . . . . . . . . . . . . . . . 14 4.3.1. Definition of ma-instruction-obj . . . . . . . . . . 17 4.3.2. Definition of ma-suppression-obj . . . . . . . . . . 17 4.4. Logging Information . . . . . . . . . . . . . . . . . . . 19 4.4.1. Definition of ma-log-obj . . . . . . . . . . . . . . 20 4.5. Capability and Status Information . . . . . . . . . . . . 21 4.5.1. Definition of ma-capability-obj . . . . . . . . . . . 21 4.5.2. Definition of ma-capability-task-obj . . . . . . . . 21 4.5.3. Definition of ma-status-obj . . . . . . . . . . . . . 22 4.5.4. Definition of ma-status-schedule-obj . . . . . . . . 23 4.5.5. Definition of ma-status-action-obj . . . . . . . . . 24 4.5.6. Definition of ma-status-suppression-obj . . . . . . . 26 4.5.7. Definition of ma-status-interface-obj . . . . . . . . 27 4.6. Reporting Information . . . . . . . . . . . . . . . . . . 28 4.6.1. Definition of ma-report-obj . . . . . . . . . . . . . 29 4.6.2. Definition of ma-report-result-obj . . . . . . . . . 30 4.6.3. Definition of ma-report-conflict-obj . . . . . . . . 32 4.6.4. Definition of ma-report-table-obj . . . . . . . . . . 32 4.6.5. Definition of ma-report-row-obj . . . . . . . . . . . 33 4.7. Common Objects: Schedules . . . . . . . . . . . . . . . . 33 4.7.1. Definition of ma-schedule-obj . . . . . . . . . . . . 35 4.7.2. Definition of ma-action-obj . . . . . . . . . . . . . 36
4.8. Common Objects: Channels . . . . . . . . . . . . . . . . 37 4.8.1. Definition of ma-channel-obj . . . . . . . . . . . . 38 4.9. Common Objects: Task Configurations . . . . . . . . . . . 38 4.9.1. Definition of ma-task-obj . . . . . . . . . . . . . . 40 4.9.2. Definition of ma-option-obj . . . . . . . . . . . . . 40 4.10. Common Objects: Registry Information . . . . . . . . . . 41 4.10.1. Definition of ma-registry-obj . . . . . . . . . . . 41 4.11. Common Objects: Event Information . . . . . . . . . . . . 41 4.11.1. Definition of ma-event-obj . . . . . . . . . . . . . 42 4.11.2. Definition of ma-periodic-obj . . . . . . . . . . . 44 4.11.3. Definition of ma-calendar-obj . . . . . . . . . . . 44 4.11.4. Definition of ma-one-off-obj . . . . . . . . . . . . 46 4.11.5. Definition of ma-immediate-obj . . . . . . . . . . . 47 4.11.6. Definition of ma-startup-obj . . . . . . . . . . . . 47 4.11.7. Definition of ma-controller-lost-obj . . . . . . . . 47 4.11.8. Definition of ma-controller-connected-obj . . . . . 47 5. Example Execution . . . . . . . . . . . . . . . . . . . . . . 48 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 7. Security Considerations . . . . . . . . . . . . . . . . . . . 50 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 8.1. Normative References . . . . . . . . . . . . . . . . . . 50 8.2. Informative References . . . . . . . . . . . . . . . . . 51 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 RFC7536]. The main components of a large- scale measurement platform are the Measurement Agents (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-scale measurement platform as used in this document is described in detail in [RFC7594].
A large-scale measurement platform involves basically three types of protocols, namely, a Control Protocol (or Protocols) between a Controller and the MAs, a Report Protocol (or Protocols) 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 configured on the MA prior to any communication with a Controller. This document defines the Information Model for both the Control and Report Protocols along with Preconfiguration Information that is required on the MA before communicating with the Controller, broadly named as the LMAP Information Model. The measurement protocols are out of the scope of this document. As defined in [RFC3444], the LMAP Information Model 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, or router). A YANG data model implementing the Information Model can be found in [RFC8194]. The definition of an Information Model serves a number of purposes: 1. To guide the standardization of one or more Control and Report protocols and data models 2. To enable high-level interoperability 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 form 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. To enable existing protocols and data models to be assessed for their suitability as part of a large-scale measurement system RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
ISO.10646] characters. datetime A type representing a date and time using the Gregorian calendar. The datetime format MUST conform to RFC 3339 [RFC3339]. uuid A type representing a Universally Unique IDentifier (UUID) as defined in RFC 4122 [RFC4122]. The UUID values are expected to be unique within an installation of a large-scale measurement system. uri A type representing a Uniform Resource Identifier as defined in STD 66 [RFC3986]. ip-address A type representing an IP address. This type supports both IPv4 and IPv6 addresses. counter A non-negative integer that monotonically increases. Counters may have discontinuities, and they are not expected to persist across restarts. credentials An opaque type representing credentials needed by a cryptographic mechanism to secure communication. Data models must expand this opaque type as needed and required by the security protocols utilized.
data An opaque type representing data obtained from measurements. Names of objects are generally assumed to be unique within an implementation. RFC7594]. As such, some subsets of this Information Model are applicable to the measurement Controller and Collector and to any device management system that preconfigures the Measurement Agent. The information described in these models will be transmitted by protocols using interfaces between the Measurement Agent and such systems according to a data model. The Information Model is divided into six aspects. 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. 1. Preconfiguration Information. Information preconfigured on the Measurement Agent prior to any communication with other components of the LMAP architecture (i.e., the Controller, the Collector, and Measurement Peers), specifically detailing how to communicate with a Controller and whether the device is enabled to participate as an MA. 2. Configuration Information. Update of the Preconfiguration Information during the registration of the MA or subsequent communication with the Controller, along with the configuration of further parameters about the MA (rather than the Measurement Tasks it should perform) that were not mandatory for the initial communication between the MA and a Controller. 3. Instruction Information. Information that is received by the MA from the Controller pertaining to the Measurement Tasks that should be executed. This includes the Task execution Schedules (other than the Controller communication Schedule supplied as Configuration or Preconfiguration Information) and related information such as the Task Configuration, communication Channels to Collectors, and Event information. It also includes Task Suppression information that is used to override normal Task execution.
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. 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 one or more Collectors, including measurement results and the context in which they were conducted. In addition, the MA may hold further information not described herein, 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 extracted by a Task and reported by the MA in the reporting communication to a Collector. It should also be noted that the MA may be in communication with other management systems that may be responsible for configuring and retrieving information from the MA device. Such systems, where available, can perform an important role in transferring the Preconfiguration Information to the MA or enabling/disabling the measurement functionality of the MA. The granularity of data transmitted in each operation of the Control and Report Protocols is not dictated by the Information Model. For example, the Instruction object may be delivered in a single operation. Alternatively, Schedules and Task Configurations may be separated or even each Schedule/Task Configuration may be delivered individually. Similarly, the Information Model does not dictate whether data is read, write, or read/write. For example, some Control Protocols may have the ability to read back Configuration and Instruction Information that has been previously set on the MA. Lastly, while some protocols may simply overwrite information (for example, refreshing the entire Instruction Information), other protocols may have the ability to update or delete selected items of information.
The information modeled by the six aspects of the Information Model is supported by a number of common information objects. These objects are also described later in this document and are comprised of: a. Schedules. A set of Schedules tells the MA to execute Actions. An Action of a Schedule leads to the execution of a Task. Without a Schedule, no Task (including measurements or reporting or communicating with the Controller) is ever executed. Schedules are used within the Instruction to specify what Tasks should be performed, when, and how to direct their results. A Schedule is also used within the Preconfiguration and Configuration Information in order to execute the Task or Tasks required to communicate with the Controller. A specific Schedule can only be active once. Attempts to start a Schedule while the same Schedule is still running will fail. b. Channels. A set of Channel objects are used to communicate with a number of endpoints (i.e., the Controller and Collectors). Each Channel object contains the information required for the communication with a single endpoint such as the target location and security details. c. Task Configurations. A set of Task Configurations is used to configure the Tasks that are run by the MA. This includes the registry entries for the Task and any configuration parameters, represented as Task Options. Task Configurations are referenced from a Schedule in order to specify what Tasks the MA should execute. d. Events. A set of Event objects that can be referenced from the Schedules. Each Schedule always references exactly one Event object that determines when the Schedule is executed. An Event object specifies either a singleton or a series of Events that indicate when Tasks should be executed. A commonly used kind of Event object is the Timing object. For Event objects specifying a series of Events, it is generally a good idea to configure an end time and to refresh the end time as needed to ensure that MAs that lose connectivity to their Controller do not continue executing Schedules forever. Figure 1 illustrates the structure in which these common information objects are referenced. The references are achieved by each object (Task Configuration, Event) being given a short textual name that is used by other objects. The objects shown in parenthesis are part of the internal object structure of a Schedule. Channels are not shown in the diagram since they are only used as an option by selected Task Configurations but are similarly referenced using a short text name.
Schedule |-- triggered by --> Event | |-- executes --> Action 1 | |-- using --> Task Configuration | | | `-- feeding to --> Destination Schedule : : `-- executes --> Action N |-- using --> Task Configuration | `-- feeding to --> Destination Schedule Figure 1: Relationship between Schedules, Events, Actions, Task Configurations, and Destination Schedules The primary function of an MA is to execute Schedules. A Schedule, which is triggered by an Event, executes a number of Actions. An Action refers to a configured Task, and it may feed results to a Destination Schedule. Both Actions and configured Tasks can provide parameters, represented as Action Options and Task Options. Tasks can implement a variety of different functions. While in terms of the Information Model, all Tasks have the same structure, it can help conceptually to think of different Task categories: 1. Measurement Tasks measure some aspect of network performance or traffic. They may also capture contextual information from the MA device or network interfaces such as the device type or interface speed. 2. Data Transfer Tasks support the communication with a Controller and Collectors: A. Reporting Tasks report the results of Measurement Tasks to Collectors B. One or more Control Tasks implement the Control Protocol and communicate with the Controller 3. Data Analysis Tasks can exist to analyze data from other Measurement Tasks locally on the MA. 4. Data Management Tasks may exist to cleanup, filter, or compress data on the MA such as Measurement Task results.
Figure 1 indicates that Actions can produce data that is fed into Destination Schedules. This can by used by Actions implementing Measurement Tasks to feed measurement results to a Schedule that triggers Actions implementing Reporting Tasks. Data fed to a Destination Schedule is consumed by the first Action of the Destination Schedule if the Destination Schedule is using the sequential or pipelined execution mode, and it is consumed by all Actions of the Destination Schedule if the Destination Schedule is using parallel execution mode.
It can be seen that these Channels, Schedules, and Task Configurations for the initial communication between the MA and its Controller are no different in terms of the Information Model to any other Channel, Schedule, or Task Configuration that might execute a Measurement Task or report the measurement results (as described later). The MA may be preconfigured with an MA-ID or may use a Device ID in the first Controller contact before it is assigned an MA-ID. The Device ID may be a Media Access Control (MAC) address or some other device identifier expressed as a URI. If the MA-ID is not provided at this stage, then it must be provided by the Controller during Configuration.
the specified communication Schedule with the Controller and the duration for which the system is willing to tolerate continued operation with potentially stale Instruction Information. While Preconfiguration Information is persistent upon a device reset or power cycle, the persistency of the Configuration Information may be device dependent. Some devices may revert back to their preconfiguration state upon reboot or factory reset, while other devices may store all Configuration and Instruction Information in persistent storage. A Controller can check whether an MA has the latest Configuration and Instruction Information by examining the Capability and Status Information for the MA.
ma-config-measurement-point: An optional identifier for the measurement point indicating where the Measurement Agent is located on a path (see [RFC7398] for further details). ma-config-report-agent-id: An optional flag indicating whether the Agent Identifier (ma-config-agent-id) is included in reports. The default value is true. ma-config-report-group-id: An optional flag indicating whether the Group-ID (ma-config-group-id) is included in reports. The default value is false. ma-config-report-measurement-point: An optional flag indicating whether the measurement point (ma-config-measurement-point) should be included in reports. The default value is false. ma-config-controller-timeout: A timer is started after each successful contact with a Controller. When the timer reaches the controller-timeout (measured in seconds), an Event is raised indicating that connectivity to the Controller has been lost (see ma-controller-lost-obj).
The Instruction supports the execution of all Tasks on the MA except those that deal with communication with the Controller (specified in Configuration or Preconfiguration Information). The Tasks are configured in Instruction Task Configurations and included by reference in the Actions of Instruction Schedules that specify when to execute them. The results can be communicated to other Schedules, or a Task may implement a Reporting Protocol and communicate results over Report Channels. Suppression is used to temporarily stop the execution of new Tasks as specified by the Instruction Schedules (and optionally to stop ongoing Tasks). A Task Configuration is used to configure the mandatory and optional parameters of a Task. It also serves to instruct the MA about the Task including the ability to resolve the Task to an executable and to specify the schema for the Task parameters. A Report Channel defines how to communicate with a single remote system specified by a URL. A Report Channel is used to send results to a single Collector but is no different in terms of the Information Model to the Control Channel used to transfer information between the MA and the Controller. Several Report Channels can be defined to enable results to be split or duplicated across different destinations. A single Channel can be used by multiple (reporting) Task Configurations to transfer data to the same Collector. A single Reporting Task Configuration can also be included in multiple Schedules. For example, a single Collector may receive data at three different cycle rates, with one Schedule reporting hourly, another reporting daily, and a third specifying that results should be sent immediately 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. Instruction Schedules specify which Actions to execute according to a given triggering Event. An Action extends a configured Task with additional specific parameters. An Event can trigger the execution of a single Action, or it can trigger a repeated series of Actions. The Schedule also specifies how to link output data from Tasks to other Schedules. Measurement Suppression information is used to override the Instruction Schedule and temporarily stop measurements or other Tasks from running on 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. It should be noted that Control Schedules and Tasks cannot be suppressed as evidenced by the lack of Suppression information in the Configuration. The Control Schedule must only reference Tasks listed as Control Tasks (i.e., within the Configuration Information). A single Suppression object is able to enable/disable a set of Instruction Tasks that are tagged for Suppression. This enables fine-grained control on which Tasks are suppressed. Suppression of both matching Actions and Measurement Schedules is supported. Support for disabling specific Actions allows malfunctioning or misconfigured Tasks or Actions that have an impact on a particular part of the network infrastructure (e.g., a particular Measurement Peer) to be targeted. Support for disabling specific Schedules allows for particularly heavy cycles or sets of less essential Measurement Tasks to be suppressed quickly and effectively. Note that Suppression has no effect on either Controller Tasks or Controller Schedules. Suppression stops new Tasks from executing. In addition, the Suppression information also supports an additional boolean that is used to select whether ongoing Tasks are also to be terminated. 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 Task Configurations will be relatively static. The Instruction 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 Suppression command without removing the existing Instruction Schedules that would continue to apply after the Suppression expires or is removed. In terms of the communication between the MA and its Controller, this can reduce the data overhead. It also encourages the reuse of the same standard Task Configurations and Reporting Channels to help ensure consistency and reduce errors.
ma-suppression-end: The optional Event indicating when Suppression ends. If not present, the Suppression does not have a defined end, i.e., the Suppression remains for an indefinite period of time. ma-suppression-match: An optional and possibly empty unordered set of match patterns. The Suppression will apply to all Schedules (and their Actions) that have a matching value in their ma-schedule-suppression-tags and all Actions that have a matching value in their ma-action-suppression-tags. Pattern matching is done using a glob style pattern (see below). ma-suppression-stop-running: An optional boolean indicating whether Suppression will stop any running matching Schedules or Actions. The default value for this boolean is false. Glob style pattern matching is following POSIX.2 fnmatch() [POSIX.2] without special treatment of file paths: * matches a sequence of characters ? matches a single character [seq] matches any character in seq [!seq] matches any character not in seq A backslash followed by a character matches the following character. In particular: \* matches * \? matches ? \\ matches \ A sequence seq may be a sequence of characters (e.g., [abc]) or a range of characters (e.g., [a-c]).