draft-ietf-lmap-framework-10.txt   draft-ietf-lmap-framework-11.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: July 18, 2015 AT&T Labs Expires: August 26, 2015 AT&T Labs
M. Bagnulo M. Bagnulo
UC3M UC3M
T. Burbridge T. Burbridge
BT BT
P. Aitken P. Aitken
Brocade Brocade
A. Akhter A. Akhter
LiveAction LiveAction
January 14, 2015 February 22, 2015
A framework for large-scale measurement platforms (LMAP) A framework for Large-Scale Measurement of Broadband Performance (LMAP)
draft-ietf-lmap-framework-10 draft-ietf-lmap-framework-11
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 July 18, 2015. This Internet-Draft will expire on August 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 46 skipping to change at page 2, line 51
5.5. Operation of LMAP over the underlying packet transfer 5.5. Operation of LMAP over the underlying packet transfer
mechanism . . . . . . . . . . . . . . . . . . . . . . . . 25 mechanism . . . . . . . . . . . . . . . . . . . . . . . . 25
5.6. Items beyond the scope of the initial LMAP work . . . . . 26 5.6. Items beyond the scope of the initial LMAP work . . . . . 26
5.6.1. End-user-controlled measurement system . . . . . . . 28 5.6.1. End-user-controlled measurement system . . . . . . . 28
6. Deployment considerations . . . . . . . . . . . . . . . . . . 28 6. Deployment considerations . . . . . . . . . . . . . . . . . . 28
6.1. Controller and the measurement system . . . . . . . . . . 28 6.1. Controller and the measurement system . . . . . . . . . . 28
6.2. Measurement Agent . . . . . . . . . . . . . . . . . . . . 29 6.2. Measurement Agent . . . . . . . . . . . . . . . . . . . . 29
6.2.1. Measurement Agent on a networked device . . . . . . . 30 6.2.1. Measurement Agent on a networked device . . . . . . . 30
6.2.2. Measurement Agent embedded in site gateway . . . . . 30 6.2.2. Measurement Agent embedded in site gateway . . . . . 30
6.2.3. Measurement Agent embedded behind site NAT /firewall 30 6.2.3. Measurement Agent embedded behind site NAT /firewall 30
6.2.4. Multi-homed Measurement Agent . . . . . . . . . . . . 31 6.2.4. Multi-homed Measurement Agent . . . . . . . . . . . . 30
6.2.5. Measurement Agent embedded in ISP network . . . . . . 31 6.2.5. Measurement Agent embedded in ISP network . . . . . . 31
6.3. Measurement Peer . . . . . . . . . . . . . . . . . . . . 32
7. Security considerations . . . . . . . . . . . . . . . . . . . 32 6.3. Measurement Peer . . . . . . . . . . . . . . . . . . . . 31
8. Privacy considerations . . . . . . . . . . . . . . . . . . . 34 6.4. Deployment examples . . . . . . . . . . . . . . . . . . . 32
8.1. Categories of entities with information of interest . . . 34 7. Security considerations . . . . . . . . . . . . . . . . . . . 35
8.2. Examples of sensitive information . . . . . . . . . . . . 35 8. Privacy considerations . . . . . . . . . . . . . . . . . . . 37
8.1. Categories of entities with information of interest . . . 37
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 . . . . . . . . . . . . . . . . . . . 36 Measurement Methods . . . . . . . . . . . . . . . . . . . 39
8.4. Privacy analysis of the communication models . . . . . . 37 8.4. Privacy analysis of the communication models . . . . . . 40
8.4.1. MA Bootstrapping . . . . . . . . . . . . . . . . . . 37 8.4.1. MA Bootstrapping . . . . . . . . . . . . . . . . . . 40
8.4.2. Controller <-> Measurement Agent . . . . . . . . . . 38 8.4.2. Controller <-> Measurement Agent . . . . . . . . . . 41
8.4.3. Collector <-> Measurement Agent . . . . . . . . . . . 39 8.4.3. Collector <-> Measurement Agent . . . . . . . . . . . 42
8.4.4. Measurement Peer <-> Measurement Agent . . . . . . . 39 8.4.4. Measurement Peer <-> Measurement Agent . . . . . . . 42
8.4.5. Measurement Agent . . . . . . . . . . . . . . . . . . 41 8.4.5. Measurement Agent . . . . . . . . . . . . . . . . . . 44
8.4.6. Storage and reporting of Measurement Results . . . . 42 8.4.6. Storage and reporting of Measurement Results . . . . 45
8.5. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.5. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.5.1. Surveillance . . . . . . . . . . . . . . . . . . . . 42 8.5.1. Surveillance . . . . . . . . . . . . . . . . . . . . 45
8.5.2. Stored data compromise . . . . . . . . . . . . . . . 42 8.5.2. Stored data compromise . . . . . . . . . . . . . . . 45
8.5.3. Correlation and identification . . . . . . . . . . . 43 8.5.3. Correlation and identification . . . . . . . . . . . 46
8.5.4. Secondary use and disclosure . . . . . . . . . . . . 43 8.5.4. Secondary use and disclosure . . . . . . . . . . . . 46
8.6. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 44 8.6. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 47
8.6.1. Data minimisation . . . . . . . . . . . . . . . . . . 44 8.6.1. Data minimisation . . . . . . . . . . . . . . . . . . 47
8.6.2. Anonymity . . . . . . . . . . . . . . . . . . . . . . 45 8.6.2. Anonymity . . . . . . . . . . . . . . . . . . . . . . 48
8.6.3. Pseudonymity . . . . . . . . . . . . . . . . . . . . 46 8.6.3. Pseudonymity . . . . . . . . . . . . . . . . . . . . 49
8.6.4. Other mitigations . . . . . . . . . . . . . . . . . . 46 8.6.4. Other mitigations . . . . . . . . . . . . . . . . . . 49
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 47 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 50
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
11. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 11. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . 47 11.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . 50
11.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . 48 11.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . 51
11.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . 49 11.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . 52
11.4. From -03 to -04 . . . . . . . . . . . . . . . . . . . . 49 11.4. From -03 to -04 . . . . . . . . . . . . . . . . . . . . 52
11.5. From -04 to -05 . . . . . . . . . . . . . . . . . . . . 50 11.5. From -04 to -05 . . . . . . . . . . . . . . . . . . . . 53
11.6. From -05 to -06 . . . . . . . . . . . . . . . . . . . . 51 11.6. From -05 to -06 . . . . . . . . . . . . . . . . . . . . 54
11.7. From -06 to -07 . . . . . . . . . . . . . . . . . . . . 51 11.7. From -06 to -07 . . . . . . . . . . . . . . . . . . . . 54
11.8. From -07 to -08 . . . . . . . . . . . . . . . . . . . . 51 11.8. From -07 to -08 . . . . . . . . . . . . . . . . . . . . 54
11.9. From -08 to -09 . . . . . . . . . . . . . . . . . . . . 51 11.9. From -08 to -09 . . . . . . . . . . . . . . . . . . . . 54
11.10. From -09 to -10 . . . . . . . . . . . . . . . . . . . . 51 11.10. From -09 to -10 . . . . . . . . . . . . . . . . . . . . 54
12. Informative References . . . . . . . . . . . . . . . . . . . 52 11.11. From -10 to -11 . . . . . . . . . . . . . . . . . . . . 55
Appendix A. Appendix: Deployment examples . . . . . . . . . . . 54 12. Informative References . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 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 (such as TVs or based agents on PCs, embedded agents in consumer devices (such as TVs
gaming consoles), service provider controlled devices such as set-top or gaming consoles), embedded in service provider controlled devices
boxes and home gateways, or simply dedicated probes. It is expected such as set-top boxes and home gateways, or simply dedicated probes.
that such a system could easily comprise 100,000 devices. MAs may also be embedded on a device that is part of an ISP's
Measurement devices may also be embedded on a device that is part of network, such as a DSLAM (Digital Subscriber Line Access
an ISP's 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 5, line 42 skipping to change at page 5, line 51
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.
Figure 1 shows the main components of a Measurement System, and the Figure 1 shows the main components of a Measurement System, and the
interactions of those components. Some of the components are outside interactions of those components. Some of the components are outside
the scope of initial LMAP work. the scope of initial LMAP work.
The MA performs Measurement Tasks. In the example shown in Figure 1, The MA performs Measurement Tasks. In the example shown in Figure 1,
the MA is observing existing traffic. Another possibility is for the the MA is observing existing traffic. Another possibility is for the
MA may generate (or receive) traffic specially created for the MA to generate (or receive) traffic specially created for the purpose
purpose and measure some metric associated with its transfer. The and measure some metric associated with its transfer. The
Appendix shows some examples of possible arrangements of the Appendix shows some examples of possible arrangements of the
components. components.
The MAs are pieces of code that can be executed in specialised The MAs are pieces of code that can be executed in specialised
hardware (hardware probe) or on a general-purpose device (like a PC hardware (hardware probe) or on a general-purpose device (like a PC
or mobile phone). A device with a Measurement Agent may have or mobile phone). A device with a Measurement Agent may have
multiple physical interfaces (Wi-Fi, Ethernet, DSL (Digital multiple physical interfaces (Wi-Fi, Ethernet, DSL (Digital
Subscriber Line); and non-physical interfaces such as PPPoE (Point- Subscriber Line); and non-physical interfaces such as PPPoE (Point-
to-Point Protocol over Ethernet) or IPsec) and the Measurement Tasks to-Point Protocol over Ethernet) or IPsec) and the Measurement Tasks
may specify any one of these. may specify any one of these.
skipping to change at page 7, line 20 skipping to change at page 7, line 28
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. As shown in Figure 1, these components are: the to perform. As shown in Figure 1, these components are: the
bootstrapper, Subscriber parameter database, data analysis tools, and bootstrapper, Subscriber parameter database, data analysis tools, and
Results repository. Results repository.
The MA needs to be bootstrapped with initial details about its The MA needs to be bootstrapped with initial details about its
skipping to change at page 8, line 8 skipping to change at page 8, line 17
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 or| |End user or| | |End user or| |End user or| |
|Measurement| |Measurement| Non-LMAP |Measurement| |Measurement| Non-LMAP
| Peer | | Peer | Scope | Peer | | Peer | Scope
+-----------+ +-----------+ v +-----------+ +-----------+ v
^ ^ ^ Observed ^ ^
\ traffic +-------------+ / ^ \ traffic flow +-------------+ / / ^
\...............|.............|........./ | \...............|.............|..../ / |
| Measurement | | | Measurement |........../ |
+----------------->| Agent | | +----------------->| Agent | Measurement traffic |
| +-------------+ | | +-------------+ |
| ^ | | | ^ | |
| Instruction | | Report | | Instruction | | Report |
| (over Control | | (over Control Channel) | | (over Control | | (over Report Channel) |
| Channel) | +---------------+ | | Channel) | +---------------+ |
| | | | | | | |
| | | | | | |
| | v LMAP | | v LMAP
| +------------+ +------------+ Scope | +------------+ +------------+ Scope
| | Controller | | Collector | | | | Controller | | Collector | |
| +------------+ +------------+ v | +------------+ +------------+ v
| ^ ^ | ^ | ^ ^ | ^
| | | | | | | | | |
| | +-------+ | | | | +-------+ | |
| | | v | | | | v |
+------------+ +----------+ +--------+ +----------+ | +------------+ +----------+ +--------+ +----------+ |
|Bootstrapper| |Subscriber|--->| data |<---| Results | Out |Bootstrapper| |Subscriber|--->| data |<---| Results | Out
+------------+ |parameter | |analysis| |repository| of +------------+ |parameter | |analysis| |repository| of
|database | | tools | +----------+ Scope |database | | tools | +----------+ Scope
+----------+ +--------+ | +----------+ +--------+ |
| |
v 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.
skipping to change at page 16, line 33 skipping to change at page 16, line 33
+-----------------+ +-------------+ +-----------------+ +-------------+
| | | Measurement | | | | Measurement |
| Controller |===================================| Agent | | Controller |===================================| Agent |
+-----------------+ +-------------+ +-----------------+ +-------------+
Instruction: -> Instruction: ->
[(Measurement Task configuration [(Measurement Task configuration
URI of Metric( URI of Metric(
[Input Parameter], [Input Parameter],
(Role)
(interface), (interface),
(Cycle-ID))), (Cycle-ID)
(measurement point)),
(Report Channel), (Report Channel),
(Schedule), (Schedule),
(Suppression information)] (Suppression information)]
<- Response(details) <- 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:
skipping to change at page 17, line 40 skipping to change at page 17, line 41
[I-D.ietf-ippm-lmap-path] of the MA and, if applicable, of the [I-D.ietf-ippm-lmap-path] of the MA and, if applicable, of the
MP or other MA. This can be useful for reporting. MP or other MA. This can be 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
skipping to change at page 20, line 39 skipping to change at page 20, line 39
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 25, line 40 skipping to change at page 25, line 40
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 [RFC6241] and Control and Report Protocols, for example NETCONF-YANG [RFC6241] and
IPFIX (Internet Protocol Flow Information Export) [RFC7011] IPFIX (Internet Protocol Flow Information Export) [RFC7011]
respectively. respectively.
skipping to change at page 28, line 40 skipping to change at page 28, line 40
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.
skipping to change at page 32, line 28 skipping to change at page 32, line 20
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 A1.
^
+----------------+ Web Traffic +----------------+ non-LMAP
|MA: Web Client |<------------>| MP: Web Server | Scope
| | +----------------+ |
...|................|....................................V...
| LMAP interface | ^
+----------------+ |
^ | |
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 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 +----------------+ ^
| MA: OWAMP |<--control--->| MP: | |
| control-client |-test-traffic>| OWAMP server & | non-LMAP
| fetch-client & |<----fetch----| session-rec'ver| Scope
| session-sender | | | |
| | +----------------+ |
...|................|....................................v...
| LMAP interface | ^
+----------------+ |
^ | |
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 figure A3
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.
+----------------+ +----------------+ ^
| MA-1: | | MA-2: | non-LMAP
| 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
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 figure A4 below.
+--------+ +----------------+ +--------+ ^
|End user| | MA: Monitor | Observed |End user| |
| or MP |<--|----------------|--traffic-->| or MP | non-LMAP
| | | | flow | | Scope
+--------+ | | +--------+ |
...|................|............................v..
| LMAP interface | ^
+----------------+ |
^ | |
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
skipping to change at page 36, line 46 skipping to change at page 39, line 46
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 addressed similar issues (see section 11.8 of [RFC7011]).
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
skipping to change at page 52, line 5 skipping to change at page 55, line 5
11.9. From -08 to -09 11.9. From -08 to -09
o Clarifications and changes from the AD review (Benoit Claise) and o Clarifications and changes from the AD review (Benoit Claise) and
security directorate review (Radia Perlman). security directorate review (Radia Perlman).
11.10. From -09 to -10 11.10. From -09 to -10
o More changes from the AD review (Benoit Claise). o More changes from the AD review (Benoit Claise).
11.11. From -10 to -11
o More changes from the AD review (Benoit Claise).
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 52, line 48 skipping to change at page 55, line 52
[RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"IPv6 Home Networking Architecture Principles", RFC 7368, "IPv6 Home Networking Architecture Principles", RFC 7368,
October 2014. October 2014.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, May 2014. 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-05 (work in progress), November 2014. lmap-use-cases-06 (work in progress), February 2015.
[I-D.ietf-ippm-metric-registry] [I-D.ietf-ippm-metric-registry]
Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
Akhter, "Registry for Performance Metrics", draft-ietf- Akhter, "Registry for Performance Metrics", draft-ietf-
ippm-metric-registry-01 (work in progress), September ippm-metric-registry-02 (work in progress), February 2015.
2014.
[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.
skipping to change at page 54, line 5 skipping to change at page 57, line 5
(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
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 A1.
^
+----------------+ Web Traffic +----------------+ non-LMAP
|MA: 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 +----------------+ ^
| MA: OWAMP |<--control--->| MP: | |
| control-client |-test-traffic>| OWAMP server & | non-LMAP
| fetch-client & |<----fetch----| session-rec'ver| Scope
| session-sender | | | |
| | +----------------+ |
...|................|....................................v...
| LMAP interface | ^
+----------------+ |
^ | |
Instruction | | Report |
| +-----------------+ |
| | |
| v LMAP
+------------+ +------------+ Scope
| Controller | | Collector | |
+------------+ +------------+ v
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. 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.
+----------------+ +----------------+ ^
| MA-1: | | MA-2: | non-LMAP
| 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
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.
+--------+ +----------------+ +--------+ ^
|End user| | MA: Monitor | |End user| |
| or MP |<--|----------------|--traffic-->| or MP | non-LMAP
| | | | | | 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
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
 End of changes. 30 change blocks. 
219 lines changed or deleted 226 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/