RFC 8193
Information Model for Large-Scale Measurement Platforms (LMAPs)
RFC 8193 (Part 1 of 12) ✨
Okay bestie, let's start with the title block 💅 This is RFC 8193, called Information Model for Large-Scale Measurement Platforms (LMAPs) 🦋. It's a Standards Track document dated August 2017, with ISSN 2070-1721. The authors are T. Burbridge and P. Eardley from BT, M. Bagnulo from Universidad Carlos III de Madrid, and J. Schoenwaelder from Jacobs University Bremen 🫶. The title block doesn't list anything it obsoletes or updates.
Abstract 🌸
Okay so this information model is all about the Measurement Agent inside an LMAP framework 🧚. It lays out the information that's configured or preconfigured on the Measurement Agent, plus the information that gets exchanged with a Controller or Collector. The whole point is to give you a view of the Measurement Agent that doesn't care about the protocol or the device, so it can be built with one or more Control and Report Protocols. It's giving clean architecture ✨
Status of This Memo 🎀
This is an Internet Standards Track document 💖
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 📚
For the current status, any errata, and how to give feedback, go to 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) as they're in effect on the date of publication. Please actually read these, because they explain your rights and restrictions for this document 🙈 If you extract Code Components from this document, they must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⭐
Table of Contents 🍓
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 . . . . . . . . . . . . . . . . . . . . . . . 531. Introduction 🌈
Okay, so a large-scale measurement platform is a bunch of components working together to take measurements from a huge number of vantage points 🧚 A typical use case is running broadband measurements [RFC7536]. The main components are the Measurement Agents (MAs), the Controller(s), and the Collector(s).
The MAs are the ones actually doing the measuring 💅 Each MA is controlled by exactly one Controller at a time, and the Collectors gather up the results the MAs produce. Here's the vibe: normal operation starts with the Controller telling a set of one or more MAs to run a set of one or more Measurement Tasks at a certain point in time. The MAs carry out those instructions, and once they're done, they report the results to one or more Collectors ✨ The overall framework is described in detail in [RFC7594] 📚
A large-scale measurement platform basically involves three types of protocols 🦋 First up is a Control Protocol (or Protocols) between a Controller and the MAs. Then there's a Report Protocol (or Protocols) between the MAs and the Collector(s). Last, there are several measurement protocols between the MAs and Measurement Peers (MPs), which are what actually perform the measurements. On top of that, some information has to be configured on the MA before it communicates with a Controller at all 🙈
This document defines the Information Model for both the Control and Report Protocols, along with the Preconfiguration Information that the MA needs before it talks to the Controller. Together, we call this the LMAP Information Model 💖 The measurement protocols are out of scope here, so we're not doing those today 🫶
As defined in [RFC3444], the LMAP Information Model describes the concepts in a large-scale measurement platform at a high level of abstraction. It doesn't depend on any specific implementation or any actual protocol used to exchange the information 🌸 The idea is that this model can be used with different protocols, in different measurement platform architectures, and across different types of MA devices (for example, a home gateway, a smartphone, a PC, or a router) 💜 A YANG data model that implements the Information Model is in [RFC8194].
Defining an Information Model is useful for a few reasons, bestie 👑
- To guide the standardization of one or more Control and Report protocols and data models
- To enable high-level interoperability between different Control and Report Protocols by making it easier to translate between their respective data models, so a Controller can instruct sub-populations of MAs that use different protocols
- To agree on what information needs to be held by an MA and passed over the Control and Report interfaces, so it can support the functionality described in the LMAP framework
- To let existing protocols and data models be assessed for their suitability as part of a large-scale measurement system 🎀
2. Requirements Language 💜
Okay, the capital-letter words matter, so listen up 🫶 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, exactly as shown here 💅
3. Notation 📐✨
okay bestie, so this section is basically the cheat sheet for how the Information Model writes its objects 🧠💖. It's kinda like a programming language, so you can read the object definitions without getting lost. 🦋
Optional properties get wrapped in square brackets, [ ], which is giving "maybe, maybe not" energy 🤷♀️. List properties use two numbers in angle brackets, <m..n>. The m is the minimum number of values and the n is the maximum, so <1..*> means at least one, no upper limit, literally no ceiling 🙌. The * symbol for n means no upper bound at all, so it's the "as many as you want" 👑.
Next up are the base types. These are the building blocks everything else is made from, so pay attention, it's lowkey the most important part 💅.
int A type representing signed or unsigned integer numbers.
This Information Model does not define a precision nor
does it make a distinction between signed and unsigned
number ranges. This type is also used to represent
enumerations.
boolean A type representing a boolean value.
string A type representing a human-readable string consisting of
a (possibly restricted) subset of Unicode and ISO/IEC
10646 [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.So the vibe is: int covers signed and unsigned numbers, and it doesn't pin down a precision or care about the signed/unsigned range split. That same type is also used for enums 🔢. boolean is just true or false, no drama 🫶.
For string, it's human-readable text made from a (possibly restricted) subset of Unicode and ISO/IEC 10646 [ISO.10646] characters 🌈. Then there's datetime, which is a date and time in the Gregorian calendar, and the datetime format MUST conform to RFC 3339 [RFC3339]. No skipping that, periodt 📅💜.
uuid is a Universally Unique IDentifier as defined in RFC 4122 [RFC4122]. These values are expected to stay unique inside one installation of a large-scale measurement system 🦋✨. uri is a Uniform Resource Identifier from STD 66 [RFC3986] 🔗.
ip-address covers IP addresses, and it supports both IPv4 and IPv6 🌸. counter is a non-negative integer that only ever goes up, but it can have discontinuities and isn't expected to survive restarts 🔄. Kinda relatable honestly 😭.
credentials is an opaque type for the stuff a cryptographic mechanism needs to secure communication 🔐. Data models have to expand it as needed for whatever security protocols are in use, so it's a placeholder with homework attached 📝. And data is an opaque type for data obtained from measurements 📊.
Last thing, and it's important: names of objects are generally assumed to be unique within an implementation 💅🎀.
4. LMAP Information Model ✨
Okay bestie, this section is all about the info a Measurement Agent (MA) stores, receives, or sends within the LMAP framework [RFC7594] 🧚. Some parts of this model also matter for the Controller, the Collector, and any device management system that preconfigures the MA, so it's a whole group project 🫶. Those systems send and receive the info over interfaces using a data model, which is how the protocols actually move everything around.
The model is split into six aspects 🌈. The first reason for splitting it up is that it's easier for readers to follow. The second is that the groupings are expected to line up with different protocols, or with different transmissions inside those protocols. So it's basically organized for both humans and machines, iconic ✨
- Preconfiguration Information. This is stuff loaded onto the MA before it talks to anyone else in the LMAP architecture (the Controller, the Collector, and Measurement Peers). It covers how to reach a Controller and whether the device is allowed to take part as an MA 🌸
- Configuration Information. This updates the Preconfiguration Information when the MA registers or talks to the Controller later on. It also sets up extra MA parameters (not the Measurement Tasks it should run) that weren't required for the first chat between the MA and a Controller 💜
- Instruction Information. This is what the MA gets from the Controller about which Measurement Tasks to execute 🔥. It includes the Task execution Schedules (except the Controller communication Schedule, which comes in as Configuration or Preconfiguration Information), plus related stuff like Task Configuration, communication Channels to Collectors, and Event information. It also has Task Suppression information, which is used to override normal Task execution 🙈
- Logging Information. This is what the MA sends back to the Controller about the results of any configuration operations, plus error and Status Information from the MA doing its thing 💀
- Capability and Status Information. This is the general status and capabilities of the MA. For example, which measurements the device supports 🦋
- Reporting Information. This is what the MA sends to one or more Collectors, including measurement results and the context they were collected in 🍓
Okay but wait, there's more 👀 The MA can also hold extra info that isn't covered here, and it can be transferred to or from other systems, including the Controller and Collector, if needed. One example is subscriber or line information that a Task extracts and the MA reports to a Collector during reporting ✨
Also, the MA might talk to other management systems that are in charge of configuring it and pulling info back off it 💅. When those systems exist, they can be a big help by moving the Preconfiguration Information over to the MA, or by turning the measurement functionality on or off.
The Information Model doesn't decide how much data goes in each operation of the Control and Report Protocols, so the granularity is totally up to the protocol 🎀. For example, the Instruction object can arrive all in one go. Or the Schedules and Task Configurations can be sent separately, or even one Schedule or Task Configuration at a time. The model also doesn't say whether data is read-only, write-only, or read/write. Some Control Protocols can read back the Configuration and Instruction Information that was set on the MA earlier 🧚. And while some protocols just overwrite everything (like refreshing the entire Instruction Information), others can update or delete individual items. Different vibes, same model 💖
The six aspects are built on a bunch of shared information objects, which are described later in the document. There are four of them:
- a. Schedules. A set of Schedules tells the MA to execute Actions. An Action in a Schedule leads to a Task getting executed. Without a Schedule, no Task ever runs, and that includes measurements, reporting, and talking to the Controller 😭. Schedules are used inside the Instruction to say what Tasks should run, when they should run, and where their results should go. A Schedule is also used inside the Preconfiguration and Configuration Information to run the Task or Tasks needed to talk to the Controller. A specific Schedule can only be active once. If you try to start a Schedule that's still running, it will fail 🚫
- b. Channels. A set of Channel objects is used to talk to a number of endpoints (the Controller and Collectors). Each Channel object holds everything needed to communicate with one endpoint, like the target location and security details 🔐
- c. Task Configurations. A set of Task Configurations is used to configure the Tasks the MA runs. This includes the registry entries for the Task and any configuration parameters, which are represented as Task Options. Schedules reference Task Configurations to say which Tasks the MA should execute 🌟
- d. Events. A set of Event objects that Schedules can reference. Every Schedule always references exactly one Event object, and that Event object decides when the Schedule runs. An Event object can specify a singleton or a series of Events that say when Tasks should run. A commonly used kind is the Timing object. For Event objects that specify a series, it's generally a good idea to set an end time and refresh it as needed. That way, MAs that lose connectivity to their Controller won't keep running Schedules forever 🕰️
Figure 1 shows how these common information objects reference each other. Each object (Task Configuration, Event) gets a short textual name, and other objects use that name to point to it 🧩. The objects in parentheses are part of the internal object structure of a Schedule. Channels aren't shown in the diagram, since only some Task Configurations use them as an option, but they're referenced by a short text name too.
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 SchedulesThe main job of an MA is to execute Schedules 💪. A Schedule gets triggered by an Event and runs a bunch of Actions. Each Action refers to a configured Task, and it can feed its results to a Destination Schedule. Both Actions and configured Tasks can take parameters, called Action Options and Task Options.
Tasks can do all sorts of things 🌈. In terms of the Information Model, every Task has the same structure, but it helps to think of them in categories:
- Measurement Tasks measure some part of network performance or traffic. They can also grab contextual info from the MA device or its network interfaces, like the device type or interface speed 📊
- Data Transfer Tasks support 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 🎛️
- Data Analysis Tasks can exist to analyze data from other Measurement Tasks, locally on the MA 🔍
- Data Management Tasks may exist to clean up, filter, or compress data on the MA, such as Measurement Task results 🧹
Figure 1 also shows that Actions can produce data that gets fed into Destination Schedules 💫. This lets Actions running Measurement Tasks feed their results to a Schedule that triggers Actions running Reporting Tasks. Data fed to a Destination Schedule gets consumed by the first Action of that Destination Schedule if it's using the sequential or pipelined execution mode. If it's using parallel execution mode, the data gets consumed by all of its Actions instead 🦄
4.1. Preconfiguration Information ✨
okay so this is the bare minimum an MA needs preconfigured so it can actually talk to a Controller during registration 💖. Some of these preconfig bits get repeated in the Configuration Information so a Controller can update them later 🔄. Some stuff is totally outside LMAP's control, like the device identifier and device security credentials 🔐.
The Preconfiguration Information needs a URL for the initial Controller, which is where Configuration Information can be communicated from, plus the security info needed for that chat. That includes the Controller's certificate (or the certificate of the Certification Authority that issued the Controller's certificate) 📜. All of this gets wrapped up as a Channel 🦋. You can give multiple Channels, but they all have to be tied to a single Controller, like over different interfaces or network protocols 🫶.
Where the MA pulls info from the Controller, the Preconfiguration Information also needs the timing of that communication and what the communication is about, like the protocol and the data being transferred ⏰. The timing is represented as an Event that invokes a Schedule, and that Schedule runs the Task(s) in charge of talking to the Controller 📅. These Task(s) are what implement the Control Protocol between the MA and the Controller, and they use the Channel info 🧚. The Task(s) can also take extra parameters, defined by a Task Configuration ⚙️.
Even when info is pushed to the MA from the Controller (instead of pulled), a Schedule still has to be supplied 🙈. In this case the Schedule just runs a Controller listener Task when the MA starts up 🌸. A Channel is still required so the MA can set up secure communication with the Controller 🔒.
Honestly, the Channels, Schedules, and Task Configurations used for this first contact are no different, as far as the Information Model goes, from any other Channel, Schedule, or Task Configuration that runs a Measurement Task or reports the results (more on that later) 💅.
The MA may be preconfigured with an MA-ID, or it may use a Device ID on the first Controller contact before it has been 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 isn't provided at this stage, the Controller has to provide it during Configuration 👑.
4.1.1. Definition of ma-preconfig-obj 🎀
object {
[uuid ma-preconfig-agent-id;]
ma-task-obj ma-preconfig-control-tasks<1..*>;
ma-channel-obj ma-preconfig-control-channels<1..*>;
ma-schedule-obj ma-preconfig-control-schedules<1..*>;
[uri ma-preconfig-device-id;]
credentials ma-preconfig-credentials;
} ma-preconfig-obj;The ma-preconfig-obj describes the info the MA needs in order to bootstrap communication with a Controller 🥰. It's made up of these elements:
ma-preconfig-agent-id: an optional UUID uniquely identifying the Measurement Agent 🪪.ma-preconfig-control-tasks: an unordered set of Task objects 🗂️.ma-preconfig-control-channels: an unordered set of Channel objects 🦋.ma-preconfig-control-schedules: an unordered set of scheduling objects 📅.ma-preconfig-device-id: an optional identifier for the device 📱.ma-preconfig-credentials: the security credentials used by the Measurement Agent 🔐.
4.2. Configuration Information 💜
Whenever the MA and the Controller talk, whether during registration or any later point (or the other way around), the choice of Controller can change 🔁. So can the timing of communication and the parameters for the communication Task(s). Those changes get captured by the Channels, Schedules, and Task Configurations objects 🧩. For example, the preconfigured Controller (specified as a Channel or Channels) can be overridden with a more suitable Controller, based on the MA device type, its location, or the characteristics of the network (like the access technology type or broadband product) 🌍. The initial communication Schedule can also be swapped for one that better fits routine communication between the MA and the Controller 🗓️.
Some Control Protocols only use a single Schedule, but others use several Schedules (and related Data Transfer Tasks) 🧠. Those can update the Configuration Information, transfer the Instruction Information, transfer Capability and Status Information, and send other stuff to the Controller, like log or error notifications 📨. You can also use multiple Channels to talk to the same Controller over multiple interfaces, like sending Logging Information over a different network 🛤️.
The MA also gets extra info that's about the MA itself, not about the measurements it runs or how it reports results 🤖. Assigning an identifier to the Measurement Agent is mandatory 🚨. If the Measurement Agent Identifier wasn't provided during preconfiguration, the Controller has to give one during Configuration 🪄. A Group-ID is optional, and it identifies a group of interest that the MA belongs to 🫧. The group could be an ISP, a broadband product, a technology, a market classification, a geographic region, or any combination of those things 🗺️. Extra flags control whether the MA-ID or the Group-ID is included in Reports 🏷️. Reporting a Group-ID without the MA-ID may let the MA stay anonymous, which can be especially handy for stopping mobile MA devices from being tracked 🕵️♀️.
An MA can also be configured to stop executing any Instruction Schedule if the Controller is unreachable 🛑. It's a fail-safe that stops Measurement and other Tasks from running when there's doubt that the Instruction Information is still valid 🧯. It's represented as a time window in seconds since the last communication with the Controller 🕰️. Once that window passes, an Event is generated that can trigger suspension of the Instruction Schedules ⏸️. The right window length depends on the communication Schedule with the Controller, plus how long the system is willing to keep running on potentially stale Instruction Information 🥱.
Preconfiguration Information sticks around through a device reset or power cycle 🔋. The persistence of the Configuration Information, though, can depend on the device 💾. Some devices go back to their preconfigured state on reboot or factory reset, while others keep all their Configuration and Instruction Information in persistent storage 🧼. A Controller can check whether an MA has the latest Configuration and Instruction Information by looking at the MA's Capability and Status Information 🔍.
4.2.1. Definition of ma-config-obj 🍓
object {
uuid ma-config-agent-id;
ma-task-obj ma-config-control-tasks<1..*>;
ma-channel-obj ma-config-control-channels<1..*>;
ma-schedule-obj ma-config-control-schedules<1..*>;
credentials ma-config-credentials;
[string ma-config-group-id;]
[string ma-config-measurement-point;]
[boolean ma-config-report-agent-id;]
[boolean ma-config-report-group-id;]
[boolean ma-config-report-measurement-point;]
[int ma-config-controller-timeout;]
} ma-config-obj;The ma-config-obj is made up of these elements:
ma-config-agent-id: a UUID uniquely identifying the Measurement Agent 🪪.ma-config-control-tasks: an unordered set of Task objects 🗂️.ma-config-control-channels: an unordered set of Channel objects 🦋.ma-config-control-schedules: an unordered set of scheduling objects 📅.ma-config-credentials: the security credentials used by the Measurement Agent 🔐.ma-config-group-id: an optional identifier of the group of Measurement Agents this Measurement Agent belongs to 🫧.ma-config-measurement-point: an optional identifier for the measurement point, showing where the Measurement Agent sits on a path (see [RFC7398] for further details) 📍.ma-config-report-agent-id: an optional flag for 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 for 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 for whether the measurement point (ma-config-measurement-point) should be included in reports. The default value is false 🙅♀️.ma-config-controller-timeout: a timer starts after each successful contact with a Controller. When the timer reaches the controller-timeout (measured in seconds), an Event is raised saying connectivity to the Controller has been lost (seema-controller-lost-obj) 🚨.
4.3. Instruction Information ✨
Okay bestie, the Instruction Information Model has four sub-elements 💅:
- Instruction Task Configurations
- Report Channels
- Instruction Schedules
- Suppression
The Instruction is what runs all the Tasks on the MA 🧚, except the ones that handle talking to the Controller (those live in Configuration or Preconfiguration Information 🫶). Tasks get set up in Instruction Task Configurations, then get pulled in by reference into the Actions of Instruction Schedules that say when to run them 🔥. Results can get passed along to other Schedules, or a Task can use a Reporting Protocol and send its results out over Report Channels 🌈. Suppression is the pause button 🦋: it temporarily stops new Tasks from starting, as the Instruction Schedules say (and it can optionally stop ongoing Tasks too).
A Task Configuration is how you set up a Task's mandatory and optional parameters 💖. It also tells the MA about the Task, like how to resolve it into something executable and what schema the Task parameters have to follow ✨.
A Report Channel is how you talk to one single remote system, identified by a URL 🎀. It sends results to a single Collector, but in terms of the Information Model it's basically the same thing as the Control Channel that moves info between the MA and the Controller, so no drama there 💅. You can define several Report Channels to split or duplicate results across different destinations 🍓. One Channel can be used by several (reporting) Task Configurations to send data to the same Collector, and one reporting Task Configuration can show up in multiple Schedules too 🦋. For example, one Collector could get data at three different cycle rates: one Schedule reporting hourly, another reporting daily, and a third saying results should be sent immediately for on-demand Measurement Tasks 😭. Or you could use multiple Report Channels so Measurement Task results go to different Collectors 🌸. The Channel element gets its full details later, since a bunch of objects share it 🫶.
Instruction Schedules are where you say which Actions to run for a given triggering Event ⭐. An Action is just a configured Task with some extra specific parameters layered on top 💜. An Event can kick off a single Action, or set off a whole repeated series of them 🔁. The Schedule also says how to link output data from Tasks over to other Schedules 🧚.
Measurement Suppression info is the override 👑: it can stop measurements (or other Tasks) from running on the MA for a set period or indefinitely 🛑. Yes, you could just remove measurements from the Measurement Schedule to stop them, but splitting Suppression out into its own info means it can get updated on the MA on a different timing cycle or protocol implementation than the Measurement Schedule 💅. Plus it's way easier for a human operator to slap on a temporary explicit Suppression than to switch to a reduced Schedule and then roll it all back later 🙈.
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). Don't try to suppress the Controller's stuff, it's not happening 💀.
A single Suppression object can enable or disable a whole set of Instruction Tasks that are tagged for Suppression 🎀. That's the fine-grained control we love to see 😍. Suppression works on both matching Actions and Measurement Schedules 🌈. Turning off specific Actions is perfect when a Task or Action is misbehaving or misconfigured and hitting a particular part of the network, like one particular Measurement Peer 🚨. Turning off specific Schedules is the move when you've got really heavy cycles or a bunch of less essential Measurement Tasks you want gone fast ⚡. Just know that Suppression has no effect on Controller Tasks or Controller Schedules 🙅♀️.
Suppression stops new Tasks from executing 🛑. The Suppression info also has an extra boolean that decides whether ongoing Tasks get terminated too 🔥.
Unsuppression happens one of two ways 🦋: either you overwrite the Measurement Suppression info (like flipping 'enabled' to False), or you give it an end time so the Suppression stops being in effect past that point ⏰.
The whole reason for these four separate elements is so each part of the Information Model can change without messing with the other three 💖. Like, the Report Channels and the set of Task Configurations are expected to be pretty static 🪨, but the Instruction Schedule is way more dynamic, since the measurement panel and test frequency get tweaked for different business goals 📈. Another win: measurements can be suppressed with a Suppression command without removing the existing Instruction Schedules, which keep applying once the Suppression expires or gets removed 🙌. In terms of MA-to-Controller communication, that cuts down on data overhead 📉. It also encourages reusing the same standard Task Configurations and Reporting Channels, which helps keep everything consistent and cuts down on errors 🫶✨.
4.3.1. Definition of ma-instruction-obj 💅
object {
ma-task-obj ma-instruction-tasks<0..*>;
ma-channel-obj ma-instruction-channels<0..*>;
ma-schedule-obj ma-instruction-schedules<0..*>;
[ma-suppression-obj ma-instruction-suppressions<0..*>;]
} ma-instruction-obj;An ma-instruction-obj is made up of these elements 🧚:
ma-instruction-tasks: A possibly empty unordered set of Task objects.ma-instruction-channels: A possibly empty unordered set of Channel objects.ma-instruction-schedules: A possibly empty unordered set of Schedule objects.ma-instruction-suppressions: An optional possibly empty unordered set of Suppression objects.
4.3.2. Definition of ma-suppression-obj 🦋
object {
string ma-suppression-name;
[ma-event-obj ma-suppression-start;]
[ma-event-obj ma-suppression-end;]
[string ma-suppression-match<0..*>;]
[boolean ma-suppression-stop-running;]
} ma-suppression-obj;The ma-suppression-obj is what controls the Suppression of Schedules or Actions 🎀. It's made up of these elements:
ma-suppression-name: A name uniquely identifying a Suppression.ma-suppression-start: The optional Event indicating when Suppression starts. If it's not present, the Suppression starts immediately, i.e., as if the value would be'immediate'⏩.ma-suppression-end: The optional Event indicating when Suppression ends. If it's not present, the Suppression doesn't have a defined end, i.e., it sticks around for an indefinite period of time ♾️.ma-suppression-match: An optional and possibly empty unordered set of match patterns. The Suppression applies to all Schedules (and their Actions) that have a matching value in theirma-schedule-suppression-tags, and all Actions that have a matching value in theirma-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 follows POSIX.2 fnmatch() [POSIX.2] without any 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 seqA 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]) 🧚✨.
4.4. Logging Information ✨
okay so the MA can tell the Controller how its Configuration or Instruction communications went 📨 and it can also keep operational logs as it runs 🗒️. It can report when its Capabilities change too. the cute part is that all of this reporting is done the exact same way as scheduling any other Task 💅. we don't treat a Measurement Task that does active or passive network measurement any differently from one that just grabs static or dynamic info from the MA, like Capabilities or Logging Information 🤷♀️. you can set up one or more logging Tasks to capture subsets of the Logging Information. then Schedules run those logging Tasks, and the Schedules also say that the resulting data gets sent back over the Controller Channels 🚀.
the Logging Information falls into three categories:
- Success, failure, or warning messages about information updates from the Controller 📬. a failure can happen if the MA can't receive or parse the Controller's message, or if it just can't do what it was told 😬. some examples:
"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""'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"
- Operational updates from the MA 🛠️. some examples:
"Out of memory: cannot record result""Collector 'collector.example.com' not responding""Unexpected restart""Suppression timeout""Failed to execute Measurement Task Configuration H"
- Status updates from the MA 🌸. some examples:
"Device interface added: eth3""Supported measurements updated""New IP address on eth0: xxx.xxx.xxx.xxx"
this Information Model doc doesn't spell out the exact format of Logging Information, because it's mostly protocol-specific and MA-specific 🙈. still, there's some common stuff we can pin down.
4.4.1. Definition of ma-log-obj
object {
uuid ma-log-agent-id;
datetime ma-log-event-time;
int ma-log-code;
string ma-log-description;
} ma-log-obj;the ma-log-obj is the generic shape of a logging object 🧩. it has these elements:
ma-log-agent-id: a uuid that uniquely identifies the Measurement Agent 🆔.ma-log-event-time: the date and time of the Event that the logging object reports ⏰.ma-log-code: a machine-readable code that describes the Event 🤖.ma-log-description: a human-readable description of the Event 💬.
4.5. Capability and Status Information ✨
the MA holds Capability Information that a Controller can ask for 🧰. Capabilities include the device interface details that Measurement Tasks can use, plus the set of Measurement Tasks/Roles (named by registry entries) that are actually installed or available on the MA 💜. Status Information covers things like when the MA last did an operation, such as contacting the Controller or producing Reports 🕰️.
4.5.1. Definition of ma-capability-obj
object {
string ma-capability-hardware;
string ma-capability-firmware;
string ma-capability-version;
[string ma-capability-tags<0..*>;]
[ma-capability-task-obj ma-capability-tasks<0..*>;]
} ma-capability-obj;the ma-capability-obj tells you about the Capabilities of the Measurement Agent 🦋. its elements are:
ma-capability-hardware: a description of the hardware of the device the Measurement Agent runs on 🔧.ma-capability-firmware: a description of the firmware of the device the Measurement Agent runs on 💾.ma-capability-version: the version of the Measurement Agent 🏷️.ma-capability-tags: an optional unordered set of tags that give extra info about the Capabilities of the Measurement Agent 🎀.ma-capability-tasks: an optional unordered set of capability objects, one for each supported Task 📋.
4.5.2. Definition of ma-capability-task-obj
object {
string ma-capability-task-name;
ma-registry-obj ma-capability-task-functions<0..*>;
string ma-capability-task-version;
} ma-capability-task-obj;the ma-capability-task-obj tells you about the capability of one Task 🌈. its elements are:
ma-capability-task-name: a name that uniquely identifies a Task 🪪.ma-capability-task-functions: a possibly empty unordered set of registry entries that name the functions this Task implements ⚙️.ma-capability-task-version: the version of the Measurement Task 📌.
4.5.3. Definition of ma-status-obj
object {
uuid ma-status-agent-id;
[uri ma-status-device-id;]
datetime ma-status-last-started;
ma-status-interface-obj ma-status-interfaces<0..*>;
[ma-status-schedule-obj ma-status-schedules<0..*>;]
[ma-status-suppression-obj ma-status-suppressions<0..*>;]
} ma-status-obj;the ma-status-obj gives you Status Information about the Measurement Agent 🌟. its elements are:
ma-status-agent-id: a uuid that uniquely identifies the Measurement Agent 🆔.ma-status-device-id: a URI that identifies the device 📍.ma-status-last-started: the date and time the Measurement Agent last started 🚦.ma-status-interfaces: an unordered set of network interfaces that are available on the device 🔌.ma-status-schedules: an optional unordered set of status objects, one for each Schedule 🗓️.ma-status-suppressions: an optional unordered set of status objects, one for each Suppression 🤫.
4.5.4. Definition of ma-status-schedule-obj
object {
string ma-status-schedule-name;
string ma-status-schedule-state;
int ma-status-schedule-storage;
counter ma-status-schedule-invocations;
counter ma-status-schedule-suppressions;
counter ma-status-schedule-overlaps;
counter ma-status-schedule-failures;
datetime ma-status-schedule-last-invocation;
[ma-status-action-obj ma-status-schedule-actions<0..*>;]
} ma-status-schedule-obj;the ma-status-schedule-obj gives you Status Information about a Schedule 🎬. its elements are:
ma-status-schedule-name: the name of the Schedule this status object is about 🏷️.ma-status-schedule-state: the state of the Schedule 🚦. the value'enabled'means the Schedule is currently enabled ✅. the value'suppressed'means it's currently suppressed 🙅♀️. the value'disabled'means it's currently disabled 😴. the value'running'means it's currently running 🏃♀️.ma-status-schedule-storage: the amount of secondary storage (for example, space allocated in a file system) that holds temporary data for the Schedule, in bytes 💽. this object reports the physical storage that's been allocated, not the storage used by logical data records 📦. data models should use a 64-bit integer type 🔢.ma-status-schedule-invocations: the number of invocations of this Schedule 📈. this counter doesn't include suppressed invocations, or invocations that got blocked because they overlapped with a previous invocation of this Schedule 🙅♀️.ma-status-schedule-suppressions: the number of suppressed executions of this Schedule 🤐.ma-status-schedule-overlaps: the number of executions that were prevented because they overlapped with a previous invocation of this Schedule 🔁.ma-status-schedule-failures: the number of failed executions of this Schedule 💥. a failed execution is one where at least one Action failed 🚫.ma-status-schedule-last-invocation: the date and time of the last invocation of this Schedule 🕓.ma-status-schedule-actions: an optional ordered list of status objects, one for each Action of the Schedule 📝.
4.5.5. Definition of ma-status-action-obj ✨
Okay bestie, this is the status report card for one Action in a Schedule 📋💅 Here's the whole object:
object {
string ma-status-action-name;
string ma-status-action-state;
int ma-status-action-storage;
counter ma-status-action-invocations;
counter ma-status-action-suppressions;
counter ma-status-action-overlaps;
counter ma-status-action-failures;
datetime ma-status-action-last-invocation;
datetime ma-status-action-last-completion;
int ma-status-action-last-status;
string ma-status-action-last-message;
datetime ma-status-action-last-failed-completion;
int ma-status-action-last-failed-status;
string ma-status-action-last-failed-message;
} ma-status-action-obj;The ma-status-action-obj gives you Status Information about an Action of a Schedule, and it has these elements 🦋
ma-status-action-name: the name of the Action of a Schedule this status object is about 🎀ma-status-action-state: the state of the Action 💖'enabled'means the Action is currently enabled ✨'suppressed'means the Action is currently suppressed 🙈'disabled'means the Action is currently disabled 💀'running'means the Action is currently running 🔥
ma-status-action-storage: the amount of secondary storage (like space allocated in a file system) holding temporary data for the Action, in bytes 🧚 This reports the physical storage that's allocated, not the storage used by logical data records. Data models should use a 64-bit integer type.ma-status-action-invocations: the number of invocations of this Action 📈 This counter does not include suppressed invocations, or invocations that got blocked because they overlapped with a previous invocation of this Action.ma-status-action-suppressions: the number of suppressed executions of this Action 🫥ma-status-action-overlaps: the number of executions that were prevented because they overlapped with a previous invocation of this Action 🌀ma-status-action-failures: the number of failed executions of this Action 😭ma-status-action-last-invocation: the date and time of the last invocation of this Action 🕰️ma-status-action-last-completion: the date and time of the last completion of this Action 🏁ma-status-action-last-status: the status code returned by the last execution of this Action 🔢ma-status-action-last-message: the status message produced by the last execution of this Action 💬ma-status-action-last-failed-completion: the date and time of the last failed completion of this Action 💔ma-status-action-last-failed-status: the status code returned by the last failed execution of this Action 🚨ma-status-action-last-failed-message: the status message produced by the last failed execution of this Action 📝
4.5.6. Definition of ma-status-suppression-obj 🫧
object {
string ma-status-suppression-name;
string ma-status-suppression-state;
} ma-status-suppression-obj;The ma-status-suppression-obj gives you Status Information about how a Suppression is doing 👀 It has these elements:
ma-status-suppression-name: the name of the Suppression this status object refers to 🎀ma-status-suppression-state: the state of the Suppression 💅'enabled'means the Suppression is currently enabled ✨'active'means the Suppression is currently active 🔥'disabled'means the Suppression is currently disabled 🥀
4.5.7. Definition of ma-status-interface-obj 🌐
object {
string ma-status-interface-name;
string ma-status-interface-type;
[int ma-status-interface-speed;]
[string ma-status-interface-link-layer-address;]
[ip-address ma-status-interface-ip-addresses<0..*>;]
[ip-address ma-status-interface-gateways<0..*>;]
[ip-address ma-status-interface-dns-servers<0..*>;]
} ma-status-interface-obj;The ma-status-interface-obj gives you Status Information about network interfaces, and it has these elements 🛜 The ones in brackets are optional, so don't panic if they're missing 🫶
ma-status-interface-name: a name that uniquely identifies a network interface 🪪ma-status-interface-type: the type of the network interface 🧩ma-status-interface-speed(optional): an indication of the speed of the interface, measured in bits per second 🏎️💨ma-status-interface-link-layer-address(optional): the link-layer address of the interface 📍ma-status-interface-ip-addresses(optional): an ordered list of IP addresses assigned to the interface 🧾ma-status-interface-gateways(optional): an ordered list of gateways assigned to the interface 🚪ma-status-interface-dns-servers(optional): an ordered list of DNS servers assigned to the interface 🗺️
That's the whole status trio, and it's giving complete picture energy 💖
4.6. Reporting Information 📬
At a time that a Schedule says so, the MA runs Tasks that send a set of measurement results to the Collector. These Reporting Tasks get configured to push Task results over a specified Report Channel to a Collector. 🚀
Quick heads up: Task output doesn't have to go to Channels! It can go to other Tasks on the MA instead (or as well, bestie 💅). That lets a first Measurement Task control a later one, like probing available line speed and then adjusting a video testing measurement. It also lets local processing spit out alarms, like when performance drops from earlier levels 🚨. And obviously, subsequent Tasks also include Tasks that implement the Reporting Protocol(s) and transfer data to one or more Collectors 🫶.
The Report generated by a Reporting Task is structured hierarchically so you don't end up repeating the report header and Measurement Task Configuration info over and over 🧚. The report starts with the timestamp of when it was generated on the MA, plus details about the MA, including the optional Measurement Agent Identifier and Group-ID (which are controlled by the Configuration Information) 🎀.
A lot of the report info is optional. It depends on how the Reporting Task is implemented and on any parameters defined in the Task Configuration for that Reporting Task 🌸. For example, some Reporting Tasks may choose to leave out the Measurement Task Configuration or Action parameters, while others will include them depending on whether the Controller sets a configurable parameter in the Task Configuration 💜.
A Reporting Task can send just the report header (datetime and optional Agent Identifier and/or Group-ID) if no measurement data is available 🦋. Whether it sends those empty reports again depends on the implementation of the Reporting Task and a potential Task Configuration parameter 🙈.
How the MA handles measurement data before it generates a Report, and how that data gets transferred from the MA to the Collector, is up to the implementation of the device, the MA, and/or the scheduled Tasks. The LMAP standards don't define it 💀. That includes decisions like putting limits on measurement data storage and what to do when that storage runs out. It's generally suggested that implementations running out of storage stop executing new Measurement Tasks and keep their old measurement data 😭.
No context information, like line speed or broadband product, is included in the report header 🍓. That data gets reported by individual Tasks at the time they execute. Either a Measurement Task can report contextual parameters that are relevant to that particular measurement, or specific Tasks can be used to gather a set of contextual and environmental data at certain times, independent of the Reporting Schedule ✨.
After the report header, the results are reported grouped by the different Measurement Task Configurations 🌈. Each Task section can optionally start by replicating the Measurement Task Configuration info, followed by the result headers (titles for the data columns) and the result data rows. The Options reported are the ones used for the scheduled execution of the Measurement Task. That means they include the Options from the Task Configuration plus the extra Options specified in the Action. The Action Options get appended to the Task Configuration Options in exactly the same order they were provided to the Task during execution 👑.
The result row data includes a time for when the measurement started, and optionally an end time. The duration also needs to be considered in data analysis, so don't skip it 🔥.
Some Measurement Tasks may optionally include an indication of cross-traffic. The definition of cross-traffic is left up to each individual Measurement Task 🤷♀️. Some Measurement Tasks may also output other environmental measures alongside cross-traffic, like CPU utilization or interface speed 💖.
Basically: the Configuration and Instruction Information travels via the Control Protocol, while the Report travels via the Report Protocol. The Report gets constructed at the moment it's sent, and it represents the inherent structure of the information sent to the Collector. Iconic, honestly 💅✨.
4.6.1. Definition of ma-report-obj
object {
datetime ma-report-date;
[uuid ma-report-agent-id;]
[string ma-report-group-id;]
[string ma-report-measurement-point;]
[ma-report-result-obj ma-report-results<0..*>;]
} ma-report-obj;The ma-report-obj gives you the metadata for a single report, and it's made up of these elements 🎀:
ma-report-date: The date and time when the report was sent to a Collector 🗓️.ma-report-agent-id: An optional uuid that uniquely identifies the Measurement Agent 🪪.ma-report-group-id: An optional identifier for the group of Measurement Agents that this Measurement Agent belongs to 👯.ma-report-measurement-point: An optional identifier for the measurement point, which shows where the Measurement Agent is located on a path (see [RFC7398] for further details) 📍.ma-report-results: An optional and possibly empty, unordered set of result objects 🧺.
4.6.2. Definition of ma-report-result-obj
object {
string ma-report-result-schedule-name;
string ma-report-result-action-name;
string ma-report-result-task-name;
[ma-option-obj ma-report-result-options<0..*>;]
[string ma-report-result-tags<0..*>;]
datetime ma-report-result-event-time;
datetime ma-report-result-start-time;
[datetime ma-report-result-end-time;]
[string ma-report-result-cycle-number;]
int ma-report-result-status;
[ma-report-conflict-obj ma-report-result-conflicts<0..*>;]
[ma-report-table-obj ma-report-result-tables<0..*>;]
} ma-report-result-obj;The ma-report-result-obj gives you the metadata for a result report of a single executed Action. It's made up of these elements 📊:
ma-report-result-schedule-name: The name of the Schedule that produced the result 🗂️.ma-report-result-action-name: The name of the Action in the Schedule that produced the result 🎬.ma-report-result-task-name: The name of the Task that produced the result 🛠️.ma-report-result-options: An optional, ordered, joined list of options provided by the Task object and the Action object when the Action was started ⚙️.ma-report-result-tags: An optional, unordered set of tags. This is the joined set of tags provided by the Task object, the Action object, and the Schedule object when the Action was started 🏷️.ma-report-result-event-time: The date and time of the Event that triggered the Schedule of the Action that produced the reported result values. The date and time does not include any added randomization 🎲.ma-report-result-start-time: The date and time when the Action that produced the reported result values started 🏁.ma-report-result-end-time: An optional date and time indicating when the Action finished 🏁✨.ma-report-result-cycle-number: An optional cycle number derived fromma-report-result-event-time. It's the time closest toma-report-result-event-timethat is a multiple of thema-event-cycle-intervalof the Event that triggered the execution of the Schedule. The value only shows up in anma-report-result-objif that Event has a definedma-event-cycle-interval. The cycle number is in the formatYYYYMMDD.HHMMSS, where YYYY is the year, MM is the month (1..12), DD is the day of the month (01..31), HH is the hour (00..23), MM is the minute (00..59), and SS is the second (00..59). It uses Coordinated Universal Time (UTC) 🌍⏰.ma-report-result-status: The status code returned by the execution of the Action 🚦.ma-report-result-conflicts: A possibly empty set of conflict Actions that might have impacted the measurement results being reported 💥.ma-report-result-tables: An optional and possibly empty, unordered set of result tables 📋.
4.6.3. Definition of ma-report-conflict-obj
object {
string ma-report-conflict-schedule-name;
string ma-report-conflict-action-name;
string ma-report-conflict-task-name;
} ma-report-conflict-obj;The ma-report-conflict-obj gives you the info about a conflicting Action that might have impacted the measurement results. It's made up of these elements 🕵️♀️:
ma-report-result-schedule-name: The name of the Schedule that may have impacted the result 🗓️.ma-report-result-action-name: The name of the Action in the Schedule that may have impacted the result 🎯.ma-report-result-task-name: The name of the Task that may have impacted the result 🔍.
4.6.4. Definition of ma-report-table-obj ✨
okay so ma-report-table-obj is basically the result table 💖 it's got three optional bits that all work together:
object {
[ma-registry-obj ma-report-table-functions<0..*>;]
[string] ma-report-table-column-labels<0..*>;]
[ma-report-row-obj ma-report-table-rows<0..*>;]
} ma-report-table-obj;the three elements are:
ma-report-table-functions: an optional, possibly empty, unordered set of registry entries that identify the functions the results are reported for 🦋ma-report-table-column-labels: an optional, possibly empty, ordered list of column labels 🎀ma-report-table-rows: a possibly empty, ordered list of result rows 🌸
4.6.5. Definition of ma-report-row-obj 🧚
a row is giving very simple energy. it's one element:
object {
data ma-report-row-values<0..*>;
} ma-report-row-obj;ma-report-row-values: a possibly empty, ordered list of result values. when it's there, the values line up with the column labels for the report, so the first value goes with the first label, and so on 💅
4.7. Common Objects: Schedules 🗓️💜
bestie, this is where the schedules live 😭 a Schedule says when to run a single Action or a whole repeated series of them. an Action is a configured Task with some extra specific parameters on top. every Schedule is basically two things: an ordered list of Actions to run, and an Event object that kicks off the whole thing. so the Schedule tells you what to run (and with what config) and when. it can also have an optional Event that stops it, or a maximum duration after which it gets stopped. 🛑
when a single Measurement Schedule has a list of Actions, they run based on the Schedule's execution mode. in sequential mode the Actions go one after another. in parallel mode they all run at the same time. in pipelined mode, the data one Action produces gets passed along to the next Action 🔥 Actions that sit in different Schedules run in parallel too, and any conflicts between them get reported in the Reporting Information where needed. if two or more Schedules share the same start time, they run in parallel. there is no mechanism to prioritise one Schedule over another, or to mutex scheduled Tasks. 🙈
a Schedule also decides how each Action's data outputs get linked to other Schedules. this is the ultimate flexibility moment 👑 it's even possible to send the output from different executions of the same Task Configuration to different destinations. a single Task that makes several different outputs is expected to tag them properly, and then a receiving Action can filter by that tag if it needs to. for example, a Measurement Task could send routine results to a data Reporting Task in a Schedule that talks hourly over the broadband interface. that same Task also outputs emergency conditions to an alarm Reporting Task in a different Schedule that talks immediately over a General Packet Radio Service (GPRS) Channel 🚨 one thing to know: Task-to-Task data transfer is always specified along with the scheduled execution of the sending Task, so the receiving Task doesn't need a matching input spec. ✨
ngl an MA implementation will probably use a queue between the Schedules or Actions, but this Information Model doesn't require or define a queue 🫶 what it does do is report the storage allocated to Schedules and Actions, so storage usage can be watched. also, it is recommended that MA implementations, by default, keep old data and stop running new Measurement Tasks if the MA runs out of storage capacity. 🌈
when you create an Action (aka specify the Task to run inside a Schedule), you can add Option parameters to it 💖 this lets the Task Configuration hold the common characteristics of a Task, while selected parameters (like a test target URL) get set as Option parameters on the Action. one Task Configuration can even be reused several times in the same Schedule with different extra parameters, which makes creating and transferring the Instruction more efficient ⚡ heads up though: what happens when an Option is defined more than once (in the Task Configuration, the Action, or both) is not standardised, and it depends on the Task. some Tasks may legitimately take multiple values for a single parameter, so no judgement there 🙈
when Options are set in both the Action and the Task Configuration, the Action Options get appended to the ones from the Task Configuration 🎀
Example: an Action in a Schedule points at one Measurement Task Configuration for measuring UDP latency. it says the results should go to a Schedule with a Reporting Action. that Reporting Task is run by a separate Schedule that's set to run hourly at 5 minutes past the hour. when it runs, the Reporting Action takes the data from the UDP latency Measurement Task, plus any other data to be included in the hourly report, and sends it all to the Collector over the Report Channel specified in its own Schedule. 📬
finally, Schedules and Actions can optionally be given tags that get included in the result reports sent to a Collector 🏷️ and Schedules can be given Suppression tags, which can be used to pick out Schedules and Actions for Suppression. 🦋
4.7.1. Definition of ma-schedule-obj 🗓️
object {
string ma-schedule-name;
ma-event-obj ma-schedule-start;
[ma-event-obj ma-schedule-end;]
[int ma-schedule-duration;]
ma-action-obj ma-schedule-actions<0..*>;
string ma-schedule-execution-mode;
[string ma-schedule-tags<0..*>;]
[string ma-schedule-suppression-tags<0..*>;]
} ma-schedule-obj;ma-schedule-obj is the main scheduling object, and it's the star of the show 🌟 its elements are:
ma-schedule-name: a name that uniquely identifies a scheduling object 💜ma-schedule-start: an Event object that says when the Schedule starts ⏰ma-schedule-end: an optional Event object that controls the forceful termination of scheduled Actions. when the Event happens, all Actions of the Schedule get forced to terminate gracefully 🛑ma-schedule-duration: an optional duration in seconds for the Schedule. all Actions of the Schedule get forced to terminate gracefully after that many seconds have passed since the Schedule started ⏳ma-schedule-actions: a possibly empty, ordered list of Actions to invoke when the Schedule starts 🎬ma-schedule-execution-mode: says whether the Actions should run sequentially, in parallel, or in pipelined mode (where data from one Action gets passed to the next one). the default execution mode is pipelined 🔁ma-schedule-tags: an optional unordered set of tags that get reported together with the measurement results to a Collector 🏷️ma-schedule-suppression-tags: an optional unordered set of Suppression tags used to select which Schedules get suppressed 🙅♀️
4.7.2. Definition of ma-action-obj 🎬
object {
string ma-action-name;
string ma-action-config-task-name;
[ma-option-obj ma-action-task-options<0..*>;]
[string ma-action-destinations<0..*>;]
[string ma-action-tags<0..*>;]
[string ma-action-suppression-tags<0..*>;]
} ma-action-obj;the ma-action-obj models a Task together with its Schedule-specific Task Options and Destination Schedules 💅 it's made up of these elements:
ma-action-name: a name that uniquely identifies an Action of a scheduling object 🦋ma-action-config-task-name: a name that identifies the configured Task the Action invokes 🧚ma-action-task-options: an optional, possibly empty, ordered list of options (name-value pairs). these get passed to the Task by being appended to the options configured for the Task object 🎀ma-action-destinations: an optional, possibly empty, unordered set of names of Destination Schedules that consume the output this Action produces 📬ma-action-tags: an optional unordered set of tags that get reported together with the measurement results to a Collector 🏷️ma-action-suppression-tags: an optional unordered set of Suppression tags used to select which Actions get suppressed 🙅♀️
4.8. Common Objects: Channels ✨
okay so a Channel is a bidirectional communication mechanism between the MA and a Controller or Collector 📡 You can define multiple Channels so results can get split up or duplicated across different Collectors 🦋
Each Channel holds the details of the remote endpoint, including its location and security credential info like a certificate 🔐 The Schedule decides when to talk over a Channel, since it runs the Control or Reporting Task that uses it ⏰ The certificate can be the digital certificate tied to the Fully Qualified Domain Name (FQDN) in the URL, or it can be the certificate of the Certification Authority that issued the certificate for the FQDN of the target URL (which gets fetched later using a communication protocol like Transport Layer Security (TLS)) 💅 To set up a secure Channel, the MA uses its own security credentials (from the Configuration Information) along with the given credentials for that particular Channel endpoint 🫶
Just like the Task Configurations, every Channel gets a text name so it can be referenced as a Task Option 🎀
Channels used to talk to the Controller are called Control Channels, and Channels to Collectors are called Report Channels. Same info, different vibes 💜 Control Channels get referenced from Control Tasks run by a Control Schedule, and Report Channels get referenced from Reporting Tasks run by an Instruction Schedule 🌸
Multiple interfaces are supported too 🌈 For example, a Reporting Task could be set up to send some results over GPRS. This is especially useful when those results show a loss of connectivity on a different network interface 😭
Example: A Channel used for reporting results may say results go to https://collector.example.org/report/, using the appropriate digital certificate to set up a secure Channel 🍓
4.8.1. Definition of ma-channel-obj ✨
object {
string ma-channel-name;
url ma-channel-target;
credentials ma-channel-credentials;
[string ma-channel-interface-name;]
} ma-channel-obj;The ma-channel-obj has these elements:
ma-channel-name: A unique name identifying the Channel object.ma-channel-target: A URL identifying the target Channel endpoint.ma-channel-credentials: The security credentials needed to establish a secure Channel.ma-channel-interface-name: An optional name of the network interface to be used. If not present, the IP protocol stack will select a suitable interface.
4.9. Common Objects: Task Configurations 🧚
Think of each Task Configuration as the blueprint for a Task the MA might do at some point 📝 It doesn't actually tell the MA to run anything at any specific time, because that's the Schedule's job ⏰ Tasks can be Measurement Tasks (the ones actually doing some passive or active measurement) or any other scheduled activity the MA handles, like moving info to or from the Controller and Collectors 🚚 Data manipulation or processing Tasks happening on the MA count too 💻
A Measurement Task Configuration is the same, information-wise, as any other Task Configuration 🫶 Both Measurement and non-Measurement Tasks can have registry entries, which let the MA uniquely identify the Task it should run and grab the schema for any parameters it can take 🔎 Registry entries are URIs, so they can identify the Task inside a namespace or point to a web or local file location with the Task info 🗂️ As mentioned earlier, these URIs can identify the Measurement Task in a public namespace like the to-be-created IPPM registry described in [IPPM-REG] 🌍
Example: A Measurement Task Configuration might set up one Measurement Task for measuring UDP latency 🏓 It could define the destination port and address for the measurement, plus the duration, internal packet timing strategy, and other parameters (for example, streaming for one hour and sending one packet every 500 ms) ⏱️ It can also define the output type and any possible parameters (for example, the output type could be the 95th percentile mean) wherever the Measurement Task accepts them 📊 It does not define when the Task starts (that's the Schedule element's job), so it doesn't by itself tell the MA to actually perform this Measurement Task 🙅♀️
The Task Configuration includes a local short name so a Schedule can reference it 🏷️ Task Configurations can also refer to registry entries like we covered above ✨ On top of that, the Task can be configured through a set of configuration Options 🎛️ How many Options there are, and what they are, depends on the Task 🤷♀️ These Options are expressed as name-value pairs, although the 'value' can be a structured object instead of a simple string or numeric value 🧩 How those name-value pairs get implemented will vary between data models 🛠️
An Option that must be present for Reporting Tasks is the Channel reference, which says how to talk to a Collector 📮 It's included in the Task Options, and its value has to match a Channel name that's been defined in the Instruction 💌 Control Tasks have a similar Option, with the value set to a specified Control Channel 🎮
A Reporting Task might also have a flag parameter, defined as an Option, that says whether to send a report without measurement results when there's no measurement result data waiting to go to the Collector 🚩 Plus, lots of Tasks will receive (as a parameter) info about which interface to use 🔌
Oh, and the Task Configuration can optionally be given tags that carry a Measurement Cycle ID 🔖 The point of this ID is to easily identify a set of measurement results produced by Measurement Tasks with comparable Options 👯 It could be manually incremented or changed whenever an Option change gets implemented, which might mean two sets of results shouldn't be compared directly 🙈
4.9.1. Definition of ma-task-obj 💜
object {
string ma-task-name;
ma-registry-obj ma-task-functions<0..*>;
[ma-option-obj ma-task-options<0..*>;]
[string ma-task-tags<0..*>;]
} ma-task-obj;The ma-task-obj defines a configured Task that can be invoked as part of an Action 🎬 You can reference a configured Task by its name, and it holds a possibly empty set of URIs that link to registry entries 🔗 Options let you configure Task parameters as name-value pairs 🎚️ The ma-task-obj has these elements:
ma-task-name: A name uniquely identifying a configured Task object.ma-task-functions: A possibly empty unordered set of registry entries identifying the functions of the configured Task.ma-task-options: An optional and possibly empty ordered list of options (name-value pairs) that are passed to the configured Task.ma-task-tags: An optional unordered set of tags that are reported together with the measurement results to a Collector.
4.9.2. Definition of ma-option-obj 🌷
object {
string ma-option-name;
[object ma-option-value;]
} ma-option-obj;The ma-option-obj models a name-value pair and has these elements:
ma-option-name: The name of the option.ma-option-value: The optional value of the option.
The ma-option-obj is used to define Task Configuration Options, which are usually specific to the Task 🎯 For Tasks linked to an entry in a registry, the registry might define well-known option names (for example, the so-called parameters in the to-be-created IPPM metric registry described in [IPPM-REG]) 📚 Control and Reporting Tasks need to know which Channel they're going to use 📡 The common option name for specifying the Channel is "channel", and its value refers to the name of an ma-channel-obj 💖
4.10. Common Objects: Registry Information 🗂️
Tasks and Actions can be associated with entries in a registry 🧾 A registry object refers to an entry in a registry (identified by a URI), and it may define a set of roles 👑
4.10.1. Definition of ma-registry-obj 🌈
object {
uri ma-registry-uri;
[string ma-registry-role<0..*>;]
} ma-registry-obj;The ma-registry-obj refers to an entry in a registry, and it defines the associated role(s) 🎀 It has these elements:
ma-registry-uri: A URI identifying an entry in a registry.ma-registry-role: An optional and possibly empty unordered set of roles for the identified registry entry.
4.11. Common Objects: Event Information ✨
okay so the Event information object is what tells a Schedule when to kick off 🔥 it can start out as one of several different forms, and more forms can be added later so Schedules can bind to even more kinds of Events 🦋 the initially defined Event forms are:
- Periodic Timing: emits multiple Events periodically, according to an interval time defined in seconds 🔁
- Calendar Timing: emits multiple Events according to a calendar-based pattern, e.g., 22 minutes past each hour of the day on weekdays 📅
- One-Off Timing: emits one Event at a specific date and time 🎯
- Immediate: emits one Event as soon as possible ⚡
- Startup: emits an Event whenever the MA is started (e.g., at device startup) 🚀
- Controller Lost: emits an Event when connectivity to the Controller has been lost 💔
- Controller Connected: emits an Event when connectivity to the Controller has been established or re-established 🫶
Optionally, each of the Event options can also specify a randomness 🎲 that should be evaluated and applied separately to each indicated Event. This randomness parameter defines a uniform interval in seconds over which the start of the Task is delayed from the starting times specified by the Event object.
Both the periodic and calendar timing objects let you run a series of Actions 💅 and while both have an optional end time, it is best practice to always configure an end time and refresh the information periodically 🙏 that way lost MAs don't keep their Tasks going forever 💀
Startup Events are only created on device startup, not when a new Instruction is transferred to the MA 🧚 so if you want scheduled Task execution both on the transfer of the Instruction and on device restart, you need to use both the Immediate and Startup timing together 👑
The datetime format used for all elements in the Information Model MUST conform to RFC 3339 [RFC3339] 🌸
4.11.1. Definition of ma-event-obj
object {
string ma-event-name;
union {
ma-periodic-obj ma-event-periodic;
ma-calendar-obj ma-event-calendar;
ma-one-off-obj ma-event-one-off;
ma-immediate-obj ma-event-immediate;
ma-startup-obj ma-event-startup;
ma-controller-lost-obj ma-event-controller-lost;
ma-controller-connected-obj ma-event-controller-connected;
}
[int ma-event-random-spread;]
[int ma-event-cycle-interval;]
} ma-event-obj;The ma-event-obj is the main Event object 💖 Event objects are identified by a name, and a generic Event object itself contains a more specific Event object. The set of specific Event objects should be extensible, and the initial set is described further below. The ma-event-obj also includes an optional uniform random spread that can randomize the start times of Schedules triggered by an Event 🎀 it consists of the following elements:
ma-event-name: The name uniquely identifies an Event object ✨ Schedules refer to Event objects by this name.ma-event-periodic: Thema-event-periodicis present for periodic timing objects.ma-event-calendar: Thema-event-calendaris present for calendar timing objects.ma-event-one-off: Thema-event-one-offis present for one-off timing objects.ma-event-immediate: Thema-event-immediateis present for immediate Event objects.ma-event-startup: Thema-event-startupis present for startup Event objects.ma-event-controller-lost: Thema-event-controller-lostis present for connectivity to Controller lost Event objects.ma-event-controller-connected: Thema-event-controller-connectedis present for connectivity to Controller established Event objects.ma-event-random-spread: The optionalma-event-random-spreadadds a random delay, defined in seconds, to the Event object 🎲 No random delay is added ifma-event-random-spreaddoes not exist.ma-event-cycle-interval: The optionalma-event-cycle-intervaldefines the duration of the time interval in seconds that is used to calculate cycle numbers 🔢 No cycle number is calculated ifma-event-cycle-intervaldoes not exist.
4.11.2. Definition of ma-periodic-obj
object {
[datetime ma-periodic-start;]
[datetime ma-periodic-end;]
int ma-periodic-interval;
} ma-periodic-obj;The ma-periodic-obj timing object has an optional start and an optional end time, plus a periodic interval 🔁 Schedules using an ma-periodic-obj are started periodically between the start and end time. It consists of the following elements:
ma-periodic-start: The optional date and time at which Schedules using this object are first started. If not present, it defaults to immediate.ma-periodic-end: The optional date and time at which Schedules using this object are last started. If not present, it defaults to indefinite.ma-periodic-interval: The interval defines the time in seconds between two consecutive starts of Tasks ⏱️
4.11.3. Definition of ma-calendar-obj
Calendar timing supports the routine execution of Schedules at specific times and/or on specific dates 📆 It can be more flexible than periodic timing, since the execution of Schedules does not have to be uniformly spaced 🥰 For example, a calendar timing could support the execution of a Measurement Task every hour between 6 pm and midnight on weekdays only 🌙
Calendar timing is also required to perform measurements at meaningful times in relation to network usage (e.g., at peak times) 📈 If the optional time zone offset is not supplied, then local system time is assumed. This is essential in some use cases 💅 to ensure consistent peak-time measurements, and it also supports MA devices that may be in an unknown time zone or that roam between different time zones (but know their own time zone information, such as through the mobile network) 🗺️
The calendar elements within the calendar timing do not have defaults, in order to avoid accidental high-frequency execution of Tasks 🙈 If all possible values for an element are desired, then the wildcard * is used.
object {
[datetime ma-calendar-start;]
[datetime ma-calendar-end;]
[string ma-calendar-months<0..*>;]
[string ma-calendar-days-of-week<0..*>;]
[string ma-calendar-days-of-month<0..*>;]
[string ma-calendar-hours<0..*>;]
[string ma-calendar-minutes<0..*>;]
[string ma-calendar-seconds<0..*>;]
[int ma-calendar-timezone-offset;]
} ma-calendar-obj;ma-calendar-start: The optional date and time at which Schedules using this object are first started. If not present, it defaults to immediate.ma-calendar-end: The optional date and time at which Schedules using this object are last started. If not present, it defaults to indefinite.ma-calendar-months: The optional set of months (1-12) on which Tasks scheduled using this object are started. The wildcard*means all months. If not present, it defaults to no months.ma-calendar-days-of-week: The optional set of days of a week ("Mon","Tue","Wed","Thu","Fri","Sat","Sun") on which Tasks scheduled using this object are started. The wildcard*means all days of the week. If not present, it defaults to no days 📅ma-calendar-days-of-month: The optional set of days of a month (1-31) on which Tasks scheduled using this object are started. The wildcard*means all days of a month. If not present, it defaults to no days.ma-calendar-hours: The optional set of hours (0-23) on which Tasks scheduled using this object are started. The wildcard*means all hours of a day. If not present, it defaults to no hours 🕐ma-calendar-minutes: The optional set of minutes (0-59) on which Tasks scheduled using this object are started. The wildcard*means all minutes of an hour. If not present, it defaults to no minutes.ma-calendar-seconds: The optional set of seconds (0-59) on which Tasks scheduled using this object are started. The wildcard*means all seconds of an hour. If not present, it defaults to no seconds.ma-calendar-timezone-offset: The optional time zone offset in minutes. If not present, it defaults to the system's local time zone 🌍
If a day of the month is specified that does not exist in the month (e.g., the 29th of February), then those values are ignored 🫠
4.11.4. Definition of ma-one-off-obj
object {
datetime ma-one-off-time;
} ma-one-off-obj;The ma-one-off-obj timing object specifies a fixed point in time 📍 Schedules using an ma-one-off-obj are started once, at the specified date and time. It consists of the following element:
ma-one-off-time: The date and time at which Schedules using this object are started.
4.11.5. Definition of ma-immediate-obj
object {
// empty
} ma-immediate-obj;The ma-immediate-obj Event object has no further information elements 🫧 Schedules using an ma-immediate-obj are started as soon as possible ⚡
4.11.6. Definition of ma-startup-obj 🌸
object {
// empty
} ma-startup-obj;Okay, the ma-startup-obj Event object has no extra info elements, bestie, so it's super minimal 🫶. Schedules or Suppressions that use it kick off at MA initialization time 🚀.
4.11.7. Definition of ma-controller-lost-obj 💔
object {
// empty
} ma-controller-lost-obj;This one also has no further info elements 🙈. It indicates that connectivity to the Controller has been lost. How does the MA even know? A timer starts after each successful contact with a Controller 🕰️. When that timer reaches the controller-timeout (measured in seconds), a ma-controller-lost-obj Event gets generated ⏰. It's lowkey perfect for starting a Suppression 🛑.
4.11.8. Definition of ma-controller-connected-obj 💖
object {
// empty
} ma-controller-connected-obj;Same vibe, no extra info elements 💅. This one means connectivity to the Controller has been established again after it was lost, so we're back in business 🎉. It can be used to end a Suppression, so the glow-up is real ✨.
5. Example Execution 🎬
Okay, the example execution is giving two Event sources, E1 and E2, and three Schedules: S1, S2, and S3 🧩. S3 gets started by Events from Event source E2, while S1 and S2 both get started by Events from Event source E1 💜. S1 and S2 each have two Actions, and S3 has a single Action 🎀. E2 has no randomization, but E1 has the randomization r 🎲.
Figure 2 shows a possible timeline of an execution 🦋. Time T moves downwards 👇. The dotted vertical line shows time progressing, and the dotted horizontal line shows which Schedules get triggered by an Event 🌈. Lines of tildes show data flowing from one Action to another Schedule 🌊. Actions inside a Schedule are named A1, A2, and so on 🍓.
E2 E1 T S1 S2 S3
sequential parallel pipelined
:
e0 +
:
:
e0+r + .......... + .......... ++
: | A1 A1 || A2
: + |+ ~~~~~~~>
: | A2 |
: | + ~~~~~~~~>
: + ~~~~~~~~~~~~~~~~~~~~~>
:
:
e1 +
:
e1+r + .......... + .......... ++
: | A1 A1 ||
: | +|~~~~~~~>
: | | A2
: + +~~~~~~~>
: | A2
: + ~~~~~~~~~~~~~~~~~~~~>
e0 + ................................... +
: | A1
e3 + |
e3+r + .......... + .......... ++ |
: | A1 A1 || A2 |
: + ++ ~~~~~~> |
: | A2 +
: + ~~~~~~~~~~~~~~~~~~~~>
V
Figure 2: Example ExecutionHeads up, though: implementations must handle possible concurrency issues ⚠️. In this example, A1 of S3 is eating up the data that got forwarded to S3, while more data is still arriving from A2 of S2 🍽️. Concurrency is a whole thing, so don't skip it, periodt 💀.
6. IANA Considerations 📋
This document does not require any IANA actions 🌷.
7. Security Considerations 🔐
Okay, this part is serious, so let's get into it 🚨. This Information Model deals with information about controlling and reporting on the Measurement Agent 🕵️. There are broadly two security considerations for an Information Model like this 🛡️.
The first one: the Information Model has to be sufficient to set up secure communication Channels to the Controller and Collector, so other information can be sent and received securely 🔒. On top of that, any mechanisms that the Network Operator or another device administrator uses to preconfigure the MA must also be secure 🧱. The point is to protect unauthorized parties from modifying Preconfiguration Information 🙅♀️. These mechanisms matter a lot so the MA can't get hijacked and, for example, roped into a distributed denial-of-service attack 😱.
The second one: no mandated information items should pose a risk to confidentiality or privacy, assuming those secure communication Channels are in place 🫣. For that reason, things like the MA context and MA-ID are left optional and can be left out of some deployments 🧁. That can let the MA stay anonymous, and it can let information about location or other context that could identify or track the MA get left out or blurred 🌫️. Implementations and deployments should also be careful about exposing device-ids when it isn't strictly needed 🙈.
An implementation of this Information Model should support all the security and privacy requirements associated with the LMAP Framework [RFC7594] 💜. Users of this Information Model are also advised to pick identifiers for Group-IDs, tags, or names of Information Model objects (like configured Tasks, Schedules, or Actions) that don't reveal any sensitive info to people who are allowed to process measurement results but aren't allowed to know the details about the Measurement Agents used to do the measurement 🤫. Protect your secrets, bestie 🔥.
8. References 📚
8.1. Normative References 🎀
[ISO.10646]International Organization for Standardization, "Information Technology - Universal Coded Character Set (UCS)", ISO Standard 10646:2014, September 2014.[POSIX.2]The Open Group, "Standard for Information Technology - Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7", IEEE Standard 1003.1, 2016 Edition, DOI, 10.1109/IEEESTD.2016.7582338, September 2016.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.[RFC3339]Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.[RFC3986]Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.[RFC4122]Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.[RFC8174]Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 🌈
[IPPM-REG]Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. Akhter, "Registry for Performance Metrics", Work in Progress, draft-ietf-ippm-metric-registry-12, June 2017.[RFC3444]Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>.[RFC7398]Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and A. Morton, "A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance", RFC 7398, DOI 10.17487/RFC7398, February 2015, <https://www.rfc-editor.org/info/rfc7398>.[RFC7536]Linsner, M., Eardley, P., Burbridge, T., and F. Sorensen, "Large-Scale Broadband Measurement Use Cases", RFC 7536, DOI 10.17487/RFC7536, May 2015, <https://www.rfc-editor.org/info/rfc7536>.[RFC7594]Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, <https://www.rfc-editor.org/info/rfc7594>.[RFC8194]Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, August 2017, <http://www.rfc-editor.org/info/rfc8194>.
Acknowledgements 🫶
Several people helped shape this spec by reviewing early drafts and actively taking part in the LMAP Working Group 💕 (apologies to anyone we accidentally left out 🙏): Vaibhav Bajpai, Michael Bugenhagen, Timothy Carey, Alissa Cooper, Kenneth Ko, Al Morton, Dan Romascanu, Henning Schulzrinne, Andrea Soppera, Barbara Stark, and Jason Weil ✨.
Marcelo Bagnulo, Trevor Burbridge, Philip Eardley, and Juergen Schoenwaelder worked in part on the Leone research project 🧪, which got funding from the European Union Seventh Framework Programme [FP7/2007-2013] under grant agreement number 317647 🇪🇺.
Juergen Schoenwaelder was partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme 🦩.
Authors' Addresses 💌
Trevor Burbridge
BT
Adastral Park, Martlesham Heath
Ipswich IP5 3RE
United Kingdom
Email: trevor.burbridge@bt.com
Philip Eardley
BT
Adastral Park, Martlesham Heath
Ipswich IP5 3RE
United Kingdom
Email: philip.eardley@bt.com
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
Spain
Email: marcelo@it.uc3m.es
Juergen Schoenwaelder
Jacobs University Bremen
Campus Ring 1
Bremen 28759
Germany
Email: j.schoenwaelder@jacobs-university.de📦 where this page comes from
- ietf: rfc8193 2017-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms