idnits 2.17.1 draft-ietf-lmap-information-model-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 695 has weird spacing: '...ion-obj ma-in...' == Line 859 has weird spacing: '...ask-obj ma-ca...' == Line 880 has weird spacing: '...try-obj ma-ca...' == Line 902 has weird spacing: '...ule-obj ma-st...' == Line 928 has weird spacing: '...ion-obj ma-...' == (6 more instances...) -- The document date (November 1, 2015) is 3100 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7594 == Outdated reference: A later version (-24) exists of draft-ietf-ippm-metric-registry-05 == Outdated reference: A later version (-12) exists of draft-ietf-lmap-yang-01 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Burbridge 3 Internet-Draft P. Eardley 4 Intended status: Standards Track BT 5 Expires: May 4, 2016 M. Bagnulo 6 Universidad Carlos III de Madrid 7 J. Schoenwaelder 8 Jacobs University Bremen 9 November 1, 2015 11 Information Model for Large-Scale Measurement Platforms (LMAP) 12 draft-ietf-lmap-information-model-07 14 Abstract 16 This Information Model applies to the Measurement Agent within a 17 Large-Scale Measurement Platform. As such it outlines the 18 information that is (pre-)configured on the MA or exists in 19 communications with a Controller or Collector within an LMAP 20 framework. The purpose of such an Information Model is to provide a 21 protocol and device independent view of the MA that can be 22 implemented via one or more Control and Report protocols. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 4, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. LMAP Information Model . . . . . . . . . . . . . . . . . . . 4 67 3.1. Pre-Configuration Information . . . . . . . . . . . . . . 8 68 3.1.1. Definition of ma-preconfig-obj . . . . . . . . . . . 9 69 3.2. Configuration Information . . . . . . . . . . . . . . . . 10 70 3.2.1. Definition of ma-config-obj . . . . . . . . . . . . . 11 71 3.3. Instruction Information . . . . . . . . . . . . . . . . . 13 72 3.3.1. Definition of ma-instruction-obj . . . . . . . . . . 15 73 3.3.2. Definition of ma-suppression-obj . . . . . . . . . . 16 74 3.4. Logging Information . . . . . . . . . . . . . . . . . . . 17 75 3.4.1. Definition of ma-log-obj . . . . . . . . . . . . . . 18 76 3.5. Capability and Status Information . . . . . . . . . . . . 18 77 3.5.1. Definition of ma-capability-obj . . . . . . . . . . . 19 78 3.5.2. Definition of ma-capability-task-obj . . . . . . . . 19 79 3.5.3. Definition of ma-status-obj . . . . . . . . . . . . . 20 80 3.5.4. Definition of ma-status-schedule-obj . . . . . . . . 20 81 3.5.5. Definition of ma-status-action-obj . . . . . . . . . 21 82 3.5.6. Definition of ma-interface-obj . . . . . . . . . . . 22 83 3.6. Reporting Information . . . . . . . . . . . . . . . . . . 23 84 3.6.1. Definition of ma-report-obj . . . . . . . . . . . . . 25 85 3.6.2. Definition of ma-report-task-obj . . . . . . . . . . 25 86 3.6.3. Definition of ma-report-row-obj . . . . . . . . . . . 26 87 3.7. Common Objects: Schedules . . . . . . . . . . . . . . . . 27 88 3.7.1. Definition of ma-schedule-obj . . . . . . . . . . . . 28 89 3.7.2. Definition of ma-action-obj . . . . . . . . . . . . . 29 90 3.8. Common Objects: Channels . . . . . . . . . . . . . . . . 30 91 3.8.1. Definition of ma-channel-obj . . . . . . . . . . . . 30 92 3.9. Common Objects: Task Configurations . . . . . . . . . . . 31 93 3.9.1. Definition of ma-task-obj . . . . . . . . . . . . . . 33 94 3.9.2. Definition of ma-option-obj . . . . . . . . . . . . . 33 96 3.10. Common Objects: Registry Information . . . . . . . . . . 34 97 3.10.1. Definition of ma-metric-registry-obj . . . . . . . . 34 98 3.11. Common Objects: Event Information . . . . . . . . . . . . 34 99 3.11.1. Definition of ma-event-obj . . . . . . . . . . . . . 35 100 3.11.2. Definition of ma-periodic-obj . . . . . . . . . . . 37 101 3.11.3. Definition of ma-calendar-obj . . . . . . . . . . . 37 102 3.11.4. Definition of ma-one-off-obj . . . . . . . . . . . . 39 103 3.11.5. Definition of ma-immediate-obj . . . . . . . . . . . 39 104 3.11.6. Definition of ma-startup-obj . . . . . . . . . . . . 40 105 3.11.7. Definition of ma-controller-lost-obj . . . . . . . . 40 106 3.11.8. Definition of ma-controller-ok-obj . . . . . . . . . 40 107 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 108 5. Security Considerations . . . . . . . . . . . . . . . . . . . 40 109 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 110 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 111 7.1. Normative References . . . . . . . . . . . . . . . . . . 41 112 7.2. Informative References . . . . . . . . . . . . . . . . . 42 113 Appendix A. Non-editorial Changes since -06 . . . . . . . . . . 42 114 Appendix B. Non-editorial Changes since -05 . . . . . . . . . . 43 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 117 1. Introduction 119 A large-scale measurement platform is a collection of components that 120 work in a coordinated fashion to perform measurements from a large 121 number of vantage points. The main components of a large-scale 122 measurement platform are the Measurement Agents (hereafter MAs), the 123 Controller(s) and the Collector(s). 125 The MAs are the elements actually performing the measurements. The 126 MAs are controlled by exactly one Controller at a time and the 127 Collectors gather the results generated by the MAs. In a nutshell, 128 the normal operation of a large-scale measurement platform starts 129 with the Controller instructing a set of one or more MAs to perform a 130 set of one or more Measurement Tasks at a certain point in time. The 131 MAs execute the instructions from a Controller, and once they have 132 done so, they report the results of the measurements to one or more 133 Collectors. The overall framework for a Large Measurement platform 134 as used in this document is described in detail in [RFC7594]. 136 A large-scale measurement platform involves basically three types of 137 protocols, namely, a Control protocol (or protocols) between a 138 Controller and the MAs, a Report protocol (or protocols) between the 139 MAs and the Collector(s) and several measurement protocols between 140 the MAs and Measurement Peers (MPs), used to actually perform the 141 measurements. In addition some information is required to be 142 configured on the MA prior to any communication with a Controller. 144 This document defines the information model for both Control and the 145 Report protocols along with pre-configuration information that is 146 required on the MA before communicating with the Controller, broadly 147 named as the LMAP Information Model. The measurement protocols are 148 out of the scope of this document. 150 As defined in [RFC3444], the LMAP Information Model defines the 151 concepts involved in a large-scale measurement platform at a high 152 level of abstraction, independent of any specific implementation or 153 actual protocol used to exchange the information. It is expected 154 that the proposed information model can be used with different 155 protocols in different measurement platform architectures and across 156 different types of MA devices (e.g., home gateway, smartphone, PC, 157 router). A YANG data model implementing the information model can be 158 found in [I-D.ietf-lmap-yang]. 160 The definition of an Information Model serves a number of purposes: 162 1. To guide the standardisation of one or more Control and Report 163 protocols and data models 165 2. To enable high-level inter-operability between different Control 166 and Report protocols by facilitating translation between their 167 respective data models such that a Controller could instruct sub- 168 populations of MAs using different protocols 170 3. To form agreement of what information needs to be held by an MA 171 and passed over the Control and Report interfaces and support the 172 functionality described in the LMAP framework 174 4. Enable existing protocols and data models to be assessed for 175 their suitability as part of a large-scale measurement system 177 2. Notation 179 This document uses a programming language-like notation to define the 180 properties of the objects of the information model. An optional 181 property is enclosed by square brackets, [ ], and a list property is 182 indicated by two numbers in angle brackets, , where m indicates 183 the minimal number of values, and n is the maximum. The symbol * for 184 n means no upper bound. 186 3. LMAP Information Model 188 The information described herein relates to the information stored, 189 received or transmitted by a Measurement Agent as described within 190 the LMAP framework [RFC7594]. As such, some subsets of this 191 information model are applicable to the measurement Controller, 192 Collector and any device management system that pre-configures the 193 Measurement Agent. The information described in these models will be 194 transmitted by protocols using interfaces between the Measurement 195 Agent and such systems according to a Data Model. 197 For clarity the information model is divided into six sections: 199 1. Pre-Configuration Information. Information pre-configured on the 200 Measurement Agent prior to any communication with other 201 components of the LMAP architecture (i.e., the Controller, 202 Collector and Measurement Peers), specifically detailing how to 203 communicate with a Controller and whether the device is enabled 204 to participate as an MA. 206 2. Configuration Information. Update of the pre-configuration 207 information during the registration of the MA or subsequent 208 communication with the Controller, along with the configuration 209 of further parameters about the MA (rather than the Tasks it 210 should perform) that were not mandatory for the initial 211 communication between the MA and a Controller. 213 3. Instruction Information. Information that is received by the MA 214 from the Controller pertaining to the Tasks that should be 215 executed. This includes the task execution Schedules (other than 216 the Controller communication Schedule supplied as 217 (pre)configuration information) and related information such as 218 the Task Configuration, communication Channels to Collectors and 219 schedule Timing information. It also includes Task Suppression 220 information that is used to over-ride normal Task execution. 222 4. Logging Information. Information transmitted from the MA to the 223 Controller detailing the results of any configuration operations 224 along with error and status information from the operation of the 225 MA. 227 5. Capability and Status Information. Information on the general 228 status and capabilities of the MA. For example, the set of 229 measurements that are supported on the device. 231 6. Reporting Information. Information transmitted from the MA to 232 one or more Collectors including measurement results and the 233 context in which they were conducted. 235 In addition the MA may hold further information not described herein, 236 and which may be optionally transferred to or from other systems 237 including the Controller and Collector. One example of information 238 in this category is subscriber or line information that may be 239 extracted by a task and reported by the MA in the reporting 240 communication to a Collector. 242 It should also be noted that the MA may be in communication with 243 other management systems which may be responsible for configuring and 244 retrieving information from the MA device. Such systems, where 245 available, can perform an important role in transferring the pre- 246 configuration information to the MA or enabling/disabling the 247 measurement functionality of the MA. 249 The Information Model is divided into sub-sections for a number of 250 reasons. Firstly the grouping of information facilitates reader 251 understanding. Secondly, the particular groupings chosen are 252 expected to map to different protocols or different transmissions 253 within those protocols. 255 The granularity of data transmitted in each operation of the Control 256 and Report Protocols is not dictated by the Information Model. For 257 example, the Instruction object may be delivered in a single 258 operation. Alternatively, Schedules and Task Configurations may be 259 separated or even each Schedule/Task Configuration may be delivered 260 individually. Similarly the Information Model does not dictate 261 whether data is read, write, or read/write. For example, some 262 Control Protocols may have the ability to read back Configuration and 263 Instruction information which have been previously set on the MA. 264 Lastly, while some protocols may simply overwrite information (for 265 example refreshing the entire Instruction Information), other 266 protocols may have the ability to update or delete selected items of 267 information. 269 The information in these six sections is captured by a number of 270 common information objects. These objects are also described later 271 in this document and comprise of: 273 1. Schedules. A set of Schedules tell the MA to do something. 274 Without a Schedule no Task (from a measurement to reporting or 275 communicating with the Controller) is ever executed. Schedules 276 are used within the Instruction to specify what tasks should be 277 performed, when, and how to direct their results. A Schedule is 278 also used within the pre-Configuration and Configuration 279 information in order to execute the Task or Tasks required to 280 communicate with the Controller. 282 2. Channels. A set of Channel objects are used to communicate with 283 a number of endpoints (i.e., the Controller and Collectors). 284 Each Channel object contains the information required for the 285 communication with a single endpoint such as the target location 286 and security details. 288 3. Task Configurations. A set of Task Configurations is used to 289 configure the Tasks that are run by the MA. This includes the 290 registry entries for the Task and any configuration parameters. 291 Task Configurations are referenced from a Schedule in order to 292 specify what Tasks the MA should execute. 294 4. Events. A set of Event objects that can be referenced from the 295 Schedules. Each Schedule always references exactly one Event 296 object. An Event object specifies either a singleton or series 297 of events that indicate when Tasks should be executed. A 298 commonly used kind of Event objects are Timing objects. 300 Figure 1 illustrates the structure in which these common information 301 objects are referenced. The references are achieved by each object 302 (Task Configuration, Event) being given a short textual name that is 303 used by other objects. The objects shown in parenthesis are part of 304 the internal object structure of a Schedule. Channels are not shown 305 in the diagram since they are only used as an option by selected Task 306 Configurations but are similarly referenced using a short text name. 308 Schedule 309 |--- triggered by ---> Event 310 | 311 |--- executes ---> Action 1 312 | |--- using ---> Task Configuration 313 | | 314 | `--- feeding to ---> Destination Schedule 315 : 316 : 317 `--- exceutes ---> Action N 318 |--- using ---> Task Configuration 319 | 320 `----feeding to --> Destination Schedule 322 Figure 1: Relationship between Schedules, Events, Actions, Task 323 Configurations, and Destination Schedules 325 It should be clear that the top-level behavior of an MA is simply to 326 execute Schedules. Every Action contained in a Schedule is defined 327 as a Task. As such, these Actions are configured through Task 328 Configurations and executed according to the Event object referenced 329 by the Schedule in which they appear. Note, however, that Actions 330 can have Action specific parameters. 332 Tasks can implement a variety of different types of Actions. While 333 in terms of the Information Model, all Tasks have the same structure, 334 it can help conceptually to think of different Task categories: 336 1. Measurement Tasks measure some aspect of network performance or 337 traffic. They may also capture contextual information from the 338 MA device or network interfaces such as the device type or 339 interface speed. 341 2. Data Transfer Tasks 343 A. Reporting Tasks report the results of Measurement Tasks to 344 Collectors 346 B. Control Task(s) implement the Control Protocol and 347 communicate with the Controller. 349 3. Data Analysis Tasks can exist to analyse data from other 350 Measurement Tasks locally on the MA 352 4. Data Management Tasks may exist to clean-up, filter or compress 353 data on the MA such as Measurement Task results 355 Figure 1 indicates that Actions can produce data that is fed into 356 Destination Schedules. This can by used by Actions implementing 357 Measurement Tasks to feed measurement results to a Schedule that 358 triggers Actions implementing Reporting Tasks. Data fed to a 359 Destination Schedule is consumed by the first Action of the 360 Destination Schedule if the Destination Schedule is using sequential 361 or pipelined execution mode and it is consumed by all Actions of the 362 Destination Schedule if the Destination Schedule is using parallel 363 execution mode. 365 3.1. Pre-Configuration Information 367 This information is the minimal information that needs to be pre- 368 configured to the MA in order for it to successfully communicate with 369 a Controller during the registration process. Some of the Pre- 370 Configuration Information elements are repeated in the Configuration 371 Information in order to allow an LMAP Controller to update these 372 items. The pre-configuration information also contains some elements 373 that are not under the control of the LMAP framework (such as the 374 device identifier and device security credentials). 376 This Pre-Configuration Information needs to include a URL of the 377 initial Controller from where configuration information can be 378 communicated along with the security information required for the 379 communication including the certificate of the Controller (or the 380 certificate of the Certification Authority which was used to issue 381 the certificate for the Controller). All this is expressed as a 382 Channel. While multiple Channels may be provided in the Pre- 383 Configuration Information they must all be associated with a single 384 Controller (e.g., over different interfaces or network protocols). 386 Where the MA pulls information from the Controller, the Pre- 387 Configuration Information also needs to contain the timing of the 388 communication with the Controller as well as the nature of the 389 communication itself (such as the protocol and data to be 390 transferred). The timing is given as a Schedule that executes the 391 Task(s) responsible for communication with the Controller. It is 392 this Task (or Tasks) that implement the Control protocol between the 393 MA and the Controller and utilises the Channel information. The 394 Task(s) may take additional parameters in which case a Task 395 Configuration can also be included. 397 Even where information is pushed to the MA from the Controller 398 (rather than pulled by the MA), a Schedule still needs to be 399 supplied. In this case the Schedule will simply execute a Controller 400 listener task when the MA is started. A Channel is still required 401 for the MA to establish secure communication with the Controller. 403 It can be seen that these Channels, Schedules and Task Configurations 404 for the initial MA-Controller communication are no different in terms 405 of the Information Model to any other Channel, Schedule or Task 406 Configuration that might execute a Measurement Task or report the 407 measurement results (as described later). 409 The MA may be pre-configured with an MA ID, or may use a Device ID in 410 the first Controller contact before it is assigned an MA ID. The 411 Device ID may be a MAC address or some other device identifier 412 expressed as a URI. If the MA ID is not provided at this stage then 413 it must be provided by the Controller during Configuration. 415 3.1.1. Definition of ma-preconfig-obj 417 object { 418 [uuid ma-preconfig-agent-id;] 419 ma-task-obj ma-preconfig-control-tasks<1..*>; 420 ma-channel-obj ma-preconfig-control-channels<1..*>; 421 ma-schedule-obj ma-preconfig-control-schedules<1..*>; 422 [uri ma-preconfig-device-id;] 423 credentials ma-preconfig-credentials; 424 } ma-preconfig-obj; 426 The ma-preconfig-obj is essentially a subset of the ma-config-obj 427 described below. The ma-preconfig-obj consists of the following 428 elements: 430 ma-preconfig-agent-id: An optional uuid uniquely identifying 431 the measurement agent. 433 ma-preconfig-control-tasks: An unordered set of tasks objects. 435 ma-preconfig-control-channels: An unordered set of channel objects. 437 ma-preconfig-control-schedules: An unordered set of scheduling 438 objects. 440 ma-preconfig-device-id: An optional identifier for the 441 device. 443 ma-preconfig-credentials: The security credentials used by the 444 measurement agent. 446 3.2. Configuration Information 448 During registration or at any later point at which the MA contacts 449 the Controller (or vice-versa), the choice of Controller, details for 450 the timing of communication with the Controller or parameters for the 451 communication Task(s) can be changed (as captured by the Channels, 452 Schedules and Task Configurations objects). For example the pre- 453 configured Controller (specified as a Channel or Channels) may be 454 over-ridden with a specific Controller that is more appropriate to 455 the MA device type, location or characteristics of the network (e.g., 456 access technology type or broadband product). The initial 457 communication Schedule may be over-ridden with one more relevant to 458 routine communications between the MA and the Controller. 460 While some Control protocols may only use a single Schedule, other 461 protocols may use several Schedules (and related data transfer Tasks) 462 to update the Configuration Information, transfer the Instruction 463 Information, transfer Capability and Status Information and send 464 other information to the Controller such as log or error 465 notifications. Multiple Channels may be used to communicate with the 466 same Controller over multiple interfaces (e.g., to send logging 467 information over a different network). 469 In addition the MA will be given further items of information that 470 relate specifically to the MA rather than the measurements it is to 471 conduct or how to report results. The assignment of an ID to the MA 472 is mandatory. If the MA Agent ID was not optionally provided during 473 the pre-configuration then one must be provided by the Controller 474 during Configuration. Optionally a Group ID may also be given which 475 identifies a group of interest to which that MA belongs. For example 476 the group could represent an ISP, broadband product, technology, 477 market classification, geographic region, or a combination of 478 multiple such characteristics. Where the Measurement Group ID is set 479 an additional flag (the Report MA ID flag) is required to control 480 whether the Measurement Agent ID is also to be reported. The 481 reporting of a Group ID without the MA ID allows the MA to remain 482 anonymous, which may be particularly useful to prevent tracking of 483 mobile MA devices. 485 Optionally an MA can also be configured to stop executing any 486 Instruction Schedule if the Controller is unreachable. This can be 487 used as a fail-safe to stop Measurement and other Tasks being 488 conducted when there is doubt that the Instruction Information is 489 still valid. This is simply represented as a time window in seconds 490 since the last communication with the Controller after which 491 Instruction Schedules are to be suspended. The appropriate value of 492 the time window will depend on the specified communication Schedule 493 with the Controller and the duration for which the system is willing 494 to tolerate continued operation with potentially stale Instruction 495 Information. 497 While Pre-Configuration Information is persistent upon device reset 498 or power cycle, the persistency of the Configuration Information may 499 be device dependent. Some devices may revert back to their pre- 500 configuration state upon reboot or factory reset, while other devices 501 may store all Configuration and Instruction information in persistent 502 storage. A Controller can check whether an MA has the latest 503 Configuration and Instruction information by examining the Capability 504 and Status information for the MA. 506 It should be noted that control schedules and tasks cannot be 507 suppressed as evidenced by the lack of suppression information in the 508 Configuration. The control schedule must only reference tasks listed 509 as control tasks (i.e., within the Configuration information). Any 510 suppress-by-default flag against control tasks will be ignored. 512 3.2.1. Definition of ma-config-obj 513 object { 514 uuid ma-config-agent-id; 515 ma-task-obj ma-config-control-tasks<1..*>; 516 ma-channel-obj ma-config-control-channels<1..*>; 517 ma-schedule-obj ma-config-control-schedules<1..*>; 518 [uri ma-config-device-id;] 519 credentials ma-config-credentials; 520 [string ma-config-group-id;] 521 [string ma-config-measurement-point;] 522 [boolean ma-config-report-agent-id;] 523 [boolean ma-config-report-measurement-point;] 524 [int ma-config-controller-timeout;] 525 } ma-config-obj; 527 The ma-config-obj consists of the following elements: 529 ma-config-agent-id: A uuid uniquely identifying the 530 measurement agent. 532 ma-config-control-tasks: An unordered set of task objects. 534 ma-config-control-channels: An unordered set of channel 535 objects. 537 ma-config-control-schedules: An unordered set of scheduling 538 objects. 540 ma-config-device-id: An optional identifier for the 541 device. 543 ma-config-credentials: The security credentials used by 544 the measurement agent. 546 ma-config-group-id: An optional identifier of the 547 group of measurement agents this 548 measurement agent belongs to. 550 ma-config-measurement-point: An optional identifier for the 551 measurement point indicating 552 where the measurement agent is 553 located on a path (see [RFC7398] 554 for further details). 556 ma-config-report-agent-id: An optional flag indicating 557 whether the identifier (ma- 558 config-agent-id) should be 559 included in reports. The default 560 value is false. 562 ma-config-report-measurement-point: An optional flag indicating 563 whether the measurement point 564 (ma-config-measurement-point) 565 should be included in reports. 566 The default value is false. 568 ma-config-controller-timeout: A timer is started after each 569 successful contact with a 570 controller. When the timer 571 reaches the controller-timeout 572 (measured in seconds), an event 573 is raised indicating that 574 connectivity to the controller 575 has been lost (see ma-controller- 576 lost-obj). 578 3.3. Instruction Information 580 The Instruction information model has four sub-elements: 582 1. Instruction Task Configurations 584 2. Report Channels 586 3. Instruction Schedules 588 4. Suppression 590 The Instruction supports the execution of all Tasks on the MA except 591 those that deal with communication with the Controller (specified in 592 (pre-)configuration information). The Tasks are configured in 593 Instruction Task Configurations and included by reference in 594 Instruction Schedules that specify when to execute them. The results 595 can be communicated to other Schedules or a Task may implement a 596 Reporting Protocol and communicate results over Report Channels. 597 Suppression is used to temporarily stop the execution of new Tasks as 598 specified by the Instruction Schedules (and optionally to stop 599 ongoing Tasks). 601 A Task Configuration is used to configure the mandatory and optional 602 parameters of a Task. It also serves to instruct the MA about the 603 Task including the ability to resolve the Task to an executable and 604 specifying the schema for the Task parameters. 606 A Report Channel defines how to communicate with a single remote 607 system specified by a URL. A Report Channel is used to send results 608 to single Collector but is no different in terms of the Information 609 Model to the Control Channel used to transfer information between the 610 MA and the Controller. Several Report Channels can be defined to 611 enable results to be split or duplicated across different 612 destinations. A single Channel can be used by multiple (reporting) 613 Task Configurations to transfer data to the same Collector. A single 614 Reporting Task Configuration can also be included in multiple 615 Schedules. E.g., a single Collector may receive data at three 616 different cycle rates, one Schedule reporting hourly, another 617 reporting daily and a third specifying that results should be sent 618 immediately for on-demand measurement tasks. Alternatively multiple 619 Report Channels can be used to send Measurement Task results to 620 different Collectors. The details of the Channel element is 621 described later as it is common to several objects. 623 Instruction Schedules specify which Actions to execute according to a 624 given triggering Event. An Action is a Task with additional specific 625 parameters. An Event can trigger the execution of a single Action or 626 it can trigger a repeated series of Actions. The Schedule also 627 specifies how to link Tasks output data to other Schedules. 629 Measurement Suppression information is used to over-ride the 630 Instruction Schedule and temporarily stop measurements or other Tasks 631 from running on the MA for a defined or indefinite period. While 632 conceptually measurements can be stopped by simply removing them from 633 the Measurement Schedule, splitting out separate information on 634 Measurement Suppression allows this information to be updated on the 635 MA on a different timing cycle or protocol implementation to the 636 Measurement Schedule. It is also considered that it will be easier 637 for a human operator to implement a temporary explicit suppression 638 rather than having to move to a reduced Schedule and then roll-back 639 at a later time. 641 The explicit Suppression instruction message is able to simply 642 enable/disable all Instruction Tasks (that are enabled for default 643 suppression) as well as having fine control on which Tasks are 644 suppressed. Suppression of both specified Task Configurations and 645 Measurement Schedules is supported. Support for disabling specific 646 Task Configurations allows malfunctioning or mis-configured Tasks or 647 Task Configurations that have an impact on a particular part of the 648 network infrastructure (e.g., a particular Measurement Peer) to be 649 targeted. Support for disabling specific Schedules allows for 650 particularly heavy cycles or sets of less essential Measurement Tasks 651 to be suppressed quickly and effectively. Note that Suppression has 652 no effect on either Controller Tasks or Controller Schedules. 654 When no tasks or schedules are explicitly listed, all Instruction 655 tasks will be suppressed (or not) as indicated by the suppress-by- 656 default flag in the Task Configuration. If tasks or schedules are 657 listed explicitly then only these listed tasks or schedules will be 658 suppressed regardless of the suppress-by-default flag. If both 659 individual tasks and individual schedules are listed then only the 660 listed schedules, plus the listed tasks where present in other 661 schedules, will be suppressed regardless of the suppress-by-default 662 flag. 664 Suppression stops new Tasks from executing. In addition, the 665 Suppression information also supports an additional Boolean that is 666 used to select whether on-going tasks are also to be terminated. 668 Unsuppression is achieved through either overwriting the Measurement 669 Suppression information (e.g., changing 'enabled' to False) or 670 through the use of an End time such that the Measurement Suppression 671 will no longer be in effect beyond this time. The datetime format 672 used for all elements in the information model (e.g., the suppression 673 start and end dates) MUST conform to RFC 3339 [RFC3339]. 675 The goal when defining these four different elements is to allow each 676 part of the information model to change without affecting the other 677 three elements. For example it is envisaged that the Report Channels 678 and the set of Task Configurations will be relatively static. The 679 Instruction Schedule, on the other hand, is likely to be more 680 dynamic, as the measurement panel and test frequency are changed for 681 various business goals. Another example is that measurements can be 682 suppressed with a Suppression command without removing the existing 683 Instruction Schedules that would continue to apply after the 684 Suppression expires or is removed. In terms of the Controller-MA 685 communication this can reduce the data overhead. It also encourages 686 the re-use of the same standard Task Configurations and Reporting 687 Channels to help ensure consistency and reduce errors. 689 3.3.1. Definition of ma-instruction-obj 691 object { 692 ma-task-obj ma-instruction-tasks<0..*>; 693 ma-channel-obj ma-instruction-channels<0..*>; 694 ma-schedule-obj ma-instruction-schedules<0..*>; 695 [ma-suppression-obj ma-instruction-suppressions<0..*>;] 696 } ma-instruction-obj; 698 An ma-instruction-obj consists of the following elements: 700 ma-instruction-tasks: A possibly empty unordered set of task 701 objects. 703 ma-instruction-channels: A possibly empty unordered set of 704 channel objects. 706 ma-instruction-schedules: A possibly empty unordered set of 707 schedule objects. 709 ma-instruction-suppressions: An optional possibly empty unordered 710 set of suppression objects. 712 3.3.2. Definition of ma-suppression-obj 714 object { 715 string ma-suppression-name; 716 [ma-event-obj ma-suppression-start;] 717 [ma-event-obj ma-suppression-end;] 718 [string ma-suppression-tags<0..*>;] 719 [boolean ma-suppression-stop-running;] 720 } ma-suppression-obj; 722 The ma-suppression-obj controls the suppression of schedules or 723 actions and consists of the following elements: 725 ma-suppression-name: A name uniquely identifying a 726 suppression. 728 ma-suppression-start: The optional event indicating when 729 suppression starts. The default value 730 is 'immediate'. 732 ma-suppression-end: The optional event indicating when 733 suppression ends. The default value is 734 'indefinite'. 736 ma-suppression-tags: An optional and possibly empty 737 unordered set of suppression tags. The 738 suppression will apply to all schedules 739 and their actions that have a matching 740 value in their ma-schedule-suppression- 741 tags and all actions that have a 742 matching value in their ma-action- 743 suppression-tags. If not present, this 744 defaults to all measurement schedules 745 and measurement actions. 747 ma-suppression-stop-running: An optional boolean indicating whether 748 suppression will stop any running 749 schedules or actions. The default 750 value for this boolean is false. 752 3.4. Logging Information 754 The MA may report on the success or failure of Configuration or 755 Instruction communications from the Controller. In addition further 756 operational logs may be produced during the operation of the MA and 757 updates to capabilities may also be reported. Reporting this 758 information is achieved in exactly the same manner as scheduling any 759 other Task. We make no distinction between a Measurement Task 760 conducting an active or passive network measurement and one which 761 solely retrieves static or dynamic information from the MA such as 762 capabilities or logging information. One or more logging tasks can 763 be programmed or configured to capture subsets of the Logging 764 Information. These logging tasks are then executed by Schedules 765 which also specify that the resultant data is to be transferred over 766 the Controller Channels. 768 The type of Logging Information will fall into three different 769 categories: 771 1. Success/failure/warning messages in response to information 772 updates from the Controller. Failure messages could be produced 773 due to some inability to receive or parse the Controller 774 communication, or if the MA is not able to act as instructed. 775 For example: 777 * "Measurement Schedules updated OK" 779 * "Unable to parse JSON" 781 * "Missing mandatory element: Measurement Timing" 783 * "'Start' does not conform to schema - expected datetime" 785 * "Date specified is in the past" 787 * "'Hour' must be in the range 1..24" 789 * "Schedule A refers to non-existent Measurement Task 790 Configuration" 792 * "Measurement Task Configuration X registry entry Y not found" 794 * "Updated Measurement Task Configurations do not include M used 795 by Measurement Schedule N" 797 2. Operational updates from the MA. For example: 799 * "Out of memory: cannot record result" 800 * "Collector 'collector.example.com' not responding" 802 * "Unexpected restart" 804 * "Suppression timeout" 806 * "Failed to execute Measurement Task Configuration H" 808 3. Status updates from the MA. For example: 810 * "Device interface added: eth3" 812 * "Supported measurements updated" 814 * "New IP address on eth0: xxx.xxx.xxx.xxx" 816 This Information Model document does not detail the precise format of 817 logging information since it is to a large extent protocol and MA 818 specific. However, some common information can be identified. 820 3.4.1. Definition of ma-log-obj 822 object { 823 uuid ma-log-agent-id; 824 datetime ma-log-event-time; 825 code ma-log-code; 826 string ma-log-description; 827 } ma-log-obj; 829 The ma-log-obj models the generic aspects of a logging object and 830 consists of the following elements: 832 ma-log-agent-id: A uuid uniquely identifying the measurement 833 agent. 835 ma-log-event-time: The date and time of the event reported in 836 the logging object. 838 ma-log-code: A machine readable code describing the 839 event. 841 ma-log-description: A human readable description of the event. 843 3.5. Capability and Status Information 845 The MA will hold Capability Information that can be retrieved by a 846 Controller. Capabilities include the device interface details 847 available to Measurement Tasks as well as the set of Measurement 848 Tasks/Roles (specified by registry entries) that are actually 849 installed or available on the MA. Status information includes the 850 times that operations were last performed such as contacting the 851 Controller or producing Reports. 853 3.5.1. Definition of ma-capability-obj 855 object { 856 string ma-capability-hardware; 857 string ma-capability-firmware; 858 string ma-capability-version; 859 [ma-capability-task-obj ma-capability-tasks<0..*>;] 860 } ma-capability-obj; 862 The ma-capability-obj provides information about the capabilities of 863 the measurement agent and consists of the following elements: 865 ma-capability-hardware: A description of the hardware of the device 866 the measurement agent is running on. 868 ma-capability-firmware: A description of the firmware of the device 869 the measurement agent is running on. 871 ma-capability-version: The version of the measurement agent. 873 ma-capability-tasks: An optional unordered set of capability 874 objects for each supported task. 876 3.5.2. Definition of ma-capability-task-obj 878 object { 879 string ma-capability-task-name; 880 ma-metric-registry-obj ma-capability-task-metrics<0..*>; 881 string ma-capability-task-version; 882 } ma-capability-task-obj; 884 The ma-capability-task-obj provides information about the capability 885 of a task and consists of the following elements: 887 ma-capability-task-name: A name uniquely identifying a task. 889 ma-capability-task-metrics: A possibly empty unordered set of 890 registered metrics and associated roles 891 this task implements. 893 ma-capability-task-version: The version of the measurement task. 895 3.5.3. Definition of ma-status-obj 897 object { 898 uuid ma-status-agent-id; 899 uri ma-status-device-id; 900 datetime ma-status-last-started; 901 ma-interface-obj ma-status-interfaces<0..*>; 902 [ma-status-schedule-obj ma-status-schedules<0..*>;] 903 } ma-status-obj; 905 The ma-status-obj provides status information about the measurement 906 agent and consists of the following elements: 908 ma-status-agent-id: A uuid uniquely identifying the measurement 909 agent. 911 ma-status-device-id: A URI identifying the device. 913 ma-status-last-started: The date and time the measurement agent 914 last started. 916 ma-status-interfaces: An unordered set of network interfaces 917 available on the device. 919 ma-status-schedules: An optional unordered set of status objects 920 for each schedule. 922 3.5.4. Definition of ma-status-schedule-obj 924 object { 925 string ma-status-schedule-name; 926 string ma-status-schedule-state; 927 datetime ma-status-schedule-last-invocation; 928 [ma-status-action-obj ma-status-schedule-actions<0..*>;] 929 } ma-status-schedule-obj; 931 The ma-status-schedule-obj provides status information about that 932 status of a schedule and consists of the following elements: 934 ma-status-schedule-name: The name of the schedule this 935 status object refers to. 937 ma-status-schedule-state: The state of the schedule. The 938 value 'enabled' indicates that 939 the schedule is currently active 940 and enabled. The value 941 'suppressed' indicates that the 942 schedule is currently suppressed. 944 The value 'disabled' indicates 945 that the schedule is currently 946 disabled. 948 ma-status-schedule-last-invocation: The date and time of the last 949 invocation of this schedule. 951 ma-status-schedule-last-invocation: The date and time of the last 952 invocation of this schedule. 954 ma-status-schedule-actions: An optional ordered list of 955 status objects for each action of 956 the schedule. 958 3.5.5. Definition of ma-status-action-obj 960 object { 961 string ma-status-action-name; 962 string ma-status-action-state; 963 datetime ma-status-action-last-invocation; 964 datetime ma-status-action-last-completion; 965 int ma-status-action-last-status; 966 string ma-status-action-last-message; 967 datetime ma-status-action-last-failed-completion; 968 int ma-status-action-last-failed-status; 969 string ma-status-action-last-failed-message; 970 } ma-status-action-obj; 972 The ma-status-action-obj provides status information about an action 973 of a schedule and consists of the following elements: 975 ma-status-action-name: The name of the action of a 976 schedule this status object 977 refers to. 979 ma-status-action-state: The state of the action. 980 The value 'enabled' 981 indicates that the action is 982 currently active and 983 enabled. The value 984 'suppressed' indicates that 985 the action is currently 986 suppressed. The value 987 'disabled' indicates that 988 the action is currently 989 disabled. 991 ma-status-action-last-invocation: The date and time of the 992 last invocation of this 993 action. 995 ma-status-action-last-completion: The date and time of the 996 last completion of this 997 action. 999 ma-status-action-last-status: The status code returned by 1000 the last execution of this 1001 action. 1003 ma-status-action-last-message: The status message produced 1004 by the last execution of 1005 this action. 1007 ma-status-action-last-failed-completion: The date and time of the 1008 last failed completion of 1009 this action. 1011 ma-status-action-last-failed-status: The status code returned by 1012 the last failed execution of 1013 this action. 1015 ma-status-action-last-failed-message: The status message produced 1016 by the last failed execution 1017 of this action. 1019 3.5.6. Definition of ma-interface-obj 1021 object { 1022 string ma-interface-name; 1023 string ma-interface-type; 1024 [int ma-interface-speed;] 1025 [string ma-interface-link-layer-address;] 1026 [ip-address ma-interface-ip-addresses<0..*>;] 1027 [ip-address ma-interface-gateways<0..*>;] 1028 [ip-address ma-interface-dns-servers<0..*>;] 1029 } ma-interface-obj; 1031 The ma-interface-obj provides status information about network 1032 interfaces and consists of the following elements: 1034 ma-interface-name: A name uniquely identifying a 1035 network interface. 1037 ma-interface-type: The type of the network interface. 1039 ma-interface-speed: An optional indication of the speed 1040 of the interface (measured in bits- 1041 per-second). 1043 ma-interface-link-layer-address: An optional link-layer address of 1044 the interface. 1046 ma-interface-ip-addresses: An optional ordered list of IP 1047 addresses assigned to the 1048 interface. 1050 ma-interface-gateways: An optional ordered list of 1051 gateways assigned to the interface. 1053 ma-interface-dns-servers: An optional ordered list of DNS 1054 servers assigned to the interface. 1056 3.6. Reporting Information 1058 At a point in time specified by a Schedule, the MA will execute a 1059 task or tasks that communicate a set of measurement results to the 1060 Collector. These Reporting Tasks will be configured to transmit task 1061 results over a specified Report Channel to a Collector. 1063 It should be noted that the output from Tasks does not need to be 1064 sent to communication Channels. It can alternatively, or 1065 additionally, be sent to other Tasks on the MA. This facilitates 1066 using a first Measurement Task to control the operation of a later 1067 Measurement Task (such as first probing available line speed and then 1068 adjusting the operation of a video testing measurement) and also to 1069 allow local processing of data to output alarms (e.g., when 1070 performance drops from earlier levels). Of course, subsequent Tasks 1071 also include Tasks that implement the reporting protocol(s) and 1072 transfer data to one or more Collector(s). 1074 The Report generated by a Reporting Task is structured hierarchically 1075 to avoid repetition of report header and Measurement Task 1076 Configuration information. The report starts with the timestamp of 1077 the report generation on the MA and details about the MA including 1078 the optional Measurement Agent ID and Group ID (controlled by the 1079 Configuration Information). 1081 Much of the report Information is optional and will depend on the 1082 implementation of the Reporting Task and any parameters defined in 1083 the Task Configuration for the Reporting Task. For example some 1084 Reporting Tasks may choose not to include the Measurement Task 1085 Configuration or scheduled task parameters, while others may do so 1086 dependent on the Controller setting a configurable parameter in the 1087 Task Configuration. 1089 It is possible for a Reporting Task to send just the Report header 1090 (datetime and optional agent ID and/or Group ID) if no measurement 1091 data is available. Whether to send such empty reports again is 1092 dependent on the implementation of the Reporting Task and potential 1093 Task Configuration parameter. 1095 The handling of measurement data on the MA before generating a Report 1096 and transfer from the MA to the Collector is dependent on the 1097 implementation of the device, MA and/or scheduled Tasks and not 1098 defined by the LMAP standards. Such decisions may include limits to 1099 the measurement data storage and what to do when such available 1100 storage becomes depleted. 1102 No context information, such as line speed or broadband product are 1103 included within the report header information as this data is 1104 reported by individual tasks at the time they execute. Either a 1105 Measurement Task can report contextual parameters that are relevant 1106 to that particular measurement, or specific tasks can be used to 1107 gather a set of contextual and environmental data. at certain times 1108 independent of the reporting schedule. 1110 After the report header information the results are reported grouped 1111 according to different Measurement Task Configurations. Each Task 1112 section optionally starts with replicating the Measurement Task 1113 Configuration information before the result headers (titles for data 1114 columns) and the result data rows. The Options reported are those 1115 used for the scheduled execution of the Measurement Task and 1116 therefore include the Options specified in the Task Configuration as 1117 well as additional Options specified in the Scheduled Task. The 1118 Scheduled Task Options are appended to the Task Configuration Options 1119 in exactly the same order as they were provided to the Task during 1120 execution. 1122 The result row data includes a time for the start of the measurement 1123 and optionally an end time where the duration also needs to be 1124 considered in the data analysis. 1126 Some Measurement Tasks may optionally include an indication of the 1127 cross-traffic although the definition of cross-traffic is left up to 1128 each individual Measurement Task. Some Measurement Tasks may also 1129 output other environmental measures in addition to cross-traffic such 1130 as CPU utlilisation or interface speed. 1132 Where the Configuration and Instruction information represent 1133 information transmitted via the Control Protocol, the Report 1134 represents the information that is transmitted via the Report 1135 Protocol. It is constructed at the time of sending a report and 1136 represents the inherent structure of the information that is sent to 1137 the Collector. 1139 3.6.1. Definition of ma-report-obj 1141 object { 1142 datetime ma-report-date; 1143 [uuid ma-report-agent-id;] 1144 [string ma-report-group-id;] 1145 [string ma-report-measurement-point;] 1146 [ma-report-task-obj ma-report-tasks<0..*>;] 1147 } ma-report-obj; 1149 The ma-report-obj provides the meta-data of a single report and 1150 consists of the following elements: 1152 ma-report-date: The date and time when the report was 1153 sent to a collector. 1155 ma-report-agent-id: An optional uuid uniquely identifying 1156 the measurement agent. 1158 ma-report-group-id: An optional identifier of the group of 1159 measurement agents this measurement 1160 agent belongs to. 1162 ma-report-measurement-point: An optional identifier for the 1163 measurement point indicating where the 1164 measurement agent is located on a path 1165 (see [RFC7398] for further details). 1167 ma-report-tasks: An optional and possibly empty 1168 unordered set of tasks result objects. 1170 3.6.2. Definition of ma-report-task-obj 1172 object { 1173 string ma-report-task-name; 1174 [ma-metric-registry-obj ma-report-task-metrics<0..*>;] 1175 [ma-option-obj ma-report-task-options<0..*>;] 1176 [ma-option-obj ma-report-task-action-options<0..*>;] 1177 [string ma-report-task-cycle-id;] 1178 [string ma-report-task-column-labels<0..*>;] 1179 [ma-report-row-obj ma-report-task-rows<0..*>;] 1180 } ma-report-task-obj; 1182 The ma-report-task-obj provides the meta-data of a result report of a 1183 single task. It consists of the following elements: 1185 ma-report-task-name: A name uniquely identifying the task 1186 that produced the results being 1187 reported. 1189 ma-report-task-metrics: An optional and possibly empty 1190 unordered set of registered metrics 1191 and associated rulels that are 1192 reported. 1194 ma-report-task-options: An optional ordered list of task 1195 options provided by the task object. 1197 ma-report-task-action-options: An optional ordered list of action 1198 options provided by the action 1199 object. 1201 ma-report-task-cycle-id: An optional measurement cycle 1202 identifier. 1204 ma-report-task-column-labels: An optional and possibly empty 1205 ordered list of column labels. 1207 ma-report-task-rows: An optional and possibly empty 1208 ordered list of result rows. 1210 3.6.3. Definition of ma-report-row-obj 1212 object { 1213 datetime ma-report-row-start-time; 1214 [datetime ma-report-row-end-time;] 1215 string ma-report-row-conflicts<0..*>; 1216 data ma-report-row-values<0..*>; 1217 } ma-report-row-obj; 1219 The ma-report-row-obj represents a result row and consists of the 1220 following elements: 1222 ma-report-row-start-time: The date and time of the start of the 1223 measurement task that produced the reported 1224 result values. 1226 ma-report-row-end-time: An optional date and time indicating when 1227 the measurement task that produced the 1228 reported result values finished. 1230 ma-report-row-conflicts: A possibly empty set of names of task that 1231 might have impacted the measurement being 1232 reported. 1234 ma-report-row-values: A possibly empty ordered list of result 1235 values. When present, it contains an 1236 ordered list of values that align to the 1237 set of column labels for the report. 1239 3.7. Common Objects: Schedules 1241 A Schedule specifies the execution of a single or repeated series of 1242 Actions. An Action is a Task with additional specific parameters. 1243 Each Schedule contains basically two elements: an ordered list of 1244 Actions to be executed and an Event object for the Schedule. The 1245 Schedule states what Actions to run (with what configuration) and 1246 when to run the Actions. 1248 Multiple Actions contained as an ordered list of a single Measurement 1249 Schedule will be executed according to the execution mode of the 1250 Schedule. In sequential mode, Actions will be executed sequentially 1251 and in parallel mode, all Actions will be executed concurrently. In 1252 pipelined mode, data produced by one Action is passed to the 1253 subsequent Action. Actions contained in different Schedules execute 1254 in parallel with such conflicts being reported in the Reporting 1255 Information where necessary. If two or more Schedules have the same 1256 start time, then the two will execute in parallel. There is no 1257 mechanism to prioritise one schedule over another or to mutex 1258 scheduled tasks. 1260 As well as specifying which Actions to execute, the Schedule also 1261 specifies how to link the data outputs from each Action to other 1262 Schedules. Specifying this within the Schedule allows the highest 1263 level of flexibility since it is even possible to send the output 1264 from different executions of the same Task Configuration to different 1265 destinations. A single Task producing multiple different outputs is 1266 expected to properly tag the different result. An Action receiving 1267 the output can then filter the results based on the tag if necessary. 1268 For example, a Measurement Task might report routine results to a 1269 data Reporting Task in a Schedule that communicates hourly via the 1270 Broadband PPP interface, but also outputs emergency conditions via an 1271 alarm Reporting Task in a different Schedule communicating 1272 immediately over a GPRS channel. Note that task-to-task data 1273 transfer is always specified in association with the scheduled 1274 execution of the sending task - there is no need for a corresponding 1275 input specification for the receiving task. While it is likely that 1276 an MA implementation will use a queue mechanism between the Schedules 1277 or Actions, this Information Model does not mandate or define a 1278 queue, or any potential associated parameters such as storage size 1279 and retention policies. 1281 When specifying the task to execute within the Schedule, i.e., 1282 creating an Action, it is possible to add to the task configuration 1283 option parameters. This allows the Task Configuration to determine 1284 the common characteristics of a Task, while selected parameters 1285 (e.g., the test target URL) are defined within the schedule. A 1286 single Tasks Configuration can even be used multiple times in the 1287 same schedule with different additional parameters. This allows for 1288 efficiency in creating and transferring the Instruction. Note that 1289 the semantics of what happens if an option is defined multiple times 1290 (either in the Task Configuration, Schedule or in both) is not 1291 standardised and will depend upon the Task. For example, some tasks 1292 may legitimately take multiple values for a single parameter. 1294 Where Options are specified in both the Schedule and the Task 1295 Configuration, the Schedule Options are appended to those specified 1296 in the Task Configuration. 1298 Example: An Action of a Schedule references a single Measurement 1299 Task Configuration for measuring UDP latency. It specifies that 1300 results are to be sent to a Schedule with a Reporting Action. 1301 This Reporting Task of the Reporting Action is executed by a 1302 separate Schedule that specifies that it should run hourly at 5 1303 minutes past the hour. When run this Reporting Action takes the 1304 data generated by the UDP latency Measurement Task as well as any 1305 other data to be included in the hourly report and transfers it to 1306 the Collector over the Report Channel specified within its own 1307 Schedule. 1309 3.7.1. Definition of ma-schedule-obj 1311 object { 1312 string ma-schedule-name; 1313 ma-event-obj ma-schedule-event; 1314 ma-action-obj ma-schedule-actions<0..*>; 1315 string ma-schedule-execution-mode; 1316 [string ma-schedule-suppression-tags<0..*>;] 1317 } ma-schedule-obj; 1319 The ma-schedule-obj is the main scheduling object. It consists of 1320 the following elements: 1322 ma-schedule-name: A name uniquely identifying a 1323 scheduling object. 1325 ma-schedule-event: An event object indicating when the 1326 schedule fires. 1328 ma-schedule-actions: A possibly empty ordered list of 1329 actions to invoke when the schedule 1330 fires. 1332 ma-schedule-execution-mode: Indicates whether the actions should be 1333 executed sequentially, in parallel, or 1334 in a pipelined mode (where data 1335 produced by one action is passed to the 1336 subsequent action). The default 1337 execution mode is pipelined. 1339 ma-schedule-suppression-tags: An optional unordered set of 1340 suppression tags. 1342 3.7.2. Definition of ma-action-obj 1344 object { 1345 string ma-action-name; 1346 string ma-action-config-task-name; 1347 [ma-option-obj ma-action-task-options<0..*>;] 1348 [string ma-action-destinations<0..*>;] 1349 [string ma-action-suppression-tags<0..*>;] 1350 } ma-action-obj; 1352 The ma-action-obj models an a task together with its schedule 1353 specific task options and destination tasks. It consists of the 1354 following elements: 1356 ma-action-name: A name uniquely identifying an action 1357 of a scheduling object. 1359 ma-action-config-task-name: A name identifying the configured task 1360 to be invoked by the action. 1362 ma-action-task-options: An optional and possibly empty ordered 1363 list of options (name-value pairs) that 1364 are passed to the task by appending 1365 them to the options configured for the 1366 task object. 1368 ma-action-destinations: An optional and possibly empty 1369 unordered set of names of destination 1370 schedules that consume output produced 1371 by this action. 1373 ma-action-suppression-tags: An optional unordered set of 1374 suppression tags. 1376 3.8. Common Objects: Channels 1378 A Channel defines a bi-directional communication channel between the 1379 MA and a Controller or Collector. Multiple Channels can be defined 1380 to enable results to be split or duplicated across different 1381 Collectors. 1383 Each Channel contains the details of the remote endpoint (including 1384 location and security credential information such as the 1385 certificate). The timing of when to communicate over a Channel is 1386 specified by the Schedule which executes the corresponding Control or 1387 Reporting Task. The certificate can be the digital certificate 1388 associated to the FQDN in the URL or it can be the certificate of the 1389 Certification Authority that was used to issue the certificate for 1390 the FQDN (Fully Qualified Domain Name) of the target URL (which will 1391 be retrieved later on using a communication protocol such as TLS). 1392 In order to establish a secure channel, the MA will use it's own 1393 security credentials (in the Configuration Information) and the given 1394 credentials for the individual Channel end-point. 1396 As with the Task Configurations, each Channel is also given a text 1397 name by which it can be referenced as a Task Option. 1399 Although the same in terms of information, Channels used for 1400 communication with the Controller are referred to as Control Channels 1401 whereas Channels to Collectors are referred to as Report Channels. 1402 Hence Control Channels will be referenced from Control Tasks executed 1403 by a Control Schedule, whereas Report Channels will be referenced 1404 from within Reporting Tasks executed by an Instruction Schedule. 1406 Multiple interfaces are also supported. For example the Reporting 1407 Task could be configured to send some results over GPRS. This is 1408 especially useful when such results indicate the loss of connectivity 1409 on a different network interface. 1411 Example: A Channel used for reporting results may specify that 1412 results are to be sent to the URL (https://collector.example.org/ 1413 report/), using the appropriate digital certificate to establish a 1414 secure channel.. 1416 3.8.1. Definition of ma-channel-obj 1417 object { 1418 string ma-channel-name; 1419 url ma-channel-target; 1420 credentials ma-channel-credentials; 1421 [string ma-channel-interface-name;] 1422 } ma-channel-obj; 1424 The ma-channel-obj consists of the following elements: 1426 ma-channel-name: A unique name identifying the channel 1427 object. 1429 ma-channel-target: A URL identifying the target channel 1430 endpoint. 1432 ma-channel-credentials: The security credentials needed to 1433 establish a secure channel. 1435 ma-channel-interface-name: An optional name of the network interface 1436 to be used. If not present, the system 1437 will select a suitable interface. 1439 3.9. Common Objects: Task Configurations 1441 Conceptually each Task Configuration defines the parameters of a Task 1442 that the Measurement Agent (MA) may perform at some point in time. 1443 It does not by itself actually instruct the MA to perform them at any 1444 particular time (this is done by a Schedule). Tasks can be 1445 Measurement Tasks (i.e., those Tasks actually performing some type of 1446 passive or active measurement) or any other scheduled activity 1447 performed by the MA such as transferring information to or from the 1448 Controller and Collectors. Other examples of Tasks may include data 1449 manipulation or processing Tasks conducted on the MA. 1451 A Measurement Task Configuration is the same in information terms to 1452 any other Task Configuration. Both measurement and non-measurement 1453 Tasks have registry entries to enable the MA to uniquely identify the 1454 Task it should execute and retrieve the schema for any parameters 1455 that may be passed to the Task. Registry entries are specified as a 1456 URI and can therefore be used to identify the Task within a namespace 1457 or point to a web or local file location for the Task information. 1458 As mentioned previously, these URIs may be used to identify the 1459 Measurement Task in a public namespace 1460 [I-D.ietf-ippm-metric-registry]. 1462 Example: A Measurement Task Configuration may configure a single 1463 Measurement Task for measuring UDP latency. The Measurement Task 1464 Configuration could define the destination port and address for 1465 the measurement as well as the duration, internal packet timing 1466 strategy and other parameters (for example a stream for one hour 1467 and sending one packet every 500 ms). It may also define the 1468 output type and possible parameters (for example the output type 1469 can be the 95th percentile mean) where the measurement task 1470 accepts such parameters. It does not define when the task starts 1471 (this is defined by the Schedule element), so it does not by 1472 itself instruct the MA to actually perform this Measurement Task. 1474 The Task Configuration will include a local short name for reference 1475 by a Schedule. Task Configurations may also refer to registry 1476 entries as described above. In addition the Task can be configured 1477 through a set of configuration Options. The nature and number of 1478 these Options will depend upon the Task. These options are expressed 1479 as name-value pairs although the 'value' may be a structured object 1480 instead of a simple string or numeric value. The implementation of 1481 these name-value pairs will vary between data models. 1483 An Option that must be present for Reporting Tasks is the Channel 1484 reference specifying how to communicate with a Collector. This is 1485 included in the task options and will have a value that matches a 1486 channel name that has been defined in the Instruction. Similarly 1487 Control Tasks will have a similar option with the value set to a 1488 specified Control Channel. 1490 A reporting task might also have a flag parameter to indicate whether 1491 to report if there is no measurement result data pending to be 1492 transferred to the Collector. In addition many tasks will also take 1493 as a parameter which interface to operate over. 1495 The Task Configuration also contains a suppress-by-default flag that 1496 specifies the behaviour of a default suppress instruction (that does 1497 not list explicit tasks or schedules). If this flag is set to FALSE 1498 then the Task will not be suppressed. It should be noted that 1499 Controller Tasks are not subject to the suppression instruction and 1500 therefore this flag will be ignored in such cases. 1502 In addition the Task Configuration may optionally also be given a 1503 Measurement Cycle ID. The purpose of this ID is to easily identify a 1504 set of measurement results that have been produced by Measurement 1505 Tasks with comparable Options. This ID could be manually incremented 1506 or otherwise changed when an Option change is implemented which could 1507 mean that two sets of results should not be directly compared. 1509 3.9.1. Definition of ma-task-obj 1511 object { 1512 string ma-task-name; 1513 ma-metric-registry-obj ma-task-metrics<0..*>; 1514 [ma-option-obj ma-task-options<0..*>;] 1515 [boolean ma-task-suppress-by-default;] 1516 [string ma-task-cycle-id;] 1517 } ma-task-obj; 1519 The ma-task-obj defines a configured task that can be invoked as part 1520 of an action. A configured task can be referenced by its name and it 1521 contains a set of URIs to link to a metrics registry or a local 1522 specification of the task. Options allow the configuration of task 1523 parameters (in the form of name-value pairs). The ma-task-obj 1524 consists of the following elements: 1526 ma-task-name: A name uniquely identifying a 1527 configured task object. 1529 ma-task-metrics: A possibly empty unordered set of 1530 registered metrics and associated roles 1531 the configured measurement task will 1532 use. 1534 ma-task-options: An optional and possibly empty ordered 1535 list of options (name-value pairs) that 1536 are passed to the configured task. 1538 ma-task-suppress-by-default: A boolean flag indicating whether this 1539 configured task will be suppressed by 1540 default. The default value of the flag 1541 is true. 1543 ma-task-cycle-id: An optional measurement cycle 1544 identifier that can be used to identify 1545 set of measurement results that have 1546 been produced by this configured tasks 1547 with comparable options. 1549 3.9.2. Definition of ma-option-obj 1551 object { 1552 string ma-option-name; 1553 [object ma-option-value;] 1554 } ma-option-obj; 1556 The ma-option-obj models a name-value pair and consists of the 1557 following elements: 1559 ma-option-name: The name of the option. 1561 ma-option-value: The optional value of the option. 1563 While many of the Task Configuration Options are left to individual 1564 tasks to define, some common Options are used by multiple tasks and 1565 benefit from standardisation. These Options are Channel and Role. 1567 o Channel is used to specify the details of an endpoint for Control 1568 or Reporting Task communications and is detailed elsewhere in this 1569 document. The common option name for specifying the channel is 1570 "channel". 1572 o Role is used to specify which Role the task should be performing 1573 (as defined in the registry) if multiple roles are available. The 1574 common option name for specifying the role is "role". 1576 3.10. Common Objects: Registry Information 1578 Tasks and actions can be associated with entries in a metrics 1579 registry. A metric is identified by a URI and a metric may have 1580 associated roles. 1582 3.10.1. Definition of ma-metric-registry-obj 1584 object { 1585 uri ma-metric-registry-entry; 1586 [string ma-metric-registry-role<0..*>;] 1587 } ma-metric-registry-obj; 1589 The ma-metric-registry-obj defines a registered metric and the 1590 associated role(s). The ma-metric-registry-obj consists of the 1591 following elements: 1593 ma-metric-registry-entry: A URI identifying a metric in a metric 1594 registry. 1596 ma-metric-registry-role: An optional and possibly empty unordered 1597 set of roles for the metric. 1599 3.11. Common Objects: Event Information 1601 The Event information object used throughout the information models 1602 can initially take one of five different forms. Additional forms may 1603 be defined later in order to bind the execution of schedules to 1604 additional events. The initially defined five Event forms are: 1606 1. Periodic Timing: Emits multiple events periodically according to 1607 an interval time defined in milliseconds 1609 2. Calendar Timing: Emits multiple events according to a calendar 1610 based pattern, e.g., 22 minutes past each hour of the day on 1611 weekdays 1613 3. One Off Timing: Emits one event at a specific date and time 1615 4. Immediate: Emits one event as soon as possible 1617 5. Startup: Emits an event whenever the MA is started (e.g., at 1618 device startup) 1620 Optionally each of the Event options may also specify a randomness 1621 that should be evaluated and applied separately to each indicated 1622 event. This randomness parameter defines a uniform interval in 1623 milliseconds over which the start of the task is delayed from the 1624 starting times specified by the timing object. 1626 Both the Periodic and Calendar timing objects allow for a series of 1627 Actions to be executed. While both have an optional end time, it is 1628 best practice to always configure an end time and refresh the 1629 information periodically to ensure that lost MAs do not continue 1630 their tasks forever. 1632 Startup events are only created on device startup, not when a new 1633 Instruction is transferred to the MA. If scheduled task execution is 1634 desired both on the transfer of the Instruction and on device restart 1635 then both the Immediate and Startup timing needs to be used in 1636 conjunction. 1638 The datetime format used for all elements in the information model 1639 MUST conform to RFC 3339 [RFC3339]. 1641 3.11.1. Definition of ma-event-obj 1642 object { 1643 string ma-event-name; 1644 union { 1645 ma-periodic-obj ma-timing-periodic; 1646 ma-calendar-obj ma-timing-calendar; 1647 ma-one-off-obj ma-timing-one-off; 1648 ma-immediate-obj ma-event-immediate; 1649 ma-startup-obj ma-event-startup; 1650 } 1651 [int ma-event-random-spread;] 1652 } ma-event-obj; 1654 The ma-event-obj is the main event object. Event objects are 1655 identified by a name. The generic event object itself contains a 1656 more specific event object and the set of specific event objects 1657 should be extensible. These five initial specific event objects are 1658 further described below. The ma-event-obj also includes an optional 1659 uniform random spread in milliseconds that can be used to randomize 1660 the start times of scheduled tasks. The ma-event-obj consists of the 1661 following elements: 1663 ma-timing-name: The name uniquely identifies an event 1664 object. Schedules refer to event objects 1665 by this name. 1667 ma-timing-periodic: The ma-timing-periodic is present for 1668 periodic timing objects. 1670 ma-timing-calendar: The ma-timing-calendar is present for 1671 calendar timing objects. 1673 ma-timing-one-off: The ma-timing-one-off is present for one- 1674 off timing objects. 1676 ma-timing-immediate: The ma-event-immediate is present for 1677 immediate event objects. 1679 ma-timing-startup: The ma-event-startup is present for startup 1680 event objects. 1682 ma-timing-random-spread: The optional ma-event-random-spread adds a 1683 random delay defined in milliseconds to the 1684 event object. 1686 3.11.2. Definition of ma-periodic-obj 1688 object { 1689 [datetime ma-periodic-start;] 1690 [datetime ma-periodic-end;] 1691 int ma-periodic-interval; 1692 } ma-periodic-obj; 1694 The ma-periodic-obj timing object has an optional start and an 1695 optional end time plus a periodic interval. Schedules using an ma- 1696 periodic-obj are started periodically between the start and end time. 1697 The ma-periodic-obj consists of the following elements: 1699 ma-periodic-start: The optional date and time at which 1700 Schedules using this object are first 1701 started. If not present it defaults to 1702 immediate. 1704 ma-periodic-end: The optional date and time at which 1705 Schedules using this object are last 1706 started. If not present it defaults to 1707 indefinite. 1709 ma-periodic-interval: The interval defines the time in 1710 milliseconds between two consecutive starts 1711 of tasks. 1713 3.11.3. Definition of ma-calendar-obj 1715 Calendar Timing supports the routine execution of Actions at specific 1716 times and/or on specific dates. It can support more flexible timing 1717 than Periodic Timing since the execution of Actions does not have to 1718 be uniformly spaced. For example a Calendar Timing could support the 1719 execution of a Measurement Task every hour between 6pm and midnight 1720 on weekdays only. 1722 Calendar Timing is also required to perform measurements at 1723 meaningful times in relation to network usage (e.g., at peak times). 1724 If the optional timezone offset is not supplied then local system 1725 time is assumed. This is essential in some use cases to ensure 1726 consistent peak-time measurements as well as supporting MA devices 1727 that may be in an unknown timezone or roam between different 1728 timezones (but know their own timezone information such as through 1729 the mobile network). 1731 The calendar elements within the Calendar Timing do not have defaults 1732 in order to avoid accidental high-frequency execution of Tasks. If 1733 all possible values for an element are desired then the wildcard * is 1734 used. 1736 object { 1737 [datetime ma-calendar-start;] 1738 [datetime ma-calendar-end;] 1739 [string ma-calendar-months<0..*>;] 1740 [string ma-calendar-days-of-week<0..*>;] 1741 [string ma-calendar-days-of-month<0..*>;] 1742 [string ma-calendar-hours<0..*>;] 1743 [string ma-calendar-minutes<0..*>;] 1744 [string ma-calendar-seconds<0..*>;] 1745 [int ma-calendar-timezone-offset;] 1746 } ma-calendar-obj; 1748 ma-calendar-start: The optional date and time at which 1749 Schedules using this object are first 1750 started. If not present it defaults to 1751 immediate. 1753 ma-calendar-end: The optional date and time at which 1754 Schedules using this object are last 1755 started. If not present it defaults to 1756 indefinite. 1758 ma-calendar-months: The optional set of months (1-12) on 1759 which tasks scheduled using this object 1760 are started. The wildcard * means all 1761 months. If not present, it defaults to 1762 no months. 1764 ma-calendar-days-of-week: The optional set of days of a week 1765 ("Mon", "Tue", "Wed", "Thu", "Fri", 1766 "Sat", "Sun") on which tasks scheduled 1767 using this object are started. The 1768 wildcard * means all days of the week. 1769 If not present, it defaults to no days. 1771 ma-calendar-days-of-month: The optional set of days of a months 1772 (1-31) on which tasks scheduled using 1773 this object are started. The wildcard 1774 * means all days of a months. If not 1775 present, it defaults to no days. 1777 ma-calendar-hours: The optional set of hours (0-23) on 1778 which tasks scheduled using this object 1779 are started. The wildcard * means all 1780 hours of a day. If not present, it 1781 defaults to no hours. 1783 ma-calendar-minutes: The optional set of minutes (0-59) on 1784 which tasks scheduled using this object 1785 are started. The wildcard * means all 1786 minutes of an hour. If not present, it 1787 defaults to no hours. 1789 ma-calendar-seconds: The optional set of seconds (0-59) on 1790 which tasks scheduled using this object 1791 are started. The wildcard * means all 1792 seconds of an hour. If not present, it 1793 defaults to no seconds. 1795 ma-calendar-timezone-offset: The optional timezone offest in hours. 1796 If not present, it defaults to the 1797 system's local timezone. 1799 If a day of the month is specified that does not exist in the month 1800 (e.g., 29th of Feburary) then those values are ignored. 1802 3.11.4. Definition of ma-one-off-obj 1804 object { 1805 datetime ma-one-off-time; 1806 } ma-one-off-obj; 1808 The ma-one-off-obj timing object specifies a fixed point in time. 1809 Schedules using an ma-one-off-obj are started once at the specified 1810 date and time. The ma-one-off-obj consists of the following 1811 elements: 1813 ma-one-off-time: The date and time at which Schedules using 1814 this object are started. 1816 3.11.5. Definition of ma-immediate-obj 1818 object { 1819 // empty 1820 } ma-immediate-obj; 1822 The ma-immediate-obj event object has no further information 1823 elements. Schedules using an ma-immediate-obj are started as soon as 1824 possible. 1826 3.11.6. Definition of ma-startup-obj 1828 object { 1829 // empty 1830 } ma-startup-obj; 1832 The ma-startup-obj event object has no further information elements. 1833 Schedules or suppressions using an ma-startup-obj are started at MA 1834 initialization time. 1836 3.11.7. Definition of ma-controller-lost-obj 1838 object { 1839 // empty 1840 } ma-controller-lost-obj; 1842 The ma-controller-lost-obj event object has no further information 1843 elements. The ma-controller-lost-obj indicates that connectivity to 1844 the controller has been lost. This is determined by a timer started 1845 after each successful contact with a controller. When the timer 1846 reaches the controller-timeout (measured in seconds), an ma- 1847 controller-lost-obj event is generated. This event may be used to 1848 start a suppression. 1850 3.11.8. Definition of ma-controller-ok-obj 1852 object { 1853 // empty 1854 } ma-controller-ok-obj; 1856 The ma-controller-ok-obj event object has no further information 1857 elements. This ma-controller-ok-obj event indicates that 1858 connectivity to the controller has been established again after it 1859 was lost. This is commonly used to end a suppression. 1861 4. IANA Considerations 1863 This document makes no request of IANA. 1865 Note to RFC Editor: this section may be removed on publication as an 1866 RFC. 1868 5. Security Considerations 1870 This Information Model deals with information about the control and 1871 reporting of the Measurement Agent. There are broadly two security 1872 considerations for such an Information Model. Firstly the 1873 Information Model has to be sufficient to establish secure 1874 communication channels to the Controller and Collector such that 1875 other information can be sent and received securely. Additionally, 1876 any mechanisms that the Network Operator or other device 1877 administrator employs to pre-configure the MA must also be secure to 1878 protect unauthorized parties from modifying pre-configuration 1879 information. These mechanisms are important to ensure that the MA 1880 cannot be hijacked, for example to participate in a DDoS attack. 1882 The second consideration is that no mandated information items should 1883 pose a risk to confidentiality or privacy given such secure 1884 communication channels. For this latter reason items such as the MA 1885 context and MA ID are left optional and can be excluded from some 1886 deployments. This would, for example, allow the MA to remain 1887 anonymous and for information about location or other context that 1888 might be used to identify or track the MA to be omitted or blurred. 1890 The Information Model should support wherever relevant, all the 1891 security and privacy requirements associated with the LMAP Framework. 1893 6. Acknowledgements 1895 The notation was inspired by the notation used in the ALTO protocol 1896 specification. 1898 Philip Eardley, Trevor Burbridge, Marcelo Bagnulo and Juergen 1899 Schoenwaelder worked in part on the Leone research project, which 1900 received funding from the European Union Seventh Framework Programme 1901 [FP7/2007-2013] under grant agreement number 317647. 1903 Juergen Schoenwaelder was partly funded by Flamingo, a Network of 1904 Excellence project (ICT-318488) supported by the European Commission 1905 under its Seventh Framework Programme. 1907 7. References 1909 7.1. Normative References 1911 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1912 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1913 RFC2119, March 1997, 1914 . 1916 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1917 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1918 . 1920 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 1921 Aitken, P., and A. Akhter, "A Framework for Large-Scale 1922 Measurement of Broadband Performance (LMAP)", RFC 7594, 1923 DOI 10.17487/RFC7594, September 2015, 1924 . 1926 7.2. Informative References 1928 [I-D.ietf-ippm-metric-registry] 1929 Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. 1930 Akhter, "Registry for Performance Metrics", draft-ietf- 1931 ippm-metric-registry-05 (work in progress), October 2015. 1933 [I-D.ietf-lmap-yang] 1934 Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 1935 LMAP Measurement Agents", draft-ietf-lmap-yang-01 (work in 1936 progress), July 2015. 1938 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1939 Information Models and Data Models", RFC 3444, DOI 10 1940 .17487/RFC3444, January 2003, 1941 . 1943 [RFC7398] Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 1944 A. Morton, "A Reference Path and Measurement Points for 1945 Large-Scale Measurement of Broadband Performance", RFC 1946 7398, DOI 10.17487/RFC7398, February 2015, 1947 . 1949 Appendix A. Non-editorial Changes since -06 1951 o The default execution mode is pipelined (LI12) 1953 o Added text to define which action consumes data in sequential, 1954 pipelines, and parallel execution mode (LI11) 1956 o Added ma-config-measurement-point, ma-report-measurement-point, 1957 and ma-config-report-measurement-point to configure and report the 1958 measurement point (LI10) 1960 o Turned ma-suppression-obj into a list that uses a start event and 1961 a stop event to define the start and end of suppression; this 1962 unifies the handling of suppression and loss of controller 1963 connectivity (LI09) 1965 o Added ma-controller-lost-obj and ma-controller-ok-obj event 1966 objects (LI09) 1968 o Added ma-status-schedule-obj to report the status of a schedule 1969 and refactored ma-task-status-obj into ma-status-action-obj to 1970 report the status of an action (LI07, LI08) 1972 o Introduced a common ma-metric-registry-obj that identifies a 1973 metric and a set of associated roles and added this object to 1974 expose metric capabilities and to support the configuration of 1975 metrics and to report the metrics used (LI06) 1977 o Introduced ma-capability-obj and ma-capability-task-obj to expose 1978 the capabilities of a measurement agent (LI05) 1980 o Use 'ordered list' or 'unordered set' instead of list, collection, 1981 etc. (LI02) 1983 o Clarification that Actions are part of a Schedule (LI03) 1985 o Deleted terms that are not strictly needed (LI04) 1987 Appendix B. Non-editorial Changes since -05 1989 o A task can now reference multiply registry entries. 1991 o Consistent usage of the term Action and Task. 1993 o Schedules are triggered by Events instead of Timings; Timings are 1994 just one of many possible event sources. 1996 o Actions feed into other Schedules (instead of Actions within other 1997 Schedules). 1999 o Removed the notion of multiple task outputs. 2001 o Support for sequential, parallel, and pipelined execution of 2002 Actions. 2004 Authors' Addresses 2006 Trevor Burbridge 2007 BT 2008 Adastral Park, Martlesham Heath 2009 Ipswich IP5 3RE 2010 United Kingdom 2012 Email: trevor.burbridge@bt.com 2013 Philip Eardley 2014 BT 2015 Adastral Park, Martlesham Heath 2016 Ipswich IP5 3RE 2017 United Kingdom 2019 Email: philip.eardley@bt.com 2021 Marcelo Bagnulo 2022 Universidad Carlos III de Madrid 2023 Av. Universidad 30 2024 Leganes, Madrid 28911 2025 Spain 2027 Email: marcelo@it.uc3m.es 2029 Juergen Schoenwaelder 2030 Jacobs University Bremen 2031 Campus Ring 1 2032 Bremen 28759 2033 Germany 2035 Email: j.schoenwaelder@jacobs-university.de