idnits 2.17.1 draft-akhter-lmap-framework-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 5 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2013) is 3938 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-burbridge-lmap-information-model-00 == Outdated reference: A later version (-04) exists of draft-linsner-lmap-use-cases-03 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-17 == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-09 == Outdated reference: A later version (-10) exists of draft-ietf-ipfix-mediation-protocol-05 == Outdated reference: A later version (-06) exists of draft-ietf-netconf-reverse-ssh-01 -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LMAP Working Group A. Akhter 3 Internet-Draft P. Aitken 4 Intended status: Informational Cisco Systems 5 Expires: January 17, 2014 July 16, 2013 7 A Framework and Inventory for a Large Scale Measurement System 8 draft-akhter-lmap-framework-00.txt 10 Abstract 12 This LMAP framework document reviews the LMAP Working Group charter, 13 considers the necessary building blocks, and looks at what we already 14 have in the IETF and what's missing, so that LMAP Working Group 15 attention can be focused on where the gaps are. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 17, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Working Group Scope . . . . . . . . . . . . . . . . . . . 4 53 1.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 5 54 1.3. LMAP Working Group Goals . . . . . . . . . . . . . . . . 5 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1. Measurement Agent . . . . . . . . . . . . . . . . . . . . 8 58 3.1.1. Measurement Agent Embedded in Site Gateway . . . . . 9 59 3.1.2. Measurement Agent behind Site NAT/Firewall . . . . . 9 60 3.1.3. Measurement Agent in-line with Site Gateway . . . . . 9 61 3.1.4. Measurement Agent in Multi Homed Site . . . . . . . . 10 62 3.2. Remote Measurement Test Target . . . . . . . . . . . . . 11 63 3.3. Controller . . . . . . . . . . . . . . . . . . . . . . . 11 64 3.4. Collector . . . . . . . . . . . . . . . . . . . . . . . . 12 65 3.5. Information Model . . . . . . . . . . . . . . . . . . . . 12 66 3.6. Transport Protocols . . . . . . . . . . . . . . . . . . . 13 67 3.7. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 3.8. Device Discovery . . . . . . . . . . . . . . . . . . . . 14 69 4. Active Measurements . . . . . . . . . . . . . . . . . . . . . 15 70 4.1. What building blocks exist today? . . . . . . . . . . . . 15 71 4.1.1. Single Sided Client Tests . . . . . . . . . . . . . . 15 72 4.1.2. OWAMP - One Way Active Measurement Protocol . . . . . 15 73 4.1.3. TWAMP - Two Way Active Measurement Protocol . . . . . 17 74 4.1.4. Cisco Service-Level Assurance Protocol . . . . . . . 18 75 4.1.5. IPPM Performance Metrics . . . . . . . . . . . . . . 18 76 4.2. Missing building blocks . . . . . . . . . . . . . . . . . 18 77 4.2.1. Time Synchronization . . . . . . . . . . . . . . . . 18 78 4.2.2. Shared Secret Distribution . . . . . . . . . . . . . 19 79 4.2.3. NAT/Firewall Traversal for Control and Test Protocols 19 80 4.2.4. IPPM Metrics Registry . . . . . . . . . . . . . . . . 19 81 4.2.5. OWAMP/TWAMP configuration . . . . . . . . . . . . . . 19 82 5. Passive Measurements . . . . . . . . . . . . . . . . . . . . 20 83 5.1. What building blocks exist today? . . . . . . . . . . . . 20 84 5.1.1. Measuring Packets . . . . . . . . . . . . . . . . . . 20 85 5.1.2. Measuring Flows . . . . . . . . . . . . . . . . . . . 20 86 5.1.3. Defining new Information Elements . . . . . . . . . . 22 87 5.1.4. Exporting Process . . . . . . . . . . . . . . . . . . 22 88 5.1.5. Mediation . . . . . . . . . . . . . . . . . . . . . . 23 89 5.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 23 90 5.2. Missing building blocks . . . . . . . . . . . . . . . . . 23 91 5.2.1. Performance metrics definition in the IPFIX registry 23 92 5.2.2. Mediation Configuration . . . . . . . . . . . . . . . 24 93 6. LMAP: Standards Re-usability . . . . . . . . . . . . . . . . 24 94 6.1. Existing Building Blocks . . . . . . . . . . . . . . . . 24 95 6.2. Missing Building Blocks . . . . . . . . . . . . . . . . . 24 96 6.2.1. Task Definitions . . . . . . . . . . . . . . . . . . 24 97 6.2.2. Instructions Setup . . . . . . . . . . . . . . . . . 25 98 6.2.3. Task Scheduling . . . . . . . . . . . . . . . . . . . 26 99 6.2.4. Combining Active and Passive Measurements . . . . . . 26 100 7. Security considerations . . . . . . . . . . . . . . . . . . . 27 101 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 102 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 10.1. Normative References . . . . . . . . . . . . . . . . . . 28 105 10.2. Informative References . . . . . . . . . . . . . . . . . 28 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 108 1. Introduction 110 There is a desire to be able to coordinate the execution of broadband 111 measurements and the collection of measurement results across a large 112 scale set of diverse devices. These devices could be software based 113 agents on PCs, embedded agents in consumer devices (e.g. blu-ray 114 players), service provider controlled devices such as set-top players 115 and home gateways, or simply dedicated probes. It is expected that 116 such a system could easily comprise 100k devices. Such a scale 117 presents unique problems in coordination, execution and measurement 118 result collection. Broad users of such a system include governmental 119 regulators looking for service compliance; network and service 120 operators (including over the top content providers) for diagnostics, 121 compliance and planning; and end users for diagnostics and service 122 compliance. The various detailed uses of such a large scale 123 measurement system are covered in [I-D.linsner-lmap-use-cases]. 125 Over the years various efforts inside and outside the IETF have 126 worked on independent components of such a system. There are also 127 existing systems that are deployed today. However, these are either 128 proprietary, closed, and/or not standardized. The IETF Large-Scale 129 Measurement of Broadband Performance (LMAP) Working Group is 130 chartered to specify the information model, associated data models, 131 and select/extend one or more protocols for secure measurement 132 control and measurement result collection. 134 With standardization, LMAP compliant Measurement Agents will be more 135 pervasive in gateways and end systems and offer a base common service 136 across vendor implementations. 138 A set of Measurement Agents is to be controlled by a single 139 organization. The Measurement Agents do not coordinate with 140 Measurement Agents under the control of other organisations. While 141 some of the capabilities are meant for end users, an end user is not 142 meant to directly control Measurement Agents, except for his own 143 Measurement Agent. The end user may interact with a service provider 144 portal to schedule and execute a measurement task using the 145 Measurement Agent on their premises. 147 The measurements themselves may be on IPv4, IPv6, and on various 148 services (DNS, HTTP, XMPP, FTP, VoIP, etc.). The Measurement Agents 149 may have multiple interfaces (WiFi, Ethernet, DSL, fiber, etc.) and 150 the measurements may specify any one of these. The measurement tasks 151 may generate synthetic traffic to perform the measurement (active 152 measurement), only observe existing traffic (passive measurement), or 153 may do a combination of both active and passive measurement. 155 Given the usage of passive measurements (and even in the case of 156 active measurement) there are valid concerns regarding privacy of the 157 measurement results and any user identifiable information. 159 1.1. Working Group Scope 161 The Large-Scale Measurement of Broadband Performance (LMAP) Working 162 Group is chartered to standardize the LMAP measurement system for 163 performance measurements of broadband access devices. 165 The Working Group is chartered to specify an information model, the 166 associated data models, and select/extend one or more protocols for 167 secure communication: 169 o A Control Protocol, from a Controller to instruct Measurement 170 Agents what performance metrics to measure, when to measure them, 171 and when and how to report the measurement results to a Collector. 173 o A Report Protocol, for a Measurement Agent to report the results 174 to the Collector. 176 The data models should be extensible for new and additional 177 measurements. LMAP will consider re-use of existing data models 178 languages. 180 The LMAP architecture will allow for measurements that utilize either 181 IPv4 or IPv6, or possibly both. Devices containing Measurement 182 Agents may have several interfaces using different link technologies. 183 Multiple address families and interfaces must be considered in the 184 Control and Report protocols. 186 Both active and passive measurements are in scope, although there may 187 be differences in their applicability to specific use cases, or in 188 the security measures needed according to the threats specific to 189 each measurement category. LMAP will not standardize performance 190 metrics. 192 The LMAP Working Group will consider privacy as a core requirement 193 and will ensure that by default measurement and collection mechanisms 194 and protocols operate in a privacy-sensitive manner, ie that privacy 195 features are at least well-defined. 197 1.2. Out of Scope 199 There are a number of items that are currently explicitly out of 200 scope for the LMAP Working Group: 202 o Inter-organization coordination and sharing of results is out of 203 scope 205 o Discovery of service parameters on Measurement Agents is out of 206 scope 208 o Sharing the service parameters between Measurement Agents is out 209 of the scope. 211 o Decision on the set of measurements to run is out of scope 213 o Protection against intentional / malicious gaming is out of scope 215 o Standardizing control of end users Measurement Agents is out of 216 scope. 218 o The management protocol to bootstrap the Measurement Agents in 219 measurement devices is out of scope. 221 1.3. LMAP Working Group Goals 223 The LMAP Working Group will produce the following work items: 225 1. The LMAP Framework - provides common terminology, basic 226 architecture elements, and justifies the simplifying constraints 228 2. The LMAP Use Cases - provides the motivating use cases as a basis 229 for the work 231 3. Information Model, the abstract definition of the information 232 carried from the Controller to the Measurement Agent and the 233 information carried from the Measurement Agent to the Collector. 234 It includes: 236 * The metric(s) that can be measured and values for its 237 parameters such as the Peer Measurement Agent participating in 238 the measurement and the desired environmental conditions (for 239 example, only conduct the measurement when there is no user 240 traffic observed) 242 * The schedule: when the measurement should be run and how the 243 results should be reported (when and to which Collector) 245 * The report: the metric(s) measured and when, the actual 246 result, and supporting metadata such as location. Result 247 reports may be organized in batches or may be reported 248 immediately, such as for an on-demand measurement. 250 4. The Control protocol and the associated data model: The 251 definition of how instructions are delivered from a Controller to 252 a Measurement Agent; this includes a Data Model consistent with 253 the Information Model plus a transport protocol. This may be a 254 simple instruction - response protocol, and LMAP will specify how 255 it operates over an existing protocol (to be selected, perhaps 256 REST-style HTTP(s) or NETCONF). 258 5. The Report protocol and the associated data model: The definition 259 of how the Report is delivered from a Measurement Agent to a 260 Collector; this includes a Data Model consistent with the 261 Information Model plus a transport protocol (to be selected, 262 perhaps REST-style HTTP(s) or IPFIX). 264 2. Terminology 266 Terms used in this document and are to be interpreted as defined in 267 the following documents: 269 o LMAP terms used in this document are defined in 270 [I-D.eardley-lmap-terminology]. 272 o IPFIX terms are defined in the Terminology section of the IPFIX 273 Architecture [RFC5470] 275 o PSAMP terms are defined in the Terminology section of the PSAMP 276 Protocol [RFC5476] 278 o TODO: where are IPPM terms defined? 279 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 280 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 281 document are to be interpreted as described in RFC 2119 [RFC2119]. 283 3. Architecture 285 A large scale measurement system is composed of several basic parts: 287 o Measurement Agents 289 o Remote Measurement Test Target(s) 291 o Controller(s) 293 o Collector(s) 295 +-------------------+ 296 |Remote Measurement | 297 |Test Target(s) | 298 +-------------------+ 299 ^ 300 |B 301 v 302 +----------+ A +-----------------+ C +------------+ 303 |Controller|<--->|Measurement Agent|----->|Collector(s)| 304 +----------+ +-----------------+ +------------+ 305 ^ ^ 306 |------------------------------------------| 307 D 309 Figure 1: LMAP Basic Parts 311 A full system would include other components such as a data parsing 312 module, report generation module, and subscriber database module. 313 However, these are not covered by the high level Figure 1. 315 There is also the concept of the measurement task and the measurement 316 result. 318 A measurement task generates a measurement result, which is composed 319 of one or many metrics as well as supplemental information from the 320 process of the task. A measurement task might time the download of a 321 specific web page. The measurement results might include the DNS 322 query time, query result used (IP address), the time to download the 323 web page and individual times for associated objects, the maximum bit 324 rate, and average bit rate. Note that some of the results are 325 derived metrics (based on other measurements, like maximum bit rate), 326 while others may not be not metrics at all (IP address used). Also 327 note that it is possible that the size of the result is not known at 328 the time of measurement task scheduling - the number of objects on 329 the web page might change, or if the measurement task includes a 330 traceroute the path will be different from many of the Measurement 331 Agents. 333 The measurement task is scheduled by the Controller via an 334 instruction. 336 3.1. Measurement Agent 338 The Measurement Agent is the component that is responsible for 339 executing a test. The Measurement Agent could take a number of 340 forms: a dedicated probe, software on a PC, embedded into an 341 appliance, or even embedded into a gateway. A single site (home, 342 branch office etc.) that is participating in a test could make use of 343 one or multiple Measurement Agents in a single measurement test. 344 e.g., if there are multiple output interfaces, there might be a 345 Measurement Agent per interface. 347 The Measurement Agent's configuration (specifically which Controller 348 to initially connect to), is out of scope within LMAP. However, 349 depending on the type of probe, it could be manually configured by 350 the user, pre-configured before shipment to the end user, or 351 configured by the application (in the case of some PC based 352 Measurement Agents). For example, a Measurement Agent that is 353 included in the app for a content provider might be configured 354 automatically by the content provider to use the content provider's 355 LMAP Controller. That said, there should be an element of local 356 premises configuration that allows the Measurement Agent (especially 357 in the case of active measurements) to mimic performance of user 358 applications at the same site. For example, making use of the same 359 DNS server as the remainder of the site. 361 The Measurement Agent could be deployed in a variety of locations. 362 Not all deployment locations are available to every kind of 363 Measurement Agent operator. There are also a variety of limitations 364 and trade-offs depending on the final placement. The next sections 365 outline some of the locations a Measurement Agent may be deployed. 366 This is not an exhaustive list and combinations of the below may also 367 apply. 369 3.1.1. Measurement Agent Embedded in Site Gateway 371 A Measurement Agent embedded with the site gateway (e.g. in the case 372 of a a branch office in a managed service environment) is one of 373 better places the Measurement Agent could be deployed. 375 All site to ISP traffic would traverse through the gateway and 376 passive measurements could easily be performed. Similarly, due to 377 this user traffic visibility, an active measurement task could be 378 rescheduled so as not to compete with user traffic. 380 Generally NAT and firewall services are built into the gateway, 381 allowing the Measurement Agent the option to offer its Controller 382 facing management interface outside of the NAT/firewall. This 383 placement of the management interface allows the Controller to 384 unilaterally contact the Measurement Agent for instructions. 386 However, if the site gateway is owned and operated by the service 387 provider, the Measurement Agent will generally not be available for 388 over the top providers, the regulator, end users or enterprises. 390 3.1.2. Measurement Agent behind Site NAT/Firewall 392 The Measurement Agent could also be embedded behind a NAT, a 393 firewall, or both. In this case the Controller may not be able to 394 unilaterally contact the Measurement Agent unless either static port 395 forwarding configuration or firewall pin holing is configured. This 396 would require user intervention, and ultimately might not be an 397 option available to the user (perhaps due to permissions). 399 The Measurement Agent may originate a session towards the Controller 400 and maintain the session for bidirectional communications. This 401 would alleviate the need to have user intervention on the gateway, 402 but would reduce the overall scalability of the Controller as it 403 would have to maintain a higher number of active sessions. 405 That said, sending keepalives to prop open the firewall could serve a 406 dual purpose in testing network reachability for the Measurement 407 Agent. 409 An alternative would be to use a protocol such as UPnP or PCP 410 [RFC6887] to control the NAT/firewall if the gateway supports this 411 kind of control. 413 3.1.3. Measurement Agent in-line with Site Gateway 415 As mentioned earlier, there are benefits in the Measurement Agent's 416 ability to observe the site's user traffic. In the case of active 417 measurement it allows the Measurement Agent to back-off on a 418 potentially disruptive measurement task to avoid impacting the user. 419 For the case of passive measurement, access to the user traffic 420 allows the Measurement Agent to gather data without a traffic 421 footprint (of interest to both the site user and network operator) as 422 well as potentially provide a greater number of samples for a 423 measurement task. 425 A Measurement Agent behind the gateway would generally not be privy 426 to observation of the user traffic unless the Measurement Agent was 427 placed in-line with the site gateway or the site gateway traffic was 428 replicated to the Measurement Agent (a capability generally not found 429 in home broadband gateways). 431 3.1.4. Measurement Agent in Multi Homed Site 433 A broadband site may be multi-homed. For example, the site may be 434 connected to multiple broadband ISPs (perhaps for redundancy or load- 435 sharing), or have a broadband as well as mobile/WiFi connectivity. 436 It may also be helpful to think of dual stack IPv4 and IPv6 broadband 437 sites as multi-homed. 439 In these cases, there needs to be clarity on which network 440 connectivity option is being measured. Sometimes this is easily 441 resolved by the location of measurement agent itself. For example, 442 if the measurement agent is built into the gateway (and the gateway 443 only has a single WAN side interface), there is little confusion or 444 choice. However, for multi-homed gateways or devices behind the 445 gateway(s) of multi-homed sites it would be preferable to explicitly 446 select the network to measure (e.g. [RFC5533]) but the network 447 measured should be included in the Measurement Result. 449 Section 3.2 of [I-D.ietf-homenet-arch] describes dual-stack and 450 multi-homing topologies that might be encountered in a home network 451 (which is generally a broadband connected site). The Multiple 452 Interfaces (mif) working group covers cases where hosts are either 453 directly attached to multiple networks (physical or virtual) or 454 indirectly (multiple default routers, etc.). xref target="RFC6419"/> 455 provides the current practices of multi-interfaces hosts today. As 456 some of the end goals of a LMAP Measurement Agent is to replicate the 457 network experience as an end user would, it is important to 458 understand the current practices. 460 3.2. Remote Measurement Test Target 462 A remote measurement test target is the other side of the measurement 463 test - the test target of the Measurement Agent. The remote 464 measurement test target could also take many different forms: a web 465 site, a service (VoIP), a DNS server, an application specific server 466 (e.g., webex), a well known web site (e.g., youtube, Google Search), 467 another Measurement Agent in another home, a powerful Measurement 468 Agent that is well network connected (Anchor Measurement Agent), or 469 even a collection of home based Measurement Agents. 471 An Anchor Measurement Agent is a remote measurement test target that 472 is well placed bandwidth-wise and is meant to handle test traffic in 473 a highly scaled (1000s of test sessions) environment. Similar to the 474 measurement agent sitting at a broadband site, it is under the 475 direction of an LMAP Controller, but might support multi-tenancy. It 476 is generally expected to respond to broadband site Measurement Agents 477 rather than initiate tests. 479 As illustrated in Figure 2, a measurement task may not only involve a 480 similar LMAP Measurement Agent, but multiple such Measurement Agents. 481 An example where this arrangement would be useful is when an Anchor 482 Measurement Agent in a path capacity measurement is unable to 483 saturate a path, while horizontal scaling properties of multiple 484 Measurement Agents can. This arrangement also alleviates any one 485 remote Measurement Agent from saturating its own access link as the 486 load is distributed. 488 +------------------+ 489 | | +--------------------------+ 490 | |<---->|Remote Measurement Agent 1| 491 | | +--------------------------+ 492 |Measurement Agent | 493 | | +--------------------------+ 494 | |<---->|Remote Measurement Agent 2| 495 | | +--------------------------+ 496 +------------------+ 498 Figure 2: Measurement Task Involving Multiple Remote Measurement 499 Agents 501 3.3. Controller 503 A Controller is responsible for providing the Measurement Agent with 504 instructions which include the test schedule, test parameters, etc. 505 It is basically the entity controlling the Measurement Agents in a 506 LMAP domain. 508 For scaling purposes there may be several Collectors as well as 509 several Controllers, perhaps regionally located. A large scale test 510 making use of multiple Controllers would need a master Controller 511 that is the ultimate source of direction. 513 3.4. Collector 515 A Collector is responsible for receiving the test results from the 516 Measurement Agent at the end of a test. It may have additional 517 features such as aggregating the results across multiple Measurement 518 Agents, remove outliers, create additional statistics, (depending on 519 usage of data) anonymization of results for privacy reasons (if not 520 done already in the Measurement Agents) etc. The work of 521 anonymization of user identifiable data has been addressed for IPFIX 522 via RFC6235 [RFC6235]. 524 For scaling purposes there may be several Collectors as well as 525 several Controllers, perhaps regionally located. A large scale test 526 making use of multiple Collectors would need to aggregate/consolidate 527 their results for the complete picture. 529 3.5. Information Model 531 For definitions and examples of Information Models and Data Models, 532 refer to [RFC3444] 534 The information shared between LMAP devices would be organized into 535 an LMAP information model [I-D.burbridge-lmap-information-model] 536 covering: 538 o Controlling the Measurement Agent (from the Controller) 540 o The Measurement Agent submitting the results (to the Collector) 542 In some cases, the Collector and Controller could be co-resident on 543 the same device but the information models would continue to be 544 separate. 546 The IETF IPFIX working group has defined an extensible information 547 model in [I-D.ietf-ipfix-information-model-rfc5102bis] which could be 548 used to organize the result metrics back to the LMAP Collector. 550 3.6. Transport Protocols 552 The information shared between the components that is in the 553 information model needs a transport protocol. Similar to the 554 information model the transport protocols would map to the following 555 main functions: 557 o Control of the Measurement Agent by the Controller 559 o Submission of measurement test results to the Collector 561 o Controller to Collector Test Configuration synchronization 563 Note that each of these could use different transport protocols. 564 However, for implementation simplification and keeping a small memory 565 footprint having the option of a single transport protocol can be 566 helpful. 568 The Controller to Controller Test Configuration Synchronization 569 provides a direct way for the Controller to communicate test 570 configuration information to the Collector. An alternate would have 571 been for the Measurement Agent to echo back the configuration to the 572 Controller. However, given several hundred thousand reports this 573 would to much duplication of data. It would be optimal to transfer 574 the test identification and configuration information directly to the 575 Collector(s) a single time. In this case, the Controller to 576 Collector Test Configuration Synchronization would be no different in 577 communications that with a Measurement Agent, except the Collector 578 would not execute the test-- it would simply understand it. Explicit 579 Collector directives (if they exist) by the Controller should not be 580 sent via the Measurement Agent. 582 The collated results from the Collector would have a pre-configured 583 path to publication or data storage. 585 To reduce the complexity and memory footprint needs of the 586 Measurement Agent it is possible that the control and report protocol 587 are the same (but still using the independent information models). 589 There are a number of transport candidate transport protocols. 590 Depending on the placement and use of the Measurement Agent certain 591 transport protocols may be preferred over others. For example if the 592 Measurement Agent is behind a NAT or firewall, it would be difficult 593 to make use of SNMP, or for the Controller to connect to the 594 Measurement Agent if REST were used. Regardless of transport 595 protocol used, the information model MUST be consistent. 597 3.7. Scaling 599 Scalability is a key issue, since LMAP is expected to scale to 600 10,000's of Measurement Agents. Therefore the architecture shown in 601 Figure 1 may include a hierarchy of Controllers and a hierarchy of 602 Collectors, e.g. with sub-controllers and sub-collectors distributed 603 topographically or geographically. Note that sub-collectors are 604 effectively IPFIX mediators [RFC6183]. 606 Separating the Control Protocol and Report Protocol allows these 607 hierarchies to scale independently, which would not be possible with 608 a single command-response protocol which requires a co-hosted 609 Controller/Collector implementation. 611 A scalability optimisation is discussed in Section 6.2.2. 613 3.8. Device Discovery 615 In a large-scale system, an LMAP controller must somehow discover 616 which Measurement Agents are available in the LMAP domain, and which 617 is the most appropriate collector for these agents to report test 618 results to. ie, for each LMAP Measurement Agent, which LMAP domain 619 is it in? 621 Possibilities include: 623 o The call home mechanism from netconf 624 [I-D.ietf-netconf-reverse-ssh] 626 o DNS SRV 628 o DNS anycast, selecting the nearest 630 o ALTO 632 o DHCP 634 Also note one corner case: a Collector may have to ignore test 635 results from a Measurement Agent which is mis-configured, or which 636 has been moved from one LMAP domain to another. ie, where the test 637 results are being reported out of scope. 639 4. Active Measurements 641 4.1. What building blocks exist today? 643 4.1.1. Single Sided Client Tests 645 A good number of active measurement tasks simply require that the 646 Measurement Agent perform client side duties and interact with a 647 Remote Measurement Test Target as a general user application would 648 have. Examples of single sided client tests include HTTP GETs from 649 private or public servers, DNS queries, FTP transfers etc. The 650 metrics are generally based on response time, bit rate of transfer 651 etc. 653 There are no requirements against the server and in fact it is likely 654 that the server might even be under the operational control of an 655 entirely different entity. Generally the servers in this will be 656 providing a user side function (a new website, DNS services, etc.) so 657 care must be taken in running too many synthetic tests as Denial of 658 Service (DoS) may be achieved or (more likely) automated DoS 659 protection mechanisms may come into play ultimately rejecting traffic 660 from that broadband site. 662 4.1.2. OWAMP - One Way Active Measurement Protocol 664 The One Way Active Measurement Protocol [RFC4656] allows for the 665 generation of a unidirectional test stream (by the Session-Sender) 666 and the measurement of that test stream by a remote entity (Session- 667 Receiver). The test stream is known as OWAMP-Test. The OWAMP- 668 Control protocol is used to (at the time of the test) negotiate 669 OWAMP-Test port numbers (for example UDP or TCP port numbers) between 670 the Session-Sender and Session-Receiver. As the test stream in OWAMP 671 is unidirectional the Session-Receiver has to compute the metrics. 672 The OWAMP-Control protocol is then used to retrieve the metrics. 673 Depending on the metrics being computed, it may be necessary for the 674 Session-Sender and Session-Receiver to the time synchronized. The 675 one-way-latency measurement is an example of this case. The OWAMP- 676 Control protocol is also used to covey from the Session-Sender to the 677 Session-Receiver any packets that were unable to be sent so the 678 Session-Receiver does not mistakenly count these non-existent packets 679 as loss. 681 Figure 3 describes the individual roles and relationships in OWAMP. 682 Any unlabeled links are unspecified by OWAMP and may be proprietary 683 protocols. 685 +----------------+ +------------------+ 686 | Session-Sender |--OWAMP-Test-->| Session-Receiver | 687 +----------------+ +------------------+ 688 ^ ^ 689 | | 690 | | 691 | | 692 | +----------------+<----------------+ 693 | | Server |<-------+ 694 | +----------------+ | 695 | ^ | 696 | | | 697 | OWAMP-Control OWAMP-Control 698 | | | 699 v v v 700 +----------------+ +-----------------+ 701 | Control-Client | | Fetch-Client | 702 +----------------+ +-----------------+ 704 Figure 3: OWAMP Individual Roles and Relationships 706 Figure 4 describes simplified individual roles and relationships in 707 OWAMP such that only two hosts are used. 709 +-----------------+ +------------------+ 710 | Control-Client |<--OWAMP-Control-->| Server | 711 | Fetch-Client | | | 712 | Session-Sender |---OWAMP-Test----->| Session-Receiver | 713 +-----------------+ +------------------+ 715 Figure 4: OWAMP Two Host Implementation 717 For the cases of many IPPM defined metrics the OWAMP is a natural fit 718 and the OWAMP-Test stream could certainly be utilized between two 719 Measurement Agents. The Session-Sender would be the local broadband 720 site Measurement Agent, while the Session-Receiver would be a Remote 721 Measurement Test Target, perhaps an anchor Measurement Agent or a 722 Measurement Agent at a broadband site. 724 In the case that Session-Receiver/Server is behind a firewall, it 725 would be challenging for the OWAMP-Control protocol to reach the 726 OWAMP Server. The usage of PCP by the Session-Receiver/Server might 727 be utilized. Another solution would be for the LMAP Controller to 728 take on the role of the OWAMP server-- with the understanding that 729 the LMAP server has open lines of communication to all Measurement 730 Agents. The case of the OWAMP-Test stream would also be challenged 731 in crossing such a firewall. The OWAMP-Test transport ports are 732 dynamically negotiated to prevent special handling by the underlying 733 network. The LMAP Controller line of communication may be of little 734 help in this case and other techniques would need to be used. 736 The OWAMP-Control protocol provides an authenticated control channel 737 that prevents unauthorized usage (and thereby conserving test 738 resources and bandwidth) as well as tampering with the results as 739 they are fetched from the Session-Receiver. Additionally, encryption 740 is also offered to prevent a third-party from improving the results 741 that reality. If authentication and encryption is to be used in an 742 LMAP scenario, the shared-secret would need to be deployed to both 743 the Session-Sender and the Session-Receiver. 745 4.1.3. TWAMP - Two Way Active Measurement Protocol 747 The Two-Way Active Measurement Protocol [RFC5357] builds on top of 748 the OWAMP work to allow two-way active measurement. In TWAMP, the 749 Session-Receiver becomes a Session-Reflector that does not keep state 750 for the test metric and simply reflects back the received test stream 751 (with some additions and modifications to account for the reverse 752 direction trip. The metric computation is performed at the Session- 753 Sender. 755 Figure 5 describes the individual roles and relationships in TWAMP. 756 Note that due to the Session-Reflector, the diagram is simplified 757 compared to OWAMP. Any unlabeled links are unspecified by OWAMP and 758 may be proprietary protocols. 760 +----------------+ +-------------------+ 761 | Session-Sender |<-TWAMP-Test-->| Session-Reflector | 762 +----------------+ +-------------------+ 763 ^ ^ 764 | | 765 | | 766 | | 767 | +----------------+<----------------+ 768 | | Server | 769 | +----------------+ 770 | ^ 771 | | 772 | TWAMP-Control 773 | | 774 v v 775 +----------------+ 776 | Control-Client | 777 +----------------+ 779 Figure 5: TWAMP Individual Roles and Relationships 781 Figure 6 describes simplified individual roles and relationships in 782 TWAMP such that only two hosts are used. 784 +-----------------+ +-------------------+ 785 | Control-Client |<--TWAMP-Control-->| Server | 786 | | | | 787 | Session-Sender |<--TWAMP-Test----->| Session-Reflector | 788 +-----------------+ +-------------------+ 790 Figure 6: TWAMP Two Host Implementation 792 For the cases of many IPPM defined metrics the TWAMP is a natural fit 793 and the TWAMP-Test stream could certainly be utilized between two 794 Measurement Agents. The Session-Sender would be the local broadband 795 site Measurement Agent, while the Session-Reflector would be a Remote 796 Measurement Test Target, perhaps an anchor Measurement Agent or a 797 Measurement Agent at a broadband site. 799 In the case that Session-Reflector/Server is behind a firewall, the 800 same challenges for TWAMP-Control and TWAMP-Test as described for 801 OWAMP earlier would apply to TWAMP. 803 4.1.4. Cisco Service-Level Assurance Protocol 805 The Cisco Service Level Assurance Protocol [RFC6812] is similar to 806 OWAMP and TWAMP in that there is a control phase that negotiates 807 transport port usage and a measurement phase. The issues described 808 previously to remote test targets situated behind a firewall would 809 continue to apply to CSLA. 811 4.1.5. IPPM Performance Metrics 813 A good number of performance methodologies and metrics exist today 814 and have been defined via various works by the IETF IPPM working 815 group. Recently, guidelines have been published for new performance 816 metrics in [RFC6390]. These guidelines are applied by the 817 Performance Metrics Directorate [pm-dir] when reviewing new metrics. 819 4.2. Missing building blocks 821 4.2.1. Time Synchronization 823 A variety of the metrics require the time synchronization to a common 824 clock. This time synchronization is not guaranteed, especially at 825 broadcast sites. Given that the Measurement Agents are communicating 826 to a common set of Controller(s) this should present an opportunity 827 to provide a fall-back common clock. In this particular case it may 828 not be in the best interest of the test to use broadband site local 829 NTP server configuration as the disparate Measurement Agents might be 830 on different NTP hierarchies. 832 4.2.2. Shared Secret Distribution 834 A secured control protocol and test stream between the Measurement 835 Agents requires the distribution of a shared key. Such a shared key 836 might be distributed by the Controller or by the Measurement Agent 837 provisioning system. 839 4.2.3. NAT/Firewall Traversal for Control and Test Protocols 841 A NAT or firewall in between the Measurement Agents can become 842 problematic. In this case the traditional method of control 843 communications between the Measurement Agents would be impaired. 844 Whereas the control protocols are on well known ports, the test 845 streams are on negotiated port values. In this case, the test 846 traffic may need to also be well known port values. There may be 847 alternative mechanisms to reach the Measurement Agent behind the 848 firewall such as via the Controller line of communication or the use 849 of PCP. 851 4.2.4. IPPM Metrics Registry 853 The IPPM WG defined an IPPM Metrics Registry [RFC4148] . However this 854 was obsoleted by [RFC6248] as the registry was found to be 855 insufficiently detailed to uniquely identify IPPM metrics. Calls to 856 the community regarding the registry were unanswered in 2010. 858 Such a registry (and the unique identification issue resolved) will 859 be needed to by the LMAP system as the controller needs to designate 860 which test (or to be more precise, which metric within a test) is to 861 be run by the measurement agent. There's currently no IPPM metrics 862 registry since [RFC4148] was obsoleted by [RFC6248]. Proposals for 863 such a registry can be found at [I-D.claise-ippm-perf-metric- 864 registry-00], [I-D.bagnulo-ippm-new-registry], and 865 [I-D.bagnulo-ippm-new-registry-independent]. The first provides a 866 simplified model, taking into account PMOL [RFC6390] and the IPFIX 867 Information Model [I-D.ietf-ipfix-information-model-rfc5102bis]. The 868 second has a single registry with sub-registries while the third 869 proposes a more distributed registry for the components involved. As 870 this new registry is created it would be extremely helpful that the 871 metrics added to the registry confirm to the performance metrics 872 guidelines outlined in [RFC6390]. 874 4.2.5. OWAMP/TWAMP configuration 875 Currently there are no standardised way to configure OWAMP and TWAMP. 876 An information model is required. A YANG module (data model) would 877 be a plus, if NETCONF is chosen as the LMAP Configuration Protocol. 879 5. Passive Measurements 881 5.1. What building blocks exist today? 883 5.1.1. Measuring Packets 885 The PSAMP Framework [RFC5474] specifies a framework for Packet 886 Sampling ("PSAMP"). 888 The PSAMP protocol [RFC5476] selects packets from a stream according 889 to a set of standardized selectors, forms a stream of reports on the 890 selected packets, and exports the reports to a Collector. The PSAMP 891 Framework [RFC5474] defines packet selection processes, with various 892 types of filtering and sampling. It defines the exporting process 893 and packet reports. 895 The architecture shown in section 3.1 of the PSAMP Framework 896 [RFC5474] corresponds well to the LMAP architecture discussed in 897 Section 3 above. The PSAMP Metering Process corresponds to LMAP 898 Measurement Agents; the PSAMP protocol corresponds to the LMAP Report 899 Protocol; the PSAMP Collector corresponds to the LMAP Collector. 901 [RFC5477] defines an Information Model for Packet Sampling Exports 902 which is used by the PSAMP protocol for encoding sampled packet data 903 and information related to the sampling process. This includes 904 confidence intervals, measurement error, and observation timestamps. 906 In PSAMP, a Selector ID identifies a Primitive Selector, and a 907 Selection Sequence ID identifies a combination of Selectors. LMAP 908 should follow a similar model, using a global ID to identify a 909 complex test built up from a set of test primitives. 911 5.1.2. Measuring Flows 913 The IPFIX Metering Process defined in [RFC5470] is designed to meter 914 flows, which are defined as: 916 A Flow is defined as a set of IP packets passing an Observation 917 Point in the network during a certain time interval. All packets 918 belonging to a particular Flow have a set of common properties. 920 Inserting IPFIX terminology into Figure 1 above gives the 921 architecture shown in Figure 7: 923 +---------------------------------+ 924 |Remote Measurement Test Target(s)| 925 | IPFIX Observation Point(s) | 926 +---------------------------------+ 927 ^ 928 | 929 v 930 +-------------------------+ 931 | IPFIX Metering Process | 932 +----------+ |.........................| +--------------------------+ 933 |Controller|<--->| Measurement Agent | | Collector(s) | 934 +----------+ |.........................| |..........................| 935 | IPFIX Exporting Process |---->| IPFIX Collecting Process | 936 +-------------------------+ +--------------------------+ 938 Figure 7: LMAP IPFIX Architecture 940 The only component of the LMAP architecture which doesn't have a 941 parallel in IPFIX is the LMAP Controller. Therefore the IPFIX 942 Architecture is clearly a key component for passive measurements in 943 an LMAP Measurement Agent. 945 Inputs to the IPFIX Metering Process are packet headers, packet 946 characteristics, and packet treatment. The Metering Process consists 947 of a set of functions that includes packet header capture, 948 timestamping, sampling, classifying, and maintaining Flow Records. 950 A packet belongs to a Flow if it completely satisfies all the defined 951 properties of the Flow. This definition covers the range from a Flow 952 containing all packets observed at a network interface to a Flow 953 consisting of just a single packet between two applications. It 954 includes packets selected by a sampling mechanism. 956 [I-D.ietf-ipfix-protocol-rfc5101bis] specifies the IPFIX Protocol 957 which transmits information from the IPFIX Metering Process over the 958 network, from an Exporting Process to a Collecting Process. The 959 Protocol defines a common data representation and a standard means of 960 communicating information over a number of transport protocols from 961 an Exporting Process to a Collecting Process. 963 The IPFIX protocol is a candidate for the LMAP Report Protocol 964 between Measurement Agents and Collectors. 966 [I-D.ietf-ipfix-information-model-rfc5102bis] defines the Information 967 Model for IPFIX export, for which IANA's IPFIX registry 968 [iana-ipfix-assignments]) is now the normative reference. The 969 information model encodes measured traffic information and 970 information related to the traffic Observation Point, the traffic 971 Metering Process, and the Exporting Process - ie, both details of the 972 measured traffic and metadata about the Measurement Agent. 974 Although developed for the IPFIX Protocol, the information model is 975 defined in an open way that readily allows it to be used in other 976 protocols and applications. The information model is maintained as 977 an IANA registry [iana-ipfix-assignments]). 979 [I-D.ietf-ipfix-ie-doctors] provides guidelines for how define new 980 IPFIX Information Elements. It provides instructions on using the 981 proper conventions for Information Elements to be registered in the 982 IANA IPFIX Information Element registry, and provides guidelines for 983 expert reviewers to evaluate new registrations. 985 [RFC6759] specifies an extension to the IPFIX information model to 986 export application information, including application ID, name, 987 description, and classification which would be useful if the test 988 needs to be run, or test results must be reported, per application. 990 5.1.3. Defining new Information Elements 992 The IPFIX Information Model defined in 993 [I-D.ietf-ipfix-information-model-rfc5102bis] is extensible: new 994 elements may be defined by following the process defined in 995 [I-D.ietf-ipfix-ie-doctors]. New Information Elements may be 996 registered in IANA's IPFIX Information Element registry, or may be 997 enterprise specific. 999 The IPFIX protocol supports export of both standard Information 1000 Elements (as defined in IANA's IPFIX registry 1001 [iana-ipfix-assignments]), and enterprise-specific Information 1002 Elements which allows non-standard (ie, proprietary) information to 1003 be carried in the protocol. 1005 This extensibility allows new information to be carried in the IPFIX 1006 protocol without any modification to the underlying protocol. 1008 5.1.4. Exporting Process 1010 An IPFIX Exporting Process [RFC5470] transmits information generated 1011 by one or more IPFIX [RFC5470] or PSAMP [RFC5474] Metering Processes 1012 to one or more Collecting Processes. IPFIX export is specified over 1013 SCTP, UDP, and TCP, with authentication and security. 1015 In LMAP terms, the Exporting Process uses the Reporting Protocol to 1016 transmit test information from Measurement Agents to the Collector. 1018 5.1.5. Mediation 1020 The sharing of information for monitoring applications having 1021 different requirements raises issues in terms of measurement system 1022 scalability, measurement flexibility, and export reliability which 1023 are described in [RFC5982]. Mediation fills the gap between 1024 restricted metering capabilities and the requirements of measurement 1025 applications by introducing an intermediate device called the 1026 Mediator. 1028 [RFC6183] describes a framework for IPFIX Mediation. It introduces a 1029 generalized concept for intermediate entities, describes the high- 1030 level Mediation architecture, key architectural components, and 1031 mediation characteristics. 1033 Mediation could be anonymization [RFC6235], aggregation 1034 [I-D.ietf-ipfix-a9n], or flow selection 1035 [I-D.ietf-ipfix-flow-selection-tech]. Removing user identifiable 1036 information eg by aggregation is especially important for passive 1037 measurements. 1039 Aggregation is needed in the ISP use case, when the ISP needs to 1040 report the information to the regulator. 1042 Note that IPFIX is required to report the output of any mediation 1043 function, possibly with stricter rules to support LMAP. 1045 5.1.6. Configuration 1047 [RFC6728] specifies the Configuration Data Model for IPFIX and PSAMP 1048 exporting and metering process configuration, and for Collecting 1049 Processes. The model is specified using YANG [RFC6020]. The 1050 configuration data is encoded in Extensible Markup Language (XML). 1052 YANG is a data modeling language used to model configuration and 1053 state data manipulated by the Network Configuration Protocol 1054 (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. 1056 5.2. Missing building blocks 1058 5.2.1. Performance metrics definition in the IPFIX registry 1060 IANA's IPFIX Information Elements registry [iana-ipfix-assignments]) 1061 defines around 400 elements, ranging from layer 2, 3, and 4 packet 1062 fields to layer 7 application details, and including timestamps, pre/ 1063 post NAT fields, sampling and filtering details. However, the 1064 registry includes very few performance metrics. 1066 The IPPM WG defined an IPPM Metrics Registry [RFC4148]. However this 1067 was obsoleted by [RFC6248]. 1069 LMAP requires a standardised performance metrics registry, i.e. a 1070 PMOL IANA registry based on section 5.4.4 of [RFC6390]. See [I-D 1071 .claise-ippm-perf-metric-registry-00], 1073 5.2.2. Mediation Configuration 1075 In the Collector infrastructure, mediation changes traffic 1076 granularity, provides time and/or spatial data composition, data 1077 anonymization, and data retention. 1079 [RFC5982] indicates that increasing numbers of data exporters, 1080 traffic, and the variety of treatments expected to be performed on 1081 the data make it more and more difficult to implement all measurement 1082 applications within a single Collector. To increase the collecting 1083 bandwidth capacity and processing capacity, distributed Collectors 1084 need to be deployed close to Exporters. In this case, those 1085 Collectors become mediators, re-exporting data on demand to 1086 centralized applications. 1088 Although the IPFIX WG has published a Mediation Problem Statement 1089 [RFC5982] and a Mediation Framework [RFC6183], and is currently 1090 working on a mediation protocol [I-D.ietf-ipfix-mediation-protocol], 1091 there's currently no configuration model for mediation. 1093 6. LMAP: Standards Re-usability 1095 6.1. Existing Building Blocks 1097 The LAMP charter has been defined [lmap-wg-charter]. The Working 1098 Group is in the process of defining the framework. 1100 6.2. Missing Building Blocks 1102 6.2.1. Task Definitions 1104 The central part of LMAP is the Measurement Task itself which 1105 performs the measurement and generates the Measurement Result that is 1106 shared with the Collector. 1108 An information model is needed to organize the Measurement Task 1109 configuration, scheduling, and result posting of measurement tasks. 1110 A proposal of such an information model can be found at 1111 [I-D.burbridge-lmap-information-model]. 1113 The Measurement Task is an instance of the Measurement Method at 1114 specific time (schedule) and place (Measurement Agent). The 1115 Measurement Method is the methodology used to generate the metrics. 1116 Therefore for comparable metrics the Measurement Method needs to be 1117 well understood and agreed upon. Additionally, the manner to 1118 reference the Measurement Method in the Instruction setup should be 1119 from a well-known registry. From experience, there are a number of 1120 existing methods to generate similarly named metrics. However, the 1121 results of these methods is not comparable as the algorithm used is 1122 not the same. The well-known registry should not simply list the 1123 measurement methods but also clearly define scope and usability of 1124 such metrics to avoid result comparison confusion. 1126 A Measurement Task would include not only the Measurement Method but 1127 also configuration parameters such as (in the case of passive 1128 monitoring) what traffic to monitor or (in the case of active 1129 monitoring) that Remote Measurement Test Target(s) and test 1130 parameters etc. Some of these configuration parameters may not be 1131 explicit but implicit based on local state on the Measurement Agent. 1132 For example, the Controller may give Instruction to provide 1133 reachability (e.g. ping) information from the 1st and 2nd hop device 1134 towards a destination IP address. In this case, each 1st and 2nd hop 1135 device would not be known to the Controller and would be different at 1136 each Measurement Agent. Another example is the selection of the 1137 specific Controllers to which the Measurement Results should be 1138 posted to. The Controller may use ALTO [I-D.ietf-alto-protocol] to 1139 discover which Collector is the best one to use for each specific 1140 Measurement Agent, or the Controller may delegate the Controller 1141 selection to the Measurement Agent (ALTO, DNS SRV, etc.). 1143 A Measurement Method could include a multi-part set of tests which 1144 chain information together to replicate a user workflow. For example 1145 the method might start with a DNS query to a specific website, a 1146 measurement on the DNS response time, and the DNS query result used 1147 in a HTTP GET (while using the VHOST of the website) and the download 1148 bitrate measured. 1150 The Measurement Task could be spread across multiple Measurement 1151 Agents each generating and submitting their Measurement Results to 1152 the Collector(s). A Measurement Task ID would need to be allocated 1153 by the Controller to identify the Task to the Collector which would 1154 further aggregating the results from Measurement Agents. This Task 1155 ID would need to be unique across Controller reboots to prevent 1156 collision of different Measurement Tasks on to the Collector. 1158 6.2.2. Instructions Setup 1159 The Controller uses the Control Protocol to communicate with the 1160 Measurement Agents, to schedule tests. (As a scalability 1161 optimisation, the Controller may also use the Control Protocol to 1162 inform the Collector of the requested test(s). Else, every 1163 Measurement Agent would have to repeat the Test details to the 1164 Collector, along with the Test results.) 1166 Which protocol should be used as the Control Protocol? Several 1167 possibilities exist, including NetConf [RFC6241], and YANG [RFC6020], 1168 Apache thrift, REST-style HTTP(s), TR-069, ALTO, ... 1170 The Control Protocol should be transport independent, and available 1171 over a variety of transports. e.g., SCTP, TCP, and UDP, in both IPv4 1172 and IPv6 networks, since Measurement Agents will be located in 1173 different kinds of networks. e.g., Home router versus branch office. 1175 6.2.3. Task Scheduling 1177 In one use case, tests are run immediately upon receipt of a command 1178 and reported immediately to the Collector. In a different use case, 1179 tests are configured ahead of time, perhaps across multiple 1180 Measurement Agents with the intention that all the Agents run the 1181 test at about the same time. In yet another case, a test may be run 1182 repeatedly or may otherwise make observations at several discrete 1183 times. 1185 Therefore the Control Protocol must be able to clearly indicate to 1186 the Measurement Agent(s) when the test is scheduled, and the 1187 Reporting Protocol must be able to clearly indicate when the test was 1188 run. 1190 These time indications may be either absolute ("at 10:23") or 1191 relative ("in 300 seconds"). Absolute timestamps require good clock 1192 synchronisation between the Controller, Measurement Agents, and 1193 Collector. Relative timestamps don't require any clock 1194 synchronisation. However, they're susceptible to delays. 1196 The IPFIX WG has standardised many timestamps 1197 [iana-ipfix-assignments]). Each time stamp is available in multiple 1198 resolutions: seconds, milliseconds, microseconds, nanoseconds, being 1199 a trade-off between range and resolution. 1201 6.2.4. Combining Active and Passive Measurements 1203 The balanced use of both active and passive measurements would be 1204 needed in a large scale measurement system. While it is certainly 1205 possible to run active measurements to variety of test targets this 1206 can be disruptive to user traffic (and to the test if the active 1207 measurement backs off) but also the remote measurement test targets 1208 that have user facing services. Additionally, active measurement 1209 would be taking away bandwidth certainly from the broadband site but 1210 potentially also from the ISP if the remote measurement test target 1211 is outside of the ISP. 1213 Many questions can be answered by simple observation rather than 1214 explicit active measurement. For example, response times for DNS 1215 queries can be gleaned by observation of user traffic rather than 1216 explicit probing. In fact, it is possible to gather more samples of 1217 measurement that would have been acceptable under active measurement. 1218 Similarly, observation of user traffic of a Video on Demand stream to 1219 well known content provider can reveal information about the network 1220 conditions along the path to the content provider's server. 1222 One proposal for making use of both active and passive measurement is 1223 to allow the Measurement Agent to make local decisions on which 1224 technique to use to deliver a particular metric-- as long as the 1225 specific method is included in the report. For example, DNS response 1226 time could be answered by passive monitoring as well as active 1227 monitoring. The Measurement Task could provide guidelines along how 1228 long to delay an active measurement in case passive measurement is 1229 unable to provide the result. If passive measurement is unable to 1230 provide a result, active measurement would be engaged. 1232 Similarly, rather than completely backing off on an last mile path 1233 capacity active measurement in the presence of user traffic the 1234 Measurement Agent might keep a historical record of the high 1235 watermark of user traffic utilization and attempt to actively probe 1236 the delta current utilization and the high-water mark or the 1237 configured service profile (that the broadband site is 20mbps 1238 connected). 1240 In all cases of the combined usage of active and passive measurement 1241 the results need to clearly indicate which method was used to what 1242 extent. 1244 7. Security considerations 1246 The privacy aspects of the end user measurements are important. The 1247 potentially large number of Measurement Agents capable of driving 1248 network traffic can be an attractive target for taking control of 1249 utilized for Denial of Service (DoS) attacks. The sizable resources 1250 associated also with the anchor Measurement Agents needs to be 1251 protected from unauthorized usage. Finally, as the Measurement 1252 Results could have potentially damaging commercial and regulatory 1253 effects they need to protected as well. 1255 The security considerations related to LMAP will be completed in the 1256 future. 1258 8. IANA Considerations 1260 There are no IANA considerations in this memo. 1262 9. Acknowledgements 1264 Thanks to all the authors of all the referenced works, and to the 1265 experts at Cisco who helped to make this draft possible. 1267 Thanks to our families for their patience and understanding while we 1268 wrote this draft. 1270 10. References 1272 10.1. Normative References 1274 [I-D.burbridge-lmap-information-model] 1275 Burbridge, T., Eardley, P., Bagnulo, M., and J. 1276 Schoenwaelder, "Information Model for Large-Scale 1277 Measurement Platforms (LMAP)", draft-burbridge-lmap- 1278 information-model-00 (work in progress), July 2013. 1280 [I-D.eardley-lmap-terminology] 1281 Eardley, P., Morton, A., Bagnulo, M., and T. Burbridge, 1282 "Terminology for Large MeAsurement Platforms (LMAP)", 1283 draft-eardley-lmap-terminology-02 (work in progress), July 1284 2013. 1286 [I-D.linsner-lmap-use-cases] 1287 Linsner, M., Eardley, P., and T. Burbridge, "Large-Scale 1288 Broadband Measurement Use Cases", draft-linsner-lmap-use- 1289 cases-03 (work in progress), July 2013. 1291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1292 Requirement Levels", BCP 14, RFC 2119, March 1997. 1294 10.2. Informative References 1296 [I-D.bagnulo-ippm-new-registry-independent] 1297 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 1298 A. Morton, "A registry for commonly used metrics. 1299 Independent registries", draft-bagnulo-ippm-new-registry- 1300 independent-01 (work in progress), July 2013. 1302 [I-D.bagnulo-ippm-new-registry] 1303 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 1304 A. Morton, "A registry for commonly used metrics", draft- 1305 bagnulo-ippm-new-registry-01 (work in progress), July 1306 2013. 1308 [I-D.ietf-alto-protocol] 1309 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 1310 ietf-alto-protocol-17 (work in progress), July 2013. 1312 [I-D.ietf-homenet-arch] 1313 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1314 "Home Networking Architecture for IPv6", draft-ietf- 1315 homenet-arch-09 (work in progress), July 2013. 1317 [I-D.ietf-ipfix-a9n] 1318 Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation 1319 for the IP Flow Information Export (IPFIX) Protocol", 1320 draft-ietf-ipfix-a9n-08 (work in progress), November 2012. 1322 [I-D.ietf-ipfix-flow-selection-tech] 1323 D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow 1324 Selection Techniques", draft-ietf-ipfix-flow-selection- 1325 tech-18 (work in progress), May 2013. 1327 [I-D.ietf-ipfix-ie-doctors] 1328 Trammell, B. and B. Claise, "Guidelines for Authors and 1329 Reviewers of IPFIX Information Elements", draft-ietf- 1330 ipfix-ie-doctors-07 (work in progress), October 2012. 1332 [I-D.ietf-ipfix-information-model-rfc5102bis] 1333 Claise, B. and B. Trammell, "Information Model for IP Flow 1334 Information eXport (IPFIX)", draft-ietf-ipfix-information- 1335 model-rfc5102bis-10 (work in progress), February 2013. 1337 [I-D.ietf-ipfix-mediation-protocol] 1338 Claise, B., Kobayashi, A., and B. Trammell, "Operation of 1339 the IP Flow Information Export (IPFIX) Protocol on IPFIX 1340 Mediators", draft-ietf-ipfix-mediation-protocol-05 (work 1341 in progress), June 2013. 1343 [I-D.ietf-ipfix-protocol-rfc5101bis] 1344 Claise, B. and B. Trammell, "Specification of the IP Flow 1345 Information eXport (IPFIX) Protocol for the Exchange of 1346 Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-10 1347 (work in progress), July 2013. 1349 [I-D.ietf-netconf-reverse-ssh] 1350 Watsen, K., "Reverse Secure Shell (Reverse SSH)", draft- 1351 ietf-netconf-reverse-ssh-01 (work in progress), June 2013. 1353 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1354 Information Models and Data Models", RFC 3444, January 1355 2003. 1357 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1358 Registry", BCP 108, RFC 4148, August 2005. 1360 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 1361 Zekauskas, "A One-way Active Measurement Protocol 1362 (OWAMP)", RFC 4656, September 2006. 1364 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1365 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1366 RFC 5357, October 2008. 1368 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 1369 "Architecture for IP Flow Information Export", RFC 5470, 1370 March 2009. 1372 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 1373 "Architecture for IP Flow Information Export", RFC 5470, 1374 March 2009. 1376 [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., 1377 Grossglauser, M., and J. Rexford, "A Framework for Packet 1378 Selection and Reporting", RFC 5474, March 2009. 1380 [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., 1381 Grossglauser, M., and J. Rexford, "A Framework for Packet 1382 Selection and Reporting", RFC 5474, March 2009. 1384 [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling 1385 (PSAMP) Protocol Specifications", RFC 5476, March 2009. 1387 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 1388 Carle, "Information Model for Packet Sampling Exports", 1389 RFC 5477, March 2009. 1391 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1392 Shim Protocol for IPv6", RFC 5533, June 2009. 1394 [RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information Export 1395 (IPFIX) Mediation: Problem Statement", RFC 5982, August 1396 2010. 1398 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1399 Network Configuration Protocol (NETCONF)", RFC 6020, 1400 October 2010. 1402 [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, 1403 "IP Flow Information Export (IPFIX) Mediation: Framework", 1404 RFC 6183, April 2011. 1406 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 1407 Support", RFC 6235, May 2011. 1409 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1410 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1411 6241, June 2011. 1413 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 1414 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April 1415 2011. 1417 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 1418 Performance Metric Development", BCP 170, RFC 6390, 1419 October 2011. 1421 [RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration Data 1422 Model for the IP Flow Information Export (IPFIX) and 1423 Packet Sampling (PSAMP) Protocols", RFC 6728, October 1424 2012. 1426 [RFC6759] Claise, B., Aitken, P., and N. Ben-Dvora, "Cisco Systems 1427 Export of Application Information in IP Flow Information 1428 Export (IPFIX)", RFC 6759, November 2012. 1430 [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, 1431 S., and E. Yedavalli, "Cisco Service-Level Assurance 1432 Protocol", RFC 6812, January 2013. 1434 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1435 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 1436 2013. 1438 [iana-ipfix-assignments] 1439 Internet Assigned Numbers Authority, ., "IP Flow 1440 Information Export Information Elements 1441 (http://www.iana.org/assignments/ipfix/ipfix.xml)", . 1443 [lmap-wg-charter] 1444 , "LMAP Working Group Charter 1445 (http://tools.ietf.org/wg/lmap/charters)", . 1447 [pm-dir] , "Performance Metrics Directorate (http://www.ietf.org/ 1448 iesg/directorate/performance-metrics.html)", . 1450 Authors' Addresses 1452 Aamer Akhter 1453 Cisco Systems, Inc. 1454 7025 Kit Creek Road 1455 RTP, NC 27709 1456 USA 1458 Email: aakhter@cisco.com 1460 Paul Aitken 1461 Cisco Systems, Inc. 1462 96 Commercial Street 1463 Edinburgh, Scotland EH6 6LX 1464 UK 1466 Email: paitken@cisco.com