idnits 2.17.00 (12 Aug 2021) /tmp/idnits56507/draft-burbridge-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 04, 2013) is 3242 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '1-12' is mentioned on line 556, but not defined == Missing Reference: 'Mon-Sun' is mentioned on line 560, but not defined == Missing Reference: '1-31' is mentioned on line 564, but not defined == Missing Reference: '1-24' is mentioned on line 568, but not defined == Missing Reference: '1-60' is mentioned on line 575, but not defined == Outdated reference: A later version (-01) exists of draft-bagnulo-ippm-new-registry-00 == Outdated reference: A later version (-02) exists of draft-eardley-lmap-framework-01 == Outdated reference: A later version (-02) exists of draft-eardley-lmap-terminology-01 Summary: 0 errors (**), 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: Informational British Telecom 5 Expires: January 05, 2014 M. Bagnulo 6 Universidad Carlos III de Madrid 7 J. Schoenwaelder 8 Jacobs University 9 July 04, 2013 11 Information Model for Large-Scale Measurement Platforms (LMAP) 12 draft-burbridge-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 the 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 January 05, 2014. 47 Copyright Notice 48 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. LMAP Information Model . . . . . . . . . . . . . . . . . . . 3 65 2.1. Information Structure . . . . . . . . . . . . . . . . . . 3 66 2.2. Pre-Configuration Information . . . . . . . . . . . . . . 4 67 2.3. Configuration Information . . . . . . . . . . . . . . . . 5 68 2.4. Instruction Information . . . . . . . . . . . . . . . . . 6 69 2.5. Logging Information . . . . . . . . . . . . . . . . . . . 9 70 2.6. Status Information . . . . . . . . . . . . . . . . . . . 10 71 2.7. Reporting Information . . . . . . . . . . . . . . . . . . 10 72 2.8. Timing Information . . . . . . . . . . . . . . . . . . . 11 73 2.8.1. Periodic Timing . . . . . . . . . . . . . . . . . . . 12 74 2.8.2. Calendar Timing . . . . . . . . . . . . . . . . . . . 12 75 2.8.3. One-Off Timing . . . . . . . . . . . . . . . . . . . 13 76 2.8.4. Immediate Timing . . . . . . . . . . . . . . . . . . 13 77 2.8.5. Timing Randomness . . . . . . . . . . . . . . . . . . 13 78 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 81 6. Informative References . . . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 A large-scale measurement platform is a collection of components that 87 work in a coordinated fashion to perform measurements from a large 88 number of vantage points. The main components of a large-scale 89 measurement platform are the Measurement Agents (hereafter MAs), the 90 Controllers and the Collectors. 92 The MAs are the elements actually performing the measurements. The 93 MAs are controlled by one or more Controllers and the Collectors 94 gather the results generated by the MAs. In a nutshell, the normal 95 operation of a large-scale measurement platform starts with the 96 Controller instructing a set of MAs to perform a set of measurements 97 at a certain point in time. The MAs execute the instructions from 98 the Controller and once they have done so they report the results of 99 the measurements to the Collector. The overall framework for a Large 100 Measurement platform is described in detail in in and the terminology used in this document 102 is defined in [I-D.eardley-lmap-terminology]. 104 A large-scale measurement platform involves basically three 105 protocols, namely, a Control protocol between the Controller(s) and 106 the MAs, a Report protocol between the MAs and the Collector(s) and 107 several measurement protocols between the MAs used to actually 108 perform the measurements. In addition the some information is 109 required to be provisioned to the MA prior to any comunication with 110 the Controller. 112 This document defines the information model for both the Control and 113 the Report protocol along with pre-configuration information that is 114 required before communicating with the Controller, broadly named as 115 the LMAP Information Model (or LMAP IM for short). The measurement 116 protocols are out of the scope of this document. 118 As defined in [RFC3444], the LMAP IM defines the concepts involved in 119 a large-scale measurement platform at a high level of abstraction, 120 independently of any specific implementation or actual protocol used 121 to exchange the information. It is expected that the proposed 122 information model can be used with different protocols in different 123 measurement platform architectures and across different types of MA 124 device (e.g. home gateway, smartphone, PC, router etc.). 126 2. LMAP Information Model 128 2.1. Information Structure 130 The information described herein relates to the information stored, 131 received or transmitted by a Measurement Agent as described within 132 the LMAP framework [I-D.eardley-lmap-framework]. As such, some 133 subsets of this information model are applicable to the measurement 134 Controller, Collector and systems that pre-configure the Measurement 135 Agent. The information described in these models will be transmitted 136 across the protocols and interfaces between the Measurement Agent and 137 such systems according to a Data Model. 139 For clarity the information model is divided into six sections: 141 1. Pre-Configuration Information. Information pre-configured on the 142 Measurement Agent prior to any communication with other 143 components of the LMAP architecture, specifically detailing how 144 to register with a Controller 146 2. Configuration Information. Information delivered to the MA on 147 registration with a Controller or updated during a later 148 communication, specifically detailing how to retrieve measurement 149 and reporting instruction information from a Controller along 150 with information specifically about the MA 152 3. Instruction Information. Information that is received by the MA 153 from the Controller pertaining to the measurement and reporting 154 configuration. This includes measurement configuration, report 155 channel configuration, measurement schedules and measurement 156 suppression information 158 4. Logging Information. Information transmitted from the MA to the 159 Controller detailing the results of any configuration operations 160 along with error and status information from the operation of the 161 MA 163 5. Status Information. Information on the general status and 164 capabilities of the MA. For example, the set of measurements 165 that are supported on the device 167 6. Reporting Information. Information transmitted from the MA to 168 the Collector including measurement results and the context in 169 which they were conducted 171 In addition the MA may hold further information not described herein, 172 and which may be optionally transferred to or from other systems 173 including the Controller and Collector. One example of information 174 in this category is subscriber or line information that may be 175 reported by the MA as optional fields in the reporting communication 176 to the Collector. 178 2.2. Pre-Configuration Information 180 This information is the minimal information that needs to be pre- 181 configured to the MA in order for it to successfully communicate with 182 a Controller during the registration process. 184 This pre-configuration information needs to include an address of the 185 Controller to contact along with the security information required 186 for the communication including the MA private and public keys and 187 the public key of the Controller. Such keys will be contained within 188 security certificates and are likely to be obtained and validated 189 through communication with a Trusted Certificate Authority. 191 In addition the information will describe how often to attempt 192 communication with the Controller. 194 Detail of the information model elements: 196 1. MA MAC: MAC Address 198 2. Controller: FQDN 200 3. MA Certificate: Certificate 202 4. Controller Communication Timing: Timing 204 The detail of the timing object is described later since it is common 205 to several parts of the information model. 207 2.3. Configuration Information 209 During registration or at any later point at which the MA contacts 210 the Controller, the choice of Controller and details for the timing 211 of communication with the Controller can be changed. For example the 212 pre-configured Controller may be replaced with a specific Controller 213 that is more appropriate to the MA device type, location of 214 characteristics of the network (e.g. access technology type or 215 broadband product). The initial communication timing object may also 216 be replaced with one more relevant to routine communications between 217 the MA and the Controller. 219 In addition the MA will be given further items of information that 220 relate specifically to the MA rather than the measurements it is to 221 conduct or how to report results. The assignment of an ID to the MA 222 is mandatory. Optionally a Group ID may also be given which 223 identifies a group of interest to which that MA belongs. For example 224 the group could represent an ISP, broadband product, technology, 225 market classification, geographic region, or a combination of 226 multiple such characteristics. Where the Measurement Group ID is set 227 an additional flag (the Report MA ID flag) is required to control 228 whether the Measurement Agent ID is to be reported. This allows the 229 MA to remain anonymous which may be particularly useful to prevent 230 tracking of mobile MA devices. 232 Detail of the additional information model elements: 234 1. Measurement Agent ID: String 236 2. Measurement Group ID (optional): String 238 3. Report MA ID flag (optional): Boolean 240 2.4. Instruction Information 242 The Instruction information model has four sub-elements: 244 1. Measurement Task Configurations: Set 246 2. Report Channels: Set 248 3. Measurement Schedules: Set 250 4. Measurement Suppression: Object 252 Conceptually each Measurement Task Configuration defines the 253 parameters of a Measurement Task that the Measurement Agent (MA) may 254 perform at some point in time. It does not by itself actually 255 instruct the MA to perform them at any particular time (this is done 256 by a Measurement Schedule). 258 Example: A Measurement Task Configuration may configure a single 259 Measurement Task for measuring UDP latency. The Measurement Task 260 Configuration could define the destination port and address for 261 the measurement as well as the duration, internal packet timing 262 strategy and other parameters (for example a stream for one hour 263 and sending one packet every 500 ms). It may also define the 264 output type and possible parameters (for example the output type 265 can be the 95th percentile mean) where the measurement task 266 accepts such parameters. It does NOT define when the task starts 267 (this is defined by the Measurement Schedule element), so it does 268 not by itself instruct the MA to actually perform this measurement 269 task. 271 The Measurement Task Configuration will include a local short name 272 for reference by the Measurement Schedule, along with a registry 273 entry [I-D.bagnulo-ippm-new-registry] that defines the Measurement 274 Task. The MA itself will resolve the registry entry to a local 275 executable program. In addition the Measurement Task is specialised 276 through a set of configuration Options. The nature and number of 277 these Options will depend upon the Measurement Task and will be 278 defined in the Measurement Task Registry. In addition the 279 Measurement Task Configuration may optionally also be given a 280 Measurement Cycle ID. The purpose of this ID is to easily identify a 281 set of measurement results that have been produced by Measurement 282 Tasks with comparable Options. This ID is manually incremented when 283 an Option change is implemented which could mean that two sets of 284 results should not be directly compared. 286 A Report Channel defines how to report results to a single Collector. 287 Several Report Channels can be defined to enable results to be split 288 or duplicated across different report intervals or destinations. 289 E.g. a single Collector may have three Report Channels, one reporting 290 hourly, another reporting daily and a third on which to send 291 immediate results for on-demand measurement tasks. 293 Each Report Channel contains the details of one collector (including 294 location and security information such as the certificate), and the 295 timing for the report i.e. when to report the results. The Report 296 Channel can use the same timing information object as a Measurement 297 Schedule defined later and the Controller Communication Timing 298 defined earlier. There are several options, such as immediately 299 after the results are obtained or at a given interval or calendar 300 based cycle). As with the Measurement task Configuration, each 301 Report Channel is also given a local short name by which it can be 302 referenced from a Measurement Schedule. 304 Example: A Report Channel may specify that results are to be sent to 305 the Collector resolved by the FQDN (collector.foo.org), using the 306 appropriate digital certificate to establish a secure channel. 307 The Report Channel specifies that the results are to be sent 308 immediately as available and not batched. 310 A Measurement Schedule contains the instruction from the Controller 311 to the MA to execute a single or repeated series of Measurement 312 Tasks. Each Measurement Schedule contains basically three elements: 313 a reference to a list of Measurement Task Configuration, a reference 314 to a set of one or more Report Channels, and a timing object for the 315 schedule. The schedule basically states what measurement task to 316 run, how to report the results, and when to run the measurement task. 317 Multiple measurement tasks in the list will be executed in order with 318 minimal gaps. Note that the Controller can instruct the MA to report 319 to several Collectors by specifying several Report Channels. 321 Example: a Measurement Schedule references a single Measurement Task 322 Configuration for the UDP latency defined in the previous example. 323 It references the Report Channel in the previous example to send 324 results immediately as available to the specified Collector. The 325 timing is specified to run the configured Measurement Task 326 Configuration every hour at 23 minutes past the hour. 328 Measurement Suppression information is used to over-ride the 329 Measurement Schedule and stop measurements from the MA for a defined 330 or indefinite period. While conceptually measurements can be stopped 331 by simply removing them from the Measurement Schedule, splitting out 332 separate information on Measurement Suppression allows this 333 information to be updated on the MA on a different timing cycle or 334 protocol implementation to the Measurement Schedule. 336 The goal when defining these four different elements is to allow each 337 part of the information model to change without affecting the other 338 three elements. For example it is envisaged that the Report Channels 339 and the set of Measurement Tasks Configurations will be relatively 340 static. The Measurement Schedule on the other hand is likely to be 341 more dynamic as the measurement panel and test frequency are changed 342 for various business goals. Another example is that measurements can 343 be suppressed with a Measurement Suppression command without removing 344 the existing Measurement Schedules that would continue to apply after 345 the Measurement Suppression expires or is removed. In terms of the 346 Controller-MA communication this can reduce the data overhead. It 347 also encourages the re-use of the same standard Measurement Task 348 Configurations and Reporting Channels to help ensure consistency and 349 reduce errors. 351 Definition of the information model elements: 353 1. Measurement Task Configurations: Set 355 1. Measurement Task Configuration: Object 357 1. Task Name (used for referral from the Measurement 358 Schedules): String 360 2. Registry Entry: URN 362 3. Options: Set (optional) 364 4. Measurement Cycle ID: String (optional) 366 2. Report Channels: Set 368 1. Report Channel: Object 370 1. Channel Name (used for referral from the Measurement 371 Schedule): String 373 2. Collector: FQDN 375 3. Report Timing: Timing 377 3. Measurement Schedules: Set 379 1. easurement Schedule: Object 381 1. Schedule Name: String 383 2. Measurement Task Configuration Names (reference by Name 384 to one of the measurement tasks defined in the 385 Measurement Task Configuration set): List 387 1. Task Name: String 389 3. Report Channel Names (reference by Name to one of the 390 measurement tasks defined in the Measurement Task 391 Configuration set): Set 393 1. Channel Name: String 395 4. Measurement Timing: Timing 397 4. Measurement Suppression: Object (optional) 399 1. Start: datetime 401 2. End: datetime 403 3. Set of Measurement Task Configuration Names (optional - 404 default all) 406 1. Task Name: String 408 2.5. Logging Information 410 The MA will report back success/failure and status information to the 411 Controller. These messages will fall into a number of different 412 categories: 414 1. Success/failure messages in response to information updates from 415 the Controller. For example: 417 * "Report Channel 'hourly db" configured" 419 * "Measurement Schedule does not conform to schema, Row 211" 421 2. Status updates from the operation of the MA. For example: 423 * "out of memory: cannot record result" 424 * "Collector 'collector.example.com' not responding" 426 Each log message will have the following Information model elements: 428 1. Log Time: datetime 430 2. Log Event: Object 432 2.6. Status Information 434 In addition to the information reported by the MA through the logging 435 information, the MA will hold further status information that can be 436 retrieved by a Controller. One category of additional information 437 that has not been defined in earlier sections is the availability of 438 Measurement Tasks on that MA. 440 MA Status information model elements: 442 1. MA ID: String 444 2. MA Device: String 446 3. MA IP: IP Address 448 4. Last Measurement: datetime 450 5. Last Report: datetime 452 6. Last Instruction: datetime 454 7. Last Configuration: datetime 456 8. Supported Measurements: Set 458 1. Registry Entry: URN 460 2.7. Reporting Information 462 At a point in time specific by the Report Channel, the MA will 463 communicate a set of measurement results to the Collector. These 464 measurement results should be communicated within the context in 465 which they were collected. 467 The report is structured hierarchically to avoid repetition of 468 report, Measurement Agent and Measurement Task Configuration 469 information. The report starts with the timestamp of the report 470 generation on the MA and details about the MA including the optional 471 Measurement Agent ID and Group ID (controlled by the Configuration 472 Information). In addition optional further MA context information 473 can be included at this point such as the line sync speed or ISP and 474 product if known by the MA. 476 After the MA information the results are reported grouped into the 477 different Measurement Tasks. Each Task starts with replicating the 478 Measurement Task Configuration information before the result headers 479 (titiles for data columns) and the result data rows. 481 Information model elements: 483 1. Report Date: datetime 485 2. Measurement Agent ID: String (optional) 487 3. Measurement Group ID: String (optional) 489 4. MA Context: Set (optional) 491 1. Context Item: Object 493 5. Measurement Task: Set 495 1. Measurement Task Configuration: Object 497 2. Result Headers: List 499 1. Column Name: String 501 3. Result Data: List 503 1. Result Row: Object 505 1. Measurement Time: datetime 507 2. Cross-traffic: Integer (optional) 509 3. Result Columns: List 511 1. Column Data 513 2.8. Timing Information 515 The Timing information object used throughput the information models 516 can take one of four different forms: 518 1. Periodic. Specifies a start, end and interval time in 519 milliseconds 521 2. Calendar: Specifies a calendar based pattern - e.g. 22 minutes 522 past each hour of the day on weekdays 524 3. One Off: A single instance occurring at a specific time 526 4. Immediate: Should occur as soon as possible 528 Optionally each of the first three options may also specify a 529 randomness that should be evaluated and applied separately to each 530 indicated event. 532 2.8.1. Periodic Timing 534 Information model elements: 536 1. 1. Timing Name: String 538 2. 2. Start: datetime (optional) 540 3. 3. End: datetime (optional) 542 4. 4. Interval: Integer (in milliseconds) 544 5. 5. Randomness: Timing Randomness (optional) 546 2.8.2. Calendar Timing 548 Information model elements: 550 1. Timing Name: String 552 2. Start: datetime (optional) 554 3. End: datetime (optional) 556 4. Months: Set (optional - default [1-12]) 558 1. Month: Integer 560 5. Weekdays: Set (optional - default [Mon-Sun]) 562 1. Weekday: String (one off Mon, Tue, Wed, Thu, Fri, Sat Sun) 564 6. Days: Set (optional - default [1-31]) 566 1. Day: Integer 568 7. Hours: Set (optional - default [1-24]) 569 1. Hour:Integer 571 8. Minutes: Set (optional - default [1-60]) 573 1. Minute: Integer 575 9. Seconds: Set (optional - default [1-60]) 577 1. Second: Integer 579 10. Randomness: Timing Randomness (optional) 581 2.8.3. One-Off Timing 583 Information model elements: 585 1. Time: datetime 587 2. Randomness: Timing Randomness (optional) 589 2.8.4. Immediate Timing 591 The immediate timing object has no further information elements. The 592 measurement or report is simply to be done as soon as possible. 594 2.8.5. Timing Randomness 596 The Timing randomness object specifies a random distribution that can 597 be applied to any scheduled execution event such as a measurement or 598 report. The intention it to be able to spread the load on the 599 Controller, Collector and network in an automated manner for a large 600 number of Measurement Agents. The randomness is expressed as a 601 distribution (e.g. Poison, Normal, Uniform etc.) along with the 602 spread over which the distribution should be applied. In additional 603 optional upper and lower bounds can be applied to control extreme 604 spread of timings. 606 Information model elements: 608 1. Distribution: String 610 2. Upper Cut: Integer (optional) 612 3. Lower Cut: Integer (optional) 614 4. Spread: Integer 616 3. IANA Considerations 618 This document makes no request of IANA . 620 Note to RFC Editor: this section may be removed on publication as an 621 RFC. 623 4. Security Considerations 625 This Information Model deals with information about the control and 626 reporting of the Measurement Agent. There are broadly two security 627 considerations for such an Information Model. Firstly the 628 Information Model has to be sufficient to establish secure 629 communication channels to the Controller and Collector such that 630 other information can be sent and received securely. The second 631 consideration is that no mandated information items pose a risk to 632 confidentiality or privacy given such secure communication channels. 633 For this latter reason items such as the MA context and MA ID are 634 left optional and can be excluded from some deployments. This would, 635 for example, allow the MA to remain anonymous and for information 636 about location or other context that might be used to identify or 637 track the MA to be ommitted or blurred. 639 5. Acknowledgements 641 6. Informative References 643 [I-D.bagnulo-ippm-new-registry] 644 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 645 A. Morton, "A registry for commonly used metrics", draft- 646 bagnulo-ippm-new-registry-00 (work in progress), January 647 2013. 649 [I-D.eardley-lmap-framework] 650 Eardley, P., Burbridge, T., and A. Morton, "A framework 651 for large-scale measurements", draft-eardley-lmap- 652 framework-01 (work in progress), February 2013. 654 [I-D.eardley-lmap-terminology] 655 Eardley, P., Morton, A., Bagnulo, M., and T. Burbridge, 656 "Terminology for Large MeAsurement Platforms (LMAP)", 657 draft-eardley-lmap-terminology-01 (work in progress), May 658 2013. 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, March 1997. 663 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 664 Information Models and Data Models", RFC 3444, January 665 2003. 667 Authors' Addresses 669 Trevor Burbridge 670 British Telecom 671 Adastral Park, Martlesham Heath 672 Ipswich IP5 3RE 673 UK 675 Philip Eardley 676 British Telecom 677 Adastral Park, Martlesham Heath 678 Ipswich IP5 3RE 679 UK 681 Marcelo Bagnulo 682 Universidad Carlos III de Madrid 683 Av. Universidad 30 684 Leganes, Madrid 28911 686 Juergen Schoenwaelder 687 Jacobs University