| < draft-ietf-lmap-framework-08.txt | draft-ietf-lmap-framework-14.txt > | |||
|---|---|---|---|---|
| Network Working Group P. Eardley | Network Working Group P. Eardley | |||
| Internet-Draft BT | Internet-Draft BT | |||
| Intended status: Informational A. Morton | Intended status: Informational A. Morton | |||
| Expires: February 8, 2015 AT&T Labs | Expires: October 31, 2015 AT&T Labs | |||
| M. Bagnulo | M. Bagnulo | |||
| UC3M | UC3M | |||
| T. Burbridge | T. Burbridge | |||
| BT | BT | |||
| P. Aitken | P. Aitken | |||
| Brocade | ||||
| A. Akhter | A. Akhter | |||
| Cisco Systems | Consultant | |||
| August 7, 2014 | April 29, 2015 | |||
| A framework for large-scale measurement platforms (LMAP) | A framework for Large-Scale Measurement of Broadband Performance (LMAP) | |||
| draft-ietf-lmap-framework-08 | draft-ietf-lmap-framework-14 | |||
| Abstract | Abstract | |||
| Measuring broadband service on a large scale requires a description | Measuring broadband service on a large scale requires a description | |||
| of the logical architecture and standardisation of the key protocols | of the logical architecture and standardisation of the key protocols | |||
| that coordinate interactions between the components. The document | that coordinate interactions between the components. The document | |||
| presents an overall framework for large-scale measurements. It also | presents an overall framework for large-scale measurements. It also | |||
| defines terminology for LMAP (large-scale measurement platforms). | defines terminology for LMAP (Large-Scale Measurement of Broadband | |||
| Performance). | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on February 8, 2015. | This Internet-Draft will expire on October 31, 2015. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2. Outline of an LMAP-based measurement system . . . . . . . . . 5 | 2. Outline of an LMAP-based measurement system . . . . . . . . . 5 | |||
| 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 4.1. The measurement system is under the direction of a single | 4.1. The measurement system is under the direction of a single | |||
| organisation . . . . . . . . . . . . . . . . . . . . . . 11 | organisation . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 4.2. Each MA may only have a single Controller at any point in | 4.2. Each MA may only have a single Controller at any point in | |||
| time . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | time . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 5. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 12 | 5. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 5.1. Bootstrapping process . . . . . . . . . . . . . . . . . . 13 | 5.1. Bootstrapping process . . . . . . . . . . . . . . . . . . 14 | |||
| 5.2. Control Protocol . . . . . . . . . . . . . . . . . . . . 14 | 5.2. Control Protocol . . . . . . . . . . . . . . . . . . . . 15 | |||
| 5.2.1. Configuration . . . . . . . . . . . . . . . . . . . . 14 | 5.2.1. Configuration . . . . . . . . . . . . . . . . . . . . 15 | |||
| 5.2.2. Instruction . . . . . . . . . . . . . . . . . . . . . 15 | 5.2.2. Instruction . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 5.2.3. Capabilities, Failure and Logging Information . . . . 18 | 5.2.3. Capabilities, Failure and Logging Information . . . . 20 | |||
| 5.3. Operation of Measurement Tasks . . . . . . . . . . . . . 20 | 5.3. Operation of Measurement Tasks . . . . . . . . . . . . . 22 | |||
| 5.3.1. Starting and Stopping Measurement Tasks . . . . . . . 20 | 5.3.1. Starting and Stopping Measurement Tasks . . . . . . . 22 | |||
| 5.3.2. Overlapping Measurement Tasks . . . . . . . . . . . . 21 | 5.3.2. Overlapping Measurement Tasks . . . . . . . . . . . . 23 | |||
| 5.4. Report Protocol . . . . . . . . . . . . . . . . . . . . . 22 | 5.4. Report Protocol . . . . . . . . . . . . . . . . . . . . . 24 | |||
| 5.4.1. Reporting of Subscriber's service parameters . . . . 23 | 5.4.1. Reporting of Subscriber's service parameters . . . . 25 | |||
| 5.5. Operation of LMAP over the underlying packet transfer | 5.5. Operation of LMAP over the underlying packet transfer | |||
| mechanism . . . . . . . . . . . . . . . . . . . . . . . . 24 | mechanism . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 5.6. Items beyond the scope of the initial LMAP work . . . . . 25 | 5.6. Items beyond the scope of the initial LMAP work . . . . . 27 | |||
| 5.6.1. End-user-controlled measurement system . . . . . . . 26 | 5.6.1. End-user-controlled measurement system . . . . . . . 28 | |||
| 6. Deployment considerations . . . . . . . . . . . . . . . . . . 26 | 6. Deployment considerations . . . . . . . . . . . . . . . . . . 28 | |||
| 6.1. Controller and the measurement system . . . . . . . . . . 26 | 6.1. Controller and the measurement system . . . . . . . . . . 28 | |||
| 6.2. Measurement Agent . . . . . . . . . . . . . . . . . . . . 27 | 6.2. Measurement Agent . . . . . . . . . . . . . . . . . . . . 29 | |||
| 6.2.1. Measurement Agent on a networked device . . . . . . . 28 | 6.2.1. Measurement Agent on a networked device . . . . . . . 30 | |||
| 6.2.2. Measurement Agent embedded in site gateway . . . . . 28 | 6.2.2. Measurement Agent embedded in site gateway . . . . . 30 | |||
| 6.2.3. Measurement Agent embedded behind site NAT /firewall 28 | 6.2.3. Measurement Agent embedded behind site NAT /firewall 30 | |||
| 6.2.4. Multi-homed Measurement Agent . . . . . . . . . . . . 28 | 6.2.4. Multi-homed Measurement Agent . . . . . . . . . . . . 31 | |||
| 6.2.5. Measurement Agent embedded in ISP network . . . . . . 29 | 6.2.5. Measurement Agent embedded in ISP network . . . . . . 31 | |||
| 6.3. Measurement Peer . . . . . . . . . . . . . . . . . . . . 29 | ||||
| 7. Security considerations . . . . . . . . . . . . . . . . . . . 30 | 6.3. Measurement Peer . . . . . . . . . . . . . . . . . . . . 32 | |||
| 8. Privacy considerations . . . . . . . . . . . . . . . . . . . 32 | 6.4. Deployment examples . . . . . . . . . . . . . . . . . . . 32 | |||
| 8.1. Categories of entities with information of interest . . . 32 | 7. Security considerations . . . . . . . . . . . . . . . . . . . 35 | |||
| 8.2. Examples of sensitive information . . . . . . . . . . . . 33 | 8. Privacy considerations . . . . . . . . . . . . . . . . . . . 37 | |||
| 8.1. Categories of entities with information of interest . . . 38 | ||||
| 8.2. Examples of sensitive information . . . . . . . . . . . . 38 | ||||
| 8.3. Different privacy issues raised by different sorts of | 8.3. Different privacy issues raised by different sorts of | |||
| Measurement Methods . . . . . . . . . . . . . . . . . . . 34 | Measurement Methods . . . . . . . . . . . . . . . . . . . 39 | |||
| 8.4. Privacy analysis of the communication models . . . . . . 34 | 8.4. Privacy analysis of the communication models . . . . . . 40 | |||
| 8.4.1. MA Bootstrapping . . . . . . . . . . . . . . . . . . 35 | 8.4.1. MA Bootstrapping . . . . . . . . . . . . . . . . . . 40 | |||
| 8.4.2. Controller <-> Measurement Agent . . . . . . . . . . 36 | 8.4.2. Controller <-> Measurement Agent . . . . . . . . . . 41 | |||
| 8.4.3. Collector <-> Measurement Agent . . . . . . . . . . . 36 | 8.4.3. Collector <-> Measurement Agent . . . . . . . . . . . 42 | |||
| 8.4.4. Measurement Peer <-> Measurement Agent . . . . . . . 36 | 8.4.4. Measurement Peer <-> Measurement Agent . . . . . . . 42 | |||
| 8.4.5. Measurement Agent . . . . . . . . . . . . . . . . . . 38 | 8.4.5. Measurement Agent . . . . . . . . . . . . . . . . . . 44 | |||
| 8.4.6. Storage and reporting of Measurement Results . . . . 39 | 8.4.6. Storage and reporting of Measurement Results . . . . 45 | |||
| 8.5. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 39 | 8.5. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
| 8.5.1. Surveillance . . . . . . . . . . . . . . . . . . . . 39 | 8.5.1. Surveillance . . . . . . . . . . . . . . . . . . . . 45 | |||
| 8.5.2. Stored data compromise . . . . . . . . . . . . . . . 39 | 8.5.2. Stored data compromise . . . . . . . . . . . . . . . 45 | |||
| 8.5.3. Correlation and identification . . . . . . . . . . . 40 | 8.5.3. Correlation and identification . . . . . . . . . . . 46 | |||
| 8.5.4. Secondary use and disclosure . . . . . . . . . . . . 40 | 8.5.4. Secondary use and disclosure . . . . . . . . . . . . 46 | |||
| 8.6. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 41 | 8.6. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 47 | |||
| 8.6.1. Data minimisation . . . . . . . . . . . . . . . . . . 41 | 8.6.1. Data minimisation . . . . . . . . . . . . . . . . . . 47 | |||
| 8.6.2. Anonymity . . . . . . . . . . . . . . . . . . . . . . 42 | 8.6.2. Anonymity . . . . . . . . . . . . . . . . . . . . . . 48 | |||
| 8.6.3. Pseudonymity . . . . . . . . . . . . . . . . . . . . 43 | 8.6.3. Pseudonymity . . . . . . . . . . . . . . . . . . . . 49 | |||
| 8.6.4. Other mitigations . . . . . . . . . . . . . . . . . . 43 | 8.6.4. Other mitigations . . . . . . . . . . . . . . . . . . 49 | |||
| 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 44 | 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 50 | |||
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 | |||
| 11. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 | 11. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 | |||
| 11.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . 45 | 11.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . 51 | |||
| 11.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . 45 | 11.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . 51 | |||
| 11.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . 46 | 11.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . 52 | |||
| 11.4. From -03 to -04 . . . . . . . . . . . . . . . . . . . . 46 | 11.4. From -03 to -04 . . . . . . . . . . . . . . . . . . . . 52 | |||
| 11.5. From -04 to -05 . . . . . . . . . . . . . . . . . . . . 47 | 11.5. From -04 to -05 . . . . . . . . . . . . . . . . . . . . 53 | |||
| 11.6. From -05 to -06 . . . . . . . . . . . . . . . . . . . . 48 | 11.6. From -05 to -06 . . . . . . . . . . . . . . . . . . . . 54 | |||
| 11.7. From -06 to -07 . . . . . . . . . . . . . . . . . . . . 48 | 11.7. From -06 to -07 . . . . . . . . . . . . . . . . . . . . 54 | |||
| 11.8. From -07 to -08 . . . . . . . . . . . . . . . . . . . . 48 | 11.8. From -07 to -08 . . . . . . . . . . . . . . . . . . . . 54 | |||
| 12. Informative References . . . . . . . . . . . . . . . . . . . 48 | 11.9. From -08 to -09 . . . . . . . . . . . . . . . . . . . . 55 | |||
| Appendix A. Appendix: Deployment examples . . . . . . . . . . . 50 | 11.10. From -09 to -10 . . . . . . . . . . . . . . . . . . . . 55 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 | 11.11. From -10 to -11 . . . . . . . . . . . . . . . . . . . . 55 | |||
| 11.12. From -11 to -12 . . . . . . . . . . . . . . . . . . . . 55 | ||||
| 11.13. From -12 to -13 . . . . . . . . . . . . . . . . . . . . 55 | ||||
| 11.14. From -13 to -14 . . . . . . . . . . . . . . . . . . . . 55 | ||||
| 12. Informative References . . . . . . . . . . . . . . . . . . . 55 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 | ||||
| 1. Introduction | 1. Introduction | |||
| There is a desire to be able to coordinate the execution of broadband | There is a desire to be able to coordinate the execution of broadband | |||
| measurements and the collection of measurement results across a large | measurements and the collection of measurement results across a large | |||
| scale set of diverse devices. These devices could be software based | scale set of Measurement Agents (MAs). These MAs could be software | |||
| agents on PCs, embedded agents in consumer devices (e.g. Blu-ray | based agents on PCs, embedded agents in consumer devices (such as TVs | |||
| players), service provider controlled devices such as set-top boxes | or gaming consoles), embedded in service provider controlled devices | |||
| and home gateways, or simply dedicated probes. It is expected that | such as set-top boxes and home gateways, or simply dedicated probes. | |||
| such a system could easily comprise 100,000 devices. Measurement | MAs may also be embedded on a device that is part of an ISP's | |||
| devices may also be embedded on a device that is part of an ISP's | ||||
| network, such as a DSLAM (Digital Subscriber Line Access | network, such as a DSLAM (Digital Subscriber Line Access | |||
| Multiplexer), router, Carrier Grade NAT (Network Address Translator) | Multiplexer), router, Carrier Grade NAT (Network Address Translator) | |||
| or ISP Gateway. Such a scale presents unique problems in | or ISP Gateway. It is expected that a measurement system could | |||
| coordination, execution and measurement result collection. Several | easily encompass a few hundred thousand or even millions of such MAs. | |||
| use cases have been proposed for large-scale measurements including: | Such a scale presents unique problems in coordination, execution and | |||
| measurement result collection. Several use cases have been proposed | ||||
| for large-scale measurements including: | ||||
| o Operators: to help plan their network and identify faults | o Operators: to help plan their network and identify faults | |||
| o Regulators: to benchmark several network operators and support | o Regulators: to benchmark several network operators and support | |||
| public policy development | public policy development | |||
| Further details of the use cases can be found in | Further details of the use cases can be found in | |||
| [I-D.ietf-lmap-use-cases]. The LMAP framework should be useful for | [I-D.ietf-lmap-use-cases]. The LMAP framework should be useful for | |||
| these, as well as other use cases, such as to help end users run | these, as well as other use cases, such as to help end users run | |||
| diagnostic checks like a network speed test. | diagnostic checks like a network speed test. | |||
| skipping to change at page 4, line 40 ¶ | skipping to change at page 5, line 7 ¶ | |||
| for example: "Report results once a day in a batch at 4am". We refer | for example: "Report results once a day in a batch at 4am". We refer | |||
| to these as the Measurement Schedule and Report Schedule. | to these as the Measurement Schedule and Report Schedule. | |||
| The Collector accepts Reports from the MAs with the Results from | The Collector accepts Reports from the MAs with the Results from | |||
| their Measurement Tasks. Therefore the MA is a device that gets | their Measurement Tasks. Therefore the MA is a device that gets | |||
| Instructions from the Controller, initiates the Measurement Tasks, | Instructions from the Controller, initiates the Measurement Tasks, | |||
| and reports to the Collector. The communications between these three | and reports to the Collector. The communications between these three | |||
| LMAP functions are structured according to a Control Protocol and a | LMAP functions are structured according to a Control Protocol and a | |||
| Report Protocol. | Report Protocol. | |||
| The desirable features for a large-scale measurement systems we are | The desirable features for a large-scale Measurement Systems we are | |||
| designing for are: | designing for are: | |||
| o Standardised - in terms of the Measurement Tasks that they | o Standardised - in terms of the Measurement Tasks that they | |||
| perform, the components, the data models and protocols for | perform, the components, the data models and protocols for | |||
| transferring information between the components. Amongst other | transferring information between the components. Amongst other | |||
| things, standardisation enables meaningful comparisons of | things, standardisation enables meaningful comparisons of | |||
| measurements made of the same metric at different times and | measurements made of the same metric at different times and | |||
| places, and provides the operator of a measurement system with | places, and provides the operator of a Measurement System with | |||
| criteria for evaluation of the different solutions that can be | criteria for evaluation of the different solutions that can be | |||
| used for various purposes including buying decisions (such as | used for various purposes including buying decisions (such as | |||
| buying the various components from different vendors). Today's | buying the various components from different vendors). Today's | |||
| systems are proprietary in some or all of these aspects. | systems are proprietary in some or all of these aspects. | |||
| o Large-scale - [I-D.ietf-lmap-use-cases] envisages Measurement | o Large-scale - [I-D.ietf-lmap-use-cases] envisages Measurement | |||
| Agents in every home gateway and edge device such as set-top boxes | Agents in every home gateway and edge device such as set-top boxes | |||
| and tablet computers, and located throughout the Internet as well | and tablet computers, and located throughout the Internet as well | |||
| [I-D.ietf-ippm-lmap-path]. It is expected that a measurement | [RFC7398]. It is expected that a Measurement System could easily | |||
| system could easily encompass a few hundred thousand or even | encompass a few hundred thousand or even millions of Measurement | |||
| millions of Measurement Agents. Existing systems have up to a few | Agents. Existing systems have up to a few thousand MAs (without | |||
| thousand MAs (without judging how much further they could scale). | judging how much further they could scale). | |||
| o Diversity - a measurement system should handle different types of | o Diversity - a Measurement System should handle Measurement Agents | |||
| Measurement Agents - for example Measurement Agents may come from | from different vendors, that are in wired and wireless networks, | |||
| different vendors, be in wired and wireless networks, be able to | can execute different sorts of Measurement Task, are on devices | |||
| execute different sorts of Measurement Task and be on devices with | with IPv4 or IPv6 addresses, and so on. | |||
| IPv4 or IPv6 addresses. | ||||
| o Privacy Respecting - the protocols and procedures should respect | ||||
| the sensitive information of all those involved in measurements. | ||||
| 2. Outline of an LMAP-based measurement system | 2. Outline of an LMAP-based measurement system | |||
| Figure 1 shows the main components of a measurement system, and the | In this section we provide an overview of the whole Measurement | |||
| interactions of those components. Some of the components are outside | System. New LMAP-specific terms are capitalised; Section 3 provides | |||
| the scope of initial LMAP work. In this section we provide an | a terminology section with a compilation of all the LMAP terms and | |||
| overview of the whole measurement system. New LMAP-specific terms | their definition. Section 4 onwards considers the LMAP components in | |||
| are capitalised; Section 3 provides a terminology section with a | more detail. | |||
| compilation of all the LMAP terms and their definition. Section 4 | ||||
| onwards considers the LMAP components in more detail. | ||||
| Other LMAP specifications will define an information model, the | Other LMAP specifications will define an information model, the | |||
| associated data models, and select/extend one or more protocols for | associated data models, and select/extend one or more protocols for | |||
| the secure communication: firstly, a Control Protocol, from a | the secure communication: firstly, a Control Protocol, from a | |||
| Controller to instruct Measurement Agents what performance metrics to | Controller to instruct Measurement Agents what performance metrics to | |||
| measure, when to measure them, how/when to report the measurement | measure, when to measure them, how/when to report the measurement | |||
| results to a Collector; secondly, a Report Protocol, for a | results to a Collector; secondly, a Report Protocol, for a | |||
| Measurement Agent to report the results to the Collector. | Measurement Agent to report the results to the Collector. | |||
| The MA performs Measurement Tasks. The MAs are pieces of code that | The Figure below shows the main components of a Measurement System, | |||
| can be executed in specialised hardware (hardware probe) or on a | and the interactions of those components. Some of the components are | |||
| general-purpose device (like a PC or mobile phone). The MA may | outside the scope of initial LMAP work. | |||
| generate Measurement Traffic and measure some metric associated with | ||||
| its transfer, or the MA may observe existing traffic, or there may be | The MA performs Measurement Tasks. One possibility is that the MA is | |||
| some kind of hybrid of these two possibilities. A device with a | observes existing traffic. Another possibility is for the MA to | |||
| Measurement Agent may have multiple physical interfaces (Wi-Fi, | generate (or receive) traffic specially created for the purpose and | |||
| Ethernet, DSL (Digital Subscriber Line); and non-physical interfaces | measure some metric associated with its transfer. The | |||
| such as PPPoE (Point-to-Point Protocol over Ethernet) or IPsec) and | Figure includes both possibilities (in practice, it may be more usual | |||
| the Measurement Tasks may specify any one of these. | for a MA to do one) whilst Section 6.4 shows some examples of | |||
| possible arrangements of the components. | ||||
| The MAs are pieces of code that can be executed in specialised | ||||
| hardware (hardware probe) or on a general-purpose device (like a PC | ||||
| or mobile phone). A device with a Measurement Agent may have | ||||
| multiple physical interfaces (Wi-Fi, Ethernet, DSL (Digital | ||||
| Subscriber Line); and non-physical interfaces such as PPPoE (Point- | ||||
| to-Point Protocol over Ethernet) or IPsec) and the Measurement Tasks | ||||
| may specify any one of these. | ||||
| The Controller manages a MA through use of the Control Protocol, | The Controller manages a MA through use of the Control Protocol, | |||
| which transfers the Instruction to the MA. This describes the | which transfers the Instruction to the MA. This describes the | |||
| Measurement Tasks the MA should perform and when. For example the | Measurement Tasks the MA should perform and when. For example the | |||
| Controller may instruct a MA at a home gateway: "Count the number of | Controller may instruct a MA at a home gateway: "Count the number of | |||
| TCP SYN packets observed in a 1 minute interval; repeat every hour at | TCP SYN packets observed in a 1 minute interval; repeat every hour at | |||
| xx.05 + Unif[0,180] seconds". The Measurement Schedule determines | xx.05 + Unif[0,180] seconds". The Measurement Schedule determines | |||
| when the Measurement Tasks are executed. The Controller also manages | when the Measurement Tasks are executed. The Controller also manages | |||
| a MA by instructing it how to report the Measurement Results, for | a MA by instructing it how to report the Measurement Results, for | |||
| example: "Report results once a day in a batch at 4am + Unif[0,180] | example: "Report results once a day in a batch at 4am + Unif[0,180] | |||
| skipping to change at page 6, line 25 ¶ | skipping to change at page 6, line 48 ¶ | |||
| soon as possible"), as well as recurring ones. | soon as possible"), as well as recurring ones. | |||
| The Collector accepts a Report from a MA with the Measurement Results | The Collector accepts a Report from a MA with the Measurement Results | |||
| from its Measurement Tasks. It then provides the Results to a | from its Measurement Tasks. It then provides the Results to a | |||
| repository (see below). | repository (see below). | |||
| A Measurement Method defines how to measure a Metric of interest. It | A Measurement Method defines how to measure a Metric of interest. It | |||
| is very useful to standardise Measurement Methods, so that it is | is very useful to standardise Measurement Methods, so that it is | |||
| meaningful to compare measurements of the same Metric made at | meaningful to compare measurements of the same Metric made at | |||
| different times and places. It is also useful to define a registry | different times and places. It is also useful to define a registry | |||
| for commonly-used Metrics [I-D.manyfolks-ippm-metric-registry] so | for commonly-used Metrics [I-D.ietf-ippm-metric-registry] so that a | |||
| that a Metric with its associated Measurement Method can be referred | Metric with its associated Measurement Method can be referred to | |||
| to simply by its identifier in the registry. The Measurement Methods | simply by its identifier in the registry. The registry will | |||
| and registry will hopefully be referenced by other standards | hopefully be referenced by other standards organisations. The | |||
| organisations. | Measurement Methods may be defined by the IETF, locally, or by some | |||
| other standards body. | ||||
| Broadly speaking there are two types of Measurement Method. It may | Broadly speaking there are two types of Measurement Method. In both | |||
| involve a single MA simply observing existing traffic - for example, | types a Measurement Agent measures a particular Observed Traffic | |||
| the Measurement Agent could count bytes or calculate the average loss | Flow. It may involve a single MA simply observing existing traffic - | |||
| for a particular flow. On the other hand, a Measurement Method may | for example, the Measurement Agent could count bytes or calculate the | |||
| involve multiple network entities, which perform different roles. | average loss for a particular flow. On the other hand, a Measurement | |||
| For example, a "ping" Measurement Method, to measure the round trip | Method may involve multiple network entities, which perform different | |||
| delay , would consist of an MA sending an ICMP (Internet Control | roles. For example, a "ping" Measurement Method, to measure the | |||
| Message Protocol) ECHO request to a responder in the Internet. In | round trip delay , would consist of an MA sending an ICMP (Internet | |||
| LMAP terms, the responder is termed a Measurement Peer (MP), meaning | Control Message Protocol) ECHO request to a responder in the | |||
| that it helps the MA but is not managed by the Controller. Other | Internet. In LMAP terms, the responder is termed a Measurement Peer | |||
| Measurement Methods involve a second MA, with the Controller | (MP), meaning that it helps the MA but is not managed by the | |||
| instructing the MAs in a coordinated manner. Traffic generated | Controller. Other Measurement Methods involve a second MA, with the | |||
| specifically as part of the Measurement Method is termed Measurement | Controller instructing the MAs in a coordinated manner. Traffic | |||
| Traffic; in the ping example, it is the ICMP ECHO Requests and | generated specifically as part of the Measurement Method is termed | |||
| Replies. The protocols used for the Measurement Traffic are out of | Measurement Traffic; in the ping example, it is the ICMP ECHO | |||
| the scope of initial LMAP work, and fall within the scope of other | Requests and Replies. The protocols used for the Measurement Traffic | |||
| IETF WGs such as IPPM (IP Performance Metrics). The Appendix has | are out of the scope of initial LMAP work, and fall within the scope | |||
| some other examples of possible arrangements of Measurement Agents | of other IETF WGs such as IPPM (IP Performance Metrics). | |||
| and Peers. | ||||
| A Measurement Task is the action performed by a particular MA at a | A Measurement Task is the action performed by a particular MA at a | |||
| particular time, as the specific instance of its role in a | particular time, as the specific instance of its role in a | |||
| Measurement Method. LMAP is mainly concerned with Measurement Tasks, | Measurement Method. LMAP is mainly concerned with Measurement Tasks, | |||
| for instance in terms of its Information Model and Protocols. | for instance in terms of its Information Model and Protocols. | |||
| For Measurement Results to be truly comparable, as might be required | For Measurement Results to be truly comparable, as might be required | |||
| by a regulator, not only do the same Measurement Methods need to be | by a regulator, not only do the same Measurement Methods need to be | |||
| used to assess Metrics, but also the set of Measurement Tasks should | used to assess Metrics, but also the set of Measurement Tasks should | |||
| follow a similar Measurement Schedule and be of similar number. The | follow a similar Measurement Schedule and be of similar number. The | |||
| details of such a characterisation plan are beyond the scope of work | details of such a characterisation plan are beyond the scope of work | |||
| in IETF although certainly facilitated by IETF's work. | in IETF although certainly facilitated by IETF's work. | |||
| Messages are transferred over a secure Channel. A Control Channel is | Both control and report messages are transferred over a secure | |||
| between the Controller and a MA; the Control Protocol delivers | Channel. A Control Channel is between the Controller and a MA; the | |||
| Instruction Messages to the MA and Capabilities, Failure and Logging | Control Protocol delivers Instruction Messages to the MA and | |||
| Information in the reverse direction. A Report Channel is between a | Capabilities, Failure and Logging Information in the reverse | |||
| MA and Collector, and the Report Protocol delivers Reports to the | direction. A Report Channel is between a MA and Collector, and the | |||
| Collector. | Report Protocol delivers Reports to the Collector. | |||
| Finally we introduce several components that are outside the scope of | Finally we introduce several components that are outside the scope of | |||
| initial LMAP work and will be provided through existing protocols or | initial LMAP work and will be provided through existing protocols or | |||
| applications. They affect how the measurement system uses the | applications. They affect how the Measurement System uses the | |||
| Measurement Results and how it decides what set of Measurement Tasks | Measurement Results and how it decides what set of Measurement Tasks | |||
| to perform. | to perform. As shown in the Figure, these components are: the | |||
| bootstrapper, Subscriber parameter database, data analysis tools, and | ||||
| Results repository. | ||||
| The MA needs to be bootstrapped with initial details about its | The MA needs to be bootstrapped with initial details about its | |||
| Controller, including authentication credentials. The LMAP work | Controller, including authentication credentials. The LMAP work | |||
| considers the bootstrap process, since it affects the Information | considers the bootstrap process, since it affects the Information | |||
| Model. However, LMAP does not define a bootstrap protocol, since it | Model. However, LMAP does not define a bootstrap protocol, since it | |||
| is likely to be technology specific and could be defined by the | is likely to be technology specific and could be defined by the | |||
| Broadband Forum, CableLabs or IEEE depending on the device. Possible | Broadband Forum, CableLabs or IEEE depending on the device. Possible | |||
| protocols are SNMP (Simple Network Management Protocol), NETCONF | protocols are SNMP (Simple Network Management Protocol), NETCONF | |||
| (Network Configuration Protocol) or (for Home Gateways) CPE WAN | (Network Configuration Protocol) or (for Home Gateways) CPE WAN | |||
| Management Protocol (CWMP) from the Auto Configuration Server (ACS) | Management Protocol (CWMP) from the Auto Configuration Server (ACS) | |||
| skipping to change at page 8, line 5 ¶ | skipping to change at page 8, line 26 ¶ | |||
| A Subscriber parameter database contains information about the line, | A Subscriber parameter database contains information about the line, | |||
| such as the customer's broadband contract (perhaps 2, 40 or 80Mb/s), | such as the customer's broadband contract (perhaps 2, 40 or 80Mb/s), | |||
| the line technology (DSL or fibre), the time zone where the MA is | the line technology (DSL or fibre), the time zone where the MA is | |||
| located, and the type of home gateway and MA. These parameters are | located, and the type of home gateway and MA. These parameters are | |||
| already gathered and stored by existing operations systems. They may | already gathered and stored by existing operations systems. They may | |||
| affect the choice of what Measurement Tasks to run and how to | affect the choice of what Measurement Tasks to run and how to | |||
| interpret the Measurement Results. For example, a download test | interpret the Measurement Results. For example, a download test | |||
| suitable for a line with an 80Mb/s contract may overwhelm a 2Mb/s | suitable for a line with an 80Mb/s contract may overwhelm a 2Mb/s | |||
| line. | line. | |||
| A results repository records all Measurement Results in an equivalent | A Results repository records all Measurement Results in an equivalent | |||
| form, for example an SQL (Structured Query Language) database, so | form, for example an SQL (Structured Query Language) database, so | |||
| that they can easily be accessed by the data analysis tools. | that they can easily be accessed by the data analysis tools. | |||
| The data analysis tools receive the results from the Collector or via | The data analysis tools receive the results from the Collector or via | |||
| the Results repository. They might visualise the data or identify | the Results repository. They might visualise the data or identify | |||
| which component or link is likely to be the cause of a fault or | which component or link is likely to be the cause of a fault or | |||
| degradation. This information could help the Controller decide what | degradation. This information could help the Controller decide what | |||
| follow-up Measurement Task to perform in order to diagnose a fault. | follow-up Measurement Task to perform in order to diagnose a fault. | |||
| The data analysis tools also need to understand the Subscriber's | The data analysis tools also need to understand the Subscriber's | |||
| service information, for example the broadband contract. | service information, for example the broadband contract. | |||
| ^ | +--------+ +-----------+ +-----------+ ^ | |||
| | | |End user| | | Observed | End user | | | |||
| +-------------+ IPPM | | |<-----|-----------|---traffic--->| | | | |||
| +---------------+ Measurement | Measurement | Scope | | | | | flow | | | | |||
| | Measurement |<------------>| Peer | | | | | | | | | Non-LMAP | |||
| | Agent | Traffic +-------------+ v | | | | | Measurement | | Scope | |||
| +------->| | ^ | | | | |<--traffic--->| | | | |||
| | +---------------+ | | +--------+ | | +-----------+ | | |||
| | ^ | | | .............|...........|.................................V | |||
| | Instruction | | Report | | <MP> |Measurement| <MP> ^ | |||
| | | +-----------------+ | | |Agent: | | | |||
| | | | | | |LMAP | | | |||
| | | v LMAP | +----------->|interface | | | |||
| | +------------+ +------------+ Scope | | +-----------+ | | |||
| | | Controller | | Collector | | | | ^ | LMAP | |||
| | +------------+ +------------+ v | | Instruction | | Report Scope | |||
| | ^ ^ | ^ | | (over Control | | (over Report Channel) | | |||
| | | | | | | | Channel) | +-----------------------+ | | |||
| | | +----------+ | | | | | | | | |||
| | | | v | | | | | | | |||
| +------------+ +----------+ +--------+ +----------+ | | | | v | | |||
| |Bootstrapper| |Subscriber|--->| data |<---|repository| Out | | +------------+ +------------+ | | |||
| +------------+ |parameter | |analysis| +----------+ of | | | Controller | | Collector | | | |||
| |database | | tools | Scope | | +------------+ +------------+ v | |||
| +----------+ +--------+ | | | ^ ^ | ^ | |||
| | | | | | | | | |||
| v | | | +--------+ | | | |||
| | | | v | | ||||
| +------------+ +----------+ +--------+ +----------+ | | ||||
| |Bootstrapper| |Subscriber|--->| data |<---| Results | Non- | ||||
| +------------+ |parameter | |analysis| |repository| LMAP | ||||
| |database | | tools | +----------+ Scope | ||||
| +----------+ +--------+ | | ||||
| | | ||||
| v | ||||
| Figure 1: Schematic of main elements of an LMAP-based | Schematic of main elements of an LMAP-based Measurement System | |||
| measurement system | (showing the elements in and out of the scope of initial LMAP work) | |||
| (showing the elements in and out of the scope of initial LMAP work) | ||||
| 3. Terminology | 3. Terminology | |||
| This section defines terminology for LMAP. Please note that defined | This section defines terminology for LMAP. Please note that defined | |||
| terms are capitalized. | terms are capitalized. | |||
| Bootstrap: A process that integrates a Measurement Agent into a | Bootstrap: A process that integrates a Measurement Agent into a | |||
| measurement system. | Measurement System. | |||
| Capabilities: Information about the performance measurement | Capabilities: Information about the performance measurement | |||
| capabilities of the MA, in particular the Measurement Method roles | capabilities of the MA, in particular the Measurement Method roles | |||
| and measurement protocol roles that it can perform, and the device | and measurement protocol roles that it can perform, and the device | |||
| hosting the MA, for example its interface type and speed, but not | hosting the MA, for example its interface type and speed, but not | |||
| dynamic information. | dynamic information. | |||
| Channel: A bi-directional logical connection that is defined by a | Channel: A bi-directional logical connection that is defined by a | |||
| specific Controller and MA, or Collector and MA, plus associated | specific Controller and MA, or Collector and MA, plus associated | |||
| security. | security. | |||
| skipping to change at page 9, line 40 ¶ | skipping to change at page 10, line 32 ¶ | |||
| Instruction. | Instruction. | |||
| Control Channel: A Channel between a Controller and a MA over which | Control Channel: A Channel between a Controller and a MA over which | |||
| Instruction Messages and Capabilities, Failure and Logging | Instruction Messages and Capabilities, Failure and Logging | |||
| Information are sent. | Information are sent. | |||
| Control Protocol: The protocol delivering Instruction(s) from a | Control Protocol: The protocol delivering Instruction(s) from a | |||
| Controller to a Measurement Agent. It also delivers Capabilities, | Controller to a Measurement Agent. It also delivers Capabilities, | |||
| Failure and Logging Information from the Measurement Agent to the | Failure and Logging Information from the Measurement Agent to the | |||
| Controller. It can also be used to update the MA's Configuration. | Controller. It can also be used to update the MA's Configuration. | |||
| It runs over the Control Channel. | ||||
| Cycle-ID: A tag that is sent by the Controller in an Instruction and | Cycle-ID: A tag that is sent by the Controller in an Instruction and | |||
| echoed by the MA in its Report. The same Cycle-ID is used by several | echoed by the MA in its Report. The same Cycle-ID is used by several | |||
| MAs that use the same Measurement Method for a Metric with the same | MAs that use the same Measurement Method for a Metric with the same | |||
| Input Parameters. Hence the Cycle-ID allows the Collector to easily | Input Parameters. Hence the Cycle-ID allows the Collector to easily | |||
| identify Measurement Results that should be comparable. | identify Measurement Results that should be comparable. | |||
| Data Model: The implementation of an Information Model in a | Data Model: The implementation of an Information Model in a | |||
| particular data modelling language [RFC3444]. | particular data modelling language [RFC3444]. | |||
| skipping to change at page 10, line 13 ¶ | skipping to change at page 11, line 7 ¶ | |||
| Measurement Task proceeds. | Measurement Task proceeds. | |||
| Failure Information: Information about the MA's failure to action or | Failure Information: Information about the MA's failure to action or | |||
| execute an Instruction, whether concerning Measurement Tasks or | execute an Instruction, whether concerning Measurement Tasks or | |||
| Reporting. | Reporting. | |||
| Group-ID: An identifier of a group of MAs. | Group-ID: An identifier of a group of MAs. | |||
| Information Model: The protocol-neutral definition of the semantics | Information Model: The protocol-neutral definition of the semantics | |||
| of the Instructions, the Report, the status of the different elements | of the Instructions, the Report, the status of the different elements | |||
| of the measurement system as well of the events in the system | of the Measurement System as well of the events in the system | |||
| [RFC3444]. | [RFC3444]. | |||
| Input Parameter: A parameter whose value is left open by the Metric | Input Parameter: A parameter whose value is left open by the Metric | |||
| and its Measurement Method and is set to a specific value in a | and its Measurement Method and is set to a specific value in a | |||
| Measurement Task. Altering the value of an Input Parameter does not | Measurement Task. Altering the value of an Input Parameter does not | |||
| change the fundamental nature of the Measurement Task. | change the fundamental nature of the Measurement Task. | |||
| Instruction: The description of Measurement Tasks for a MA to perform | Instruction: The description of Measurement Tasks for a MA to perform | |||
| and the details of the Report for it to send. It is the collective | and the details of the Report for it to send. It is the collective | |||
| description of the Measurement Task configurations, the configuration | description of the Measurement Task configurations, the configuration | |||
| of the Measurement Schedules, the configuration of the Report | of the Measurement Schedules, the configuration of the Report | |||
| Channel(s), the configuration of Report Schedule(s), and the details | Channel(s), the configuration of Report Schedule(s), and the details | |||
| of any suppression. | of any suppression. | |||
| Instruction Message: The message that carries an Instruction from a | Instruction Message: The message that carries an Instruction from a | |||
| Controller to a Measurement Agent. | Controller to a Measurement Agent. | |||
| Logging Information: Information about the operation of the | Logging Information: Information about the operation of the | |||
| Measurement Agent and which may be useful for debugging. | Measurement Agent, which may be useful for debugging. | |||
| Measurement Agent (MA): The function that receives Instruction | Measurement Agent (MA): The function that receives Instruction | |||
| Messages from a Controller and operates the Instruction by executing | Messages from a Controller and operates the Instruction by executing | |||
| Measurement Tasks (using protocols outside the initial LMAP work | Measurement Tasks (using protocols outside the initial LMAP work | |||
| scope and perhaps in concert with one or more other Measurement | scope and perhaps in concert with one or more other Measurement | |||
| Agents or Measurement Peers) and (if part of the Instruction) by | Agents or Measurement Peers) and (if part of the Instruction) by | |||
| reporting Measurement Results to a Collector or Collectors. | reporting Measurement Results to a Collector or Collectors. | |||
| Measurement Agent Identifier (MA-ID): a UUID [RFC4122] that | Measurement Agent Identifier (MA-ID): a UUID [RFC4122] that | |||
| identifies a particular MA and is configured as part of the | identifies a particular MA and is configured as part of the | |||
| Bootstrapping process. | Bootstrapping process. | |||
| Measurement Method: The process for assessing the value of a Metric; | Measurement Method: The process for assessing the value of a Metric; | |||
| the process of measuring some performance or reliability parameter | the process of measuring some performance or reliability parameter | |||
| associated with the transfer of traffic; where this process involves | associated with the transfer of traffic. | |||
| multiple MAs or MPs, each may perform different roles. | ||||
| Measurement Peer (MP): The function that assists a Measurement Agent | Measurement Peer (MP): The function that assists a Measurement Agent | |||
| with Measurement Tasks and does not have an interface to the | with Measurement Tasks and does not have an interface to the | |||
| Controller or Collector. | Controller or Collector. | |||
| Measurement Result: The output of a single Measurement Task (the | Measurement Result: The output of a single Measurement Task (the | |||
| value obtained for the parameter of interest or Metric). | value obtained for the parameter of interest or Metric). | |||
| Measurement Schedule: The schedule for performing Measurement Tasks. | Measurement Schedule: The schedule for performing Measurement Tasks. | |||
| Measurement System: The set of LMAP-defined and related components | ||||
| that are operated by a single organisation, for the purpose of | ||||
| measuring performance aspects of the network. | ||||
| Measurement Task: The action performed by a particular Measurement | Measurement Task: The action performed by a particular Measurement | |||
| Agent that consists of the single assessment of a Metric through | Agent that consists of the single assessment of a Metric through | |||
| operation of a Measurement Method role at a particular time, with all | operation of a Measurement Method role at a particular time, with all | |||
| of the role's Input Parameters set to specific values. | of the role's Input Parameters set to specific values. | |||
| Measurement Traffic: the packet(s) generated by some types of | Measurement Traffic: the packet(s) generated by some types of | |||
| Measurement Method that involve measuring some parameter associated | Measurement Method that involve measuring some parameter associated | |||
| with the transfer of the packet(s). | with the transfer of the packet(s). | |||
| Metric: The quantity related to the performance and reliability of | Metric: The quantity related to the performance and reliability of | |||
| the network that we'd like to know the value of. | the network that we'd like to know the value of. | |||
| Observed Traffic Flow: In RFC 7011, a Traffic Flow (or Flow) is | ||||
| defined as a set of packets or frames passing an Observation Point in | ||||
| the network during a certain time interval. All packets belonging to | ||||
| a particular Flow have a set of common properties, such as packet | ||||
| header fields, characteristics, and treatments. A Flow measured by | ||||
| the LMAP system is termed an Observed Traffic Flow. Its properties | ||||
| are summarized and tabulated in Measurement Results (as opposed to | ||||
| raw capture and export). | ||||
| Report: The set of Measurement Results and other associated | Report: The set of Measurement Results and other associated | |||
| information (as defined by the Instruction). The Report is sent by a | information (as defined by the Instruction). The Report is sent by a | |||
| Measurement Agent to a Collector. | Measurement Agent to a Collector. | |||
| Report Channel: A Channel between a Collector and a MA over which | Report Channel: A Channel between a Collector and a MA over which | |||
| Report messages are sent. | Report messages are sent. | |||
| Report Protocol: The protocol delivering Report(s) from a Measurement | Report Protocol: The protocol delivering Report(s) from a Measurement | |||
| Agent to a Collector. | Agent to a Collector. It runs over the Report Channel. | |||
| Report Schedule: the schedule for sending Reports to a Collector. | Report Schedule: the schedule for sending Reports to a Collector. | |||
| Subscriber: An entity (associated with one or more users) that is | Subscriber: An entity (associated with one or more users) that is | |||
| engaged in a subscription with a service provider. | engaged in a subscription with a service provider. | |||
| Suppression: the temporary cessation of Measurement Tasks. | Suppression: the temporary cessation of Measurement Tasks. | |||
| 4. Constraints | 4. Constraints | |||
| The LMAP framework makes some important assumptions, which constrain | The LMAP framework makes some important assumptions, which constrain | |||
| the scope of the initial LMAP work. | the scope of the initial LMAP work. | |||
| 4.1. The measurement system is under the direction of a single | 4.1. The measurement system is under the direction of a single | |||
| organisation | organisation | |||
| In the LMAP framework, the measurement system is under the direction | In the LMAP framework, the Measurement System is under the direction | |||
| of a single organisation that is responsible for any impact that its | of a single organisation that is responsible for any impact that its | |||
| measurements have on a user's quality of experience and privacy. | measurements have on a user's quality of experience and privacy. | |||
| Clear responsibility is critical given that a misbehaving large-scale | Clear responsibility is critical given that a misbehaving large-scale | |||
| measurement system could potentially harm user experience, user | Measurement System could potentially harm user experience, user | |||
| privacy and network security. | privacy and network security. | |||
| However, the components of an LMAP measurement system can be deployed | However, the components of an LMAP Measurement System can be deployed | |||
| in administrative domains that are not owned by the measuring | in administrative domains that are not owned by the measuring | |||
| organisation. Thus, the system of functions deployed by a single | organisation. Thus, the system of functions deployed by a single | |||
| organisation constitutes a single LMAP domain which may span | organisation constitutes a single LMAP domain which may span | |||
| ownership or other administrative boundaries. | ownership or other administrative boundaries. | |||
| 4.2. Each MA may only have a single Controller at any point in time | 4.2. Each MA may only have a single Controller at any point in time | |||
| A MA is instructed by one Controller and is in one measurement | A MA is instructed by one Controller and is in one Measurement | |||
| system. The constraint avoids different Controllers giving a MA | System. The constraint avoids different Controllers giving a MA | |||
| conflicting instructions and so means that the MA does not have to | conflicting instructions and so means that the MA does not have to | |||
| manage contention between multiple Measurement (or Report) Schedules. | manage contention between multiple Measurement (or Report) Schedules. | |||
| This simplifies the design of MAs (critical for a large-scale | This simplifies the design of MAs (critical for a large-scale | |||
| infrastructure) and allows a Measurement Schedule to be tested on | infrastructure) and allows a Measurement Schedule to be tested on | |||
| specific types of MA before deployment to ensure that the end user | specific types of MA before deployment to ensure that the end user | |||
| experience is not impacted (due to CPU, memory or broadband-product | experience is not impacted (due to CPU, memory or broadband-product | |||
| constraints). | constraints). However, a Measurement System may have several | |||
| Controllers. | ||||
| An operator may have several Controllers, perhaps with a Controller | ||||
| for different types of MA (home gateways, tablets) or location | ||||
| (Ipswich, Edinburgh). | ||||
| 5. Protocol Model | 5. Protocol Model | |||
| A protocol model [RFC4101] presents an architectural model for how | A protocol model [RFC4101] presents an architectural model for how | |||
| the protocol operates and needs to answer three basic questions: | the protocol operates and needs to answer three basic questions: | |||
| 1. What problem is the protocol trying to achieve? | 1. What problem is the protocol trying to address? | |||
| 2. What messages are being transmitted and what do they mean? | 2. What messages are being transmitted and what do they mean? | |||
| 3. What are the important, but unobvious, features of the protocol? | 3. What are the important, but unobvious, features of the protocol? | |||
| An LMAP system goes through the following phases: | An LMAP system goes through the following phases: | |||
| o a Bootstrapping process before the MA can take part in the other | o a Bootstrapping process before the MA can take part in the other | |||
| three phases | three phases. | |||
| o a Control Protocol, which delivers Instruction Messages from a | o a Control Protocol, which delivers Instruction Messages from a | |||
| Controller to a MA, detailing what Measurement Tasks the MA should | Controller to a MA (amongst other things). | |||
| perform and when, and how it should report the Measurement | ||||
| Results. It also delivers Capabilities, Failure and logging | ||||
| Information from a MA to its Controller. Finally, it allows the | ||||
| Controller to update the MA's Configuration. | ||||
| o the actual Measurement Tasks, which measure some performance or | o the actual Measurement Tasks, which measure some performance or | |||
| reliability parameter(s) associated with the transfer of packets. | reliability parameter(s) associated with the transfer of packets. | |||
| The LMAP work does not define Metrics and Measurement Methods, | o a Report Protocol, which delivers Reports containing the | |||
| these are defined elsewhere (e.g. IPPM). | Measurement Results from a MA to a Collector. | |||
| o a Report Protocol, which delivers Reports from a MA to a | ||||
| Collector. The Report contains the Measurement Results. | ||||
| The diagrams show the various LMAP messages and uses the following | The diagrams show the various LMAP messages and uses the following | |||
| convention: | convention: | |||
| o (optional): indicated by round brackets | o (optional): indicated by round brackets | |||
| o [potentially repeated]: indicated by square brackets | o [potentially repeated]: indicated by square brackets | |||
| The protocol model is closely related to the Information Model | The protocol model is closely related to the Information Model | |||
| [I-D.ietf-lmap-information-model], which is the abstract definition | [I-D.ietf-lmap-information-model], which is the abstract definition | |||
| of the information carried by the protocol. (If there is any | of the information carried by the protocol. (If there is any | |||
| difference between this document and the Information Model, the | difference between this document and the Information Model, the | |||
| latter is definitive, since it is on the standards track.) The | latter is definitive, since it is on the standards track.) The | |||
| purpose of both is to provide a protocol and device independent view, | purpose of both is to provide a protocol and device independent view, | |||
| which can be implemented via specific protocols. LMAP defines a | which can be implemented via specific protocols. LMAP defines a | |||
| specific Control Protocol and Report Protocol, but others could be | specific Control Protocol and Report Protocol, but others could be | |||
| defined by other standards bodies or be proprietary. However it is | defined by other standards bodies or be proprietary. However it is | |||
| important that they all implement the same Information Model and | important that they all implement the same Information Model and | |||
| protocol model, in order to ease the definition, operation and | protocol model, in order to ease the definition, operation and | |||
| interoperability of large-scale measurement systems. | interoperability of large-scale Measurement Systems. | |||
| 5.1. Bootstrapping process | 5.1. Bootstrapping process | |||
| The primary purpose of bootstrapping is to enable a MA to be | The primary purpose of bootstrapping is to enable a MA to be | |||
| integrated into a measurement system. The MA retrieves information | integrated into a Measurement System. The MA retrieves information | |||
| about itself (like its identity in the measurement system) and about | about itself (like its identity in the Measurement System) and about | |||
| the Controller, the Controller learns information about the MA, and | the Controller, the Controller learns information about the MA, and | |||
| they learn about security information to communicate (such as | they learn about security information to communicate (such as | |||
| certificates and credentials). | certificates and credentials). | |||
| Whilst this memo considers the bootstrapping process, it is beyond | Whilst this memo considers the bootstrapping process, it is beyond | |||
| the scope of initial LMAP work to define a bootstrap mechanism, as it | the scope of initial LMAP work to define a bootstrap mechanism, as it | |||
| depends on the type of device and access. | depends on the type of device and access. | |||
| As a result of the bootstrapping process the MA learns information | As a result of the bootstrapping process the MA learns information | |||
| with the following aims ([I-D.ietf-lmap-information-model] defines | with the following aims ([I-D.ietf-lmap-information-model] defines | |||
| skipping to change at page 14, line 42 ¶ | skipping to change at page 15, line 42 ¶ | |||
| the MA to inform the Controller about its Capabilities and any | the MA to inform the Controller about its Capabilities and any | |||
| Failure and Logging Information (Section 5.2.2). Finally, the | Failure and Logging Information (Section 5.2.2). Finally, the | |||
| Control Protocol allows the Controller to update the MA's | Control Protocol allows the Controller to update the MA's | |||
| Configuration. | Configuration. | |||
| 5.2.1. Configuration | 5.2.1. Configuration | |||
| Configuration allows the Controller to update the MA about some or | Configuration allows the Controller to update the MA about some or | |||
| all of the information that it obtained during the bootstrapping | all of the information that it obtained during the bootstrapping | |||
| process: the MA-ID, the (optional) Group-ID and the Control Channel. | process: the MA-ID, the (optional) Group-ID and the Control Channel. | |||
| The measurement system might use Configuration for several reasons. | The Measurement System might use Configuration for several reasons. | |||
| For example, the bootstrapping process could 'hard code' the MA with | For example, the bootstrapping process could 'hard code' the MA with | |||
| details of an initial Controller, and then the initial Controller | details of an initial Controller, and then the initial Controller | |||
| could configure the MA with details about the Controller that sends | could configure the MA with details about the Controller that sends | |||
| Instruction Messages. (Note that a MA only has one Control Channel, | Instruction Messages. (Note that a MA only has one Control Channel, | |||
| and so is associated with only one Controller, at any moment.) | and so is associated with only one Controller, at any moment.) | |||
| Note that an implementation may choose to combine Configuration | Note that an implementation may choose to combine Configuration | |||
| information and an Instruction Message into a single message. | information and an Instruction Message into a single message. | |||
| +-----------------+ +-------------+ | +-----------------+ +-------------+ | |||
| | | | Measurement | | | | | Measurement | | |||
| | Controller |======================================| Agent | | | Controller |===================================| Agent | | |||
| +-----------------+ +-------------+ | +-----------------+ +-------------+ | |||
| Configuration information: -> | Configuration information: -> | |||
| (MA-ID), | (MA-ID), | |||
| (Group-ID), | (Group-ID), | |||
| (Control Channel) | (Control Channel) | |||
| <- Response(details) | <- Response(details) | |||
| 5.2.2. Instruction | 5.2.2. Instruction | |||
| The Instruction is the description of the Measurement Tasks for a | The Instruction is the description of the Measurement Tasks for a | |||
| Measurement Agent to do and the details of the Measurement Reports | Measurement Agent to do and the details of the Measurement Reports | |||
| for it to send. In order to update the Instruction the Controller | for it to send. In order to update the Instruction the Controller | |||
| uses the Control Protocol to send an Instruction Message over the | uses the Control Protocol to send an Instruction Message over the | |||
| Control Channel. | Control Channel. | |||
| +-----------------+ +-------------+ | +-----------------+ +-------------+ | |||
| | | | Measurement | | | | | Measurement | | |||
| | Controller |======================================| Agent | | | Controller |===================================| Agent | | |||
| +-----------------+ +-------------+ | +-----------------+ +-------------+ | |||
| Instruction: -> | Instruction: -> | |||
| [(Measurement Task configuration( | [(Measurement Task configuration | |||
| [Input Parameter], | URI of Metric( | |||
| (interface), | [Input Parameter], | |||
| (Cycle-ID))), | (Role) | |||
| (Report Channel), | (interface), | |||
| (Schedule), | (Cycle-ID) | |||
| (Suppression information)] | (measurement point)), | |||
| <- Response(details) | (Report Channel), | |||
| (Schedule), | ||||
| (Suppression information)] | ||||
| <- Response(details) | ||||
| The Instruction defines information with the following aims | The Instruction defines information with the following aims | |||
| ([I-D.ietf-lmap-information-model] defines the consequent list of | ([I-D.ietf-lmap-information-model] defines the consequent list of | |||
| information elements): | information elements): | |||
| o the Measurement Task configurations, each of which needs: | o the Measurement Task configurations, each of which needs: | |||
| * the Metric, specified as a URI to a registry entry; it includes | * the Metric, specified as a URI to a registry entry; it includes | |||
| the specification of a Measurement Method. The registry could | the specification of a Measurement Method. The registry could | |||
| be defined by the IETF [I-D.manyfolks-ippm-metric-registry], | be defined by a standards organisation or locally by the | |||
| locally by the operator of the measurement system or perhaps by | operator of the Measurement System. Note that, at the time of | |||
| another standards organisation. | writing, the IETF works on such a registry specification | |||
| [I-D.ietf-ippm-metric-registry]. | ||||
| * the Measurement Method role. For some Measurement Methods, | * the Measurement Method role. For some Measurement Methods, | |||
| different parties play different roles; for example (figure A3 | different parties play different roles; for example (see | |||
| in the Appendix) an iperf sender and receiver. Each Metric and | Section 6.4) an iperf sender and receiver. Each Metric and its | |||
| its associated Measurement Method will describe all measurement | associated Measurement Method will describe all measurement | |||
| roles involved in the process. | roles involved in the process. | |||
| * a boolean flag (suppress or do-not-suppress) indicating how | * a boolean flag (suppress or do-not-suppress) indicating if such | |||
| such a Measurement Task is impacted by a Suppression message | a Measurement Task is impacted by a Suppression message (see | |||
| (see Section 5.2.2.1). Thus, the flag is an Input Parameter. | Section 5.2.2.1). Thus, the flag is an Input Parameter. | |||
| * any Input Parameters that need to be set for the Metric and the | * any Input Parameters that need to be set for the Metric and the | |||
| Measurement Method. For example, the address of a Measurement | Measurement Method. For example, the address of a Measurement | |||
| Peer (or other Measurement Agent) that may be involved in a | Peer (or other Measurement Agent) that may be involved in a | |||
| Measurement Task. | Measurement Task , or traffic filters associated with the | |||
| Observed Traffic Flow. | ||||
| * if the device with the MA has multiple interfaces, then the | * if the device with the MA has multiple interfaces, then the | |||
| interface to use (if not defined, then the default interface is | interface to use (if not defined, then the default interface is | |||
| used). | used). | |||
| * optionally, a Cycle-ID. | * optionally, a Cycle-ID. | |||
| * optionally, the measurement point designation | * optionally, the measurement point designation [RFC7398] of the | |||
| [I-D.ietf-ippm-lmap-path] of the MA and, if applicable, of the | MA and, if applicable, of the MP or other MA. This can be | |||
| MP or other MA. This can be useful for reporting. | useful for reporting. | |||
| o configuration of the Schedules, each of which needs: | o configuration of the Schedules, each of which needs: | |||
| * the timing of when the Measurement Tasks are to be performed, | * the timing of when the Measurement Tasks are to be performed, | |||
| or the Measurement Reports are to be sent. Possible types of | or the Measurement Reports are to be sent. Possible types of | |||
| timing are periodic, calendar-based periodic, one-off immediate | timing are periodic, calendar-based periodic, one-off immediate | |||
| and one-off at a future time | and one-off at a future time | |||
| o configuration of the Report Channels, each of which needs: | o configuration of the Report Channel(s), each of which needs: | |||
| * the address of the Collector, for instance its URL | * the address of the Collector, for instance its URL | |||
| * security for this Report Channel, for example the X.509 | * security for this Report Channel, for example the X.509 | |||
| certificate | certificate | |||
| o Suppression information, if any (see Section 5.2.1.1) | o Suppression information, if any (see Section 5.2.1.1) | |||
| A single Instruction Message may contain some or all of the above | A single Instruction Message may contain some or all of the above | |||
| parts. The finest level of granularity possible in an Instruction | parts. The finest level of granularity possible in an Instruction | |||
| Message is determined by the implementation and operation of the | Message is determined by the implementation and operation of the | |||
| Control Protocol. For example, a single Instruction Message may add | Control Protocol. For example, a single Instruction Message may add | |||
| or update an individual Measurement Schedule - or it may only update | or update an individual Measurement Schedule - or it may only update | |||
| the complete set of Measurement Schedules; a single Instruction | the complete set of Measurement Schedules; a single Instruction | |||
| Message may update both Measurement Schedules and Measurement Task | Message may update both Measurement Schedules and Measurement Task | |||
| configurations - or only one at a time; and so on. However, | configurations - or only one at a time; and so on. However, | |||
| Suppression information always replaces (rather than adds to) any | Suppression information always replaces (rather than adds to) any | |||
| previous Suppression information. | previous Suppression information. | |||
| skipping to change at page 17, line 20 ¶ | skipping to change at page 18, line 27 ¶ | |||
| example, if it doesn't include a parameter that is mandatory for the | example, if it doesn't include a parameter that is mandatory for the | |||
| requested Metric and Measurement Method, or it is missing details of | requested Metric and Measurement Method, or it is missing details of | |||
| the target Collector. | the target Collector. | |||
| The Instruction Message instructs the MA; the Control Protocol does | The Instruction Message instructs the MA; the Control Protocol does | |||
| not allow the MA to negotiate, as this would add complexity to the | not allow the MA to negotiate, as this would add complexity to the | |||
| MA, Controller and Control Protocol for little benefit. | MA, Controller and Control Protocol for little benefit. | |||
| 5.2.2.1. Suppression | 5.2.2.1. Suppression | |||
| The Instruction may include Suppression information. The purpose of | The Instruction may include Suppression information. The main | |||
| Suppression is to enable the Controller to instruct the MA not to | motivation for Suppression is to enable the Measurement System to | |||
| perform Measurement Tasks. It is used if the measurement system | eliminate Measurement Traffic, because there is some unexpected | |||
| wants to eliminate inessential traffic, because there is some | network issue for example. There may be other circumstances when | |||
| unexpected network issue for example. | Suppression is useful, for example to eliminate inessential Reporting | |||
| traffic (even if there is no Measurement Traffic). | ||||
| The Suppression information may include any of the following optional | The Suppression information may include any of the following optional | |||
| fields: | fields: | |||
| o a set of Measurement Tasks to suppress; the others are not | o a set of Measurement Tasks to suppress; the others are not | |||
| suppressed. For example, this could be useful if a particular | suppressed. For example, this could be useful if a particular | |||
| Measurement Task is overloading a Measurement Peer. | Measurement Task is overloading a Measurement Peer with | |||
| Measurement Traffic. | ||||
| o a set of Measurement Schedules to suppress; the others are not | o a set of Measurement Schedules to suppress; the others are not | |||
| suppressed. For example, suppose the measurement system has | suppressed. For example, suppose the Measurement System has | |||
| defined two Schedules, one with the most critical Measurement | defined two Schedules, one with the most critical Measurement | |||
| Tasks and the other with less critical ones that create a lot of | Tasks and the other with less critical ones that create a lot of | |||
| Measurement Traffic, then it may only want to suppress the second. | Measurement Traffic, then it may only want to suppress the second. | |||
| o if both the previous fields are included then the MA suppresses | o a set of Reporting Schedules to suppress; the others are not | |||
| the union - in other words, it suppresses both the set of | suppressed. This can be particularly useful in the case of a | |||
| Measurement Tasks and the set of Measurement Schedules. | Measurement Method that doesn't generate Measurement Traffic; it | |||
| may need to continue observing traffic flows but temporarily | ||||
| suppress Reports due to the network footprint of the Reports. | ||||
| o if all the previous fields are included then the MA suppresses the | ||||
| union - in other words, it suppresses the set of Measurement | ||||
| Tasks, the set of Measurement Schedules, and the set of Reporting | ||||
| Schedules. | ||||
| o if the Suppression information includes neither a set of | o if the Suppression information includes neither a set of | |||
| Measurement Tasks nor a set of Measurement Schedules, then the MA | Measurement Tasks nor a set of Measurement Schedules, then the MA | |||
| does not begin new Measurement Tasks that have the boolean flag | does not begin new Measurement Tasks that have the boolean flag | |||
| set to "suppress"; however, the MA does begin new Measurement | set to "suppress"; however, the MA does begin new Measurement | |||
| Tasks that have the flag set to "do-not-suppress". | Tasks that have the flag set to "do-not-suppress". | |||
| o a start time, at which suppression begins. If absent, then | o a start time, at which suppression begins. If absent, then | |||
| Suppression begins immediately. | Suppression begins immediately. | |||
| skipping to change at page 18, line 25 ¶ | skipping to change at page 20, line 5 ¶ | |||
| An un-Suppress message instructs the MA no longer to suppress, | An un-Suppress message instructs the MA no longer to suppress, | |||
| meaning that the MA once again begins new Measurement Tasks, | meaning that the MA once again begins new Measurement Tasks, | |||
| according to its Measurement Schedule. | according to its Measurement Schedule. | |||
| Note that Suppression is not intended to permanently stop a | Note that Suppression is not intended to permanently stop a | |||
| Measurement Task (instead, the Controller should send a new | Measurement Task (instead, the Controller should send a new | |||
| Measurement Schedule), nor to permanently disable a MA (instead, some | Measurement Schedule), nor to permanently disable a MA (instead, some | |||
| kind of management action is suggested). | kind of management action is suggested). | |||
| +-----------------+ +-------------+ | +-----------------+ +-------------+ | |||
| | | | Measurement | | | | | Measurement | | |||
| | Controller |===================================| Agent | | | Controller |==============================| Agent | | |||
| +-----------------+ +-------------+ | +-----------------+ +-------------+ | |||
| Suppress: | Suppress: | |||
| [(Measurement Task), -> | [(Measurement Task), -> | |||
| (Measurement Schedule), | (Measurement Schedule), | |||
| [start time], | [start time], | |||
| [end time], | [end time], | |||
| [on-going suppressed?]] | [on-going suppressed?]] | |||
| Un-suppress -> | Un-suppress -> | |||
| 5.2.3. Capabilities, Failure and Logging Information | 5.2.3. Capabilities, Failure and Logging Information | |||
| The Control Protocol also enables the MA to inform the Controller | The Control Protocol also enables the MA to inform the Controller | |||
| about various information, such as its Capabilities and any Failures. | about various information, such as its Capabilities and any Failures. | |||
| It is also possible to use a device-specific mechanism which is | It is also possible to use a device-specific mechanism which is | |||
| beyond the scope of the initial LMAP work. | beyond the scope of the initial LMAP work. | |||
| Capabilities are information about the MA that the Controller needs | Capabilities are information about the MA that the Controller needs | |||
| to know in order to correctly instruct the MA, such as: | to know in order to correctly instruct the MA, such as: | |||
| skipping to change at page 19, line 4 ¶ | skipping to change at page 20, line 32 ¶ | |||
| about various information, such as its Capabilities and any Failures. | about various information, such as its Capabilities and any Failures. | |||
| It is also possible to use a device-specific mechanism which is | It is also possible to use a device-specific mechanism which is | |||
| beyond the scope of the initial LMAP work. | beyond the scope of the initial LMAP work. | |||
| Capabilities are information about the MA that the Controller needs | Capabilities are information about the MA that the Controller needs | |||
| to know in order to correctly instruct the MA, such as: | to know in order to correctly instruct the MA, such as: | |||
| o the Measurement Method (roles) that the MA supports | o the Measurement Method (roles) that the MA supports | |||
| o the measurement protocol types and roles that the MA supports | o the measurement protocol types and roles that the MA supports | |||
| o the interfaces that the MA has | o the interfaces that the MA has | |||
| o the version of the MA | o the version of the MA | |||
| o the version of the hardware, firmware or software of the device | o the version of the hardware, firmware or software of the device | |||
| with the MA | with the MA | |||
| o its Instruction (this could be useful if the Controller thinks | ||||
| something has gone wrong, and wants to check what Instruction the | ||||
| MA is using) | ||||
| o but not dynamic information like the currently unused CPU, memory | o but not dynamic information like the currently unused CPU, memory | |||
| or battery life of the device with the MA. | or battery life of the device with the MA. | |||
| Failure Information concerns why the MA has been unable to execute a | Failure Information concerns why the MA has been unable to execute a | |||
| Measurement Task or deliver a Report, for example: | Measurement Task or deliver a Report, for example: | |||
| o the Measurement Task failed to run properly because the MA | o the Measurement Task failed to run properly because the MA | |||
| (unexpectedly) has no spare CPU cycles | (unexpectedly) has no spare CPU cycles | |||
| o the MA failed record the Measurement Results because it | o the MA failed to record the Measurement Results because it | |||
| (unexpectedly) is out of spare memory | (unexpectedly) is out of spare memory | |||
| o a Report failed to deliver Measurement Results because the | o a Report failed to deliver Measurement Results because the | |||
| Collector (unexpectedly) is not responding | Collector (unexpectedly) is not responding | |||
| o but not if a Measurement Task correctly doesn't start. For | o but not if a Measurement Task correctly doesn't start. For | |||
| example, the first step of some Measurement Methods is for the MA | example, the first step of some Measurement Methods is for the MA | |||
| to check there is no cross-traffic. | to check there is no cross-traffic. | |||
| Logging Information concerns how the MA is operating and may help | Logging Information concerns how the MA is operating and may help | |||
| skipping to change at page 20, line 5 ¶ | skipping to change at page 21, line 38 ¶ | |||
| the Controller forgets what the MA can do or otherwise wants to | the Controller forgets what the MA can do or otherwise wants to | |||
| resynchronize what it knows about the MA), or on its own initiative | resynchronize what it knows about the MA), or on its own initiative | |||
| (for example when the MA first communicates with a Controller or if | (for example when the MA first communicates with a Controller or if | |||
| it becomes capable of a new Measurement Method). Another example of | it becomes capable of a new Measurement Method). Another example of | |||
| the latter case is if the device with the MA re-boots, then the MA | the latter case is if the device with the MA re-boots, then the MA | |||
| should notify its Controller in case its Instruction needs to be | should notify its Controller in case its Instruction needs to be | |||
| updated; to avoid a "mass calling event" after a widespread power | updated; to avoid a "mass calling event" after a widespread power | |||
| restoration affecting many MAs, it is sensible for an MA to pause for | restoration affecting many MAs, it is sensible for an MA to pause for | |||
| a random delay, perhaps in the range of one minute or so. | a random delay, perhaps in the range of one minute or so. | |||
| +-----------------+ +-------------+ | +-----------------+ +-------------+ | |||
| | | | Measurement | | | | | Measurement | | |||
| | Controller |===================================| Agent | | | Controller |==================================| Agent | | |||
| +-----------------+ +-------------+ | +-----------------+ +-------------+ | |||
| (Instruction: | (Instruction: | |||
| [(Request Capabilities), | [(Request Capabilities), | |||
| (Request Failure Information), | (Request Failure Information), | |||
| (Request Logging Information)]) -> | (Request Logging Information), | |||
| <- (Capabilities), | (Request Instruction)]) -> | |||
| <- (Capabilities), | ||||
| (Failure Information), | (Failure Information), | |||
| (Logging Information) | (Logging Information), | |||
| (Instruction) | ||||
| 5.3. Operation of Measurement Tasks | 5.3. Operation of Measurement Tasks | |||
| This LMAP framework is neutral to what the actual Measurement Task | This LMAP framework is neutral to what the actual Measurement Task | |||
| is. It does not define Metrics and Measurement Methods, these are | is. It does not define Metrics and Measurement Methods, these are | |||
| defined elsewhere (e.g. IPPM). | defined elsewhere. | |||
| The MA carries out the Measurement Tasks as instructed, unless it | The MA carries out the Measurement Tasks as instructed, unless it | |||
| gets an updated Instruction. The MA acts autonomously, in terms of | gets an updated Instruction. The MA acts autonomously, in terms of | |||
| operation of the Measurement Tasks and reporting of the Results; it | operation of the Measurement Tasks and reporting of the Results; it | |||
| doesn't do a 'safety check' with the Controller to ask whether it | doesn't do a 'safety check' with the Controller to ask whether it | |||
| should still continue with the requested Measurement Tasks. | should still continue with the requested Measurement Tasks. | |||
| The MA may operate Measurement Tasks sequentially or in parallel (see | The MA may operate Measurement Tasks sequentially or in parallel (see | |||
| Section 5.3.2). | Section 5.3.2). | |||
| 5.3.1. Starting and Stopping Measurement Tasks | 5.3.1. Starting and Stopping Measurement Tasks | |||
| This LMAP framework does not define a generic start and stop process, | This LMAP framework does not define a generic start and stop process, | |||
| since the correct approach depends on the particular Measurement | since the correct approach depends on the particular Measurement | |||
| Task; the details are defined as part of each Measurement Method. | Task; the details are defined as part of each Measurement Method. | |||
| This section provides some general hints. The MA does not inform the | This section provides some general hints. The MA does not inform the | |||
| Controller about Measurement Tasks starting and stopping. | Controller about Measurement Tasks starting and stopping. | |||
| Before sending Measurement Traffic the MA may run a pre-check. (The | Before beginning a Measurement Task the MA may want to run a pre- | |||
| pre-check could be defined as a separate, preceding Task or as the | check. (The pre-check could be defined as a separate, preceding Task | |||
| first part of a larger Task.) Action could include: | or as the first part of a larger Task.) | |||
| For Measurement Tasks that observe existing traffic, action could | ||||
| include: | ||||
| o checking that there is traffic of interest; | ||||
| o checking that the device with the MA has enough resources to | ||||
| execute the Measurement Task reliably. Note that the designer of | ||||
| the Measurement System should ensure that the device's | ||||
| capabilities are normally sufficient to comfortably operate the | ||||
| Measurement Tasks. | ||||
| For Measurement Tasks that generate Measurement Traffic, a pre-check | ||||
| could include: | ||||
| o the MA checking that there is no cross-traffic. In other words, a | o the MA checking that there is no cross-traffic. In other words, a | |||
| check that the end-user isn't already sending traffic; | check that the end-user isn't already sending traffic; | |||
| o the MA checking with the Measurement Peer (or other Measurement | o the MA checking with the Measurement Peer (or other Measurement | |||
| Agent involved in the Measurement Task) that it can handle a new | Agent) involved in the Measurement Task that it can handle a new | |||
| Measurement Task (in case, for example, the Measurement Peer is | Measurement Task. For example, the Measurement Peer may already | |||
| already handling many Measurement Tasks with other MAs); | be handling many Measurement Tasks with other MAs; | |||
| o sending traffic that probes the path to check it isn't overloaded; | o sending traffic that probes the path to check it isn't overloaded; | |||
| o checking that the device with the MA has enough resources to | o checking that the device with the MA has enough resources to | |||
| execute the Measurement Task reliably. Note that the designer of | execute the Measurement Task reliably. | |||
| the measurement system should ensure that the device's | ||||
| capabilities are normally sufficient to comfortably operate the | ||||
| Measurement Tasks. | ||||
| It is possible that similar checks continue during the Measurement | It is possible that similar checks continue during the Measurement | |||
| Task, especially one that is long-running and/or creates a lot of | Task, especially one that is long-running and/or creates a lot of | |||
| Measurement Traffic, and might lead to it being abandoned whilst in- | Measurement Traffic, and might lead to it being abandoned whilst in- | |||
| progress. A Measurement Task could also be abandoned in response to | progress. A Measurement Task could also be abandoned in response to | |||
| a "suppress" message (see Section 5.2.1). Action could include: | a "suppress" message (see Section 5.2.1). Action could include: | |||
| o For 'upload' tests, the MA not sending traffic | o For 'upload' tests, the MA not sending traffic | |||
| o For 'download' tests, the MA closing the TCP connection or sending | o For 'download' tests, the MA closing the TCP connection or sending | |||
| skipping to change at page 21, line 38 ¶ | skipping to change at page 23, line 35 ¶ | |||
| traffic forever after a Controller has permanently failed (or | traffic forever after a Controller has permanently failed (or | |||
| communications with the Controller have failed), the MA can be | communications with the Controller have failed), the MA can be | |||
| configured with a time limit; if the MA doesn't hear from the | configured with a time limit; if the MA doesn't hear from the | |||
| Controller for this length of time, then it stops operating | Controller for this length of time, then it stops operating | |||
| Measurement Tasks. | Measurement Tasks. | |||
| 5.3.2. Overlapping Measurement Tasks | 5.3.2. Overlapping Measurement Tasks | |||
| It is possible that a MA starts a new Measurement Task before another | It is possible that a MA starts a new Measurement Task before another | |||
| Measurement Task has completed. This may be intentional (the way | Measurement Task has completed. This may be intentional (the way | |||
| that the measurement system has designed the Measurement Schedules), | that the Measurement System has designed the Measurement Schedules), | |||
| but it could also be unintentional - for instance, if a Measurement | but it could also be unintentional - for instance, if a Measurement | |||
| Task has a 'wait for X' step which pauses for an unexpectedly long | Task has a 'wait for X' step which pauses for an unexpectedly long | |||
| time. This document makes no assumptions about the impact of one | time. This document makes no assumptions about the impact of one | |||
| Measurement Task on another. | Measurement Task on another. | |||
| The operator of the measurement system can handle (or not) | The operator of the Measurement System can handle (or not) | |||
| overlapping Measurement Tasks in any way they choose - it is a policy | overlapping Measurement Tasks in any way they choose - it is a policy | |||
| or implementation issue and not the concern of LMAP. Some possible | or implementation issue and not the concern of LMAP. Some possible | |||
| approaches are: to configure the MA not to begin the second | approaches are: to configure the MA not to begin the second | |||
| Measurement Task; to start the second Measurement Task as usual; for | Measurement Task; to start the second Measurement Task as usual; for | |||
| the action to be an Input Parameter of the Measurement Task; and so | the action to be an Input Parameter of the Measurement Task; and so | |||
| on. | on. | |||
| It may be important to include in the Measurement Report the fact | It may be important to include in the Measurement Report the fact | |||
| that the Measurement Task overlapped with another. | that the Measurement Task overlapped with another. | |||
| 5.4. Report Protocol | 5.4. Report Protocol | |||
| The primary purpose of the Report Protocol is to allow a Measurement | The primary purpose of the Report Protocol is to allow a Measurement | |||
| Agent to report its Measurement Results to a Collector, along with | Agent to report its Measurement Results to a Collector, along with | |||
| the context in which they were obtained. | the context in which they were obtained. | |||
| +-----------------+ +-------------+ | +-----------------+ +-------------+ | |||
| | | | Measurement | | | | | Measurement | | |||
| | Collector |===================================| Agent | | | Collector |==================================| Agent | | |||
| +-----------------+ +-------------+ | +-----------------+ +-------------+ | |||
| <- Report: | <- Report: | |||
| [MA-ID &/or Group-ID], | [MA-ID &/or Group-ID], | |||
| [Measurement Result], | [Measurement Result], | |||
| [details of Measurement Task], | [details of Measurement Task], | |||
| [Cycle-ID] | [Cycle-ID] | |||
| ACK -> | ACK -> | |||
| The Report contains: | The Report contains: | |||
| o the MA-ID or a Group-ID (to anonymise results) | o the MA-ID or a Group-ID (to anonymise results) | |||
| o the actual Measurement Results, including the time they were | o the actual Measurement Results, including the time they were | |||
| measured. In general the time is simply the MA's best estimate | measured. In general the time is simply the MA's best estimate | |||
| and there is no guarantee on the accuracy or granularity of the | and there is no guarantee on the accuracy or granularity of the | |||
| information. It is possible that some specific analysis of a | information. It is possible that some specific analysis of a | |||
| particular Measurement Method's Results will impose timing | particular Measurement Method's Results will impose timing | |||
| skipping to change at page 22, line 47 ¶ | skipping to change at page 24, line 44 ¶ | |||
| o the details of the Measurement Task (to avoid the Collector having | o the details of the Measurement Task (to avoid the Collector having | |||
| to ask the Controller for this information later). For example, | to ask the Controller for this information later). For example, | |||
| the interface used for the measurements. | the interface used for the measurements. | |||
| o the Cycle-ID, if one was included in the Instruction. | o the Cycle-ID, if one was included in the Instruction. | |||
| o perhaps the Subscriber's service parameters (see Section 5.4.1). | o perhaps the Subscriber's service parameters (see Section 5.4.1). | |||
| o the measurement point designation of the MA and, if applicable, | o the measurement point designation of the MA and, if applicable, | |||
| the MP or other MA, if the information was included in the | the MP or other MA, if the information was included in the | |||
| Instruction. This numbering system is defined in | Instruction. This numbering system is defined in [RFC7398] and | |||
| [I-D.ietf-ippm-lmap-path] and allows a Measurement Report to | allows a Measurement Report to describe abstractly the path | |||
| describe abstractly the path measured (for example, "from a MA at | measured (for example, "from a MA at a home gateway to a MA at a | |||
| a home gateway to a MA at a DSLAM"). Also, the MA can anonymise | DSLAM"). Also, the MA can anonymise results by including | |||
| results by including measurement point designations instead of IP | measurement point designations instead of IP addresses | |||
| addresses (Section 8.6.2). | (Section 8.6.2). | |||
| The MA sends Reports as defined by the Instruction. It is possible | The MA sends Reports as defined by the Instruction. It is possible | |||
| that the Instruction tells the MA to report the same Results to more | that the Instruction tells the MA to report the same Results to more | |||
| than one Collector, or to report a different subset of Results to | than one Collector, or to report a different subset of Results to | |||
| different Collectors. It is also possible that a Measurement Task | different Collectors. It is also possible that a Measurement Task | |||
| may create two (or more) Measurement Results, which could be reported | may create two (or more) Measurement Results, which could be reported | |||
| differently (for example, one Result could be reported periodically, | differently (for example, one Result could be reported periodically, | |||
| whilst the second Result could be an alarm that is created as soon as | whilst the second Result could be an alarm that is created as soon as | |||
| the measured value of the Metric crosses a threshold and that is | the measured value of the Metric crosses a threshold and that is | |||
| reported immediately). | reported immediately). | |||
| Optionally, a Report is not sent when there are no Measurement | Optionally, a Report is not sent when there are no Measurement | |||
| Results. | Results. | |||
| In the initial LMAP Information Model and Report Protocol, for | In the initial LMAP Information Model and Report Protocol, for | |||
| simplicity we assume that all Measurement Results are reported as-is, | simplicity we assume that all Measurement Results are reported as-is, | |||
| but allow extensibility so that a measurement system (or perhaps a | but allow extensibility so that a Measurement System (or perhaps a | |||
| second phase of LMAP) could allow a MA to: | second phase of LMAP) could allow a MA to: | |||
| o label, or perhaps not include, Measurement Results impacted by, | o label, or perhaps not include, Measurement Results impacted by, | |||
| for instance, cross-traffic or the Measurement Peer (or other | for instance, cross-traffic or a Measurement Peer (or other | |||
| Measurement Agent) being busy | Measurement Agent) being busy | |||
| o label Measurement Results obtained by a Measurement Task that | o label Measurement Results obtained by a Measurement Task that | |||
| overlapped with another | overlapped with another | |||
| o not report the Measurement Results if the MA believes that they | o not report the Measurement Results if the MA believes that they | |||
| are invalid | are invalid | |||
| o detail when Suppression started and ended | o detail when Suppression started and ended | |||
| skipping to change at page 23, line 50 ¶ | skipping to change at page 25, line 48 ¶ | |||
| may be invalid. | may be invalid. | |||
| 5.4.1. Reporting of Subscriber's service parameters | 5.4.1. Reporting of Subscriber's service parameters | |||
| The Subscriber's service parameters are information about his/her | The Subscriber's service parameters are information about his/her | |||
| broadband contract, line rate and so on. Such information is likely | broadband contract, line rate and so on. Such information is likely | |||
| to be needed to help analyse the Measurement Results, for example to | to be needed to help analyse the Measurement Results, for example to | |||
| help decide whether the measured download speed is reasonable. | help decide whether the measured download speed is reasonable. | |||
| The information could be transferred directly from the Subscriber | The information could be transferred directly from the Subscriber | |||
| parameter database to the data analysis tools. It may also be | parameter database to the data analysis tools. If the subscriber's | |||
| possible to transfer the information via the MA. How (and if) the MA | service parameters are available to the MAs, they could be reported | |||
| knows such information is likely to depend on the device type. The | with the Measurement Results in the Report Protocol. How (and if) | |||
| MA could either include the information in a Measurement Report or | the MA knows such information is likely to depend on the device type. | |||
| separately. | ||||
| The MA could either include the information in a Measurement Report | ||||
| or separately. | ||||
| 5.5. Operation of LMAP over the underlying packet transfer mechanism | 5.5. Operation of LMAP over the underlying packet transfer mechanism | |||
| The above sections have described LMAP's protocol model. Other | The above sections have described LMAP's protocol model. Other | |||
| specifications will define the actual Control and Report Protocols, | specifications will define the actual Control and Report Protocols, | |||
| possibly operating over an existing protocol, such as REST-style | possibly operating over an existing protocol, such as REST-style | |||
| HTTP(S). It is also possible that a different choice is made for the | HTTP(S). It is also possible that a different choice is made for the | |||
| Control and Report Protocols, for example NETCONF-YANG and IPFIX | Control and Report Protocols, for example NETCONF-YANG [RFC6241] and | |||
| (Internet Protocol Flow Information Export) respectively. | IPFIX (Internet Protocol Flow Information Export) [RFC7011] | |||
| respectively. | ||||
| From an LMAP perspective, the Controller needs to know that the MA | From an LMAP perspective, the Controller needs to know that the MA | |||
| has received the Instruction Message, or at least that it needs to be | has received the Instruction Message, or at least that it needs to be | |||
| re-sent as it may have failed to be delivered. Similarly the MA | re-sent as it may have failed to be delivered. Similarly the MA | |||
| needs to know about the delivery of Capabilities and Failure | needs to know about the delivery of Capabilities and Failure | |||
| information to the Controller and Reports to the Collector. How this | information to the Controller and Reports to the Collector. How this | |||
| is done depends on the design of the Control and Report Protocols and | is done depends on the design of the Control and Report Protocols and | |||
| the underlying packet transfer mechanism. | the underlying packet transfer mechanism. | |||
| For the Control Protocol, the underlying packet transfer mechanism | For the Control Protocol, the underlying packet transfer mechanism | |||
| could be: | could be: | |||
| o a 'push' protocol (that is, from the Controller to the MA) | o a 'push' protocol (that is, from the Controller to the MA) | |||
| o a multicast protocol (from the Controller to a group of MAs) | o a multicast protocol (from the Controller to a group of MAs) | |||
| o a 'pull' protocol. The MA periodically checks with Controller if | o a 'pull' protocol. The MA periodically checks with Controller if | |||
| the Instruction has changed and pulls a new Instruction if | the Instruction has changed and pulls a new Instruction if | |||
| necessary. A pull protocol seems attractive for a MA behind a NAT | necessary. A pull protocol seems attractive for a MA behind a NAT | |||
| (as is typical for a MA on an end-user's device), so that it can | or firewall (as is typical for a MA on an end-user's device), so | |||
| initiate the communications. A pull mechanism is likely to | that it can initiate the communications. It also seems attractive | |||
| require the MA to be configured with how frequently it should | for a MA on a mobile device, where the Controller might not know | |||
| check in with the Controller, and perhaps what it should do if the | how to reach the MA. A pull mechanism is likely to require the MA | |||
| Controller is unreachable after a certain number of attempts. | to be configured with how frequently it should check in with the | |||
| Controller, and perhaps what it should do if the Controller is | ||||
| unreachable after a certain number of attempts. | ||||
| o a hybrid protocol. In addition to a pull protocol, the Controller | o a hybrid protocol. In addition to a pull protocol, the Controller | |||
| can also push an alert to the MA that it should immediately pull a | can also push an alert to the MA that it should immediately pull a | |||
| new Instruction. | new Instruction. | |||
| For the Report Protocol, the underlying packet transfer mechanism | For the Report Protocol, the underlying packet transfer mechanism | |||
| could be: | could be: | |||
| o a 'push' protocol (that is, from the MA to the Collector) | o a 'push' protocol (that is, from the MA to the Collector) | |||
| o perhaps supplemented by the ability for the Collector to 'pull' | o perhaps supplemented by the ability for the Collector to 'pull' | |||
| Measurement Results from a MA. | Measurement Results from a MA. | |||
| 5.6. Items beyond the scope of the initial LMAP work | 5.6. Items beyond the scope of the initial LMAP work | |||
| There are several potential interactions between LMAP elements that | There are several potential interactions between LMAP elements that | |||
| are beyond the scope of the initial LMAP work: | are beyond the scope of the initial LMAP work: | |||
| 1. It does not define a coordination process between MAs. Whilst a | 1. It does not define a coordination process between MAs. Whilst a | |||
| measurement system may define coordinated Measurement Schedules | Measurement System may define coordinated Measurement Schedules | |||
| across its various MAs, there is no direct coordination between | across its various MAs, there is no direct coordination between | |||
| MAs. | MAs. | |||
| 2. It does not define interactions between the Collector and | 2. It does not define interactions between the Collector and | |||
| Controller. It is quite likely that there will be such | Controller. It is quite likely that there will be such | |||
| interactions, optionally intermediated by the data analysis | interactions, optionally intermediated by the data analysis | |||
| tools. For example, if there is an "interesting" Measurement | tools. For example, if there is an "interesting" Measurement | |||
| Result then the measurement system may want to trigger extra | Result then the Measurement System may want to trigger extra | |||
| Measurement Tasks that explore the potential cause in more | Measurement Tasks that explore the potential cause in more | |||
| detail; or if the Collector unexpectedly does not hear from a MA, | detail; or if the Collector unexpectedly does not hear from a MA, | |||
| then the measurement system may want to trigger the Controller to | then the Measurement System may want to trigger the Controller to | |||
| send a fresh Instruction Message to the MA. | send a fresh Instruction Message to the MA. | |||
| 3. It does not define coordination between different measurement | 3. It does not define coordination between different Measurement | |||
| systems. For example, it does not define the interaction of a MA | Systems. For example, it does not define the interaction of a MA | |||
| in one measurement system with a Controller or Collector in a | in one Measurement System with a Controller or Collector in a | |||
| different measurement system. Whilst it is likely that the | different Measurement System. Whilst it is likely that the | |||
| Control and Report Protocols could be re-used or adapted for this | Control and Report Protocols could be re-used or adapted for this | |||
| scenario, any form of coordination between different | scenario, any form of coordination between different | |||
| organisations involves difficult commercial and technical issues | organisations involves difficult commercial and technical issues | |||
| and so, given the novelty of large-scale measurement efforts, any | and so, given the novelty of large-scale measurement efforts, any | |||
| form of inter-organisation coordination is outside the scope of | form of inter-organisation coordination is outside the scope of | |||
| the initial LMAP work. Note that a single MA is instructed by a | the initial LMAP work. Note that a single MA is instructed by a | |||
| single Controller and is only in one measurement system. | single Controller and is only in one Measurement System. | |||
| * An interesting scenario is where a home contains two | * An interesting scenario is where a home contains two | |||
| independent MAs, for example one controlled by a regulator and | independent MAs, for example one controlled by a regulator and | |||
| one controlled by an ISP. Then the Measurement Traffic of one | one controlled by an ISP. Then the Measurement Traffic of one | |||
| MA is treated by the other MA just like any other end-user | MA is treated by the other MA just like any other end-user | |||
| traffic. | traffic. | |||
| 4. It does not consider how to prevent a malicious party "gaming the | 4. It does not consider how to prevent a malicious party "gaming the | |||
| system". For example, where a regulator is running a measurement | system". For example, where a regulator is running a Measurement | |||
| system in order to benchmark operators, a malicious operator | System in order to benchmark operators, a malicious operator | |||
| could try to identify the broadband lines that the regulator was | could try to identify the broadband lines that the regulator was | |||
| measuring and prioritise that traffic. It is assumed this is a | measuring and prioritise that traffic. It is assumed this is a | |||
| policy issue and would be dealt with through a code of conduct | policy issue and would be dealt with through a code of conduct | |||
| for instance. | for instance. | |||
| 5. It does not define how to analyse Measurement Results, including | 5. It does not define how to analyse Measurement Results, including | |||
| how to interpret missing Results. | how to interpret missing Results. | |||
| 6. It does not specifically define a end-user-controlled measurement | 6. It does not specifically define a end-user-controlled Measurement | |||
| system, see sub-section 5.6.1. | System, see sub-section 5.6.1. | |||
| 5.6.1. End-user-controlled measurement system | 5.6.1. End-user-controlled measurement system | |||
| This framework concentrates on the cases where an ISP or a regulator | This framework concentrates on the cases where an ISP or a regulator | |||
| runs the measurement system. However, we expect that LMAP | runs the Measurement System. However, we expect that LMAP | |||
| functionality will also be used in the context of an end-user- | functionality will also be used in the context of an end-user- | |||
| controlled measurement system. There are at least two ways this | controlled Measurement System. There are at least two ways this | |||
| could happen (they have various pros and cons): | could happen (they have various pros and cons): | |||
| 1. an end-user could somehow request the ISP- (or regulator-) run | 1. an end-user could somehow request the ISP- (or regulator-) run | |||
| measurement system to test his/her line. The ISP (or regulator) | Measurement System to test his/her line. The ISP (or regulator) | |||
| Controller would then send an Instruction to the MA in the usual | Controller would then send an Instruction to the MA in the usual | |||
| LMAP way. | LMAP way. | |||
| 2. an end-user could deploy their own measurement system, with their | 2. an end-user could deploy their own Measurement System, with their | |||
| own MA, Controller and Collector. For example, the user could | own MA, Controller and Collector. For example, the user could | |||
| implement all three functions onto the same end-user-owned end | implement all three functions onto the same end-user-owned end | |||
| device, perhaps by downloading the functions from the ISP or | device, perhaps by downloading the functions from the ISP or | |||
| regulator. Then the LMAP Control and Report Protocols do not | regulator. Then the LMAP Control and Report Protocols do not | |||
| need to be used, but using LMAP's Information Model would still | need to be used, but using LMAP's Information Model would still | |||
| be beneficial. The Measurement Peer (or other MA involved in the | be beneficial. A Measurement Peer (or other MA involved in a | |||
| Measurement Task) could be in the home gateway or outside the | Measurement Task) could be in the home gateway or outside the | |||
| home network; in the latter case the Measurement Peer is highly | home network; in the latter case the Measurement Peer is highly | |||
| likely to be run by a different organisation, which raises extra | likely to be run by a different organisation, which raises extra | |||
| privacy considerations. | privacy considerations. | |||
| In both cases there will be some way for the end-user to initiate the | In both cases there will be some way for the end-user to initiate the | |||
| Measurement Task(s). The mechanism is outside the scope of the | Measurement Task(s). The mechanism is outside the scope of the | |||
| initial LMAP work, but could include the user clicking a button on a | initial LMAP work, but could include the user clicking a button on a | |||
| GUI or sending a text message. Presumably the user will also be able | GUI or sending a text message. Presumably the user will also be able | |||
| to see the Measurement Results, perhaps summarised on a webpage. It | to see the Measurement Results, perhaps summarised on a webpage. It | |||
| is suggested that these interfaces conform to the LMAP guidance on | is suggested that these interfaces conform to the LMAP guidance on | |||
| privacy in Section 8. | privacy in Section 8. | |||
| 6. Deployment considerations | 6. Deployment considerations | |||
| The Appendix has some examples of possible deployment arrangements of | ||||
| Measurement Agents and Peers. | ||||
| 6.1. Controller and the measurement system | 6.1. Controller and the measurement system | |||
| The Controller should understand both the MA's LMAP Capabilities (for | The Controller should understand both the MA's LMAP Capabilities (for | |||
| instance what Metrics and Measurement Methods it can perform) and | instance what Metrics and Measurement Methods it can perform) and | |||
| about the MA's other capabilities like processing power and memory. | about the MA's other capabilities like processing power and memory. | |||
| This allows the Controller to make sure that the Measurement Schedule | This allows the Controller to make sure that the Measurement Schedule | |||
| of Measurement Tasks and the Reporting Schedule are sensible for each | of Measurement Tasks and the Reporting Schedule are sensible for each | |||
| MA that it instructs. | MA that it instructs. | |||
| An Instruction is likely to include several Measurement Tasks. | An Instruction is likely to include several Measurement Tasks. | |||
| Typically these run at different times, but it is also possible for | Typically these run at different times, but it is also possible for | |||
| them to run at the same time. Some Tasks may be compatible, in that | them to run at the same time. Some Tasks may be compatible, in that | |||
| they do not affect each other's Results, whilst with others great | they do not affect each other's Results, whilst with others great | |||
| care would need to be taken. Some Tasks may be complementary. For | care would need to be taken. Some Tasks may be complementary. For | |||
| example, one Task may be followed by a traceroute Task to the same | example, one Task may be followed by a traceroute Task to the same | |||
| destination address, in order to learn the network path that was | destination address, in order to learn the network path that was | |||
| measured. | measured. | |||
| The Controller should ensure that the Measurement Tasks do not have | The Controller should ensure that the Measurement Tasks do not have | |||
| an adverse effect on the end user. Tasks, especially those that | an adverse effect on the end user. Tasks, especially those that | |||
| generate a substantial amount of traffic, will often include a pre- | generate a substantial amount of Measurement Traffic, will often | |||
| check that the user isn't already sending traffic (Section 5.3). | include a pre-check that the user isn't already sending traffic | |||
| Another consideration is whether Measurement Traffic will impact a | (Section 5.3). Another consideration is whether Measurement Traffic | |||
| Subscriber's bill or traffic cap. | will impact a Subscriber's bill or traffic cap. | |||
| A measurement system may have multiple Controllers (but note the | A Measurement System may have multiple Controllers (but note the | |||
| overriding principle that a single MA is instructed by a single | overriding principle that a single MA is instructed by a single | |||
| Controller at any point in time (Section 4.2)). For example, there | Controller at any point in time (Section 4.2)). For example, there | |||
| could be different Controllers for different types of MA (home | could be different Controllers for different types of MA (home | |||
| gateways, tablets) or locations (Ipswich, Edinburgh), for load | gateways, tablets) or locations (Ipswich, Edinburgh, Paris), for load | |||
| balancing or to cope with failure of one Controller. | balancing or to cope with failure of one Controller. | |||
| The measurement system also needs to consider carefully how to | The measurement system also needs to consider carefully how to | |||
| interpret missing Results; for example, if the missing Results are | interpret missing Results. The correct interpretation depends on why | |||
| ignored and the lack of a Report is caused by its broadband being | the Results are missing (perhaps related to measurement suppression | |||
| broken, then the estimate of overall performance, averaged across all | or delayed Report submission), and potentially on the specifics of | |||
| MAs, would be too optimistic. The correct interpretation may depend | the Measurement Task and Measurement Schedule. For example, the set | |||
| on the specifics of the Measurement Task and Measurement Schedule. | of packets represented by a Flow may be empty; that is, an Observed | |||
| Traffic Flow may represent zero or more packets. The Flow would | ||||
| still be reported according to schedule. | ||||
| 6.2. Measurement Agent | 6.2. Measurement Agent | |||
| The MA should be cautious about resuming Measurement Tasks if it re- | ||||
| boots or has been off-line for some time, as its Instruction may be | ||||
| stale. In the former case it also needs to ensure that its clock has | ||||
| re-set correctly, so that it interprets the Schedule correctly. | ||||
| If the MA runs out of storage space for Measurement Results or can't | ||||
| contact the Controller, then the appropriate action is specific to | ||||
| the device and Measurement System. | ||||
| The Measurement Agent could take a number of forms: a dedicated | The Measurement Agent could take a number of forms: a dedicated | |||
| probe, software on a PC, embedded into an appliance, or even embedded | probe, software on a PC, embedded into an appliance, or even embedded | |||
| into a gateway. A single site (home, branch office etc.) that is | into a gateway. A single site (home, branch office etc.) that is | |||
| participating in a measurement could make use of one or multiple | participating in a measurement could make use of one or multiple | |||
| Measurement Agents or Measurement Peers in a single measurement. | Measurement Agents or Measurement Peers in a single measurement. | |||
| The Measurement Agent could be deployed in a variety of locations. | The Measurement Agent could be deployed in a variety of locations. | |||
| Not all deployment locations are available to every kind of | Not all deployment locations are available to every kind of | |||
| Measurement Agent. There are also a variety of limitations and | Measurement Agent. There are also a variety of limitations and | |||
| trade-offs depending on the final placement. The next sections | trade-offs depending on the final placement. The next sections | |||
| skipping to change at page 29, line 10 ¶ | skipping to change at page 31, line 20 ¶ | |||
| single LAN-side interface, there is little confusion - for | single LAN-side interface, there is little confusion - for | |||
| Measurement Methods that generate Measurement Traffic, the location | Measurement Methods that generate Measurement Traffic, the location | |||
| of the other MA or Measurement Peer determines whether the WAN or LAN | of the other MA or Measurement Peer determines whether the WAN or LAN | |||
| is measured. | is measured. | |||
| However, the device with the Measurement Agent may be multi-homed. | However, the device with the Measurement Agent may be multi-homed. | |||
| For example, a home or campus may be connected to multiple broadband | For example, a home or campus may be connected to multiple broadband | |||
| ISPs, such as a wired and wireless broadband provider, perhaps for | ISPs, such as a wired and wireless broadband provider, perhaps for | |||
| redundancy or load- sharing. It may also be helpful to think of dual | redundancy or load- sharing. It may also be helpful to think of dual | |||
| stack IPv4 and IPv6 broadband devices as multi-homed. More | stack IPv4 and IPv6 broadband devices as multi-homed. More | |||
| generally, Section 3.2 of [I-D.ietf-homenet-arch] describes dual- | generally, Section 3.2 of [RFC7368] describes dual-stack and multi- | |||
| stack and multi-homing topologies that might be encountered in a home | homing topologies that might be encountered in a home network, | |||
| network, [RFC6419] provides the current practices of multi-interfaces | [RFC6419] provides the current practices of multi-interfaces hosts, | |||
| hosts, and the Multiple Interfaces (mif) working group covers cases | and the Multiple Interfaces (mif) working group covers cases where | |||
| where hosts are either directly attached to multiple networks | hosts are either directly attached to multiple networks (physical or | |||
| (physical or virtual) or indirectly (multiple default routers, etc.). | virtual) or indirectly (multiple default routers, etc.). In these | |||
| In these cases, there needs to be clarity on which network | cases, there needs to be clarity on which network connectivity option | |||
| connectivity option is being measured. | is being measured. | |||
| One possibility is to have a Measurement Agent per interface. Then | One possibility is to have a Measurement Agent per interface. Then | |||
| the Controller's choice of MA determines which interface is measured. | the Controller's choice of MA determines which interface is measured. | |||
| However, if a MA can measure any of the interfaces, then the | However, if a MA can measure any of the interfaces, then the | |||
| Controller defines in the Instruction which interface the MA should | Controller defines in the Instruction which interface the MA should | |||
| use for a Measurement Task; if the choice of interface is not defined | use for a Measurement Task; if the choice of interface is not defined | |||
| then the MA uses the default one. Explicit definition is preferred | then the MA uses the default one. Explicit definition is preferred | |||
| if the measurement system wants to measure the performance of a | if the Measurement System wants to measure the performance of a | |||
| particular network, whereas using the default is better if the | particular network, whereas using the default is better if the | |||
| measurement system wants to include the impact of the MA's interface | Measurement System wants to include the impact of the MA's interface | |||
| selection algorithm. In any case, the Measurement Result should | selection algorithm. In any case, the Measurement Result should | |||
| include the network that was measured. | include the network that was measured. | |||
| 6.2.5. Measurement Agent embedded in ISP network | 6.2.5. Measurement Agent embedded in ISP network | |||
| A MA may be embedded on a device that is part of an ISP's network, | A MA may be embedded on a device that is part of an ISP's network, | |||
| such as a router or switch. Usually the network devices with an | such as a router or switch. Usually the network devices with an | |||
| embedded MA will be strategically located, such as a Carrier Grade | embedded MA will be strategically located, such as a Carrier Grade | |||
| NAT or ISP Gateway. [I-D.ietf-ippm-lmap-path] gives many examples | NAT or ISP Gateway. [RFC7398] gives many examples where a MA might | |||
| where a MA might be located within a network to provide an | be located within a network to provide an intermediate measurement | |||
| intermediate measurement point on the end-to-end path. Other | point on the end-to-end path. Other examples include a network | |||
| examples include a network device whose primary role is to host MA | device whose primary role is to host MA functions and the necessary | |||
| functions and the necessary measurement protocol. | measurement protocol. | |||
| 6.3. Measurement Peer | 6.3. Measurement Peer | |||
| A Measurement Peer participates in some Measurement Methods. It may | A Measurement Peer participates in some Measurement Methods. It may | |||
| have specific functionality to enable it to participate in a | have specific functionality to enable it to participate in a | |||
| particular Measurement Method. On the other hand, other Measurement | particular Measurement Method. On the other hand, other Measurement | |||
| Methods may require no special functionality, for example if the | Methods may require no special functionality. For example if the | |||
| Measurement Agent sends a ping to example.com then the server at | Measurement Agent sends a ping to example.com then the server at | |||
| example.com plays the role of a Measurement Peer. | example.com plays the role of a Measurement Peer; or if the MA | |||
| monitors existing traffic, then the existing end points are | ||||
| Measurement Peers. | ||||
| A device may participate in some Measurement Methods as a Measurement | A device may participate in some Measurement Methods as a Measurement | |||
| Agent and in others as a Measurement Peer. | Agent and in others as a Measurement Peer. | |||
| Measurement Schedules should account for limited resources in a | Measurement Schedules should account for limited resources in a | |||
| Measurement Peer when instructing a MA to execute measurements with a | Measurement Peer when instructing a MA to execute measurements with a | |||
| Measurement Peer. In some measurement protocols, such as [RFC4656] | Measurement Peer. In some measurement protocols, such as [RFC4656] | |||
| and [RFC5357], the Measurement Peer can reject a measurement session | and [RFC5357], the Measurement Peer can reject a measurement session | |||
| or refuse a control connection prior to setting-up a measurement | or refuse a control connection prior to setting-up a measurement | |||
| session and so protect itself from resource exhaustion. This is a | session and so protect itself from resource exhaustion. This is a | |||
| valuable capability because the MP may be used by more than one | valuable capability because the MP may be used by more than one | |||
| organisation. | organisation. | |||
| 6.4. Deployment examples | ||||
| In this section we describe some deployment scenarios that are | ||||
| feasible within the LMAP framework defined in this document. | ||||
| A very simple example of a Measurement Peer (MP) is a web server that | ||||
| the MA is downloading a web page from (such as www.example.com) in | ||||
| order to perform a speed test. The web server is a MP and from its | ||||
| perspective, the MA is just another client; the MP doesn't have a | ||||
| specific function for assisting measurements. This is described in | ||||
| the figure below. | ||||
| ^ | ||||
| +------------------+ Web Traffic +----------------+ non-LMAP | ||||
| | Web Client |<------------>| Web Server | Scope | ||||
| | | +----------------+ | | ||||
| ...|..................|....................................V... | ||||
| |MA:LMAP interface | <MP:> ^ | ||||
| +------------------+ | | ||||
| ^ | | | ||||
| Instruction | | Report | | ||||
| | +-----------------+ | | ||||
| | | | | ||||
| | v LMAP | ||||
| +------------+ +------------+ Scope | ||||
| | Controller | | Collector | | | ||||
| +------------+ +------------+ V | ||||
| Schematic of LMAP-based Measurement System, | ||||
| with Web server as Measurement Peer | ||||
| Another case that is slightly different than this would be the one of | ||||
| a TWAMP-responder. This is also a MP, with a helper function, the | ||||
| TWAMP server, which is specially deployed to assist the MAs that | ||||
| perform TWAMP tests. Another example is with a ping server, as | ||||
| described in Section 2. | ||||
| A further example is the case of a traceroute like measurement. In | ||||
| this case, for each packet sent, the router where the TTL expires is | ||||
| performing the MP function. So for a given Measurement Task, there | ||||
| is one MA involved and several MPs, one per hop. | ||||
| In the figure below we depict the case of an OWAMP (One-Way Active | ||||
| Measurement Protocol) responder acting as an MP. In this case, the | ||||
| helper function in addition reports results back to the MA. So it | ||||
| has both a data plane and control interface with the MA. | ||||
| +------------------+ OWAMP +----------------+ ^ | ||||
| | OWAMP |<--control--->| | | | ||||
| | control-client |-test-traffic>| OWAMP server & | non-LMAP | ||||
| | fetch-client & |<----fetch----| session-rec'ver| Scope | ||||
| | session-sender | | | | | ||||
| | | +----------------+ | | ||||
| ...|..................|....................................v... | ||||
| |MA:LMAP interface | <MP:> ^ | ||||
| +------------------+ | | ||||
| ^ | | | ||||
| Instruction | | Report | | ||||
| | +-----------------+ | | ||||
| | | | | ||||
| | v LMAP | ||||
| +------------+ +------------+ Scope | ||||
| | Controller | | Collector | | | ||||
| +------------+ +------------+ v | ||||
| Schematic of LMAP-based Measurement System, | ||||
| with OWAMP server as Measurement Peer | ||||
| However, it is also possible to use two Measurement Agents when | ||||
| performing one way Measurement Tasks, as described in the figure | ||||
| below. Both MAs are instructed by the Controller: MA-1 to send the | ||||
| traffic and MA-2 to measure the received traffic and send Reports to | ||||
| the Collector. Note that the Measurement Task at MA-2 can listen for | ||||
| traffic from MA-1 and respond multiple times without having to be | ||||
| rescheduled. | ||||
| +----------------+ +----------------+ ^ | ||||
| | | | | non-LMAP | ||||
| | iperf -u sender|-UDP traffic->| iperf -u recvr | Scope | ||||
| | | | | v | ||||
| ...|................|..............|................|........ | ||||
| | MA-1: | | MA-2: | ^ | ||||
| | LMAP interface | | LMAP interface | | | ||||
| +----------------+ +----------------+ | | ||||
| ^ ^ | | | ||||
| Instruction | Instruction{Report} | | Report | | ||||
| {task, | +-------------------+ | | | ||||
| schedule} | | | | | ||||
| | | v LMAP | ||||
| +------------+ +------------+ Scope | ||||
| | Controller | | Collector | | | ||||
| +------------+ +------------+ v | ||||
| Schematic of LMAP-based Measurement System, with two | ||||
| Measurement Agents cooperating to measure UDP traffic | ||||
| Next, we consider Measurement Methods that meter the Observed Traffic | ||||
| Flow. Traffic generated in one point in the network flowing towards | ||||
| a given destination and the traffic is observed in some point along | ||||
| the path. One way to implement this is that the endpoints generating | ||||
| and receiving the traffic are not instructed by the Controller; hence | ||||
| they are MPs. The MA is located along the path with a monitor | ||||
| function that measures the traffic. The MA is instructed by the | ||||
| Controller to monitor that particular traffic and to send the Report | ||||
| to the Collector. It is depicted in the figure below. | ||||
| +--------+ +------------------+ +--------+ ^ | ||||
| |End user| | Monitor | Observed |End user| | | ||||
| | |<--|------------------|--traffic-->| | non-LMAP | ||||
| | | | | flow | | Scope | ||||
| +--------+ | | +--------+ | | ||||
| ...|..................|............................v.. | ||||
| |MA:LMAP interface | <MP:> ^ | ||||
| +------------------+ | | ||||
| ^ | | | ||||
| Instruction | | Report | | ||||
| | +-----------------+ | | ||||
| | | | | ||||
| | v LMAP | ||||
| +------------+ +------------+ Scope | ||||
| | Controller | | Collector | | | ||||
| +------------+ +------------+ v | ||||
| Schematic of LMAP-based Measurement System, | ||||
| with a Measurement Agent monitoring traffic | ||||
| 7. Security considerations | 7. Security considerations | |||
| The security of the LMAP framework should protect the interests of | The security of the LMAP framework should protect the interests of | |||
| the measurement operator(s), the network user(s) and other actors who | the measurement operator(s), the network user(s) and other actors who | |||
| could be impacted by a compromised measurement deployment. The | could be impacted by a compromised measurement deployment. The | |||
| measurement system must secure the various components of the system | Measurement System must secure the various components of the system | |||
| from unauthorised access or corruption. Much of the general advice | from unauthorised access or corruption. Much of the general advice | |||
| contained in section 6 of [RFC4656] is applicable here. | contained in section 6 of [RFC4656] is applicable here. | |||
| The process to upgrade the firmware in an MA is outside the scope of | The process to upgrade the firmware in an MA is outside the scope of | |||
| the initial LMAP work, similar to the protocol to bootstrap the MAs | the initial LMAP work, just as is the protocol to bootstrap the MAs. | |||
| (as specified in the charter). However, systems which provide remote | However, systems which provide remote upgrade must secure authorised | |||
| upgrade must secure authorised access and integrity of the process. | access and integrity of the process. | |||
| We assume that each Measurement Agent (MA) will receive its | We assume that each Measurement Agent (MA) will receive its | |||
| Instructions from a single organisation, which operates the | Instructions from a single organisation, which operates the | |||
| Controller. These Instructions must be authenticated (to ensure that | Controller. These Instructions must be authenticated (to ensure that | |||
| they come from the trusted Controller), checked for integrity (to | they come from the trusted Controller), checked for integrity (to | |||
| ensure no-one has tampered with them) and not vulnerable to replay | ensure no-one has tampered with them) and not vulnerable to replay | |||
| attacks. If a malicious party can gain control of the MA they can | attacks. If a malicious party can gain control of the MA they can | |||
| use it to launch DoS attacks at targets, reduce the end user's | use it to launch DoS attacks at targets, create a platform for | |||
| quality of experience and corrupt the Measurement Results that are | pervasive monitoring [RFC7258], reduce the end user's quality of | |||
| reported to the Collector. By altering the Measurement Tasks and/or | experience and corrupt the Measurement Results that are reported to | |||
| the address that Results are reported to, they can also compromise | the Collector. By altering the Measurement Tasks and/or the address | |||
| the confidentiality of the network user and the MA environment (such | that Results are reported to, they can also compromise the | |||
| as information about the location of devices or their traffic). The | confidentiality of the network user and the MA environment (such as | |||
| Instruction messages also need to be encrypted to maintain | information about the location of devices or their traffic). The | |||
| Instruction Messages also need to be encrypted to maintain | ||||
| confidentiality, as the information might be useful to an attacker. | confidentiality, as the information might be useful to an attacker. | |||
| In some circumstances (if the MA is behind a NAT for instance), the | ||||
| Controller cannot contact the MA directly and so the MA must contact | ||||
| the Controller (the "pull" model). The Controller should ensure that | ||||
| its resources cannot be exhausted by a malicious party pretending to | ||||
| be a MA. For example, the Controller could limit the rate of "pull" | ||||
| requests from a single MA. | ||||
| Reporting by the MA must be encrypted to maintain confidentiality, so | Reporting by the MA must be encrypted to maintain confidentiality, so | |||
| that only the authorised Collector can decrypt the results, to | that only the authorised Collector can decrypt the results, to | |||
| prevent the leakage of confidential or private information. | prevent the leakage of confidential or private information. | |||
| Reporting must also be authenticated (to ensure that it comes from a | Reporting must also be authenticated (to ensure that it comes from a | |||
| trusted MA and that the MA reports to a genuine Collector) and not | trusted MA and that the MA reports to a genuine Collector) and not | |||
| vulnerable to tampering (which can be ensured through integrity and | vulnerable to tampering (which can be ensured through integrity and | |||
| replay checks). It must not be possible to fool a MA into injecting | replay checks). It must not be possible to fool a MA into injecting | |||
| falsified data and the results must also be held and processed | falsified data and the results must also be held and processed | |||
| securely after collection and analysis. See section 8.5.2 below for | securely after collection and analysis. See section 8.5.2 below for | |||
| additional considerations on stored data compromise, and section 8.6 | additional considerations on stored data compromise, and section 8.6 | |||
| on potential mitigations for compromise. | on potential mitigations for compromise. | |||
| Since Collectors will be contacted repeatedly by MAs using the | Since Collectors will be contacted repeatedly by MAs using the | |||
| skipping to change at page 31, line 33 ¶ | skipping to change at page 36, line 47 ¶ | |||
| o limit the transmission rate from a single MA. | o limit the transmission rate from a single MA. | |||
| o limit the memory/storage consumed by a single MA's reports. | o limit the memory/storage consumed by a single MA's reports. | |||
| o efficiently reject reporting connections from unknown sources. | o efficiently reject reporting connections from unknown sources. | |||
| o separate resources if multiple authentication strengths are used, | o separate resources if multiple authentication strengths are used, | |||
| where the resources should be separated according to each class of | where the resources should be separated according to each class of | |||
| strength. | strength. | |||
| A corrupted MA could report falsified information to the Collector. | ||||
| Whether this can be effectively mitigated depends on the platform on | ||||
| which the MA is deployed, but where the MA is deployed on a customer- | ||||
| controlled device then the reported data is to some degree inherently | ||||
| untrustworthy. Further, a sophisticated party could distort some | ||||
| Measurement Methods, perhaps by dropping or delaying packets for | ||||
| example. This suggests that the network operator should be cautious | ||||
| about relying on Measurement Results for action such as refunding | ||||
| fees if a service level agreement is not met. | ||||
| As part of the protocol design, it will be decided how LMAP operates | ||||
| over the underlying protocol (Section 5.5). The choice raises | ||||
| various security issues, such as how to operate through a NAT and how | ||||
| to protect the Controller and Collector from denial of service | ||||
| attacks. | ||||
| The security mechanisms described above may not be strictly necessary | The security mechanisms described above may not be strictly necessary | |||
| if the network's design ensures the LMAP components and their | if the network's design ensures the LMAP components and their | |||
| communications are already secured, for example potentially if they | communications are already secured, for example potentially if they | |||
| are all part of an ISP's dedicated management network. | are all part of an ISP's dedicated management network. | |||
| Finally, there are three other issues related to security: privacy | Finally, there are three other issues related to security: privacy | |||
| (considered in Section 8 below), availability and 'gaming the | (considered in Section 8 below), availability and 'gaming the | |||
| system'. While the loss of some MAs may not be considered critical, | system'. While the loss of some MAs may not be considered critical, | |||
| the unavailability of the Collector could mean that valuable business | the unavailability of the Collector could mean that valuable business | |||
| data or data critical to a regulatory process is lost. Similarly, | data or data critical to a regulatory process is lost. Similarly, | |||
| the unavailability of a Controller could mean that the MAs do not | the unavailability of a Controller could mean that the MAs do not | |||
| operate a correct Measurement Schedule. | operate a correct Measurement Schedule. | |||
| A malicious party could "game the system". For example, where a | A malicious party could "game the system". For example, where a | |||
| regulator is running a measurement system in order to benchmark | regulator is running a Measurement System in order to benchmark | |||
| operators, an operator could try to identify the broadband lines that | operators, an operator could try to identify the broadband lines that | |||
| the regulator was measuring and prioritise that traffic. Normally, | the regulator was measuring and prioritise that traffic. Normally, | |||
| this potential issue is handled by a code of conduct. It is outside | this potential issue is handled by a code of conduct. It is outside | |||
| the scope of the initial LMAP work to consider the issue. | the scope of the initial LMAP work to consider the issue. | |||
| 8. Privacy considerations | 8. Privacy considerations | |||
| The LMAP work considers privacy as a core requirement and will ensure | The LMAP work considers privacy as a core requirement and will ensure | |||
| that by default the Control and Report Protocols operate in a | that by default the Control and Report Protocols operate in a | |||
| privacy-sensitive manner and that privacy features are well-defined. | privacy-sensitive manner and that privacy features are well-defined. | |||
| skipping to change at page 32, line 46 ¶ | skipping to change at page 38, line 31 ¶ | |||
| sensitive information which may be stored in the process of | sensitive information which may be stored in the process of | |||
| performing Measurement Tasks and collecting Results. | performing Measurement Tasks and collecting Results. | |||
| o Regulators: Public authorities responsible for exercising | o Regulators: Public authorities responsible for exercising | |||
| supervision of the electronic communications sector, and which may | supervision of the electronic communications sector, and which may | |||
| have access to sensitive information of individuals who | have access to sensitive information of individuals who | |||
| participate in a measurement campaign. Similarly, regulators | participate in a measurement campaign. Similarly, regulators | |||
| desire to protect the participants and their own sensitive | desire to protect the participants and their own sensitive | |||
| information. | information. | |||
| o Other LMAP system operators: Organisations who operate measurement | o Other LMAP system operators: Organisations who operate Measurement | |||
| systems or participate in measurements in some way. | Systems or participate in measurements in some way. | |||
| Although privacy is a protection extended to individuals, we include | ||||
| discussion of ISPs and other LMAP system operators in this section. | ||||
| These organisations have sensitive information involved in the LMAP | ||||
| system, and many of the same dangers and mitigations are applicable. | ||||
| Further, the ISPs store information on their Subscribers beyond that | Although privacy is a protection extended to individuals, we discuss | |||
| used in the LMAP system (for instance billing information), and there | data protection by ISPs and other LMAP system operators in this | |||
| should be a benefit in considering all the needs and potential | section. These organisations have sensitive information involved in | |||
| solutions coherently. | the LMAP system, and many of the same dangers and mitigations are | |||
| applicable. Further, the ISPs store information on their Subscribers | ||||
| beyond that used in the LMAP system (for instance billing | ||||
| information), and there should be a benefit in considering all the | ||||
| needs and potential solutions coherently. | ||||
| 8.2. Examples of sensitive information | 8.2. Examples of sensitive information | |||
| This section gives examples of sensitive information which may be | This section gives examples of sensitive information which may be | |||
| measured or stored in a measurement system, and which is to be kept | measured or stored in a Measurement System, and which is to be kept | |||
| private by default in the LMAP core protocols. | private by default in the LMAP core protocols. | |||
| Examples of Subscriber or authorised Internet user sensitive | Examples of Subscriber or authorised Internet user sensitive | |||
| information: | information: | |||
| o Sub-IP layer addresses and names (MAC address, base station ID, | o Sub-IP layer addresses and names (MAC address, base station ID, | |||
| SSID) | SSID) | |||
| o IP address in use | o IP address in use | |||
| skipping to change at page 34, line 4 ¶ | skipping to change at page 39, line 37 ¶ | |||
| o Measurement Results (some may be shared, others may be private) | o Measurement Results (some may be shared, others may be private) | |||
| o Measurement Schedule (exact times) | o Measurement Schedule (exact times) | |||
| o Network topology (locations, connectivity, redundancy) | o Network topology (locations, connectivity, redundancy) | |||
| o Subscriber billing information, and any of the above Subscriber | o Subscriber billing information, and any of the above Subscriber | |||
| information known to the provider. | information known to the provider. | |||
| o Authentication credentials (such as certificates) | o Authentication credentials (such as certificates) | |||
| Other organisations will have some combination of the lists above. | Other organisations will have some combination of the lists above. | |||
| The LMAP system would not typically expose all of the information | The LMAP system would not typically expose all of the information | |||
| above, but could expose a combination of items which could be | above, but could expose a combination of items which could be | |||
| correlated with other pieces collected by an attacker (as discussed | correlated with other pieces collected by an attacker (as discussed | |||
| in the section on Threats below). | in the section on Threats below). | |||
| 8.3. Different privacy issues raised by different sorts of Measurement | 8.3. Different privacy issues raised by different sorts of Measurement | |||
| Methods | Methods | |||
| Measurement Methods raise different privacy issues depending on | Measurement Methods raise different privacy issues depending on | |||
| whether they measure traffic created specifically for that purpose, | whether they measure traffic created specifically for that purpose, | |||
| or whether they measure user traffic. | or whether they measure user traffic. | |||
| Measurement Tasks conducted on user traffic store sensitive | Measurement Tasks conducted on user traffic store sensitive | |||
| information, however briefly this storage may be. We note that some | information, however briefly this storage may be. We note that some | |||
| authorities make a distinction on time of storage, and information | authorities make a distinction on time of storage, and information | |||
| that is kept only temporarily to perform a communications function is | that is kept only temporarily to perform a communications function is | |||
| not subject to regulation (for example, active queue management, deep | not subject to regulation (for example, active queue management, deep | |||
| packet inspection). Such Measurement Tasks could reveal all the | packet inspection). Such Measurement Tasks could reveal all the | |||
| websites a Subscriber visits and the applications and/or services | websites a Subscriber visits and the applications and/or services | |||
| they use. | they use. This issue is not specific to LMAP. For instance, IPFIX | |||
| has discussed similar issues (see section 11.8 of [RFC7011]), but | ||||
| mitigations described in the sections below were considered beyond | ||||
| their scope. | ||||
| Other types of Measurement Task are conducted on traffic which is | Other types of Measurement Task are conducted on traffic which is | |||
| created specifically for the purpose. Even if a user host generates | created specifically for the purpose. Even if a user host generates | |||
| Measurement Traffic, there is limited sensitive information about the | Measurement Traffic, there is limited sensitive information about the | |||
| Subscriber present and stored in the measurement system: | Subscriber present and stored in the Measurement System: | |||
| o IP address in use (and possibly sub-IP addresses and names) | o IP address in use (and possibly sub-IP addresses and names) | |||
| o Status as a study volunteer and Schedule of Measurement Tasks | o Status as a study volunteer and Schedule of Measurement Tasks | |||
| On the other hand, for a service provider the sensitive information | On the other hand, for a service provider the sensitive information | |||
| like Measurement Results is the same for all Measurement Tasks. | like Measurement Results is the same for all Measurement Tasks. | |||
| From the Subscriber perspective, both types of Measurement Task | From the Subscriber perspective, both types of Measurement Task | |||
| potentially expose the description of Internet access service and | potentially expose the description of Internet access service and | |||
| skipping to change at page 36, line 46 ¶ | skipping to change at page 42, line 32 ¶ | |||
| and stored. | and stored. | |||
| The Measurement Results are the additional sensitive information | The Measurement Results are the additional sensitive information | |||
| included in the Collector-MA exchange. Organisations collecting LMAP | included in the Collector-MA exchange. Organisations collecting LMAP | |||
| measurements have the responsibility for data control. Thus, the | measurements have the responsibility for data control. Thus, the | |||
| Results and other information communicated in the Collector protocol | Results and other information communicated in the Collector protocol | |||
| must be secured. | must be secured. | |||
| 8.4.4. Measurement Peer <-> Measurement Agent | 8.4.4. Measurement Peer <-> Measurement Agent | |||
| A Measurement Method involving a Measurement Peer (or second | A Measurement Method involving Measurement Traffic raises potential | |||
| Measurement Agent) raises potential privacy issues, although the | privacy issues, although the specification of the mechanisms is | |||
| specification of the mechanisms is beyond the scope of the initial | beyond the scope of the initial LMAP work. The high-level | |||
| LMAP work. The high-level communications model below illustrates the | communications model below illustrates the various exchanges to | |||
| various exchanges to execute such a Measurement Method and store the | execute such a Measurement Method and store the Results. | |||
| Results. | ||||
| We note the potential for additional observers in the figures below | We note the potential for additional observers in the figures below | |||
| by indicating the possible presence of a NAT, which has additional | by indicating the possible presence of a NAT, which has additional | |||
| significance to the protocols and direction of initiation. | significance to the protocols and direction of initiation. | |||
| The various messages are optional, depending on the nature of the | The various messages are optional, depending on the nature of the | |||
| Measurement Method. It may involve sending Measurement Traffic from | Measurement Method. It may involve sending Measurement Traffic from | |||
| the Measurement Peer to MA, MA to Measurement Peer, or both. | the Measurement Peer to MA, MA to Measurement Peer, or both. | |||
| Similarly, a second (or more) MAs may be involved. | Similarly, a second (or more) MAs may be involved. (Note: For | |||
| simplicity, the Figure and description don't show the non-LMAP | ||||
| functionality that is associated with the transfer of the Measurement | ||||
| Traffic and is located at the devices with the MA and MP.) | ||||
| _________________ _________________ | _________________ _________________ | |||
| | | | | | | | | | | |||
| |Measurement Peer |=========== NAT ? ==========|Measurement Agent| | |Measurement Peer |=========== NAT ? ==========|Measurement Agent| | |||
| |_________________| |_________________| | |_________________| |_________________| | |||
| <- (Key Negotiation & | <- (Key Negotiation & | |||
| Encryption Setup) | Encryption Setup) | |||
| (Encrypted Channel -> | (Encrypted Channel -> | |||
| Established) | Established) | |||
| (Announce capabilities -> | (Announce capabilities -> | |||
| skipping to change at page 38, line 13 ¶ | skipping to change at page 44, line 7 ¶ | |||
| includes a pre-check that the end-user isn't already sending traffic, | includes a pre-check that the end-user isn't already sending traffic, | |||
| the Measurement Peer may be able to deduce when the Subscriber is | the Measurement Peer may be able to deduce when the Subscriber is | |||
| away on holiday, for example. | away on holiday, for example. | |||
| If the Measurement Traffic is unencrypted, as found in many systems | If the Measurement Traffic is unencrypted, as found in many systems | |||
| today, then both timing and limited results are open to on-path | today, then both timing and limited results are open to on-path | |||
| observers. | observers. | |||
| 8.4.5. Measurement Agent | 8.4.5. Measurement Agent | |||
| Some Measurement Methods only involve a single Measurement Agent. | Some Measurement Methods only involve a single Measurement Agent | |||
| They raise potential privacy issues, although the specification of | observing existing traffic. They raise potential privacy issues, | |||
| the mechanisms is beyond the scope of the initial LMAP work. | although the specification of the mechanisms is beyond the scope of | |||
| the initial LMAP work. | ||||
| The high-level communications model below illustrates the collection | The high-level communications model below illustrates the collection | |||
| of user information of interest with the Measurement Agent performing | of user information of interest with the Measurement Agent performing | |||
| the monitoring and storage of the Results. This particular exchange | the monitoring and storage of the Results. This particular exchange | |||
| is for measurement of DNS Response Time, which most frequently uses | is for measurement of DNS Response Time, which most frequently uses | |||
| UDP transport. | UDP transport. (Note: For simplicity, the Figure and description | |||
| don't show the non-LMAP functionality that is associated with the | ||||
| transfer of the Measurement Traffic and is located at the devices | ||||
| with the MA.) | ||||
| _________________ ____________ | _________________ ____________ | |||
| | | | | | | | | | | |||
| | DNS Server |=========== NAT ? ==========*=======| User client| | | DNS Server |=========== NAT ? ==========*=======| User client| | |||
| |_________________| ^ |____________| | |_________________| ^ |____________| | |||
| ______|_______ | ______|_______ | |||
| | | | | | | |||
| | Measurement | | | Measurement | | |||
| | Agent | | | Agent | | |||
| |______________| | |______________| | |||
| skipping to change at page 40, line 40 ¶ | skipping to change at page 46, line 37 ¶ | |||
| characteristics of an individual, and Identification as using this | characteristics of an individual, and Identification as using this | |||
| combination to infer identity. | combination to infer identity. | |||
| The main risk is that the LMAP system could unwittingly provide a key | The main risk is that the LMAP system could unwittingly provide a key | |||
| piece of the correlation chain, starting with an unknown Subscriber's | piece of the correlation chain, starting with an unknown Subscriber's | |||
| IP address and another piece of information. For example, a | IP address and another piece of information. For example, a | |||
| Subscriber utilised Internet access from 2000 to 2310 UTC, because | Subscriber utilised Internet access from 2000 to 2310 UTC, because | |||
| the Measurement Tasks were deferred, or sent a name resolution for | the Measurement Tasks were deferred, or sent a name resolution for | |||
| www.example.com at 2300 UTC. | www.example.com at 2300 UTC. | |||
| If a user's access with another system already gave away sensitive | ||||
| info, correlation is clearly easier and can result in re- | ||||
| identification, even when an LMAP conserves sensitive information to | ||||
| great extent. | ||||
| 8.5.4. Secondary use and disclosure | 8.5.4. Secondary use and disclosure | |||
| Sections 5.2.3 and 5.2.4 of [RFC6973] describes Secondary Use as | Sections 5.2.3 and 5.2.4 of [RFC6973] describes Secondary Use as | |||
| unauthorised utilisation of an individual's information for a purpose | unauthorised utilisation of an individual's information for a purpose | |||
| the individual did not intend, and Disclosure is when such | the individual did not intend, and Disclosure is when such | |||
| information is revealed causing other's notions of the individual to | information is revealed causing other's notions of the individual to | |||
| change, or confidentiality to be violated. | change, or confidentiality to be violated. | |||
| Measurement Methods that measure user traffic are a form of Secondary | Measurement Methods that measure user traffic are a form of Secondary | |||
| Use, and the Subscribers' permission should be obtained beforehand. | Use, and the Subscribers' permission should be obtained beforehand. | |||
| skipping to change at page 42, line 49 ¶ | skipping to change at page 48, line 51 ¶ | |||
| Protocol and injecting Measurement Results (known fingerprint, see | Protocol and injecting Measurement Results (known fingerprint, see | |||
| section 3.2 of [RFC6973]) for inclusion with the shared and | section 3.2 of [RFC6973]) for inclusion with the shared and | |||
| anonymised results, then fingerprinting those records to ascertain | anonymised results, then fingerprinting those records to ascertain | |||
| the anonymisation process. | the anonymisation process. | |||
| Beside anonymisation of measured Results for a specific user or | Beside anonymisation of measured Results for a specific user or | |||
| provider, the value of sensitive information can be further diluted | provider, the value of sensitive information can be further diluted | |||
| by summarising the results over many individuals or areas served by | by summarising the results over many individuals or areas served by | |||
| the provider. There is an opportunity enabled by forming anonymity | the provider. There is an opportunity enabled by forming anonymity | |||
| sets [RFC6973] based on the reference path measurement points in | sets [RFC6973] based on the reference path measurement points in | |||
| [I-D.ietf-ippm-lmap-path]. For example, all measurements from the | [RFC7398]. For example, all measurements from the Subscriber device | |||
| Subscriber device can be identified as "mp000", instead of using the | can be identified as "mp000", instead of using the IP address or | |||
| IP address or other device information. The same anonymisation | other device information. The same anonymisation applies to the | |||
| applies to the Internet Service Provider, where their Internet | Internet Service Provider, where their Internet gateway would be | |||
| gateway would be referred to as "mp190". | referred to as "mp190". | |||
| Another anonymisation technique is for the MA to include its Group-ID | Another anonymisation technique is for the MA to include its Group-ID | |||
| instead of its MA-ID in its Measurement Reports, with several MAs | instead of its MA-ID in its Measurement Reports, with several MAs | |||
| sharing the same Group-ID. | sharing the same Group-ID. | |||
| 8.6.3. Pseudonymity | 8.6.3. Pseudonymity | |||
| Section 6.1.2 of [RFC6973] indicates that pseudonyms, or nicknames, | Section 6.1.2 of [RFC6973] indicates that pseudonyms, or nicknames, | |||
| are a possible mitigation to revealing one's true identity, since | are a possible mitigation to revealing one's true identity, since | |||
| there is no requirement to use real names in almost all protocols. | there is no requirement to use real names in almost all protocols. | |||
| skipping to change at page 44, line 14 ¶ | skipping to change at page 50, line 16 ¶ | |||
| reduction and temporary storage mitigations as appropriate and | reduction and temporary storage mitigations as appropriate and | |||
| certified through code review. | certified through code review. | |||
| LMAP protocols, devices, and the information they store clearly need | LMAP protocols, devices, and the information they store clearly need | |||
| to be secure from unauthorised access. This is the hand-off between | to be secure from unauthorised access. This is the hand-off between | |||
| privacy and security considerations (Section 7). The Data Controller | privacy and security considerations (Section 7). The Data Controller | |||
| has the (legal) responsibility to maintain data protections described | has the (legal) responsibility to maintain data protections described | |||
| in the Subscriber's agreement and agreements with other | in the Subscriber's agreement and agreements with other | |||
| organisations. | organisations. | |||
| Finally, it is recommended that each entity in section 8.1, | ||||
| (individuals, ISPs, Regulators, others) assess the risks of LMAP data | ||||
| collection by conducting audits of their data protection methods. | ||||
| 9. IANA considerations | 9. IANA considerations | |||
| There are no IANA considerations in this memo. | There are no IANA considerations in this memo. | |||
| 10. Acknowledgments | 10. Acknowledgments | |||
| This document originated as a merger of three individual drafts: | This document originated as a merger of three individual drafts: | |||
| draft-eardley-lmap-terminology-02, draft-akhter-lmap-framework-00, | draft-eardley-lmap-terminology-02, draft-akhter-lmap-framework-00, | |||
| and draft-eardley-lmap-framework-02. | and draft-eardley-lmap-framework-02. | |||
| skipping to change at page 44, line 36 ¶ | skipping to change at page 50, line 42 ¶ | |||
| -02. Thanks to Barbara Stark and Ken Ko for many helpful comments | -02. Thanks to Barbara Stark and Ken Ko for many helpful comments | |||
| about later versions. | about later versions. | |||
| Thanks to numerous people for much discussion, directly and on the | Thanks to numerous people for much discussion, directly and on the | |||
| LMAP list (apologies to those unintentionally omitted): Alan Clark, | LMAP list (apologies to those unintentionally omitted): Alan Clark, | |||
| Alissa Cooper, Andrea Soppera, Barbara Stark, Benoit Claise, Brian | Alissa Cooper, Andrea Soppera, Barbara Stark, Benoit Claise, Brian | |||
| Trammell, Charles Cook, Dan Romascanu, Dave Thorne, Frode Soerensen, | Trammell, Charles Cook, Dan Romascanu, Dave Thorne, Frode Soerensen, | |||
| Greg Mirsky, Guangqing Deng, Jason Weil, Jean-Francois Tremblay, | Greg Mirsky, Guangqing Deng, Jason Weil, Jean-Francois Tremblay, | |||
| Jerome Benoit, Joachim Fabini, Juergen Schoenwaelder, Jukka Manner, | Jerome Benoit, Joachim Fabini, Juergen Schoenwaelder, Jukka Manner, | |||
| Ken Ko, Lingli Deng, Mach Chen, Matt Mathis, Marc Ibrahim, Michael | Ken Ko, Lingli Deng, Mach Chen, Matt Mathis, Marc Ibrahim, Michael | |||
| Bugenhagen, Michael Faath, Nalini Elkins, Rolf Winter, Sam Crawford, | Bugenhagen, Michael Faath, Nalini Elkins, Radia Perlman, Rolf Winter, | |||
| Sharam Hakimi, Steve Miller, Ted Lemon, Timothy Carey, Vaibhav | Sam Crawford, Sharam Hakimi, Steve Miller, Ted Lemon, Timothy Carey, | |||
| Bajpai, Vero Zheng, William Lupton. | Vaibhav Bajpai, Vero Zheng, William Lupton. | |||
| Philip Eardley, Trevor Burbridge and Marcelo Bagnulo work in part on | Philip Eardley, Trevor Burbridge and Marcelo Bagnulo work in part on | |||
| the Leone research project, which receives funding from the European | the Leone research project, which receives funding from the European | |||
| Union Seventh Framework Programme [FP7/2007-2013] under grant | Union Seventh Framework Programme [FP7/2007-2013] under grant | |||
| agreement number 317647. | agreement number 317647. | |||
| 11. History | 11. History | |||
| First WG version, copy of draft-folks-lmap-framework-00. | First WG version, copy of draft-folks-lmap-framework-00. | |||
| skipping to change at page 47, line 8 ¶ | skipping to change at page 53, line 11 ¶ | |||
| the various issues as detailed in | the various issues as detailed in | |||
| http://tools.ietf.org/agenda/89/slides/slides-89-lmap-2.pdf. In | http://tools.ietf.org/agenda/89/slides/slides-89-lmap-2.pdf. In | |||
| particular: | particular: | |||
| o tweaked definitions, especially of Measurement Agent and | o tweaked definitions, especially of Measurement Agent and | |||
| Measurement Peer | Measurement Peer | |||
| o Instruction - left to each implementation & deployment of LMAP to | o Instruction - left to each implementation & deployment of LMAP to | |||
| decide on the granularity at which an Instruction Message works | decide on the granularity at which an Instruction Message works | |||
| o words added about overlapping Measurement Tasks (measurement | o words added about overlapping Measurement Tasks (Measurement | |||
| system can handle any way they choose; Report should mention if | System can handle any way they choose; Report should mention if | |||
| the Task overlapped with another) | the Task overlapped with another) | |||
| o Suppression: no defined impact on Passive Measurement Task; extra | o Suppression: no defined impact on Passive Measurement Task; extra | |||
| option to suppress on-going Active Measurement Tasks; suppression | option to suppress on-going Active Measurement Tasks; suppression | |||
| doesn't go to Measurement Peer, since they don't understand | doesn't go to Measurement Peer, since they don't understand | |||
| Instructions | Instructions | |||
| o new concept of Data Transfer Task (and therefore adjustment of the | o new concept of Data Transfer Task (and therefore adjustment of the | |||
| Channel concept) | Channel concept) | |||
| skipping to change at page 48, line 48 ¶ | skipping to change at page 55, line 5 ¶ | |||
| 11.8. From -07 to -08 | 11.8. From -07 to -08 | |||
| o Clarifications resulting from WG 3rd LC, as discussed in | o Clarifications resulting from WG 3rd LC, as discussed in | |||
| https://tools.ietf.org/agenda/90/slides/slides-90-lmap-0.pdf, plus | https://tools.ietf.org/agenda/90/slides/slides-90-lmap-0.pdf, plus | |||
| comments made in the IETF-90 meeting. | comments made in the IETF-90 meeting. | |||
| o added mention of "measurement point designations" in Measurement | o added mention of "measurement point designations" in Measurement | |||
| Task configuration and Report Protocol. | Task configuration and Report Protocol. | |||
| 11.9. From -08 to -09 | ||||
| o Clarifications and changes from the AD review (Benoit Claise) and | ||||
| security directorate review (Radia Perlman). | ||||
| 11.10. From -09 to -10 | ||||
| o More changes from the AD review (Benoit Claise). | ||||
| 11.11. From -10 to -11 | ||||
| o More changes from the AD review (Benoit Claise). | ||||
| 11.12. From -11 to -12 | ||||
| o Fixing nits from IETF Last call and authors. | ||||
| 11.13. From -12 to -13 | ||||
| o IESG changes. | ||||
| 11.14. From -13 to -14 | ||||
| o Fixing Figure 1. | ||||
| 12. Informative References | 12. Informative References | |||
| [Bur10] Burkhart, M., Schatzmann, D., Trammell, B., and E. Boschi, | [Bur10] Burkhart, M., Schatzmann, D., Trammell, B., and E. Boschi, | |||
| "The Role of Network Trace anonymisation Under Attack", | "The Role of Network Trace anonymisation Under Attack", | |||
| January 2010. | January 2010. | |||
| [TR-069] TR-069, , "CPE WAN Management Protocol", | [TR-069] TR-069, , "CPE WAN Management Protocol", | |||
| http://www.broadband-forum.org/technical/trlist.php, | http://www.broadband-forum.org/technical/trlist.php, | |||
| November 2013. | November 2013. | |||
| skipping to change at page 49, line 23 ¶ | skipping to change at page 56, line 5 ¶ | |||
| [RFC1035] Mockapetris, P., "Domain names - implementation and | [RFC1035] Mockapetris, P., "Domain names - implementation and | |||
| specification", STD 13, RFC 1035, November 1987. | specification", STD 13, RFC 1035, November 1987. | |||
| [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, | [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, | |||
| June 2005. | June 2005. | |||
| [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally | [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally | |||
| Unique IDentifier (UUID) URN Namespace", RFC 4122, July | Unique IDentifier (UUID) URN Namespace", RFC 4122, July | |||
| 2005. | 2005. | |||
| [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. | ||||
| Bierman, "Network Configuration Protocol (NETCONF)", RFC | ||||
| 6241, June 2011. | ||||
| [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of | ||||
| the IP Flow Information Export (IPFIX) Protocol for the | ||||
| Exchange of Flow Information", STD 77, RFC 7011, September | ||||
| 2013. | ||||
| [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, | ||||
| "IPv6 Home Networking Architecture Principles", RFC 7368, | ||||
| October 2014. | ||||
| [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an | ||||
| Attack", BCP 188, RFC 7258, May 2014. | ||||
| [I-D.ietf-lmap-use-cases] | [I-D.ietf-lmap-use-cases] | |||
| Linsner, M., Eardley, P., Burbridge, T., and F. Sorensen, | Linsner, M., Eardley, P., Burbridge, T., and F. Sorensen, | |||
| "Large-Scale Broadband Measurement Use Cases", draft-ietf- | "Large-Scale Broadband Measurement Use Cases", draft-ietf- | |||
| lmap-use-cases-03 (work in progress), April 2014. | lmap-use-cases-06 (work in progress), February 2015. | |||
| [I-D.manyfolks-ippm-metric-registry] | ||||
| Bagnulo, M., Claise, B., Eardley, P., and A. Morton, | ||||
| "Registry for Performance Metrics", draft-manyfolks-ippm- | ||||
| metric-registry-00 (work in progress), February 2014. | ||||
| [I-D.ietf-homenet-arch] | [I-D.ietf-ippm-metric-registry] | |||
| Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, | Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. | |||
| "IPv6 Home Networking Architecture Principles", draft- | Akhter, "Registry for Performance Metrics", draft-ietf- | |||
| ietf-homenet-arch-17 (work in progress), July 2014. | ippm-metric-registry-02 (work in progress), February 2015. | |||
| [RFC6419] Wasserman, M. and P. Seite, "Current Practices for | [RFC6419] Wasserman, M. and P. Seite, "Current Practices for | |||
| Multiple-Interface Hosts", RFC 6419, November 2011. | Multiple-Interface Hosts", RFC 6419, November 2011. | |||
| [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. | [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. | |||
| Selkirk, "Port Control Protocol (PCP)", RFC 6887, April | Selkirk, "Port Control Protocol (PCP)", RFC 6887, April | |||
| 2013. | 2013. | |||
| [I-D.ietf-lmap-information-model] | [I-D.ietf-lmap-information-model] | |||
| Burbridge, T., Eardley, P., Bagnulo, M., and J. | Burbridge, T., Eardley, P., Bagnulo, M., and J. | |||
| Schoenwaelder, "Information Model for Large-Scale | Schoenwaelder, "Information Model for Large-Scale | |||
| Measurement Platforms (LMAP)", draft-ietf-lmap- | Measurement Platforms (LMAP)", draft-ietf-lmap- | |||
| information-model-01 (work in progress), June 2014. | information-model-05 (work in progress), April 2015. | |||
| [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization | [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization | |||
| Support", RFC 6235, May 2011. | Support", RFC 6235, May 2011. | |||
| [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., | [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., | |||
| Morris, J., Hansen, M., and R. Smith, "Privacy | Morris, J., Hansen, M., and R. Smith, "Privacy | |||
| Considerations for Internet Protocols", RFC 6973, July | Considerations for Internet Protocols", RFC 6973, July | |||
| 2013. | 2013. | |||
| [I-D.ietf-ippm-lmap-path] | ||||
| Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and | ||||
| A. Morton, "A Reference Path and Measurement Points for | ||||
| LMAP", draft-ietf-ippm-lmap-path-05 (work in progress), | ||||
| August 2014. | ||||
| [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. | [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. | |||
| Zekauskas, "A One-way Active Measurement Protocol | Zekauskas, "A One-way Active Measurement Protocol | |||
| (OWAMP)", RFC 4656, September 2006. | (OWAMP)", RFC 4656, September 2006. | |||
| [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. | [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. | |||
| Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", | Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", | |||
| RFC 5357, October 2008. | RFC 5357, October 2008. | |||
| [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between | [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between | |||
| Information Models and Data Models", RFC 3444, January | Information Models and Data Models", RFC 3444, January | |||
| 2003. | 2003. | |||
| Appendix A. Appendix: Deployment examples | [RFC7398] Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and | |||
| A. Morton, "A Reference Path and Measurement Points for | ||||
| In this section we describe some deployment scenarios that are | Large-Scale Measurement of Broadband Performance", RFC | |||
| feasible within the LMAP framework defined in this document. | 7398, February 2015. | |||
| The LMAP framework defines two types of components involved in the | ||||
| actual measurement task, namely the Measurement Agent (MA) and the | ||||
| Measurement Peer (MP). The fundamental difference conveyed in the | ||||
| definition of these terms is that the MA has a interface with the | ||||
| Controller/Collector while the MP does not. The MP is broadly | ||||
| defined as a function that assists the MA in the Measurement Task but | ||||
| has no interface with the Controller/Collector. There are many | ||||
| elements in the network that can fall into this broad definition of | ||||
| MP. We believe that the MP terminology is useful to allow us to | ||||
| refer an element of the network that plays a role that is | ||||
| conceptually important to understand and describe the measurement | ||||
| task being performed. We next illustrate these concepts by | ||||
| describing several deployment scenarios. | ||||
| A very simple example of a Measurement Peer is a web server that the | ||||
| MA is downloading a web page from (such as www.example.com) in order | ||||
| to perform a speed test. The web server is a MP and from its | ||||
| perspective, the MA is just another client; the MP doesn't have a | ||||
| specific function for assisting measurements. This is described in | ||||
| the figure A1. | ||||
| ^ | ||||
| +----------------+ Web Traffic +----------------+ IPPM | ||||
| | Web Client |<------------>| MP: Web Server | Scope | ||||
| | | +----------------+ | | ||||
| ...|................|....................................V... | ||||
| | LMAP interface | ^ | ||||
| +----------------+ | | ||||
| ^ | | | ||||
| Instruction | | Report | | ||||
| | +-----------------+ | | ||||
| | | | | ||||
| | v LMAP | ||||
| +------------+ +------------+ Scope | ||||
| | Controller | | Collector | | | ||||
| +------------+ +------------+ V | ||||
| Figure A1: Schematic of LMAP-based measurement system, | ||||
| with Web server as Measurement Peer | ||||
| Another case that is slightly different than this would be the one of | ||||
| a TWAMP-responder. This is also a MP, with a helper function, the | ||||
| TWAMP server, which is specially deployed to assist the MAs that | ||||
| perform TWAMP tests. Another example is with a ping server, as | ||||
| described in Section 2. | ||||
| A further example is the case of a traceroute like measurement. In | ||||
| this case, for each packet sent, the router where the TTL expires is | ||||
| performing the MP function. So for a given Measurement Task, there | ||||
| is one MA involved and several MPs, one per hop. | ||||
| In figure A2 we depict the case of an OWAMP (One-Way Active | ||||
| Measurement Protocol) responder acting as an MP. In this case, the | ||||
| helper function in addition reports results back to the MA. So it | ||||
| has both a data plane and control interface with the MA. | ||||
| +----------------+ OWAMP +----------------+ ^ | ||||
| | OWAMP |<--control--->| MP: | | | ||||
| | control-client |>test-traffic>| OWAMP server & | IPPM | ||||
| | fetch-client & |<----fetch----| session-rec'ver| Scope | ||||
| | session-sender | | | | | ||||
| | | +----------------+ | | ||||
| ...|................|....................................v... | ||||
| | LMAP interface | ^ | ||||
| +----------------+ | | ||||
| ^ | | | ||||
| Instruction | | Report | | ||||
| | +-----------------+ | | ||||
| | | | | ||||
| | v LMAP | ||||
| +------------+ +------------+ Scope | ||||
| | Controller | | Collector | | | ||||
| +------------+ +------------+ v | ||||
| IPPM | ||||
| Figure A2: Schematic of LMAP-based measurement system, | ||||
| with OWAMP server as Measurement Peer | ||||
| However, it is also possible to use two Measurement Agents when | ||||
| performing one way Measurement Tasks, as described in figure A3 | ||||
| below. In this case, MA1 generates the traffic and MA2 receives the | ||||
| traffic and send the reports to the Collector. Note that both MAs | ||||
| are instructed by the Controller. MA1 receives an Instruction to | ||||
| send the traffic and MA2 receives an Instruction to measured the | ||||
| received traffic and send Reports to the Collector. | ||||
| +----------------+ +----------------+ ^ | ||||
| | MA1 | | MA2 | IPPM | ||||
| | iperf -u sender|-UDP traffic->| iperf -u recvr | Scope | ||||
| | | | | v | ||||
| ...|................|..............|................|....v... | ||||
| | LMAP interface | | LMAP interface | ^ | ||||
| +----------------+ +----------------+ | | ||||
| ^ ^ | | | ||||
| Instruction | Instruction{Report} | | Report | | ||||
| {task, | +-------------------+ | | | ||||
| schedule} | | | | | ||||
| | | v LMAP | ||||
| +------------+ +------------+ Scope | ||||
| | Controller | | Collector | | | ||||
| +------------+ +------------+ v | ||||
| IPPM | ||||
| Figure A3: Schematic of LMAP-based measurement system, | ||||
| with two Measurement Agents cooperating to measure UDP traffic | ||||
| Next, we consider Measurement Methods that measure user traffic. | ||||
| Traffic generated in one point in the network flowing towards a given | ||||
| destination and the traffic is observed in some point along the path. | ||||
| One way to implement this is that the endpoints generating and | ||||
| receiving the traffic are not instructed by the Controller; hence | ||||
| they are MPs. The MA is located along the path with a monitor | ||||
| function that measures the traffic. The MA is instructed by the | ||||
| Controller to monitor that particular traffic and to send the Report | ||||
| to the Collector. It is depicted in figure A4 below. | ||||
| +-----+ +----------------+ +------+ ^ | ||||
| | MP | | MA: Monitor | | MP | IPPM | ||||
| | |<--|----------------|---traffic--->| | Scope | ||||
| +-----+ | | +------+ | | ||||
| .......|................|.........................v........... | ||||
| | LMAP interface | ^ | ||||
| +----------------+ | | ||||
| ^ | | | ||||
| Instruction | | Report | | ||||
| | +-----------------+ | | ||||
| | | | | ||||
| | v LMAP | ||||
| +------------+ +------------+ Scope | ||||
| | Controller | | Collector | | | ||||
| +------------+ +------------+ v | ||||
| Figure A4: Schematic of LMAP-based measurement system, | ||||
| with a Measurement Agent monitoring traffic | ||||
| Finally, we should consider the case of a router or a switch along | ||||
| the measurement path. This certainly performs an important role in | ||||
| the measurement - if packets are not forwarded, the measurement task | ||||
| will not work. Whilst it doesn't has an interface with the | ||||
| Controller or Collector, and so fits into the definition of MP, | ||||
| usually it is not particularly useful to highlight it as a MP. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Philip Eardley | Philip Eardley | |||
| BT | BT | |||
| Adastral Park, Martlesham Heath | Adastral Park, Martlesham Heath | |||
| Ipswich | Ipswich | |||
| ENGLAND | ENGLAND | |||
| Email: philip.eardley@bt.com | Email: philip.eardley@bt.com | |||
| skipping to change at page 55, line 4 ¶ | skipping to change at page 57, line 39 ¶ | |||
| Email: philip.eardley@bt.com | Email: philip.eardley@bt.com | |||
| Al Morton | Al Morton | |||
| AT&T Labs | AT&T Labs | |||
| 200 Laurel Avenue South | 200 Laurel Avenue South | |||
| Middletown, NJ | Middletown, NJ | |||
| USA | USA | |||
| Email: acmorton@att.com | Email: acmorton@att.com | |||
| Marcelo Bagnulo | Marcelo Bagnulo | |||
| Universidad Carlos III de Madrid | Universidad Carlos III de Madrid | |||
| Av. Universidad 30 | Av. Universidad 30 | |||
| Leganes, Madrid 28911 | Leganes, Madrid 28911 | |||
| SPAIN | SPAIN | |||
| Phone: 34 91 6249500 | Phone: 34 91 6249500 | |||
| Email: marcelo@it.uc3m.es | Email: marcelo@it.uc3m.es | |||
| URI: http://www.it.uc3m.es | URI: http://www.it.uc3m.es | |||
| Trevor Burbridge | Trevor Burbridge | |||
| BT | BT | |||
| Adastral Park, Martlesham Heath | Adastral Park, Martlesham Heath | |||
| Ipswich | Ipswich | |||
| ENGLAND | ENGLAND | |||
| Email: trevor.burbridge@bt.com | Email: trevor.burbridge@bt.com | |||
| Paul Aitken | Paul Aitken | |||
| Cisco Systems, Inc. | Brocade | |||
| 96 Commercial Street | Edinburgh, Scotland | |||
| Edinburgh, Scotland EH6 6LX | ||||
| UK | UK | |||
| Email: paitken@cisco.com | Email: paitken@brocade.com | |||
| Aamer Akhter | Aamer Akhter | |||
| Cisco Systems, Inc. | Consultant | |||
| 7025 Kit Creek Road | 118 Timber Hitch | |||
| RTP, NC 27709 | Cary, NC | |||
| USA | USA | |||
| Email: aakhter@cisco.com | Email: aakhter@gmail.com | |||
| End of changes. 149 change blocks. | ||||
| 582 lines changed or deleted | 696 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||