RFC 8193
Information Model for Large-Scale Measurement Platforms (LMAPs)
Pages: 53
Proposed Standard
Proposed Standard
Part 3 of 3 – Pages 41 to 53
4.11. Common Objects: Event Information
The Event information object used throughout the Information Models can initially take one of several different forms. Additional forms may be defined later in order to bind the execution of Schedules to additional Events. The initially defined Event forms are: 1. Periodic Timing: Emits multiple Events periodically according to an interval time defined in seconds 2. Calendar Timing: Emits multiple Events according to a calendar- based pattern, e.g., 22 minutes past each hour of the day on weekdays 3. One-Off Timing: Emits one Event at a specific date and time 4. Immediate: Emits one Event as soon as possible
5. Startup: Emits an Event whenever the MA is started (e.g., at
device startup)
6. Controller Lost: Emits an Event when connectivity to the
Controller has been lost
7. Controller Connected: Emits an Event when connectivity to the
Controller has been established or re-established
Optionally, each of the Event options may 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 allow for a series of
Actions to be executed. While both have an optional end time, it is
best practice to always configure an end time and refresh the
information periodically to ensure that lost MAs do not continue
their Tasks forever.
Startup Events are only created on device startup, not when a new
Instruction is transferred to the MA. If scheduled Task execution is
desired both on the transfer of the Instruction and on device
restart, then both the Immediate and Startup timing needs to be used
in conjunction.
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. A generic Event object itself contains a more
specific Event object. The set of specific Event objects should be
extensible. The initial set of specific Event objects is further
described below. The ma-event-obj also includes an optional uniform
random spread that can be used to randomize the start times of
Schedules triggered by an Event. The ma-event-obj 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: The ma-event-periodic is present for
periodic timing objects.
ma-event-calendar: The ma-event-calendar is present for
calendar timing objects.
ma-event-one-off: The ma-event-one-off is present for
one-off timing objects.
ma-event-immediate: The ma-event-immediate is present for
immediate Event objects.
ma-event-startup: The ma-event-startup is present for
startup Event objects.
ma-event-controller-lost: The ma-event-controller-lost is
present for connectivity to
Controller lost Event objects.
ma-event-controller-connected: The ma-event-controller-connected is
present for connectivity to
Controller established Event objects.
ma-event-random-spread: The optional ma-event-random-spread
adds a random delay defined in
seconds to the Event object. No
random delay is added if
ma-event-random-spread does not
exist.
ma-event-cycle-interval: The optional ma-event-cycle-interval
defines the duration of the time
interval in seconds that is used to
calculate cycle numbers. No cycle
number is calculated if
ma-event-cycle-interval does 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. The ma-periodic-obj 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 support more
flexible timing 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 as well as supporting MA devices
that may be in an unknown time zone or to 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. The ma-one-off-obj consists of the following
elements:
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; The ma-startup-obj Event object has no further information elements. Schedules or Suppressions using an ma-startup-obj are started at MA initialization time.4.11.7. Definition of ma-controller-lost-obj
object { // empty } ma-controller-lost-obj; The ma-controller-lost-obj Event object has no further information elements. The ma-controller-lost-obj indicates that connectivity to the Controller has been lost. This is determined by a timer started after each successful contact with a Controller. When the timer reaches the controller-timeout (measured in seconds), a ma-controller-lost-obj Event is generated. This Event may be used to start a Suppression.4.11.8. Definition of ma-controller-connected-obj
object { // empty } ma-controller-connected-obj; The ma-controller-connected-obj Event object has no further information elements. The ma-controller-connected-obj indicates that connectivity to the Controller has been established again after it was lost. This Event may be used to end a Suppression.
5. Example Execution
The example execution has two Event sources, E1 and E2, and three Schedules, S1, S2, and S3. The Schedule S3 is started by Events of Event source E2 while the Schedules S1 and S2 are both started by Events of the Event source E1. The Schedules S1 and S2 have two Actions each, and Schedule S3 has a single Action. The Event source E2 has no randomization while the Event source E1 has the randomization r. Figure 2 shows a possible timeline of an execution. The time T is progressing downwards. The dotted vertical line indicates progress of time while a dotted horizontal line indicates which Schedules are triggered by an Event. Lines of tildes indicate data flowing from an Action to another Schedule. Actions within a Schedule are named A1, A2, etc.
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 Execution Note that implementations must handle possible concurrency issues. In the example execution, Action A1 of Schedule S3 is consuming the data that has been forwarded to Schedule S3 while additional data is arriving from Action A2 of Schedule S2.6. IANA Considerations
This document does not require any IANA actions.
7. Security Considerations
This Information Model deals with information about the control and reporting of the Measurement Agent. There are broadly two security considerations for such an Information Model. Firstly, the Information Model has to be sufficient to establish secure communication Channels to the Controller and Collector such that other information can be sent and received securely. Additionally, any mechanisms that the Network Operator or other device administrator employs to preconfigure the MA must also be secure to protect unauthorized parties from modifying Preconfiguration Information. These mechanisms are important to ensure that the MA cannot be hijacked, for example, to participate in a distributed denial-of-service attack. The second consideration is that no mandated information items should pose a risk to confidentiality or privacy given such secure communication Channels. For this latter reason, items such as the MA context and MA-ID are left optional and can be excluded from some deployments. This may, for example, allow the MA to remain anonymous and for information about location or other context that might be used to identify or track the MA to be omitted or blurred. Implementations and deployments should also be careful about exposing device-ids when this is not strictly needed. An implementation of this Information Model should support all the security and privacy requirements associated with the LMAP Framework [RFC7594]. In addition, users of this Information Model are advised to choose identifiers for Group-IDs, tags, or names of Information Model objects (e.g., configured Tasks, Schedules, or Actions) that do not reveal any sensitive information to people authorized to process measurement results but who are not authorized to know details about the Measurement Agents that were used to perform the measurement.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 contributed to this specification by reviewing early draft versions and actively participating in the LMAP Working Group (apologies to those unintentionally omitted): 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 received 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