idnits 2.17.1 draft-eardley-lmap-terminology-02.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2013) is 3942 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) == Missing Reference: 'RFC3444' is mentioned on line 321, but not defined == Outdated reference: A later version (-01) exists of draft-bagnulo-ippm-new-registry-independent-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Eardley 3 Internet-Draft BT 4 Intended status: Standards Track A. Morton 5 Expires: January 12, 2014 AT&T Labs 6 M. Bagnulo 7 UC3M 8 T. Burbridge 9 BT 10 July 11, 2013 12 Terminology for Large MeAsurement Platforms (LMAP) 13 draft-eardley-lmap-terminology-02 15 Abstract 17 This documents defines terminology for Large Scale Measurement 18 Platforms. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 12, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. LMAP Terminology . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Other potentially useful terminology . . . . . . . . . . 6 58 4. Commentary and notes . . . . . . . . . . . . . . . . . . . . 6 59 5. Security considerations . . . . . . . . . . . . . . . . . . . 9 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 62 8. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 8.1. from -00 to -01: . . . . . . . . . . . . . . . . . . . . 9 64 8.2. from -01 to -02 . . . . . . . . . . . . . . . . . . . . . 10 65 9. Informative References . . . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 This document, in Section 3, defines terminology for LMAP. Since 71 'raw' terminology is reader-unfriendly, Section 2 provides an initial 72 idea of the terminology by explaining how LMAP works whilst using the 73 terms. Section 4 provides some commentary on the terminology, 74 including a comparison with that in [RFC2330]. 76 Please note that defined terms are capitalized. 78 2. Summary 80 A Measurement Task is an act that yields a single Measurement Result. 81 An Active Measurement Task involves (for example) a Measurement Agent 82 injecting test packet(s) into the network destined for a Measurement 83 Peer and measuring some performance or reliability parameter 84 associated with the transfer. The generic version of the Measurement 85 Task is the Measurement Method; in other words the Measurement Task 86 is the instantiation of the Measurement Method at a specific time and 87 place. 89 For example, a Measurement Method might be the injection of a UDP 90 packet by a Measurement Agent destined for a Measurement Peer, which 91 immediately reflects the UDP packet back to the Measurement Agent, 92 which measures the round trip latency. The associated Measurement 93 Task might be: the injection of a UDP packet by the Measurement Agent 94 at 192.0.2.0 destined for the Measurement Peer at 198.51.100.0 at UTC 95 13:01 and 58.6 seconds on 2013-06-15, with the Measurement Peer 96 immediately reflecting the UDP packet back to the source, which 97 measures the associated round trip latency (using a second timestamp 98 associated with arrival). 100 A Metric is a parameter of interest that is related to the 101 performance and reliability of the Internet. For example, "UDP 102 latency". Typically the value of a Metric is assessed as simply the 103 average of several Measurement Results. However a Derived Metric 104 consists of some combination of various Measurement Results. For 105 example, a path delay might be assessed by adding several component 106 delays, or the bulk transport capacity might be assessed by combining 107 several different parameters as suggested in 108 [I-D.mathis-ippm-model-based-metrics]. 110 How and when to perform the Measurement Task and report the 111 Measurement Result is defined by the Instruction, which the 112 Controller sends to the Measurement Agent. Whilst the Instruction 113 may define a single Measurement Task, more typically it defines a 114 series of Measurement Tasks, all based on the same Measurement Method 115 and carried out at regular times according to a Measurement Schedule. 116 The Measurement Result of the former is likely to be reported 117 immediately, whilst Measurement Results of the latter will be sent at 118 regular time intervals, as defined by the Report Schedule. The 119 Instruction consists of the following items (which effectively define 120 a series of Measurement Tasks): 122 1. The Measurement Method: typically this is defined by a reference 123 in a well-known registry (for example, 'how to measure UDP 124 latency') 126 2. The configuration of parameters left open by the Measurement 127 Method (for example, the addresses of the Measurement Agent and 128 Measurement Peer) 130 3. The Measurement Schedule (for example, start at 0400 UTC, repeat 131 every 500 ms, end at 0403 UTC) 133 4. Any environmental constraints (for example, do not perform the 134 Measurement Task if there is cross-traffic) 136 5. How and when to send a report: 138 a. The definition of the Report. Typically the Report includes 139 every single Measurement Result (since the last Report), but 140 it may instead be a statistic (such as their average). 141 Typically the Report also includes other relevant 142 information, for example an 'echo' of the Measurement Method, 143 configuration parameters and schedule. 145 b. The configuration of parameters associated with the Report 146 (for example, the address of the Collector to which the 147 Report is sent) 149 c. The Report Schedule (for example, send once a day at 01:00 150 hours) 152 The Control Protocol and Report Protocol define the delivery of the 153 Instruction and the Report (respectively); they consist of a Data 154 Model (the semantics and structure of the information, in a 155 particular data modeling language such as a JSON schema language or 156 YANG) and a transport protocol (such as HTTP or NETCONF). 158 3. LMAP Terminology 160 Active Measurement Method (Task): A type of Measurement Method (Task) 161 that involves a Measurement Agent and a Measurement Peer (or possibly 162 Peers), where either the Measurement Agent or the Measurement Peer 163 injects test packet(s) into the network destined for the other, and 164 which involves one of them measuring some performance or reliability 165 parameter associated with the transfer of the packet(s). 167 Bootstrap Protocol: A protocol that initialises a Measurement Agent 168 with the information necessary to talk to a Controller. 170 Collector: A function that receives a Report from a Measurement 171 Agent. Colloquially, a Collector is a physical device that performs 172 this function. 174 Controller: A function that provides a Measurement Agent with 175 Instruction(s). Colloquially, a Controller is a physical device that 176 performs this function. 178 Control Protocol: The protocol delivering Instruction(s) from a 179 Controller to a Measurement Agent. 181 Data Model: The implementation of an Information Model in a 182 particular data modelling language. 184 Derived Metric: A Metric that is a combination of other Metrics, and/ 185 or a combination of the same Metric measured over different parts of 186 the network, or at different times. 188 Information Model: The protocol-neutral definition of the semantics 189 of either the Instruction or the Report. 191 Instruction: The description of Measurement Tasks to perform and the 192 details of the Report to send. The Instruction is sent by a 193 Controller to a Measurement Agent. 195 Measurement Agent (MA): The function that receives Instructions from 196 a Controller, performs Measurement Tasks (perhaps in concert with a 197 Measurement Peer) and reports Measurement Results to a Collector. 198 Colloquially, a Measurement Agent is a physical device that performs 199 this function. 201 Measurement Method: The process for assessing the value of a Metric; 202 the process of measuring some performance or reliability parameter; 203 the generalisation of a Measurement Task. 205 Measurement Peer: The function that receives control messages and 206 test packets from a Measurement Agent and may reply to the 207 Measurement Agent as defined by the Measurement Method. 209 Measurement Result: The output of a single Measurement Task (the 210 value obtained for the parameter of interest, or Metric). 212 Measurement Schedule: the schedule for performing a series of 213 Measurement Tasks. 215 Measurement Task: The act that yields a single Measurement Result; 216 the act consisting of the (single) operation of the Measurement 217 Method at a particular time and with all its parameters set to 218 specific values. 220 Metric: The quantity related to the performance and reliability of 221 the Internet that we'd like to know the value of, and that is 222 carefully specified. 224 Passive Measurement Method (Task): A Measurement Method (Task) in 225 which a Measurement Agent observes existing traffic at a specific 226 measurement point, but does not inject test packet(s). 228 Report: The Measurement Results and other associated information (as 229 defined by the Instruction); a specific instance of the Data Model. 230 The Report is sent by a Measurement Agent to a Collector. 232 Report Protocol: The protocol delivering Report(s) from a Measurement 233 Agent to a Collector. 235 Report Schedule: the schedule for sending a series of Reports to a 236 Collector. 238 3.1. Other potentially useful terminology 240 The following terms have also been suggested and will be included 241 above, assuming they prove useful during the early stages of the LMAP 242 work. 244 Cycle-ID: A tag that is sent by the Controller in an Instruction and 245 echoed by the MA in its Report; Measurement Results with the same 246 Cycle-ID are expected to be comparable. 248 Environmental Constraint: A parameter that is measured as part of the 249 Measurement Task, its value determining whether the rest of the 250 Measurement Task proceeds. 252 Group-ID: An identifier of a group of MAs. 254 Measurement Parameter: A parameter whose value is left open by the 255 Measurement Method. 257 Measurement Suppression: a type of Instruction that stops 258 (suppresses) Measurement Tasks. 260 Report Channel: a specific Report Schedule and Collector 262 4. Commentary and notes 264 To avoid confusion the word 'Measurement' is only used as an 265 adjective. 267 It is worth explaining how the terms defined here compare with those 268 in [RFC2330], "Framework for IP Performance Metrics". The definition 269 of Metric is taken from RFC2330. The definition of Measurement 270 Method is (we believe) equivalent in RFC2330's terms to a measurement 271 methodology for a singleton metric. A set of Measurement Tasks 272 defined by a Measurement Schedule relates to RFC2330's concept of a 273 sample metric. 275 If a Measurement Method is used multiple times under identical or 276 similar conditions, it should result in a consistent value for the 277 Metric. 279 A Measurement Method may be a more specific version of another 280 Measurement Method. For example, 281 [I-D.bagnulo-ippm-new-registry-independent] defines UDP latency as a 282 round trip delay [RFC2681] with the packet type set to UDP. 284 A registry, as proposed in 285 [I-D.bagnulo-ippm-new-registry-independent], would be a registry of 286 Measurement Methods and their associated Metrics. A Passive 287 Measurement Method (Task) involves only a Measurement Agent; for 288 example, it measures the mix of applications. An Active Measurement 289 Method (Task) also involves a Measurement Peer. It is possible that 290 some Active Measurement Methods (Tasks) involve additional 291 Measurement Agent(s) or Measurement Peer(s); for example, one way to 292 measure 'latency under load' may be to send test traffic between a 293 Measurement Agent and Measurement Peer whilst a second Measurement 294 Peer generates the load (cross-traffic). 296 The consensus is that the LMAP working group should assume that a 297 Measurement Agent receives Instruction from only a single Controller 298 at any point in time (however it may Report to more than one 299 Collector). 301 By definition a Measurement Peer does not interact with a Controller 302 or Collector. A Measurement Peer will typically respond to the test 303 packet(s) from the Measurement Agent. For example, it may echo a UDP 304 packet, or measure the amount of loss of the test packets and then 305 send the Measurement Results to the Measurement Agent. 307 The Measurement Agent is implemented either in specialised hardware 308 or as code on general purpose devices like a PC, tablet or 309 smartphone. Note that a Measurement Peer may not have specific LMAP 310 or IPPM functionality. For example, to assess DNS response time a 311 Measurement Agent sends DNS requests to a standard DNS server. 313 A Controller can send an Instruction for immediate action, containing 314 a one-off Measurement Task. This is in addition to the more typical 315 scenario of a series of Measurement Tasks carried out on a regular 316 schedule, with the Measurement Results reported periodically. 318 It may be sensible for an Instruction to be able to refer to more 319 than one Measurement Method. This is for further study. 321 [RFC3444] discusses the difference between an Information Model and 322 Data Model. An Informational Model "model[s] managed objects at a 323 conceptual level, independent of any specific implementations or 324 protocols used to transport the data ... it defines relationships 325 between managed objects". A Data Model is "defined at a lower level 326 of abstraction and includes many details ... and include[s] protocol- 327 specific constructs." Multiple Data Models can be derived from a 328 single Information Model, since a conceptual/abstract model can be 329 implemented in different ways. An Informational Model is for 330 designers and operators, whilst a Data Model is for implementors. 332 An Information Model can be divided into different parts and sub- 333 parts, to allow the values in each part and sub-part to be updated 334 independently. For example, one part could be contain the 335 Instruction Information and another the Reporting Information. The 336 Instruction could contain sub-parts for configuring Measurement Tasks 337 and for setting Measurement Schedules (which may be updated at 338 different times and frequencies). This is discussed in 339 [information-model] 341 The Control Protocol defines the Data Model and so effectively 342 defines the Instruction. The Instruction includes: the Measurement 343 Method; values for the parameters that the Measurement Method leaves 344 open (configuration); when to perform the Measurement Tasks (the 345 Measurement Schedule); any environmental conditions (such as "don't 346 perform the Measurement Task if there is end user traffic present"); 347 the Report Protocol, which includes its Data Model; when to send a 348 Report (the Report Schedule); where to send the Report (the address 349 of the Collector) and values for any other parameters that the Report 350 Protocol leaves open (configuration). This is for discussion. 352 Typically the Report includes every single Measurement Result, but it 353 may instead be a statistic (such as their average). The latter may 354 be useful when the bandwidth between the Measurement Agent and 355 Collector is severely constrained and/or the full set of Measurement 356 Results provides little extra information. 358 The Report includes: the Measurement Results (or statistic based on 359 them); the details of the Measurement Tasks (essentially a copy of 360 much of the Instruction, for example the Measurement Method, the 361 configuration parameters and the time at which each Measurement 362 Result was obtained); and other relevant information known by the 363 Measurement Agent (such as the line's speed, the version of the 364 Measurement Agent, and the amount of cross-traffic during the 365 measurement). Again this is very much for discussion. 367 A proposal for a Control Protocol based on HTTP is currently under 368 development. There are already internet drafts describing a Control 369 Protocol based on NETCONF and a Report Protocol based on IPFIX. 371 The job of a Bootstrap Protocol is to provide an automated way to 372 associate a Measurement Agent to its Controller, including 373 authentication credentials. Similarly, there should be a way to pull 374 the plug on rogue Measurement Agents. The current consensus on the 375 LMAP mailing list is that the working group should define the 376 bootstrap process but not a protocol. The reason is that it could be 377 done in many different ways, depending on the device and the 378 measurement system, for instance: loaded at manufacture, updated 379 locally via USB port, or orchestrated via a protocol (which may be 380 defined by organisations other than the IETF, for example, the 381 Broadband Forum). 383 The purpose of the Cycle-ID is to allow the data analysis tools to 384 identify easily Measurement Results that are expected to be 385 comparable, typically because the associated Measurement Tasks all 386 operate the same Measurement Method with the same values for its 387 parameters. This set of Measurement Tasks could be termed the 388 Measurement Cycle. 390 An example of an Environmental Constraint is "no end-user traffic". 391 The Measurement Agent could measure the amount of end-user traffic 392 over the previous 10 seconds; if there is none then it uploads a file 393 to the Measurement Peer, whilst if the end-user is active then it 394 defers the upload. 396 The Report Channel contains the details of one collector (including 397 location and security information such as the certificate), and the 398 timing for the report (when to report the results). Each Report 399 Channel is also given a local short name by which it can be 400 referenced from a Measurement Schedule. 402 The Group-ID identifies a group of interest to which a MA belongs. 403 For example the group could represent an ISP, broadband product, 404 technology, market classification, geographic region, or a 405 combination of multiple such characteristics. A MA can remain 406 anonymous by including its Group-ID (and not its own identifier) in 407 the Reports it sends. 409 Measurement Suppression is used to over-ride the Measurement 410 Schedule. A Controller uses Measurement Suppresion to stop a MA 411 making measurements for a defined or indefinite period. For 412 discussion of Measurement Suppression, see [information-model] 414 5. Security considerations 416 There are no security considerations in this memo. 418 6. IANA Considerations 420 There are no IANA considerations in this memo. 422 7. Acknowledgments 424 We thank participants on the LMAP mailing list for their input, 425 especially Juergen Schoenwaelder for his detailed review. 427 8. History 429 8.1. from -00 to -01: 431 'Complete Measurement Agent' replaced by 'Measurement Agent', and 432 'Remote Measurement Agent' replaced by 'Measurement Peer'. 434 Bootstrap protocol added 436 Section 3.1 added, with terms Cycle-ID, Measurement Parameter and 437 Environmental Constraints 439 Adjustments to terms for: Active Measurement Method (Task), Control 440 Protocol, Information Model, Instruction, Report Protocol. 442 8.2. from -01 to -02 444 Added to Section 3.1 the terms Group-ID, Measurement Suppression and 445 Report Channel, as these are used in [information-model] 447 Other minor clarifications. 449 9. Informative References 451 [I-D.bagnulo-ippm-new-registry-independent] 452 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 453 A. Morton, "A registry for commonly used metrics. 454 Independent registries", draft-bagnulo-ippm-new-registry- 455 independent-00 (work in progress), January 2013. 457 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 458 "Framework for IP Performance Metrics", RFC 2330, May 459 1998. 461 [I-D.mathis-ippm-model-based-metrics] 462 Mathis, M. and A. Morton, "Model Based Internet 463 Performance Metrics", draft-mathis-ippm-model-based- 464 metrics-01 (work in progress), February 2013. 466 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 467 Delay Metric for IPPM", RFC 2681, September 1999. 469 [information-model] 470 Burbridge, T., Eardley, P., Bagnulo, M., and J. 471 Schoenwaelder, "Information Model for Large-Scale 472 Measurement Platforms (LMAP)", , . 475 Authors' Addresses 476 Philip Eardley 477 British Telecom 478 Adastral Park, Martlesham Heath 479 Ipswich 480 ENGLAND 482 Email: philip.eardley@bt.com 484 Al Morton 485 AT&T Labs 486 200 Laurel Avenue South 487 Middletown, NJ 488 USA 490 Email: acmorton@att.com 492 Marcelo Bagnulo 493 Universidad Carlos III de Madrid 494 Av. Universidad 30 495 Leganes, Madrid 28911 496 SPAIN 498 Phone: 34 91 6249500 499 Email: marcelo@it.uc3m.es 500 URI: http://www.it.uc3m.es 502 Trevor Burbridge 503 British Telecom 504 Adastral Park, Martlesham Heath 505 Ipswich 506 ENGLAND 508 Email: trevor.burbridge@bt.com