idnits 2.17.1 draft-ietf-lmap-information-model-00.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 435 has weird spacing: '...ion-obj ma-su...' == Line 447 has weird spacing: '...ask-obj ma-s...' == Line 567 has weird spacing: '...ace-obj ma-...' == Line 574 has weird spacing: '...ity-obj ma-s...' == Line 637 has weird spacing: '...ask-obj ma-re...' == (5 more instances...) -- The document date (February 14, 2014) is 3723 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) == Outdated reference: A later version (-14) exists of draft-ietf-lmap-framework-03 Summary: 0 errors (**), 0 flaws (~~), 9 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 British Telecom 5 Expires: August 18, 2014 M. Bagnulo 6 Universidad Carlos III de Madrid 7 J. Schoenwaelder 8 Jacobs University Bremen 9 February 14, 2014 11 Information Model for Large-Scale Measurement Platforms (LMAP) 12 draft-ietf-lmap-information-model-00 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 August 18, 2014. 47 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. LMAP Information Model . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Information Structure . . . . . . . . . . . . . . . . . . 4 67 3.2. Pre-Configuration Information . . . . . . . . . . . . . . 5 68 3.3. Configuration Information . . . . . . . . . . . . . . . . 6 69 3.4. Instruction Information . . . . . . . . . . . . . . . . . 7 70 3.5. MA to Controller Information . . . . . . . . . . . . . . . 11 71 3.6. Capability and Status Information . . . . . . . . . . . . 13 72 3.7. Reporting Information . . . . . . . . . . . . . . . . . . 14 73 3.8. Channels . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 3.9. Timing Information . . . . . . . . . . . . . . . . . . . . 16 75 3.9.1. Periodic Timing . . . . . . . . . . . . . . . . . . . 17 76 3.9.2. Calendar Timing . . . . . . . . . . . . . . . . . . . 17 77 3.9.3. One-Off Timing . . . . . . . . . . . . . . . . . . . . 18 78 3.9.4. Immediate Timing . . . . . . . . . . . . . . . . . . . 18 79 3.9.5. Timing Randomness . . . . . . . . . . . . . . . . . . 18 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 85 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 A large-scale measurement platform is a collection of components that 91 work in a coordinated fashion to perform measurements from a large 92 number of vantage points. The main components of a large-scale 93 measurement platform are the Measurement Agents (hereafter MAs), the 94 Controller(s) and the Collector(s). 96 The MAs are the elements actually performing the measurements. The 97 MAs are controlled by exactly one Controller at a time and the 98 Collectors gather the results generated by the MAs. In a nutshell, 99 the normal operation of a large-scale measurement platform starts 100 with the Controller instructing a set of one or more MAs to perform a 101 set of one or more Measurement Tasks at a certain point in time. The 102 MAs execute the instructions from a Controller, and once they have 103 done so, they report the results of the measurements to one or more 104 Collectors. The overall framework for a Large Measurement platform 105 as used in this document is described in detail in 106 [I-D.ietf-lmap-framework]. 108 A large-scale measurement platform involves basically three 109 protocols, namely, a Control protocol between a Controller and the 110 MAs, a Report protocol between the MAs and the Collector(s) and 111 several measurement protocols between the MAs and Measurement Peers 112 (MPs), used to actually perform the measurements. In addition some 113 information is required to be provisioned in the MA prior to any 114 communication with the initial Controller. 116 This document defines the information model for both the Control and 117 the Report protocol along with pre-configuration information that is 118 required before communicating with the Controller, broadly named as 119 the LMAP Information Model (or LMAP IM for short). The measurement 120 protocols are out of the scope of this document. 122 As defined in [RFC3444], the LMAP IM defines the concepts involved in 123 a large-scale measurement platform at a high level of abstraction, 124 independent of any specific implementation or actual protocol used to 125 exchange the information. It is expected that the proposed 126 information model can be used with different protocols in different 127 measurement platform architectures and across different types of MA 128 devices (e.g., home gateway, smartphone, PC, router). 130 The definition of an Information Model serves a number of purposes: 132 1. To guide the standardisation of one or more Control and Report 133 protocol and data model implementations 135 2. To enable high-level inter-operability between different Control 136 and Report protocols by facilitating translation between their 137 respective data models such that a Controller could instruct sub- 138 populations of MAs using different protocols 140 3. To from agreement of what information needs to be held by an MA 141 and passed over the Control and Report interfaces and support the 142 functionality described in the LMAP framework 144 4. Enable existing protocols and data models to be assessed for 145 their suitability as part of a large-scale measurement system 147 2. Notation 149 This document use an adaptation of the C-style struct notation to 150 define the fields (names/values) of the objects of the information 151 model. An optional field is enclosed by [ ], and an array is 152 indicated by two numbers in angle brackets, >, where m 153 indicates the minimal number of values, and n is the maximum. The 154 symbol * for n means no upper bound. 156 3. LMAP Information Model 158 3.1. Information Structure 160 The information described herein relates to the information stored, 161 received or transmitted by a Measurement Agent as described within 162 the LMAP framework [I-D.ietf-lmap-framework]. As such, some subsets 163 of this information model are applicable to the measurement 164 Controller, Collector and systems that pre-configure the Measurement 165 Agent. The information described in these models will be transmitted 166 across the protocols and interfaces between the Measurement Agent and 167 such systems according to a Data Model. 169 For clarity the information model is divided into six sections: 171 1. Pre-Configuration Information. Information pre-configured on the 172 Measurement Agent prior to any communication with other 173 components of the LMAP architecture (i.e., the Controller, 174 Collector and Measurement Peers), specifically detailing how to 175 communicate with an initial Controller and whether the device is 176 enabled to participate as an MA. 178 2. Configuration Information. Information delivered to the MA on 179 registration with a Controller or updated during a later 180 communication, in particular detailing how to retrieve 181 measurement and reporting instruction information from a 182 Controller along with information specifically about the MA. 184 3. Instruction Information. Information that is received by the MA 185 from the Controller pertaining to the measurement and reporting 186 configuration. This includes measurement configuration, report 187 channel configuration, measurement schedules and measurement 188 suppression information. 190 4. MA to Controller Information. Information transmitted from the 191 MA to the Controller detailing the results of any configuration 192 operations along with error and status information from the 193 operation of the MA. 195 5. Capability and Status Information. Information on the general 196 status and capabilities of the MA. For example, the set of 197 measurements that are supported on the device. 199 6. Reporting Information. Information transmitted from the MA to 200 the Collector including measurement results and the context in 201 which they were conducted. 203 In addition the MA may hold further information not described herein, 204 and which may be optionally transferred to or from other systems 205 including the Controller and Collector. One example of information 206 in this category is subscriber or line information that may be 207 reported by the MA as optional fields in the reporting communication 208 to a Collector. 210 It should also be noted that the MA may be in communication with 211 other management systems which may be responsible for configuring and 212 retrieving information from the MA device. Such systems, where 213 available, can perform an important role in transferring the pre- 214 configuration information to the MA or enabling/disabling the 215 measurement functionality of the MA. 217 The Information Model is divided into sub-sections for a number of 218 reasons. Firstly the grouping of information facilitates reader 219 understanding. Secondly, the particular groupings chosen are 220 expected to map to different protocols or different transmissions 221 within those protocols. 223 3.2. Pre-Configuration Information 225 This information is the minimal information that needs to be pre- 226 configured to the MA in order for it to successfully communicate with 227 a Controller during the registration process. 229 This pre-configuration information needs to include a URL of the 230 initial Controller where configuration information can be retrieved 231 along with the security information required for the communication 232 including the certificate of the Controller (or the certificate of 233 the Certification Authority which was used to issue the certificate 234 for the Controller) as well as the timing for that communication. 235 All this is expressed as the Instruction Channel. As part of the 236 Instruction Channel, the MA's security information is configured 237 which can be either a certificate and a private key or a password, 238 depending on the security solution used. 240 The MA may already be pre-configured with an MA ID, or may use a 241 Device ID in the initial Controller contact before it is assigned an 242 MA ID. The Device ID may be a MAC address or some other device 243 identifier expressed as a URN. 245 Detail of the information model elements: 247 object { 248 ma-channel-obj ma-instruction-channel; 249 ma-channel-obj ma-ma-to-controller-channel; 250 [urn ma-device-id;] 251 [uuid ma-agent-id;] 252 } ma-preconfig-obj; 254 The detail of the Channel object is described later since it is 255 common to several parts of the information model. 257 3.3. Configuration Information 259 During registration or at any later point at which the MA contacts 260 the Controller, the choice of Controller and details for the timing 261 of communication with the Controller can be changed (as captured by 262 the Instruction Channel information object). For example the pre- 263 configured Controller may be replaced with a specific Controller that 264 is more appropriate to the MA device type, location or 265 characteristics of the network (e.g. access technology type or 266 broadband product). The initial communication timing object may be 267 replaced with one more relevant to routine communications between the 268 MA and the Controller. 270 In addition the MA will be given further items of information that 271 relate specifically to the MA rather than the measurements it is to 272 conduct or how to report results. The assignment of an ID to the MA 273 is mandatory. Optionally a Group ID may also be given which 274 identifies a group of interest to which that MA belongs. For example 275 the group could represent an ISP, broadband product, technology, 276 market classification, geographic region, or a combination of 277 multiple such characteristics. Where the Measurement Group ID is set 278 an additional flag (the Report MA ID flag) is required to control 279 whether the Measurement Agent ID is also to be reported. The 280 reporting of a Group ID without the MA ID allows the MA to remain 281 anonymous, which may be particularly useful to prevent tracking of 282 mobile MA devices. 284 Optionally an MA can also be configured to stop Measurement Tasks if 285 the Controller is unreachable. This can be used as a fail-safe to 286 stop Measurement Tasks being conducted when there is doubt that the 287 Instruction Information is still valid. This is simply represented 288 as a number of failed communication attempts before Measurement Tasks 289 are suspended. The appropriate number of failed attempts will depend 290 on the timing of the Instruction Channel and the duration for which 291 the system is willing to tolerate continued operation with 292 potentially stale Instruction Information. 294 Detail of the additional information model elements: 296 object { 297 uuid ma-agent-id; 298 ma-channel-obj ma-instruction-channel; 299 [string ma-group-id;] 300 [boolean ma-report-ma-id-flag;] 301 [int ma-instruction-channel-failure-threshold;] 302 } ma-config-obj; 304 3.4. Instruction Information 306 The Instruction information model has four sub-elements: 308 1. Measurement Task Configurations 310 2. Report Channels 312 3. Measurement Schedules 314 4. Measurement Suppression 316 Conceptually each Measurement Task Configuration defines the 317 parameters of a Measurement Task that the Measurement Agent (MA) may 318 perform at some point in time. It does not by itself actually 319 instruct the MA to perform them at any particular time (this is done 320 by a Measurement Schedule). 322 Example: A Measurement Task Configuration may configure a single 323 Measurement Task for measuring UDP latency. The Measurement Task 324 Configuration could define the destination port and address for 325 the measurement as well as the duration, internal packet timing 326 strategy and other parameters (for example a stream for one hour 327 and sending one packet every 500 ms). It may also define the 328 output type and possible parameters (for example the output type 329 can be the 95th percentile mean) where the measurement task 330 accepts such parameters. It does NOT define when the task starts 331 (this is defined by the Measurement Schedule element), so it does 332 not by itself instruct the MA to actually perform this measurement 333 task. 335 The Measurement Task Configuration will include a local short name 336 for reference by the Measurement Schedule, along with a registry 337 entry [I-D.bagnulo-ippm-new-registry] that defines the Measurement 338 Task. The MA itself will resolve the registry entry to a local 339 executable program. In addition the Measurement Task is specialised 340 through a set of configuration Options. The nature and number of 341 these Options will depend upon the Measurement Task and will be 342 defined in the Measurement Task Registry. In addition the 343 Measurement Task Configuration may optionally also be given a 344 Measurement Cycle ID. The purpose of this ID is to easily identify a 345 set of measurement results that have been produced by Measurement 346 Tasks with comparable Options. This ID is manually incremented when 347 an Option change is implemented which could mean that two sets of 348 results should not be directly compared. 350 A Report Channel defines how to report results to a single Collector. 351 Several Report Channels can be defined to enable results to be split 352 or duplicated across different report intervals or destinations. 353 E.g. a single Collector may have three Report Channels, one reporting 354 hourly, another reporting daily and a third on which to send 355 immediate results for on-demand measurement tasks. Alternatively 356 multiple Report Channels can be used to send Measurement Task results 357 to different Collectors. The details of the Channel element is 358 described later as it is common to several objects. 360 A Measurement Schedule contains the Instruction from the Controller 361 to the MA to execute a single or repeated series of Measurement 362 Tasks. Each Measurement Schedule contains basically two elements: a 363 reference to a list of Measurement Task Configuration and a timing 364 object for the schedule. The schedule basically states what 365 measurement task to run, how to report the results per Measurement 366 Task Configuration, and when to run the measurement task. Multiple 367 measurement tasks in the list will be executed in order with minimal 368 gaps. Note that the Controller can instruct the MA to report to 369 several Collectors by specifying several Report Channels. 371 Each Measurement Task Configuration named in the Measurement Schedule 372 can be allocated to independent Report Channels, giving flexibility 373 to report different Measurement Tasks to different Collectors or on 374 different timings. Furthermore, as each Measurement Task may have 375 multiple data outputs, these outputs can each be assigned to 376 different Report Channels. For example a Measurement Task might 377 report routine results hourly via the Broadband PPP interface, but 378 also output emergency conditions immediately via a GPRS channel. 380 Example: a Measurement Schedule references a single Measurement Task 381 Configuration for the UDP latency defined in the previous example. 382 It references the Report Channel in the previous example to send 383 results immediately as available to the specified Collector. The 384 timing is specified to run the configured Measurement Task 385 Configuration every hour at 23 minutes past the hour. 387 Measurement Suppression information is used to over-ride the 388 Measurement Schedule and stop measurements from the MA for a defined 389 or indefinite period. While conceptually measurements can be stopped 390 by simply removing them from the Measurement Schedule, splitting out 391 separate information on Measurement Suppression allows this 392 information to be updated on the MA on a different timing cycle or 393 protocol implementation to the Measurement Schedule. It is also 394 considered that it will be easier for a human operator to implement a 395 temporary explicit suppression rather than having to move to a 396 reduced Schedule and then roll-back at a later time. The explicit 397 Suppression instruction message is able to simply enable/disable all 398 Measurement Tasks as well as having fine control on which Tasks are 399 suppressed. Suppression of both specified Measurement Tasks 400 Configurations and Measurement Schedules is supported. Support for 401 disabling specific Measurement Task Configurations allows 402 malfunctioning or mis-configured Measurement Tasks or Measurement 403 Task Configurations that have an impact on a particular part of the 404 network infrastructure (e.g., a particular Measurement Peer) to be 405 targetted. Support for disabling specific Measurement Schedules 406 allows for particularly heavy cycles or sets of less essential 407 Measurement Tasks to be suppressed quickly and effectively. 409 Unsuppression is achieved through either overwriting the Measurement 410 Suppression information (e.g. changing 'enabled' to False) or through 411 the use of an End time such that the Measurement Suppression will no 412 longer be in effect beyond this time. 414 The goal when defining these four different elements is to allow each 415 part of the information model to change without affecting the other 416 three elements. For example it is envisaged that the Report Channels 417 and the set of Measurement Tasks Configurations will be relatively 418 static. The Measurement Schedule on the other hand is likely to be 419 more dynamic as the measurement panel and test frequency are changed 420 for various business goals. Another example is that measurements can 421 be suppressed with a Measurement Suppression command without removing 422 the existing Measurement Schedules that would continue to apply after 423 the Measurement Suppression expires or is removed. In terms of the 424 Controller-MA communication this can reduce the data overhead. It 425 also encourages the re-use of the same standard Measurement Task 426 Configurations and Reporting Channels to help ensure consistency and 427 reduce errors. 429 Definition of the information model elements: 431 object { 432 ma-task-obj ma-tasks<0..*>; 433 ma-channel-obj ma-report-channels<0..*>; 434 ma-schedule-obj ma-schedules<0..*>; 435 ma-suppression-obj ma-suppression; 436 } ma-instruction-obj; 438 object { 439 string ma-task-name; 440 urn ma-task-registry; 441 string ma-task-options<0..*>; 442 [string ma-task-cycle-id;] 443 } ma-task-obj; 445 object { 446 string ma-schedule-name; 447 ma-sched-task-obj ma-schedule-tasks<0..*>; 448 ma-timing-obj ma-schedule-timing; 449 } ma-schedule-obj; 451 object { 452 string ma-schedule-task-name; 453 ma-sched-report-obj ma-schedule-task-reports<0..*>; 454 } ma-sched-task-obj; 456 object { 457 [int ma-schedule-task-filter;] // default: all 458 string ma-schedule-task-report-channel-name; 459 } ma-sched-report-obj; 460 object { 461 boolean ma-suppression-enabled; 462 [datetime ma-suppression-start;] // default: immediate 463 [datetime ma-suppression-end;] // default: indefinite 464 [string ma-suppression-task-names<0..*>;] 465 // default: all tasks if 466 // ma-suppression-task-names is empty 467 [string ma-suppression-schedule-names<0..*>;] 468 // default: all schedules if 469 // ma-suppression-schedule-names is empty 470 } ma-suppression-obj; 472 3.5. MA to Controller Information 474 The MA may report on the success or failure of Configuration or 475 Instruction communications from the Controller. In addition further 476 operational logs may be produced during the operation of the MA and 477 updates to capabilities may also be reported. Reporting this 478 information is achieved simply and flexibly in exactly the same 479 manner as any Measurement Task. We make no distinction between a 480 Measurement Task conducting an active or passive network measurement 481 and one which solely retrieves static information from the MA such as 482 logging information. One or more logging tasks can be programmed or 483 configured to capture subsets of the MA to Controller Information. 484 These logging tasks are then executed by Measurement Schedules (if 485 not permanently running) and the resultant data assigned to the MA to 486 Controller Channel. 488 The type of MA to Controller Information will fall into three 489 different categories: 491 1. Success/failure/warning messages in response to information 492 updates from the Controller. Failure messages could be produced 493 due to some inability to receive or parse the Controller 494 communication, or if the MA is not able to act as instructed. 495 For example: 497 * "Measurement Schedules updated OK" 499 * "Unable to parse JSON" 501 * "Missing mandatory element: Measurement Timing" 503 * "'Start' does not conform to schema - expected datetime" 505 * "Date specified is in the past" 506 * "'Hour' must be in the range 1..24" 508 * "Schedule A refers to non-existent Measurement Task 509 Configuration" 511 * "Measurement Task Configuration X registry entry Y not found" 513 * "Updated Measurement Task Configurations do not include M used 514 by Measurement Schedule N" 516 2. Operational updates from the MA. For example: 518 * "Out of memory: cannot record result" 520 * "Collector 'collector.example.com' not responding" 522 * "Unexpected restart" 524 * "Suppression timeout" 526 * "Failed to execute Measurement Task Configuration H" 528 3. Status updates from the MA. For example: 530 * "Interface added: eth3 " 532 * "Supported measurements updated" 534 * "New IP address on eth0: xxx.xxx.xxx.xxx" 536 This Information Model document does not detail the precise format of 537 logging information since it is to a large extend protocol and 538 measurement task specific. However, some common information can be 539 identified. 541 MA Logging information model elements: 543 object { 544 uuid ma-log-agent-id; 545 datetime ma-log-event-time; 546 code ma-log-code; 547 string ma-log-description; 548 } ma-log-obj; 550 3.6. Capability and Status Information 552 The MA will hold Capability Information that can be retrieved by a 553 Controller. Capabilities include the interface details available to 554 Measurement Tasks and Reports as well as the set of Measurement Tasks 555 that are actually installed or available on the MA. Status 556 information includes the times that operations were last performed 557 such as contacting the Controller or producing Reports. 559 MA Status information model elements: 561 object { 562 uuid ma-agent-id; 563 urn ma-device-id; 564 string ma-hardware; 565 string ma-firmware; 566 string ma-software; 567 ma-interface-obj ma-interfaces<0..*>; 569 datetime ma-last-measurement; 570 datetime ma-last-report; 571 datetime ma-last-instruction; 572 datetime ma-last-configuration; 574 ma-capability-obj ma-supported-measurements<0..*>; 575 } ma-status-obj; 577 object { 578 string ma-interface-name; 579 string ma-interface-type; 580 int ma-interface-speed; // mbps 581 string ma-link-layer-address; 582 ip-address ma-interface-ip-addresses<0..*>; 583 [ip-address ma-interface-gateways<0..*>;] 584 [ip-address ma-interface-dns-servers<0..*>;] 585 } ma-interface-obj; 587 object { 588 urn ma-measurement-id; 589 [string ma-measurement-version;] 590 } ma-capability-obj; 592 3.7. Reporting Information 594 At a point in time specific by the Report Channel, the MA will 595 communicate a set of measurement results to the Collector. These 596 measurement results should be communicated within the context in 597 which they were collected. 599 It should be noted that Collectors can be implemented by many types 600 of devices and systems, including the MA itself. In this manner data 601 from Measurement Tasks can (also) be stored locally on the MA and 602 used as input by other Measurement Tasks. This facilitates using a 603 first Measurement Task to control the operation of a later 604 Measurement Task (such as probing available line speed) and also to 605 allow local processing of data to output alarms (e.g. when 606 performance drops from earlier levels). 608 The report is structured hierarchically to avoid repetition of 609 report, Measurement Agent and Measurement Task Configuration 610 information. The report starts with the timestamp of the report 611 generation on the MA and details about the MA including the optional 612 Measurement Agent ID and Group ID (controlled by the Configuration 613 Information). In addition optional further MA context information 614 can be included at this point such as the line sync speed or ISP and 615 product if known by the MA. 617 After the MA information the results are reported grouped into the 618 different Measurement Tasks. Each Measurement Task starts with 619 replicating the Measurement Task Configuration information before the 620 result headers (titles for data columns) and the result data rows. 621 The result data rows may optionally include an indication of the 622 cross-traffic (e.g., the total number of octets of non-measurement 623 traffic passing through the interfaces used by a Measurement Task 624 during the measurement period). 626 The datetime format used for all elements in the information model 627 (i.e., Report Date and Measurement Time in the Reporting Information) 628 MUST conform to RFC 3339 [RFC3339] and ISO8601. 630 Information model elements: 632 object { 633 datetime ma-report-date; 634 [uuid ma-report-agent-id;] 635 [string ma-report-group-id;] 636 ma-context-obj ma-report-context<0..*>; 637 ma-report-task-obj ma-report-tasks<0..*>; 638 } ma-report-obj; 639 object { 640 ma-task-obj ma-report-task-config; 641 string ma-report-task-column-headers<0..*>; 642 ma-result-row-obj ma-report-task-rows<0..*>; 643 } ma-report-task-obj; 645 object { 646 datetime ma-report-result-time; 647 [int ma-report-result-cross-traffic;] 648 data ma-report-result-values<0..*>; 649 } ma-result-row-obj; 651 The ma-context-obj, which covers things like line speed or the device 652 type, is not further detailed here. 654 3.8. Channels 656 A Channel defines a communication channel between the MA and other 657 element of the measurement framework i.e. with the Collector to 658 report results back, to Controller to retrieve Instructions or other 659 information exchanged between the parties. Several Channels can be 660 defined to enable results to be split or duplicated across different 661 report intervals or destinations. E.g. a single Collector may have 662 three Report Channels, one reporting hourly, another reporting daily 663 and a third on which to send immediate results for on-demand 664 measurement tasks. 666 Each Channel contains the details of the target (including location 667 and security information such as the certificate), and the timing for 668 the communication i.e. when to establish the communication. The 669 certificate can be the digital certificate associated to the FQDN in 670 the URL or it can be the certificate of the Certification Authority 671 that was used to issue the certificate for the FQDN (Fully Qualified 672 Domain Name) of the target URL (which will be retrieved later on 673 using a communication protocol such as SSL). The Channel can use the 674 same timing information object as a Measurement Schedule and the 675 Controller Communication Timing defined earlier. There are several 676 options, such as immediately after the results are obtained or at a 677 given interval or calendar based cycle). As with the Measurement 678 task Configuration, each Channel is also given a local short name by 679 which it can be referenced from a Measurement Schedule or other 680 elements. 682 As for Measurement Tasks, multiple interfaces are also supported. 683 For example the Controller could choose to receive some results over 684 GPRS. This is especially useful when such results indicate the loss 685 of connectivity on a different network interface. 687 Facility is also provided for the Controller to choose whether to 688 receive empty reports where there is no Measurement Task information. 689 In some cases this may be desirable to monitor the health of the 690 measurement system. 692 Example: A Channel using for reporting results may specify that 693 results are to be sent to the URL 694 (https://collector.foo.org/report/), using the appropriate digital 695 certificate to establish a secure channel. The Channel specifies 696 that the results are to be sent immediately as available and not 697 batched. 699 object { 700 string ma-channel-name; 701 url ma-channel-target; 702 certificate ma-channel-certificate; 703 ma-timing-obj ma-channel-timing; 704 [string ma-channel-interface-name;] 705 [boolean ma-channel-connect-always;] 706 // default: false 707 // (only connect when data is pending) 708 } ma-channel-obj; 710 3.9. Timing Information 712 The Timing information object used throughout the information models 713 can take one of four different forms: 715 1. Periodic. Specifies a start, end and interval time in 716 milliseconds 718 2. Calendar: Specifies a calendar based pattern - e.g. 22 minutes 719 past each hour of the day on weekdays 721 3. One Off: A single instance occurring at a specific time 723 4. Immediate: Should occur as soon as possible 725 Optionally each of the first three options may also specify a 726 randomness that should be evaluated and applied separately to each 727 indicated event. 729 The datetime format used for all elements in the information model 730 (i.e., Report Date and Measurement Time in the Reporting Information) 731 MUST conform to RFC 3339 [RFC3339] and ISO8601. 733 object { 734 [string ma-timing-name;] 735 union { 736 ma-periodic-obj ma-timing-periodic; 737 ma-calendar-obj ma-timing-calendar; 738 ma-one-off-obj ma-timing-one-off; 739 ma-immediate-obj ma-timing-immediate; 740 } 741 [ma-randomness-obj ma-timing-randomness;] 742 } ma-timing-obj; 744 3.9.1. Periodic Timing 746 Information model elements: 748 object { 749 [datetime ma-periodic start;] // default: immediate 750 [datetime ma-periodic-end;] // default: indefinite 751 int ma-periodic-interval; // milliseconds 752 } ma-periodic-obj; 754 3.9.2. Calendar Timing 756 Calendar Timing supports the routine execution of Measurement Tasks 757 at specific times and/or on specific dates. It can support more 758 flexible timing than Periodic Timing since the Measurement Task 759 execution does not have to be uniformly spaced. For example a 760 Calendar Timing could support the execution of a Measurement Task 761 every hour between 6pm and midnight on weekdays only. 763 Calendar Timing is also required to perform measurements at 764 meaningful instances in relation to network usage (e.g., at peak 765 times). If the optional timezone offset is not supplied then local 766 system time is assumed. This is essential in some use cases to 767 ensure consistent peak-time measurements as well as supporting MA 768 devices that may be in an unknown timezone or roam between different 769 timezones (but know their own timezone information such as through 770 the mobile network). 772 Information model elements: 774 object { 775 [datetime ma-calendar-start;] // default: immediate 776 [datetime ma-calendar-end;] // default: indefinite 777 [int ma-calendar-months<0..*>;] // default: 1-12 778 [days ma-calendar-weekdays<0..*>;] // default: all 779 [int ma-calendar-hours<0..*>;] // default: 0-23 780 [int ma-calendar-minutes<0..*>;] // default: 0-59 781 [int ma-calendar-seconds<0..*>;] // default: 0-59 782 [int ma-calendar-timezone-offset;] 783 // default: system timezone offset 784 } ma-calendar-obj; 786 3.9.3. One-Off Timing 788 Information model elements: 790 object { 791 datetime ma-one-off-time; 792 } ma-one-off-obj; 794 3.9.4. Immediate Timing 796 The immediate timing object has no further information elements. The 797 measurement or report is simply to be done as soon as possible. 799 object { 800 // empty 801 } ma-immediate-obj; 803 3.9.5. Timing Randomness 805 The Timing randomness object specifies a random distribution that can 806 be applied to any scheduled execution event such as a measurement or 807 report. The intention it to be able to spread the load on the 808 Controller, Collector and network in an automated manner for a large 809 number of Measurement Agents. The randomness is expressed as a 810 distribution (e.g. Poison, Normal, Uniform etc.) along with the 811 spread over which the distribution should be applied. In additional 812 optional upper and lower bounds can be applied to control extreme 813 spread of timings. 815 Information model elements: 817 object { 818 string ma-randomness-distribution; 819 [int ma-randomness-lower-cut;] 820 [int ma-randomness-upper-cut;] 821 int ma-randomness-spread; 823 } ma-randomness-obj; 825 4. IANA Considerations 827 This document makes no request of IANA. 829 Note to RFC Editor: this section may be removed on publication as an 830 RFC. 832 5. Security Considerations 834 This Information Model deals with information about the control and 835 reporting of the Measurement Agent. There are broadly two security 836 considerations for such an Information Model. Firstly the 837 Information Model has to be sufficient to establish secure 838 communication channels to the Controller and Collector such that 839 other information can be sent and received securely. Additionally, 840 any mechanisms that the Network Operator or other device 841 administrator employs to pre-configure the MA must also be secure to 842 protect unauthorized parties from modifying pre-configuration 843 information. The second consideration is that no mandated 844 information items pose a risk to confidentiality or privacy given 845 such secure communication channels. For this latter reason items 846 such as the MA context and MA ID are left optional and can be 847 excluded from some deployments. This would, for example, allow the 848 MA to remain anonymous and for information about location or other 849 context that might be used to identify or track the MA to be omitted 850 or blurred. 852 6. Acknowledgements 854 The notation was inspired by the notation used in the ALTO protocol 855 specification. 857 Philip Eardley, Trevor Burbridge, Marcelo Bagnulo and Juergen 858 Schoenwaelder work in part on the Leone research project, which 859 receives funding from the European Union Seventh Framework Programme 860 [FP7/2007-2013] under grant agreement number 317647. 862 7. References 863 7.1. Normative References 865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 866 Requirement Levels", BCP 14, RFC 2119, March 1997. 868 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 869 Internet: Timestamps", RFC 3339, July 2002. 871 7.2. Informative References 873 [I-D.bagnulo-ippm-new-registry] 874 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 875 A. Morton, "A registry for commonly used metrics", 876 draft-bagnulo-ippm-new-registry-01 (work in progress), 877 July 2013. 879 [I-D.ietf-lmap-framework] 880 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 881 Aitken, P., and A. Akhter, "A framework for large-scale 882 measurement platforms (LMAP)", 883 draft-ietf-lmap-framework-03 (work in progress), 884 January 2014. 886 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 887 Information Models and Data Models", RFC 3444, 888 January 2003. 890 Authors' Addresses 892 Trevor Burbridge 893 British Telecom 894 Adastral Park, Martlesham Heath 895 Ipswich, IP5 3RE 896 United Kingdom 898 Philip Eardley 899 British Telecom 900 Adastral Park, Martlesham Heath 901 Ipswich, IP5 3RE 902 United Kingdom 903 Marcelo Bagnulo 904 Universidad Carlos III de Madrid 905 Av. Universidad 30 906 Leganes, Madrid, 28911 907 Spain 909 Juergen Schoenwaelder 910 Jacobs University Bremen 911 Campus Ring 1 912 Bremen, 28759 913 Germany