draft-ietf-lmap-framework-09.txt   draft-ietf-lmap-framework-10.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: June 15, 2015 AT&T Labs Expires: July 18, 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 LiveAction
December 12, 2014 January 14, 2015
A framework for large-scale measurement platforms (LMAP) A framework for large-scale measurement platforms (LMAP)
draft-ietf-lmap-framework-09 draft-ietf-lmap-framework-10
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 platforms).
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 43
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 June 15, 2015. This Internet-Draft will expire on July 18, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 time . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 13 5. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Bootstrapping process . . . . . . . . . . . . . . . . . . 14 5.1. Bootstrapping process . . . . . . . . . . . . . . . . . . 14
5.2. Control Protocol . . . . . . . . . . . . . . . . . . . . 15 5.2. Control Protocol . . . . . . . . . . . . . . . . . . . . 15
5.2.1. Configuration . . . . . . . . . . . . . . . . . . . . 15 5.2.1. Configuration . . . . . . . . . . . . . . . . . . . . 15
5.2.2. Instruction . . . . . . . . . . . . . . . . . . . . . 16 5.2.2. Instruction . . . . . . . . . . . . . . . . . . . . . 16
5.2.3. Capabilities, Failure and Logging Information . . . . 19 5.2.3. Capabilities, Failure and Logging Information . . . . 20
5.3. Operation of Measurement Tasks . . . . . . . . . . . . . 21 5.3. Operation of Measurement Tasks . . . . . . . . . . . . . 21
5.3.1. Starting and Stopping Measurement Tasks . . . . . . . 21 5.3.1. Starting and Stopping Measurement Tasks . . . . . . . 22
5.3.2. Overlapping Measurement Tasks . . . . . . . . . . . . 22 5.3.2. Overlapping Measurement Tasks . . . . . . . . . . . . 23
5.4. Report Protocol . . . . . . . . . . . . . . . . . . . . . 23 5.4. Report Protocol . . . . . . . . . . . . . . . . . . . . . 23
5.4.1. Reporting of Subscriber's service parameters . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . 27 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 . . . . . . . 29 6.2.1. Measurement Agent on a networked device . . . . . . . 30
6.2.2. Measurement Agent embedded in site gateway . . . . . 29 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 . . . . . . . . . . . . 30 6.2.4. Multi-homed Measurement Agent . . . . . . . . . . . . 31
6.2.5. Measurement Agent embedded in ISP network . . . . . . 31 6.2.5. Measurement Agent embedded in ISP network . . . . . . 31
6.3. Measurement Peer . . . . . . . . . . . . . . . . . . . . 31 6.3. Measurement Peer . . . . . . . . . . . . . . . . . . . . 32
7. Security considerations . . . . . . . . . . . . . . . . . . . 31 7. Security considerations . . . . . . . . . . . . . . . . . . . 32
8. Privacy considerations . . . . . . . . . . . . . . . . . . . 33 8. Privacy considerations . . . . . . . . . . . . . . . . . . . 34
8.1. Categories of entities with information of interest . . . 34 8.1. Categories of entities with information of interest . . . 34
8.2. Examples of sensitive information . . . . . . . . . . . . 35 8.2. Examples of sensitive information . . . . . . . . . . . . 35
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 . . . . . . . . . . . . . . . . . . . 36
8.4. Privacy analysis of the communication models . . . . . . 36 8.4. Privacy analysis of the communication models . . . . . . 37
8.4.1. MA Bootstrapping . . . . . . . . . . . . . . . . . . 37 8.4.1. MA Bootstrapping . . . . . . . . . . . . . . . . . . 37
8.4.2. Controller <-> Measurement Agent . . . . . . . . . . 37 8.4.2. Controller <-> Measurement Agent . . . . . . . . . . 38
8.4.3. Collector <-> Measurement Agent . . . . . . . . . . . 38 8.4.3. Collector <-> Measurement Agent . . . . . . . . . . . 39
8.4.4. Measurement Peer <-> Measurement Agent . . . . . . . 38 8.4.4. Measurement Peer <-> Measurement Agent . . . . . . . 39
8.4.5. Measurement Agent . . . . . . . . . . . . . . . . . . 40 8.4.5. Measurement Agent . . . . . . . . . . . . . . . . . . 41
8.4.6. Storage and reporting of Measurement Results . . . . 41 8.4.6. Storage and reporting of Measurement Results . . . . 42
8.5. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.5. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.5.1. Surveillance . . . . . . . . . . . . . . . . . . . . 41 8.5.1. Surveillance . . . . . . . . . . . . . . . . . . . . 42
8.5.2. Stored data compromise . . . . . . . . . . . . . . . 41 8.5.2. Stored data compromise . . . . . . . . . . . . . . . 42
8.5.3. Correlation and identification . . . . . . . . . . . 42 8.5.3. Correlation and identification . . . . . . . . . . . 43
8.5.4. Secondary use and disclosure . . . . . . . . . . . . 42 8.5.4. Secondary use and disclosure . . . . . . . . . . . . 43
8.6. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 43 8.6. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 44
8.6.1. Data minimisation . . . . . . . . . . . . . . . . . . 43 8.6.1. Data minimisation . . . . . . . . . . . . . . . . . . 44
8.6.2. Anonymity . . . . . . . . . . . . . . . . . . . . . . 44 8.6.2. Anonymity . . . . . . . . . . . . . . . . . . . . . . 45
8.6.3. Pseudonymity . . . . . . . . . . . . . . . . . . . . 45 8.6.3. Pseudonymity . . . . . . . . . . . . . . . . . . . . 46
8.6.4. Other mitigations . . . . . . . . . . . . . . . . . . 45 8.6.4. Other mitigations . . . . . . . . . . . . . . . . . . 46
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 46 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 47
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
11. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 11. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
11.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . 46 11.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . 47
11.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . 47 11.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . 48
11.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . 48 11.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . 49
11.4. From -03 to -04 . . . . . . . . . . . . . . . . . . . . 48 11.4. From -03 to -04 . . . . . . . . . . . . . . . . . . . . 49
11.5. From -04 to -05 . . . . . . . . . . . . . . . . . . . . 49 11.5. From -04 to -05 . . . . . . . . . . . . . . . . . . . . 50
11.6. From -05 to -06 . . . . . . . . . . . . . . . . . . . . 50 11.6. From -05 to -06 . . . . . . . . . . . . . . . . . . . . 51
11.7. From -06 to -07 . . . . . . . . . . . . . . . . . . . . 50 11.7. From -06 to -07 . . . . . . . . . . . . . . . . . . . . 51
11.8. From -07 to -08 . . . . . . . . . . . . . . . . . . . . 50 11.8. From -07 to -08 . . . . . . . . . . . . . . . . . . . . 51
11.9. From -08 to -09 . . . . . . . . . . . . . . . . . . . . 50 11.9. From -08 to -09 . . . . . . . . . . . . . . . . . . . . 51
12. Informative References . . . . . . . . . . . . . . . . . . . 50 11.10. From -09 to -10 . . . . . . . . . . . . . . . . . . . . 51
Appendix A. Appendix: Deployment examples . . . . . . . . . . . 52 12. Informative References . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 Appendix A. Appendix: Deployment examples . . . . . . . . . . . 54
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 diverse devices. These devices could be software based
agents on PCs, embedded agents in consumer devices (such as TVs or agents on PCs, embedded agents in consumer devices (such as TVs or
gaming consoles), service provider controlled devices such as set-top gaming consoles), service provider controlled devices such as set-top
boxes and home gateways, or simply dedicated probes. It is expected boxes and home gateways, or simply dedicated probes. It is expected
that such a system could easily comprise 100,000 devices. that such a system could easily comprise 100,000 devices.
skipping to change at page 6, line 37 skipping to change at page 6, line 37
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.ietf-ippm-metric-registry] so that a for commonly-used Metrics [I-D.ietf-ippm-metric-registry] so that a
Metric with its associated Measurement Method can be referred to Metric with its associated Measurement Method can be referred to
simply by its identifier in the registry. The registry will simply by its identifier in the registry. The registry will
hopefully be referenced by other standards organisations. The hopefully be referenced by other standards organisations. The
Measurement Methods may be defined by the IETF, locally, or by some Measurement Methods may be defined by the IETF, locally, or by some
other standards body. 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). are out of the scope of initial LMAP work, and fall within the scope
of other IETF WGs such as IPPM (IP Performance Metrics).
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
skipping to change at page 12, line 17 skipping to change at page 12, line 17
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. It runs over the Report Channel. Agent to a Collector. It runs over the Report Channel.
skipping to change at page 16, line 47 skipping to change at page 17, line 13
be defined by the IETF [I-D.ietf-ippm-metric-registry], locally be defined by the IETF [I-D.ietf-ippm-metric-registry], locally
by the operator of the Measurement System or perhaps by another by the operator of the Measurement System or perhaps by another
standards organisation. standards organisation.
* 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 (figure A3
in the Appendix) an iperf sender and receiver. Each Metric and in the Appendix) an iperf sender and receiver. Each Metric and
its associated Measurement Method will describe all measurement its 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
[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.
skipping to change at page 18, line 16 skipping to change at page 18, line 29
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 main The Instruction may include Suppression information. The main
motivation for Suppression is to enable the Measurement System to motivation for Suppression is to enable the Measurement System to
eliminate Measurement Traffic, because there is some unexpected eliminate Measurement Traffic, because there is some unexpected
network issue for example. There may be other circumstances when network issue for example. There may be other circumstances when
Suppression is useful, for example to eliminate inessential Reporting Suppression is useful, for example to eliminate inessential Reporting
traffic. 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 with Measurement Task is overloading a Measurement Peer with
Measurement Traffic. 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 29, line 4 skipping to change at page 29, line 30
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, Paris), 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. The correct interpretation depends on why interpret missing Results. The correct interpretation depends on why
the Results are missing, and potentially on the specifics of the the Results are missing (perhaps related to measurement suppression
Measurement Task and Measurement Schedule. or delayed Report submission), and potentially on the specifics of
the Measurement Task and Measurement Schedule. For example, the set
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- 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 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 stale. In the former case it also needs to ensure that its clock has
re-set correctly, so that it interprets the Schedule correctly. re-set correctly, so that it interprets the Schedule correctly.
If the MA runs out of storage space for Measurement Results or can't If the MA runs out of storage space for Measurement Results or can't
contact the Controller, then the appropriate action is specific to contact the Controller, then the appropriate action is specific to
skipping to change at page 50, line 46 skipping to change at page 51, line 46
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 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
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 13 skipping to change at page 53, line 22
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-02 (work in progress), August 2014. information-model-03 (work in progress), January 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] [I-D.ietf-ippm-lmap-path]
skipping to change at page 57, line 23 skipping to change at page 58, line 23
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 EH6 6LX Edinburgh, Scotland EH6 6LX
UK UK
Email: paitken@cisco.com Email: paitken@brocade.com
Aamer Akhter Aamer Akhter
Cisco Systems, Inc. LiveAction
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. 28 change blocks. 
82 lines changed or deleted 109 lines changed or added

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