GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7594

Internet Engineering Task Force (IETF) P. Eardley Request for Comments: 7594 BT Category: Informational A. Morton ISSN: 2070-1721 AT&T Labs

                                                            M. Bagnulo
                                                                  UC3M
                                                          T. Burbridge
                                                                    BT
                                                             P. Aitken
                                                               Brocade
                                                             A. Akhter
                                                            Consultant
                                                        September 2015

A Framework for Large-Scale Measurement of Broadband Performance (LMAP)

Abstract

 Measuring broadband service on a large scale requires a description
 of the logical architecture and standardisation of the key protocols
 that coordinate interactions between the components.  This document
 presents an overall framework for large-scale measurements.  It also
 defines terminology for LMAP (Large-Scale Measurement of Broadband
 Performance).

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7594.

Eardley, et al. Informational [Page 1] RFC 7594 LMAP Framework September 2015

Copyright Notice

 Copyright (c) 2015 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
 2.  Outline of an LMAP-Based Measurement System . . . . . . . . .   5
 3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   9
 4.  Constraints . . . . . . . . . . . . . . . . . . . . . . . . .  12
   4.1.  The Measurement System Is Under the Direction of a Single
         Organisation  . . . . . . . . . . . . . . . . . . . . . .  13
   4.2.  Each MA May Only Have a Single Controller at Any Point in
         Time  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
 5.  Protocol Model  . . . . . . . . . . . . . . . . . . . . . . .  13
   5.1.  Bootstrapping Process . . . . . . . . . . . . . . . . . .  14
   5.2.  Control Protocol  . . . . . . . . . . . . . . . . . . . .  15
     5.2.1.  Configuration . . . . . . . . . . . . . . . . . . . .  15
     5.2.2.  Instruction . . . . . . . . . . . . . . . . . . . . .  16
     5.2.3.  Capabilities, Failure, and Logging Information  . . .  20
   5.3.  Operation of Measurement Tasks  . . . . . . . . . . . . .  22
     5.3.1.  Starting and Stopping Measurement Tasks . . . . . . .  22
     5.3.2.  Overlapping Measurement Tasks . . . . . . . . . . . .  24
   5.4.  Report Protocol . . . . . . . . . . . . . . . . . . . . .  24
     5.4.1.  Reporting of the Subscriber's Service Parameters  . .  26
   5.5.  Operation of LMAP over the Underlying Packet Transfer
         Mechanism . . . . . . . . . . . . . . . . . . . . . . . .  26
   5.6.  Items beyond the Scope of the Initial LMAP Work . . . . .  27
     5.6.1.  End-User-Controlled Measurement System  . . . . . . .  28
 6.  Deployment Considerations . . . . . . . . . . . . . . . . . .  29
   6.1.  Controller and the Measurement System . . . . . . . . . .  29
   6.2.  Measurement Agent . . . . . . . . . . . . . . . . . . . .  30
     6.2.1.  Measurement Agent on a Networked Device . . . . . . .  30
     6.2.2.  Measurement Agent Embedded in a Site Gateway  . . . .  31
     6.2.3.  Measurement Agent Embedded behind a Site NAT or
             Firewall  . . . . . . . . . . . . . . . . . . . . . .  31

Eardley, et al. Informational [Page 2] RFC 7594 LMAP Framework September 2015

     6.2.4.  Multihomed Measurement Agent  . . . . . . . . . . . .  31
     6.2.5.  Measurement Agent Embedded in an ISP Network  . . . .  32
   6.3.  Measurement Peer  . . . . . . . . . . . . . . . . . . . .  32
   6.4.  Deployment Examples . . . . . . . . . . . . . . . . . . .  33
 7.  Security Considerations . . . . . . . . . . . . . . . . . . .  36
 8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  38
   8.1.  Categories of Entities with Information of Interest . . .  38
   8.2.  Examples of Sensitive Information . . . . . . . . . . . .  39
   8.3.  Different Privacy Issues Raised by Different Sorts of
         Measurement Methods . . . . . . . . . . . . . . . . . . .  40
   8.4.  Privacy Analysis of the Communication Models  . . . . . .  41
     8.4.1.  MA Bootstrapping  . . . . . . . . . . . . . . . . . .  41
     8.4.2.  Controller <-> Measurement Agent  . . . . . . . . . .  42
     8.4.3.  Collector <-> Measurement Agent . . . . . . . . . . .  43
     8.4.4.  Measurement Peer <-> Measurement Agent  . . . . . . .  43
     8.4.5.  Measurement Agent . . . . . . . . . . . . . . . . . .  45
     8.4.6.  Storage and Reporting of Measurement Results  . . . .  46
   8.5.  Threats . . . . . . . . . . . . . . . . . . . . . . . . .  46
     8.5.1.  Surveillance  . . . . . . . . . . . . . . . . . . . .  46
     8.5.2.  Stored Data Compromise  . . . . . . . . . . . . . . .  47
     8.5.3.  Correlation and Identification  . . . . . . . . . . .  47
     8.5.4.  Secondary Use and Disclosure  . . . . . . . . . . . .  48
   8.6.  Mitigations . . . . . . . . . . . . . . . . . . . . . . .  48
     8.6.1.  Data Minimisation . . . . . . . . . . . . . . . . . .  48
     8.6.2.  Anonymity . . . . . . . . . . . . . . . . . . . . . .  49
     8.6.3.  Pseudonymity  . . . . . . . . . . . . . . . . . . . .  50
     8.6.4.  Other Mitigations . . . . . . . . . . . . . . . . . .  50
 9.  Informative References  . . . . . . . . . . . . . . . . . . .  51
 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  54
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  54

1. Introduction

 There is a desire to be able to coordinate the execution of broadband
 measurements and the collection of measurement results across a large
 scale set of Measurement Agents (MAs).  These MAs could be
 software-based agents on PCs, embedded agents in consumer devices
 (such as TVs or gaming consoles), embedded in service-provider-
 controlled devices such as set-top boxes and home gateways, or simply
 dedicated probes.  MAs may also be embedded on a device that is part
 of an ISP's network, such as a DSLAM (Digital Subscriber Line Access
 Multiplexer), router, Carrier Grade NAT (Network Address Translator),
 or ISP Gateway.  It is expected that a measurement system could
 easily encompass a few hundred thousand or even millions of such MAs.
 Such a scale presents unique problems in coordination, execution, and
 measurement result collection.  Several use cases have been proposed
 for large-scale measurements including:

Eardley, et al. Informational [Page 3] RFC 7594 LMAP Framework September 2015

 o  Operators: to help plan their network and identify faults
 o  Regulators: to benchmark several network operators and support
    public policy development
 Further details of the use cases can be found in [RFC7536].  The LMAP
 framework should be useful for these, as well as other use cases,
 such as to help end users run diagnostic checks like a network speed
 test.
 The LMAP framework has three basic elements: Measurement Agents,
 Controllers, and Collectors.
 Measurement Agents (MAs) initiate the actual measurements, which are
 called Measurement Tasks in the LMAP terminology.  In principle,
 there are no restrictions on the type of device in which the MA
 function resides.
 The Controller instructs one or more MAs and communicates the set of
 Measurement Tasks an MA should perform and when.  For example, it may
 instruct an MA at a home gateway: "Measure the 'UDP latency' with
 www.example.org; repeat every hour at xx.05".  The Controller also
 manages an MA by instructing it on how to report the Measurement
 Results, for example: "Report results once a day in a batch at 4am".
 We refer to these as the Measurement Schedule and Report Schedule.
 The Collector accepts Reports from the MAs with the Results from
 their Measurement Tasks.  Therefore, the MA is a device that gets
 Instructions from the Controller, initiates the Measurement Tasks,
 and reports to the Collector.  The communications between these three
 LMAP functions are structured according to a Control Protocol and a
 Report Protocol.
 The design goals are the following large-scale Measurement System
 features:
 o  Standardised - in terms of the Measurement Tasks that they
    perform, the components, the data models, and the protocols for
    transferring information between the components.  Amongst other
    things, standardisation enables meaningful comparisons of
    measurements made of the same Metric at different times and
    places, and provides the operator of a Measurement System with
    criteria for evaluation of the different solutions that can be
    used for various purposes including buying decisions (such as
    buying the various components from different vendors).  Today's
    systems are proprietary in some or all of these aspects.

Eardley, et al. Informational [Page 4] RFC 7594 LMAP Framework September 2015

 o  Large-scale - [RFC7536] envisages Measurement Agents in every home
    gateway and edge device such as set-top boxes and tablet
    computers, and located throughout the Internet as well [RFC7398].
    It is expected that a Measurement System could easily encompass a
    few hundred thousand or even millions of Measurement Agents.
    Existing systems have up to a few thousand MAs (without judging
    how much further they could scale).
 o  Diversity - a Measurement System should handle Measurement Agents
    from different vendors that are in wired and wireless networks,
    can execute different sorts of Measurement Tasks, are on devices
    with IPv4 or IPv6 addresses, and so on.
 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

 In this section, we provide an overview of the whole Measurement
 System.  New LMAP-specific terms are capitalised; Section 3 provides
 a terminology section with a compilation of all the LMAP terms and
 their definitions.  Section 4 onwards considers the LMAP components
 in more detail.
 Other LMAP specifications will define an Information Model, the
 associated Data Models, and select/extend one or more protocols for
 the secure communication: firstly, a Control Protocol, for a
 Controller to instruct Measurement Agents regarding which performance
 Metrics to measure, when to measure them, and how/when to report the
 measurement results to a Collector; secondly, a Report Protocol, for
 a Measurement Agent to report the results to the Collector.
 Figure 1 shows the main components of a Measurement System, and the
 interactions of those components.  Some of the components are outside
 the scope of initial LMAP work.
 The MA performs Measurement Tasks.  One possibility is that the MA
 observes existing traffic.  Another possibility is for the MA to
 generate (or receive) traffic specially created for the purpose and
 measure some Metric associated with its transfer.  Figure 1 includes
 both possibilities (in practice, it may be more usual for an 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

Eardley, et al. Informational [Page 5] RFC 7594 LMAP Framework September 2015

 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 an MA through use of the Control Protocol,
 which transfers the Instruction to the MA.  This describes the
 Measurement Tasks the MA should perform and when.  For example the
 Controller may instruct an MA at a home gateway: "Count the number of
 TCP SYN packets observed in a 1 minute interval; repeat every hour at
 xx.05 + Unif[0,180] seconds".  The Measurement Schedule determines
 when the Measurement Tasks are executed.  The Controller also manages
 an MA by instructing it on how to report the Measurement Results, for
 example: "Report results once a day in a batch at 4am + Unif[0,180]
 seconds; if the end user is active then delay the report 5 minutes."
 The Report Schedule determines when the Reports are uploaded to the
 Collector.  The Measurement Schedule and Report Schedule can define
 one-off (non-recurring) actions (for example, "Do measurement now",
 "Report as soon as possible"), as well as recurring ones.
 The Collector accepts a Report from an MA with the Measurement
 Results from its Measurement Tasks.  It then provides the Results to
 a repository.
 A Measurement Method defines how to measure a Metric of interest.  It
 is very useful to standardise Measurement Methods, so that it is
 meaningful to compare measurements of the same Metric made at
 different times and places.  It is also useful to define a registry
 for commonly used Metrics [IPPM-REG] so that a Metric and its
 associated Measurement Method can be referred to simply by its
 identifier in the registry.  The registry will hopefully be
 referenced by other standards organisations.  The Measurement Methods
 may be defined by the IETF, locally, or by some other standards body.
 Broadly speaking there are two types of Measurement Methods.  In both
 types, a Measurement Agent measures a particular Observed Traffic
 Flow.  It may involve a single MA simply observing existing traffic
 -- for example, the Measurement Agent could count bytes or calculate
 the average loss for a particular flow.  On the other hand, a
 Measurement Method may observe traffic created specifically for the
 purpose of measurement.  This requires multiple network entities,
 which perform different roles.  For example, to measure the round
 trip delay one possible Measurement Method would consist of an MA
 sending an ICMP (Internet Control Message Protocol) ECHO request
 ("ping") to a responder in the Internet.  In LMAP terms, the
 responder is termed a Measurement Peer (MP), meaning that it helps
 the MA but is not managed by the Controller.  Other Measurement
 Methods involve a second MA, with the Controller instructing the MAs
 in a coordinated manner.  Traffic generated specifically as part of

Eardley, et al. Informational [Page 6] RFC 7594 LMAP Framework September 2015

 the Measurement Method is termed Measurement Traffic; in the ping
 example, it is the ICMP ECHO Requests and Replies.  The protocols
 used for the Measurement Traffic 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
 particular time, as the specific instance of its role in a
 Measurement Method.  LMAP is mainly concerned with Measurement Tasks,
 for instance in terms of its Information Model and Protocols.
 For Measurement Results to be truly comparable, as might be required
 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
 follow a similar Measurement Schedule and be of similar number.  The
 details of such a characterisation plan are beyond the scope of IETF
 work, although it is certainly facilitated by the IETF's work.
 Both control and report messages are transferred over a secure
 Channel.  A Control Channel is between the Controller and an MA; the
 Control Protocol delivers Instruction Messages to the MA and
 Capabilities, Failure, and Logging Information in the reverse
 direction.  A Report Channel is between an MA and Collector, and the
 Report Protocol delivers Reports to the Collector.
 Finally, we introduce several components that are outside the scope
 of initial LMAP work that will be provided through existing protocols
 or applications.  They affect how the Measurement System uses the
 Measurement Results and how it decides what set of Measurement Tasks
 to perform.  As shown in Figure 1, 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
 Controller, including authentication credentials.  The LMAP work
 considers the Bootstrap process, since it affects the Information
 Model.  However, LMAP does not define a Bootstrap protocol, since it
 is likely to be technology specific and could be defined by the
 Broadband Forum, CableLabs, or IEEE depending on the device.
 Possible protocols are SNMP (Simple Network Management Protocol),
 NETCONF (Network Configuration Protocol), or (for Home Gateways) CPE
 WAN Management Protocol (CWMP) from the Auto Configuration Server
 (ACS) (as specified in TR-069 [TR-069]).
 A Subscriber parameter database contains information about the line,
 such as the customer's broadband contract (perhaps 2, 40, or 80
 Mb/s), the line technology (DSL or fibre), the time zone in which the
 MA is located, and the type of home gateway and MA.  These parameters

Eardley, et al. Informational [Page 7] RFC 7594 LMAP Framework September 2015

 are already gathered and stored by existing operations systems.  They
 may affect the choice of what Measurement Tasks to run and how to
 interpret the Measurement Results.  For example, a download test
 suitable for a line with an 80 Mb/s contract may overwhelm a 2 Mb/s
 line.
 A Results repository records all Measurement Results in an equivalent
 form, for example an SQL (Structured Query Language) database, so
 that they can easily be accessed by the data analysis tools.
 The data analysis tools receive the results from the Collector or via
 the Results repository.  They might visualise the data or identify
 which component or link is likely to be the cause of a fault or
 degradation.  This information could help the Controller decide what
 follow-up Measurement Task to perform in order to diagnose a fault.
 The data analysis tools also need to understand the Subscriber's
 service information, for example, the broadband contract.

Eardley, et al. Informational [Page 8] RFC 7594 LMAP Framework September 2015

   +--------+      +-----------+              +-----------+      ^
   |End user|      |           |   Observed   | End user  |      |
   |        |<-----|-----------|---Traffic--->|           |      |
   |        |      |           |   Flow       |           |      |
   |        |      |           |              |           |   Non-LMAP
   |        |      |           | Measurement  |           |    Scope
   |        |      |           |<--Traffic--->|           |      |
   +--------+      |           |              +-----------+      |
   ................|...........|.................................V
      <MP>         |Measurement|                  <MP>           ^
                   |Agent:     |                                 |
                   |LMAP       |                                 |
      +----------->|interface  |                                 |
      |            +-----------+                                 |
      |                ^    |                                   LMAP
      |    Instruction |    |  Report                          Scope
      |  (over Control |    | (over Report Channel)              |
      |     Channel)   |    +-----------------------+            |
      |                |                            |            |
      |                |                            |            |
      |                |                            v            |
      |          +------------+               +------------+     |
      |          | Controller |               |  Collector |     |
      |          +------------+               +------------+     v
      |                ^      ^                     |            ^
      |                |      |                     |            |
      |                |      +--------+            |            |
      |                |               |            v            |
   +------------+   +----------+    +--------+    +----------+   |
   |Bootstrapper|   |Subscriber|--->|  data  |<---| Results  |  Non-
   +------------+   |parameter |    |analysis|    |repository|  LMAP
                    |database  |    | tools  |    +----------+ Scope
                    +----------+    +--------+                   |
                                                                 |
                                                                 v
   MP: Measurement Peer
   Figure 1: Schematic of main elements of an LMAP-based Measurement
 System (showing the elements in and out of the scope of initial LMAP
                                 work)

3. Terminology

 This section defines terminology for LMAP.  Please note that defined
 terms are capitalised throughout.

Eardley, et al. Informational [Page 9] RFC 7594 LMAP Framework September 2015

 Bootstrap: A process that integrates a Measurement Agent into a
 Measurement System.
 Capabilities: Information about the performance measurement
 capabilities of the MA, in particular the Measurement Method roles
 and measurement protocol roles that it can perform, and the device
 hosting the MA, for example its interface type and speed, but not
 dynamic information.
 Channel: A bidirectional logical connection that is defined by a
 specific Controller and MA, or Collector and MA, plus associated
 security.
 Collector: A function that receives a Report from an MA.
 Configuration: A process for informing the MA about its MA-ID,
 (optional) Group-ID, and Control Channel.
 Controller: A function that provides a Measurement Agent with its
 Instruction.
 Control Channel: A Channel between a Controller and an MA over which
 Instruction Messages and Capabilities, Failure, and Logging
 Information are sent.
 Control Protocol: The protocol delivering Instruction(s) from a
 Controller to a Measurement Agent.  It also delivers Capabilities,
 Failure, and Logging Information from the Measurement Agent to the
 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
 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
 Input Parameters.  Hence, the Cycle-ID allows the Collector to easily
 identify Measurement Results that should be comparable.
 Data Model: The implementation of an Information Model in a
 particular data modelling language [RFC3444].
 Environmental Constraint: A parameter that is measured as part of the
 Measurement Task, its value determining whether the rest of the
 Measurement Task proceeds.
 Failure Information: Information about the MA's failure to take
 action or execute an Instruction, whether concerning Measurement
 Tasks or Reporting.

Eardley, et al. Informational [Page 10] RFC 7594 LMAP Framework September 2015

 Group-ID: An identifier of a group of MAs.
 Information Model: The protocol-neutral definition of the semantics
 of the Instructions, the Report, the status of the different elements
 of the Measurement System, as well of the events in the system
 [RFC3444].
 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
 Measurement Task.  Altering the value of an Input Parameter does not
 change the fundamental nature of the Measurement Task.
 Instruction: The description of Measurement Tasks for an MA to
 perform and the details of the Report for it to send.  It is the
 collective description of the Measurement Task configurations, the
 configuration of the Measurement Schedules, the configuration of the
 Report Channel(s), the configuration of Report Schedule(s), and the
 details of any Suppression.
 Instruction Message: The message that carries an Instruction from a
 Controller to a Measurement Agent.
 Logging Information: Information about the operation of the
 Measurement Agent, which may be useful for debugging.
 Measurement Agent (MA): The function that receives Instruction
 Messages from a Controller and operates the Instruction by executing
 Measurement Tasks (using protocols outside the scope of the initial
 LMAP work and perhaps in concert with one or more other Measurement
 Agents or Measurement Peers) and (if part of the Instruction) by
 reporting Measurement Results to a Collector or Collectors.
 Measurement Agent Identifier (MA-ID): a Universally Unique IDentifier
 [RFC4122] that identifies a particular MA and is configured as part
 of the Bootstrapping process.
 Measurement Method: The process for assessing the value of a Metric;
 the process of measuring some performance or reliability Metric
 associated with the transfer of traffic.
 Measurement Peer (MP): The function that assists a Measurement Agent
 with Measurement Tasks and does not have an interface to the
 Controller or Collector.
 Measurement Result: The output of a single Measurement Task (the
 value obtained for the Metric).
 Measurement Schedule: The schedule for performing Measurement Tasks.

Eardley, et al. Informational [Page 11] RFC 7594 LMAP Framework September 2015

 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
 Agent that consists of the single assessment of a Metric through
 operation of a Measurement Method role at a particular time, with all
 of the role's Input Parameters set to specific values.
 Measurement Traffic: the packet(s) generated by some types of
 Measurement Method that involve measuring some parameter associated
 with the transfer of the packet(s).
 Metric: The quantity related to the performance and reliability of
 the network that we'd like to know the value of.
 Observed Traffic Flow: In RFC 7011 [RFC7011], 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 summarised and tabulated in
 Measurement Results (as opposed to raw capture and export).
 Report: The set of Measurement Results and other associated
 information (as defined by the Instruction).  The Report is sent by a
 Measurement Agent to a Collector.
 Report Channel: A Channel between a Collector and an MA over which
 Report messages are sent.
 Report Protocol: The protocol delivering Report(s) from a Measurement
 Agent to a Collector.  It runs over the Report Channel.
 Report Schedule: The schedule for sending Reports to a Collector.
 Subscriber: An entity (associated with one or more users) that is
 engaged in a subscription with a service provider.
 Suppression: The temporary cessation of Measurement Tasks.

4. Constraints

 The LMAP framework makes some important assumptions, which constrain
 the scope of the initial LMAP work.

Eardley, et al. Informational [Page 12] RFC 7594 LMAP Framework September 2015

4.1. The Measurement System Is Under the Direction of a Single

    Organisation
 In the LMAP framework, the Measurement System is under the direction
 of a single organisation that is responsible for any impact that its
 measurements have on a user's quality of experience and privacy.
 Clear responsibility is critical given that a misbehaving large-scale
 Measurement System could potentially harm user experience, user
 privacy, and network security.
 However, the components of an LMAP Measurement System can be deployed
 in administrative domains that are not owned by the measuring
 organisation.  Thus, the system of functions deployed by a single
 organisation constitutes a single LMAP domain, which may span
 ownership or other administrative boundaries.

4.2. Each MA May Only Have a Single Controller at Any Point in Time

 An MA is instructed by one Controller and is in one Measurement
 System.  The constraint avoids different Controllers giving an MA
 conflicting instructions and so means that the MA does not have to
 manage contention between multiple Measurement (or Report) Schedules.
 This simplifies the design of MAs (critical for a large-scale
 infrastructure) and allows a Measurement Schedule to be tested on
 specific types of MAs before deployment to ensure that the end-user
 experience is not impacted (due to CPU, memory, or broadband-product
 constraints).  However, a Measurement System may have several
 Controllers.

5. Protocol Model

 A protocol model [RFC4101] presents an architectural model for how
 the protocol operates and needs to answer three basic questions:
 1.  What problem is the protocol trying to address?
 2.  What messages are being transmitted and what do they mean?
 3.  What are the important, but not obvious [sic], features of the
     protocol?
 An LMAP system goes through the following phases:
 o  a Bootstrapping process before the MA can take part in the other
    three phases.
 o  a Control Protocol, which delivers Instruction Messages from a
    Controller to an MA (amongst other things).

Eardley, et al. Informational [Page 13] RFC 7594 LMAP Framework September 2015

 o  the actual Measurement Tasks, which measure some performance or
    reliability Metric(s) associated with the transfer of packets.
 o  a Report Protocol, which delivers Reports containing the
    Measurement Results from an MA to a Collector.
 The figures show the various LMAP messages and use the following
 conventions:
 o  (optional): indicated by round brackets
 o  [potentially repeated]: indicated by square brackets
 The protocol model is closely related to the Information Model
 [LMAP-INFO], which is the abstract definition of the information
 carried by the protocol.  (If there is any difference between this
 document and the Information Model, the latter is definitive.)  The
 purpose of both is to provide a protocol and device-independent view,
 which can be implemented via specific protocols.  LMAP defines a
 specific Control Protocol and Report Protocol, but others could be
 defined by other standards bodies or be proprietary.  However, it is
 important that they all implement the same Information Model and
 protocol model, in order to ease the definition, operation, and
 interoperability of large-scale Measurement Systems.

5.1. Bootstrapping Process

 The primary purpose of Bootstrapping is to enable an MA to be
 integrated into a Measurement System.  The MA retrieves information
 about itself (like its identity in the Measurement System) and about
 the Controller, the Controller learns information about the MA, and
 they learn about security information to communicate (such as
 certificates and credentials).
 Whilst this memo considers the Bootstrapping process, it is beyond
 the scope of initial LMAP work to define a Bootstrap mechanism, as it
 depends on the type of device and access.
 As a result of the Bootstrapping process, the MA learns the following
 information ([LMAP-INFO] defines the consequent list of information
 elements):
 o  its identifier, either its MA-ID or a device identifier such as
    one of its Media Access Control (MAC) addresses or both.
 o  (optionally) a Group-ID, shared by several MAs and could be useful
    for privacy reasons.  For instance, reporting the Group-ID and not
    the MA-ID could hinder tracking of a mobile device.

Eardley, et al. Informational [Page 14] RFC 7594 LMAP Framework September 2015

 o  the Control Channel, which is defined by:
  • the address that identifies the Control Channel, such as the

Controller's FQDN (Fully Qualified Domain Name) [RFC1035]).

  • security information (for example, to enable the MA to decrypt

the Instruction Message and encrypt messages sent to the

       Controller).
 The details of the Bootstrapping process are device/access specific.
 For example, the information could be in the firmware, manually
 configured, or transferred via a protocol like that described in
 TR-069 [TR-069].  There may be a multi-stage process where the MA
 contacts a 'hard-coded' address, which replies with the Bootstrapping
 information.
 The MA must learn its MA-ID before getting an Instruction, either
 during Bootstrapping or via Configuration (Section 5.2.1).

5.2. Control Protocol

 The primary purpose of the Control Protocol is to allow the
 Controller to configure a Measurement Agent with an Instruction about
 what Measurement Tasks to do, when to do them, and how to report the
 Measurement Results (Section 5.2.2).  The Measurement Agent then acts
 on the Instruction autonomously.  The Control Protocol also enables
 the MA to inform the Controller about its Capabilities and any
 Failure and Logging Information (Section 5.2.3).  Finally, the
 Control Protocol allows the Controller to update the MA's
 Configuration.

5.2.1. Configuration

 Configuration allows the Controller to update the MA about some or
 all of the information that it obtained during the Bootstrapping
 process: the MA-ID, the (optional) Group-ID, and the Control Channel.
 Figure 2 outlines the Configuration process.  The Measurement System
 might use Configuration for several reasons.  For example, the
 Bootstrapping process could 'hard code' the MA with details of an
 initial Controller, and then the initial Controller could configure
 the MA with details about the Controller that sends Instruction
 Messages.  (Note that an MA only has one Control Channel, so it is
 associated with only one Controller, at any moment.)
 Note that an implementation may choose to combine Configuration
 information and an Instruction Message into a single message.

Eardley, et al. Informational [Page 15] RFC 7594 LMAP Framework September 2015

 +-----------------+                                   +-------------+
 |                 |                                   | Measurement |
 |  Controller     |===================================|  Agent      |
 +-----------------+                                   +-------------+
 Configuration information:               ->
 (MA-ID),
 (Group-ID),
 (Control Channel)
                                          <-        Response(details)
 MA: Measurement Agent
                  Figure 2: Outline of Configuration

5.2.2. Instruction

 The Instruction is the description of the Measurement Tasks for a
 Measurement Agent to do and the details of the Measurement Reports
 for it to send.  Figure 3 outlines the Instruction process.  In order
 to update the Instruction, the Controller uses the Control Protocol
 to send an Instruction Message over the Control Channel.
 +-----------------+                                   +-------------+
 |                 |                                   | Measurement |
 |  Controller     |===================================|  Agent      |
 +-----------------+                                   +-------------+
 Instruction:                            ->
 [(Measurement Task configuration
     URI of Metric(
    [Input Parameter],
    (role)
    (interface),
    (Cycle-ID)
    (measurement point)),
  (Report Channel),
  (Schedule),
  (Suppression information)]
                                         <-         Response(details)
                   Figure 3: Outline of Instruction

Eardley, et al. Informational [Page 16] RFC 7594 LMAP Framework September 2015

 The Instruction defines the following information ([LMAP-INFO]
 defines the consequent list of information elements):
 o  the Measurement Task configurations, each of which needs:
  • the Metric, specified as a URI to a registry entry; it includes

the specification of a Measurement Method. The registry could

       be defined by a standards organisation or locally by the
       operator of the Measurement System.  Note that, at the time of
       writing, the IETF is working on such a registry specification
       [IPPM-REG].
  • the Measurement Method role. For some Measurement Methods,

different parties play different roles; for example, an iperf

       sender and receiver (see Section 6.4).  Each Metric and its
       associated Measurement Method will describe all measurement
       roles involved in the process.
  • a boolean flag (suppress or do-not-suppress) indicating if such

a Measurement Task is impacted by a Suppression message (see

       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

Measurement Method. For example, the address of a Measurement

       Peer (or other Measurement Agent) that may be involved in a
       Measurement Task, or traffic filters associated with the
       Observed Traffic Flow.
  • the interface to use (if not defined, then the default

interface is used), if the device with the MA has multiple

       interfaces.
  • optionally, a Cycle-ID.
  • optionally, the measurement point designation [RFC7398] of the

MA and, if applicable, of the MP or other MA. This can be

       useful for reporting.
 o  configuration of the Schedules, each of which needs:
  • the timing of when the Measurement Tasks are to be performed or

the Measurement Reports are to be sent. Possible types of

       timing are periodic, calendar-based periodic, one-off
       immediate, and one-off at a future time.

Eardley, et al. Informational [Page 17] RFC 7594 LMAP Framework September 2015

 o  configuration of the Report Channel(s), each of which needs:
  • the address of the Collector, for instance its URL.
  • security for this Report Channel, for example, the X.509

certificate.

 o  Suppression information, if any (see Section 5.2.2.1).
 A single Instruction Message may contain some or all of the above
 parts.  The finest level of granularity possible in an Instruction
 Message is determined by the implementation and operation of the
 Control Protocol.  For example, a single Instruction Message may add
 or update an individual Measurement Schedule -- or it may only update
 the complete set of Measurement Schedules; a single Instruction
 Message may update both Measurement Schedules and Measurement Task
 configurations -- or only one at a time; and so on.  However,
 Suppression information always replaces (rather than adds to) any
 previous Suppression information.
 The MA informs the Controller that it has successfully understood the
 Instruction Message, or that it cannot take action on the Instruction
 -- for example, if it doesn't include a parameter that is mandatory
 for the requested Metric and Measurement Method, or if it is missing
 details of the target Collector.
 The Instruction Message instructs the MA; the Control Protocol does
 not allow the MA to negotiate, as this would add complexity to the
 MA, Controller, and Control Protocol for little benefit.

5.2.2.1. Suppression

 The Instruction may include Suppression information.  The main
 motivation for Suppression is to enable the Measurement System to
 eliminate Measurement Traffic, because there is some unexpected
 network issue, for example.  There may be other circumstances when
 Suppression is useful, for example, to eliminate inessential
 Reporting traffic (even if there is no Measurement Traffic).
 Figure 4 outlines the Suppression process.
 The Suppression information may include any of the following optional
 fields:
 o  a set of Measurement Tasks to suppress; the others are not
    suppressed.  For example, this could be useful if a particular
    Measurement Task is overloading a Measurement Peer with
    Measurement Traffic.

Eardley, et al. Informational [Page 18] RFC 7594 LMAP Framework September 2015

 o  a set of Measurement Schedules to suppress; the others are not
    suppressed.  For example, suppose the Measurement System has
    defined two Schedules, one with the most critical Measurement
    Tasks and the other with less critical ones that create a lot of
    Measurement Traffic, in which case it may only want to suppress
    the second.
 o  a set of Reporting Schedules to suppress; the others are not
    suppressed.  This can be particularly useful in the case of a
    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
    Measurement Tasks nor a set of Measurement Schedules, then the MA
    does not begin new Measurement Tasks that have the boolean flag
    set to suppress; however, the MA does begin new Measurement Tasks
    that have the flag set to do-not-suppress.
 o  a start time, at which Suppression begins.  If absent, then
    Suppression begins immediately.
 o  an end time, at which Suppression ends.  If absent, then
    Suppression continues until the MA receives an Un-suppress
    message.
 o  a demand that the MA immediately end on-going Measurement Task(s)
    that are tagged for Suppression.  (Most likely it is appropriate
    to delete the associated partial Measurement Result(s).)  This
    could be useful in the case of a network emergency so that the
    operator can eliminate all inessential traffic as rapidly as
    possible.  If absent, the MA completes on-going Measurement Tasks.
 An Un-suppress message instructs the MA to no longer suppress,
 meaning that the MA once again begins new Measurement Tasks,
 according to its Measurement Schedule.
 Note that Suppression is not intended to permanently stop a
 Measurement Task (instead, the Controller should send a new
 Measurement Schedule), nor to permanently disable an MA (instead,
 some kind of management action is suggested).

Eardley, et al. Informational [Page 19] RFC 7594 LMAP Framework September 2015

 +-----------------+                              +-------------+
 |                 |                              | Measurement |
 |  Controller     |==============================|  Agent      |
 +-----------------+                              +-------------+
 Suppress:
 [(Measurement Task),                  ->
  (Measurement Schedule),
  (start time),
  (end time),
  (on-going suppressed?)]
 Un-suppress                           ->
                   Figure 4: Outline of Suppression

5.2.3. Capabilities, Failure, and Logging Information

 The Control Protocol also enables the MA to inform the Controller
 about various information, such as its Capabilities and any Failures.
 Figure 5 outlines the process for Capabilities, Failure, and Logging
 Information.  It is also possible to use a device-specific mechanism,
 which is beyond the scope of the initial LMAP work.
 Capabilities are information about the MA that the Controller needs
 to know in order to correctly instruct the MA, such as:
 o  the Measurement Method (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 version of the MA.
 o  the version of the hardware, firmware, or software of the device
    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,
    or battery life of the device with the MA.

Eardley, et al. Informational [Page 20] RFC 7594 LMAP Framework September 2015

 Failure Information concerns why the MA has been unable to execute a
 Measurement Task or deliver a Report, for example:
 o  the Measurement Task failed to run properly because the MA
    (unexpectedly) has no spare CPU cycles.
 o  the MA failed to record the Measurement Results because it
    (unexpectedly) is out of spare memory.
 o  a Report failed to deliver Measurement Results because the
    Collector (unexpectedly) is not responding.
 o  but not if a Measurement Task correctly doesn't start.  For
    example, the first step of some Measurement Methods is for the MA
    to check that there is no cross-traffic.
 Logging Information concerns how the MA is operating and may help
 debugging, for example:
 o  the last time the MA ran a Measurement Task.
 o  the last time the MA sent a Measurement Report.
 o  the last time the MA received an Instruction Message.
 o  whether the MA is currently suppressing Measurement Tasks.
 Capabilities, Failure, and Logging Information are sent by the MA,
 either in response to a request from the Controller (for example, if
 the Controller forgets what the MA can do or otherwise wants to
 resynchronise what it knows about the MA), or on its own initiative
 (for example, when the MA first communicates with a Controller or if
 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
 should notify its Controller in case its Instruction needs to be
 updated; to avoid a "mass calling event" after a widespread power
 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.

Eardley, et al. Informational [Page 21] RFC 7594 LMAP Framework September 2015

 +-----------------+                                  +-------------+
 |                 |                                  | Measurement |
 |  Controller     |==================================|  Agent      |
 +-----------------+                                  +-------------+
     (Request Capabilities),
     (Request Failure Information),
     (Request Logging Information),
     (Request Instruction)                ->
                                          <-           (Capabilities),
                                                (Failure Information),
                                                (Logging Information),
                                                        (Instruction)
  Figure 5: Outline of Capabilities, Failure, and Logging Information

5.3. Operation of Measurement Tasks

 This LMAP framework is neutral to what the actual Measurement Task
 is.  It does not define Metrics and Measurement Methods; these are
 defined elsewhere.
 The MA carries out the Measurement Tasks as instructed, unless it
 gets an updated Instruction.  The MA acts autonomously, in terms of
 operation of the Measurement Tasks and reporting of the Results; it
 doesn't do a 'safety check' with the Controller to ask whether it
 should still continue with the requested Measurement Tasks.
 The MA may operate Measurement Tasks sequentially or in parallel (see
 Section 5.3.2).

5.3.1. Starting and Stopping Measurement Tasks

 This LMAP framework does not define a generic start and stop process,
 since the correct approach depends on the particular Measurement
 Task; the details are defined as part of each Measurement Method.
 This section provides some general hints.  The MA does not inform the
 Controller about Measurement Tasks starting and stopping.
 Before beginning a Measurement Task, the MA may want to run a
 pre-check.  (The pre-check could be defined as a separate, preceding
 Task 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.

Eardley, et al. Informational [Page 22] RFC 7594 LMAP Framework September 2015

 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 resources
    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
    check that the end-user isn't already sending traffic.
 o  the MA checking with the Measurement Peer (or other Measurement
    Agent) involved in the Measurement Task that it can handle a new
    Measurement Task.  For example, the Measurement Peer may already
    be handling many Measurement Tasks with other MAs.
 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
    execute the Measurement Task reliably.
 Similar checks may continue during the Measurement Task, in
 particular for a Measurement Task that is long-running and/or creates
 a lot of Measurement Traffic.  If, for example, the check detects
 that the end-user has started sending traffic, then the Measurement
 Task can be abandoned.  A Measurement Task could also be abandoned in
 response to a "suppress" message (see Section 5.2.2.1).  Action could
 include:
 o  for 'upload' tests, the MA not sending traffic.
 o  for 'download' tests, the MA closing the TCP connection or sending
    a TWAMP (Two-Way Active Measurement Protocol) Stop-Sessions
    command [RFC5357].
 The Controller may want an MA to run the same Measurement Task
 indefinitely (for example, "run the 'upload speed' Measurement Task
 once an hour until further notice").  To prevent the MA continuously
 generating traffic after a Controller has permanently failed (or
 communications with the Controller have failed), the MA can be
 configured with a time limit; if the MA doesn't hear from the
 Controller for this length of time, then it stops operating
 Measurement Tasks.

Eardley, et al. Informational [Page 23] RFC 7594 LMAP Framework September 2015

5.3.2. Overlapping Measurement Tasks

 An MA may start a new Measurement Task before another Measurement
 Task has completed.  This may be intentional (the way that the
 Measurement System has designed the Measurement Schedules), but it
 could also be unintentional -- for instance, if a Measurement Task
 has a 'wait for X' step that pauses for an unexpectedly long time.
 This document makes no assumptions about the impact of one
 Measurement Task on another.
 The operator of the Measurement System can handle (or not)
 overlapping Measurement Tasks in any way they choose -- it is a
 policy or implementation issue and not the concern of LMAP.  Some
 possible approaches are: to configure the MA to not begin the second
 Measurement Task; to start the second Measurement Task as usual; for
 the action to be an Input Parameter of the Measurement Task; and so
 on.
 It may be important for the Measurement Report to include the fact
 that the Measurement Tasks overlapped.

5.4. Report Protocol

 The primary purpose of the Report Protocol is to allow a Measurement
 Agent to report its Measurement Results to a Collector, along with
 the context in which they were obtained.  Figure 6 outlines the
 Report process.
 +-----------------+                                  +-------------+
 |                 |                                  | Measurement |
 |   Collector     |==================================|  Agent      |
 +-----------------+                                  +-------------+
                                   <-    Report:
                                                [MA-ID &/or Group-ID],
                                                 [Measurement Result],
                                        [details of Measurement Task],
                                                           (Cycle-ID)
 ACK                               ->
 MA: Measurement Agent
                    Figure 6: Outline of the Report
 The Report contains:
 o  the MA-ID or a Group-ID (to anonymise results).

Eardley, et al. Informational [Page 24] RFC 7594 LMAP Framework September 2015

 o  the actual Measurement Results, including the time they were
    measured.  In general, the time is simply the MA's best estimate
    and there is no guarantee on the accuracy or granularity of the
    information.  It is possible that some specific analysis of a
    particular Measurement Method's Results will impose timing
    requirements.
 o  the details of the Measurement Task (to avoid the Collector having
    to ask the Controller for this information later), for example,
    the interface used for the measurements.
 o  the Cycle-ID, if one was included in the Instruction.
 o  perhaps the Subscriber's service parameters (see Section 5.4.1).
 o  the measurement point designation of the MA and, if applicable,
    the MP or other MA, if the information was included in the
    Instruction.  This numbering system is defined in [RFC7398] and
    allows a Measurement Report to describe the path measured
    abstractly (for example, "from a measurement agent at a home
    gateway to a measurement peer at a DSLAM").  Also, the MA can
    anonymise results by including measurement point designations
    instead of IP addresses (Section 8.6.2).
 The MA sends Reports as defined by the Instruction.  The Instruction
 may tell the MA to report the same Results to more than one
 Collector, or to report a different subset of Results to different
 Collectors.  Also, a Measurement Task may create two (or more)
 Measurement Results, which could be reported differently (for
 example, one Result could be reported periodically, 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 reported
 immediately).
 Optionally, a Report is not sent when there are no Measurement
 Results.
 In the initial LMAP Information Model and Report Protocol, for
 simplicity we assume that all Measurement Results are reported as-is,
 but allow extensibility so that a Measurement System (or perhaps a
 second phase of LMAP) could allow an MA to:
 o  label, or perhaps not include, Measurement Results impacted by,
    for instance, cross-traffic or a Measurement Peer (or other
    Measurement Agent) being busy.
 o  label Measurement Results obtained by a Measurement Task that
    overlapped with another.

Eardley, et al. Informational [Page 25] RFC 7594 LMAP Framework September 2015

 o  not report the Measurement Results if the MA believes that they
    are invalid.
 o  detail when Suppression started and ended.
 As discussed in Section 6.1, data analysis of the Results should
 carefully consider potential bias from any Measurement Results that
 are not reported, or from Measurement Results that are reported but
 may be invalid.

5.4.1. Reporting of the Subscriber's Service Parameters

 The Subscriber's service parameters are information about his/her
 broadband contract, line rate and so on.  Such information is likely
 to be needed to help analyse the Measurement Results, for example to
 help decide whether the measured download speed is reasonable.
 The information could be transferred directly from the Subscriber
 parameter database to the data analysis tools.  If the Subscriber's
 service parameters are available to the MAs, they could be reported
 with the Measurement Results in the Report Protocol.  How (and if)
 the MA knows such information is likely to depend on the device type.
 The MA could either include the information in a Measurement Report
 or separately.

5.5. Operation of LMAP over the Underlying Packet Transfer Mechanism

 The above sections have described LMAP's protocol model.  Other
 specifications will define the actual Control and Report Protocols,
 possibly operating over an existing protocol, such as REST-style
 [REST] HTTP(S).  It is also possible that a different choice is made
 for the Control and Report Protocols, for example NETCONF-YANG
 [RFC6241] and IPFIX (Internet Protocol Flow Information Export)
 [RFC7011], respectively.
 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
 re-sent as it may have failed to be delivered.  Similarly the MA
 needs to know about the delivery of Capabilities, Failure, and
 Logging Information to the Controller and Reports to the Collector.
 How this is done depends on the design of the Control and Report
 Protocols and the underlying packet transfer mechanism.
 For the Control Protocol, the underlying packet transfer mechanism
 could be:
 o  a 'push' protocol (that is, from the Controller to the MA).

Eardley, et al. Informational [Page 26] RFC 7594 LMAP Framework September 2015

 o  a multicast protocol (from the Controller to a group of MAs).
 o  a 'pull' protocol.  The MA periodically checks with Controller if
    the Instruction has changed and pulls a new Instruction if
    necessary.  A pull protocol seems attractive for an MA behind a
    NAT or firewall (as is typical for an MA on an end-user's device)
    so that it can initiate the communications.  It also seems
    attractive for an MA on a mobile device, where the Controller
    might not know how to reach the MA.  A pull mechanism is likely to
    require that the MA 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
    can also push an alert to the MA that it should immediately pull a
    new Instruction.
 For the Report Protocol, the underlying packet transfer mechanism
 could be:
 o  a 'push' protocol (that is, from the MA to the Collector)
 o  perhaps supplemented by the ability for the Collector to 'pull'
    Measurement Results from an MA.

5.6. Items beyond the Scope of the Initial LMAP Work

 There are several potential interactions between LMAP elements that
 are beyond the scope of the initial LMAP work, which are as follows:
 1.  It does not define a coordination process between MAs.  Whilst a
     Measurement System may define coordinated Measurement Schedules
     across its various MAs, there is no direct coordination between
     MAs.
 2.  It does not define interactions between the Collector and
     Controller.  It is quite likely that there will be such
     interactions, optionally intermediated by the data analysis
     tools.  For example, if there is an "interesting" Measurement
     Result, then the Measurement System may want to trigger extra
     Measurement Tasks that explore the potential cause in more
     detail; or if the Collector unexpectedly does not hear from an
     MA, then the Measurement System may want to trigger the
     Controller to send a fresh Instruction Message to the MA.

Eardley, et al. Informational [Page 27] RFC 7594 LMAP Framework September 2015

 3.  It does not define coordination between different Measurement
     Systems.  For example, it does not define the interaction of an
     MA in one Measurement System with a Controller or Collector in a
     different Measurement System.  Whilst it is likely that the
     Control and Report Protocols could be re-used or adapted for this
     scenario, any form of coordination between different
     organisations involves difficult commercial and technical issues
     and so, given the novelty of large-scale measurement efforts, any
     form of inter-organisation coordination is outside the scope of
     the initial LMAP work.  Note that a single MA is instructed by a
     single Controller and is only in one Measurement System.
  • An interesting scenario is where a home contains two

independent MAs, for example one controlled by a regulator and

        one controlled by an ISP.  Then the Measurement Traffic of one
        MA is treated by the other MA just like any other end-user
        traffic.
 4.  It does not consider how to prevent a malicious party "gaming the
     system".  For example, where a regulator is running a Measurement
     System in order to benchmark operators, a malicious operator
     could try to identify the broadband lines that the regulator was
     measuring and prioritise that traffic.  It is assumed that this
     is a policy issue and would be dealt with through a code of
     conduct for instance.
 5.  It does not define how to analyse Measurement Results, including
     how to interpret missing Results.
 6.  It does not specifically define a end-user-controlled Measurement
     System, see Section 5.6.1.

5.6.1. End-User-Controlled Measurement System

 This framework concentrates on the cases where an ISP or a regulator
 runs the Measurement System.  However, we expect that LMAP
 functionality will also be used in the context of an end-user-
 controlled Measurement System.  There are at least two ways this
 could happen (they have various pros and cons):
 1.  an end-user could somehow request the ISP-run (or regulator-run)
     Measurement System to test his/her line.  The ISP (or regulator)
     Controller would then send an Instruction to the MA in the usual
     LMAP way.

Eardley, et al. Informational [Page 28] RFC 7594 LMAP Framework September 2015

 2.  an end-user could deploy their own Measurement System, with their
     own MA, Controller, and Collector.  For example, the user could
     implement all three functions onto the same end-user-owned end
     device, perhaps by downloading the functions from the ISP or
     regulator.  Then the LMAP Control and Report Protocols do not
     need to be used, but using LMAP's Information Model would still
     be beneficial.  A Measurement Peer (or other MA involved in a
     Measurement Task) could be in the home gateway or outside the
     home network; in the latter case, the Measurement Peer is highly
     likely to be run by a different organisation, which raises extra
     privacy considerations.
 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
 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
 to see the Measurement Results, perhaps summarised on a webpage.  It
 is suggested that these interfaces conform to the LMAP guidance on
 privacy in Section 8.

6. Deployment Considerations

6.1. Controller and the Measurement System

 The Controller should understand both the MA's LMAP Capabilities (for
 example, what Metrics and Measurement Methods it can perform) and the
 MA's other capabilities like processing power and memory.  This
 allows the Controller to ensure that the Measurement Schedule of
 Measurement Tasks and the Reporting Schedule are sensible for each MA
 that it instructs.
 An Instruction is likely to include several Measurement Tasks.
 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
 they do not affect each other's Results, whilst with others great
 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
 destination address, in order to learn the network path that was
 measured.
 The Controller should ensure that the Measurement Tasks do not have
 an adverse effect on the end user.  Tasks, especially those that
 generate a substantial amount of Measurement Traffic, will often
 include a pre-check that the user isn't already sending traffic
 (Section 5.3.1).  Another consideration is whether Measurement
 Traffic will impact a Subscriber's bill or traffic cap.

Eardley, et al. Informational [Page 29] RFC 7594 LMAP Framework September 2015

 A Measurement System may have multiple Controllers (but note the
 overriding principle that a single MA be instructed by a single
 Controller at any point in time (Section 4.2)).  For example, there
 could be different Controllers for different types of MA (for
 example, home gateways, tablets) or locations (for example, Ipswich,
 Edinburgh, Paris), for load balancing or to cope with failure of one
 Controller.
 The measurement system also needs to consider carefully how to
 interpret missing Results.  The correct interpretation depends on why
 the Results are missing (perhaps related to measurement Suppression
 or delayed Report submission) and potentially on the specifics of the
 Measurement Task and Measurement Schedule.  For example, an Observed
 Traffic Flow may be empty, but the Measurement Report may still be
 sent according to the Report Schedule.

6.2. Measurement Agent

 The MA should be cautious about resuming Measurement Tasks if it
 reboots or has been offline for some time, as its Instruction may be
 stale.  In the former case, it also needs to ensure that its clock
 has reset 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.  For example, an
 MA could be a dedicated probe or software on a PC; it could also be
 embedded into an appliance or even embedded into a gateway.  A single
 site (for example, home, branch office, etc.) that is participating
 in a measurement could make use of one or multiple Measurement Agents
 or Measurement Peers in a single measurement.
 The Measurement Agent could be deployed in a variety of locations.
 Not all deployment locations are available to every kind of
 Measurement Agent.  There are also a variety of limitations and
 trade-offs depending on the final placement.  The next sections
 outline some of the locations a Measurement Agent may be deployed.
 This is not an exhaustive list and combinations may also apply.

6.2.1. Measurement Agent on a Networked Device

 An MA may be embedded on a device that is directly connected to the
 network, such as an MA on a smartphone.  Other examples include an MA
 downloaded and installed on a subscriber's laptop computer or tablet
 when the network service is provided on wired or other wireless radio
 technologies, such as Wi-Fi.

Eardley, et al. Informational [Page 30] RFC 7594 LMAP Framework September 2015

6.2.2. Measurement Agent Embedded in a Site Gateway

 One of the better places the Measurement Agent could be deployed is
 embedded within the site gateway (for example, a home router or the
 edge router of a branch office in a managed service environment).
 All site-to-ISP traffic would traverse through the gateway.  So,
 Measurement Methods that measure user traffic could easily be
 performed.  Similarly, due to this user traffic visibility, a
 Measurement Method that generates Measurement Traffic could ensure it
 does not compete with user traffic.  Generally NAT and firewall
 services are built into the gateway, allowing the Measurement Agent
 the option to offer its Controller-facing management interface
 outside of the NAT/firewall.  This placement of the management
 interface allows the Controller to unilaterally contact the
 Measurement Agent with Instructions.  However, a Measurement Agent on
 a site gateway (whether end-user or service-provider owned) will
 generally not be directly available for over-the-top providers, the
 regulator, end users, or enterprises.

6.2.3. Measurement Agent Embedded behind a Site NAT or Firewall

 The Measurement Agent could also be embedded behind a NAT, a
 firewall, or both.  In this case, the Controller may not be able to
 unilaterally contact the Measurement Agent unless either static port
 forwarding or firewall pin holing is configured.  Configuring port
 forwarding could use protocols such as the Port Control Protocol
 [RFC6887], the CPE WAN Management Protocol [TR-069], or Universal
 Plug and Play [UPnP].  To open a pin hole in the firewall, the
 Measurement Agent could send keepalives towards the Controller (and
 perhaps use these also as a network reachability test).

6.2.4. Multihomed Measurement Agent

 If the device with the Measurement Agent is single homed, then there
 is no confusion about what interface to measure.  Similarly, if the
 MA is at the gateway and the gateway only has a single WAN-side and a
 single LAN-side interface, there is little confusion -- for
 Measurement Methods that generate Measurement Traffic, the location
 of the other MA or Measurement Peer determines whether the WAN or LAN
 is measured.
 However, the device with the Measurement Agent may be multihomed.
 For example, a home or campus may be connected to multiple broadband
 ISPs, such as a wired and wireless broadband provider, perhaps for
 redundancy or load sharing.  It may also be helpful to think of dual
 stack IPv4 and IPv6 broadband devices as multihomed.  More generally,
 Section 3.2 of [RFC7368] describes dual-stack and multihoming
 topologies that might be encountered in a home network, [RFC6419]

Eardley, et al. Informational [Page 31] RFC 7594 LMAP Framework September 2015

 provides the current practices of multi-interfaces hosts, and the
 Multiple Interfaces (mif) working group covers cases where hosts are
 either directly attached (for example, physical or virtual) or
 indirectly (for example, multiple default routers, etc.) to multiple
 networks.  In these cases, there needs to be clarity on which network
 connectivity option is being measured.
 One possibility is to have a Measurement Agent per interface.  Then
 the Controller's choice of MA determines which interface is measured.
 However, if an MA can measure any of the interfaces, then the
 Controller defines in the Instruction which interface the MA should
 use for a Measurement Task.  If the choice of interface is not
 defined, then the MA uses the default one.  Explicit definition is
 preferred if the Measurement System wants to measure the performance
 of a particular network, whereas using the default is better if the
 Measurement System wants to include the impact of the MA's interface
 selection algorithm.  In any case, the Measurement Result should
 include the network that was measured.

6.2.5. Measurement Agent Embedded in an ISP Network

 An 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
 embedded MA will be strategically located, such as a Carrier-Grade
 NAT or ISP Gateway.  [RFC7398] gives many examples where an MA might
 be located within a network to provide an intermediate measurement
 point on the end-to-end path.  Other examples include a network
 device whose primary role is to host MA functions and the necessary
 measurement protocol.

6.3. Measurement Peer

 A Measurement Peer participates in some Measurement Methods.  It may
 have specific functionality to enable it to participate in a
 particular Measurement Method.  On the other hand, other Measurement
 Methods may require no special functionality.  For example, if the
 Measurement Agent sends a ping to example.com, then the server at
 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
 Agent and in others as a Measurement Peer.
 Measurement Schedules should account for limited resources in a
 Measurement Peer when instructing an MA to execute measurements with
 a Measurement Peer.  In some measurement protocols, such as [RFC4656]
 and [RFC5357], the Measurement Peer can reject a measurement session

Eardley, et al. Informational [Page 32] RFC 7594 LMAP Framework September 2015

 or refuse a control connection prior to setting up a measurement
 session and so protect itself from resource exhaustion.  This is a
 valuable capability because the MP may be used by more than one
 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 from
 which the MA downloads a web page (such as www.example.com) in order
 to perform a speed test.  The web server is an 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
 Figure 7.
                                                            ^
    +------------------+  web traffic +----------------+ non-LMAP
    |     web client   |<------------>|   web server   |  Scope
    |                  |              +----------------+    |
 ...|..................|....................................V...
    |MA:LMAP interface |                     <MP>           ^
    +------------------+                                    |
             ^     |                                        |
 Instruction |     |  Report                                |
             |     +-----------------+                      |
             |                       |                      |
             |                       v                     LMAP
       +------------+         +------------+               Scope
       | Controller |         |  Collector |                |
       +------------+         +------------+                V
 MA: Measurement Agent
 MP: Measurement Peer
   Figure 7: LMAP deployment example, with Web server as Measurement
                                 Peer
 Another example of an MP is a TWAMP Server and TWAMP
 Session-Reflector.  This form of MP is deployed to assist the MAs
 that perform TWAMP tests, where the MA is co-located with the TWAMP
 Control-Client and Session-Sender.  Another example, which was
 described in Section 2, has a ping server as the Measurement Peer.

Eardley, et al. Informational [Page 33] RFC 7594 LMAP Framework September 2015

 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 8, we depict the case of an OWAMP (One-Way Active
 Measurement Protocol) Server and Session-Receiver acting as an MP.
 In this case, the OWAMP Server conveys results back to the OWAMP
 Fetch-Client, thus the MP conducts both control-plane and data-plane
 communications with its OWAMP counterparts co-located with the MA.
    +------------------+    OWAMP     +-----------------+    ^
    | OWAMP            |<--control--->|                 |    |
    | control-client   |-test-traffic>| OWAMP server &  | non-LMAP
    | fetch-client &   |<----fetch----| session-receiver|  Scope
    | session-sender   |              |                 |    |
    |                  |              +-----------------+    |
 ...|..................|.....................................v...
    |MA:LMAP interface |                    <MP>             ^
    +------------------+                                     |
             ^     |                                         |
 Instruction |     |  Report                                 |
             |     +-----------------+                       |
             |                       |                       |
             |                       v                     LMAP
       +------------+         +------------+               Scope
       | Controller |         |  Collector |                 |
       +------------+         +------------+                 v
 MA: Measurement Agent
 MP: Measurement Peer
  Figure 8: LMAP deployment example, 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 9.  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.

Eardley, et al. Informational [Page 34] RFC 7594 LMAP Framework September 2015

    +----------------+              +-------------------+    ^
    |                |              |                   | non-LMAP
    | iperf -u sender|-UDP traffic->| iperf -u receiver |  Scope
    |                |              |                   |    v
 ...|................|..............|...................|........
    |  MA-1:         |              |  MA-2:            |    ^
    | LMAP interface |              | LMAP interface    |    |
    +----------------+              +-------------------+    |
             ^                        ^   |                  |
 Instruction |    Instruction{Report} |   | Report           |
 {Task,      |    +-------------------+   |                  |
  Schedule}  |    |                       |                  |
             |    |                       v                 LMAP
        +------------+             +------------+          Scope
        | Controller |             |  Collector |            |
        +------------+             +------------+            v
 MA: Measurement Agent
    Figure 9: 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 is 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 10.

Eardley, et al. Informational [Page 35] RFC 7594 LMAP Framework September 2015

 +--------+   +------------------+            +--------+      ^
 |End user|   |      monitor     | Observed   |End user|      |
 |        |<--|------------------|--Traffic-->|        |  non-LMAP
 |        |   |                  |   Flow     |        |    Scope
 +--------+   |                  |            +--------+      |
  ............|..................|............................v..
    <MP>      |MA:LMAP interface |               <MP>         ^
              +------------------+                            |
                      ^     |                                 |
          Instruction |     |  Report                         |
                      |     +-----------------+               |
                      |                       |               |
                      |                       v              LMAP
                +------------+         +------------+        Scope
                | Controller |         |  Collector |         |
                +------------+         +------------+         v
 MA: Measurement Agent
 MP: Measurement Peer
     Figure 10: LMAP deployment example, with a Measurement Agent
                          monitoring traffic

7. Security Considerations

 The security of the LMAP framework should protect the interests of
 the measurement operator(s), the network user(s), and other actors
 who could be impacted by a compromised measurement deployment.  The
 Measurement System must secure the various components of the system
 from unauthorised access or corruption.  Much of the general advice
 contained in Section 6 of [RFC4656] is applicable here.
 The process to upgrade the firmware in an MA is outside the scope of
 the initial LMAP work, just as is the protocol to Bootstrap the MAs.
 However, systems that provide remote upgrades must secure authorised
 access and integrity of the process.
 We assume that each Measurement Agent (MA) will receive its
 Instructions from a single organisation, which operates the
 Controller.  These Instructions must be authenticated (to ensure that
 they come from the trusted Controller), checked for integrity (to
 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
 use it to launch denial-of-service (DoS) attacks at targets, create a
 platform for pervasive monitoring [RFC7258], reduce the end-user's
 quality of experience, and corrupt the Measurement Results that are
 reported to the Collector.  By altering the Measurement Tasks and/or
 the address that Results are reported to, they can also compromise

Eardley, et al. Informational [Page 36] RFC 7594 LMAP Framework September 2015

 the confidentiality of the network user and the MA environment (such
 as 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.
 Reporting by the MA must be encrypted to maintain confidentiality, so
 that only the authorised Collector can decrypt the results to prevent
 the leakage of confidential or private information.  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 vulnerable to
 tampering (which can be ensured through integrity and replay checks).
 It must not be possible to fool an MA into injecting falsified data
 and the results must also be held and processed securely after
 collection and analysis.  See Section 8.5.2 for additional
 considerations on stored data compromise, and Section 8.6 on
 potential mitigations for compromise.
 Since Collectors will be contacted repeatedly by MAs using the Report
 Protocol to convey their recent results, a successful attack to
 exhaust the communication resources would prevent a critical
 operation: reporting.  Therefore, all LMAP Collectors should
 implement technical mechanisms to:
 o  limit the number of reporting connections from a single MA
    (simultaneous and established in some time period).
 o  limit the transmission rate from a single MA.
 o  limit the memory/storage consumed by a single MA's reports.
 o  efficiently reject reporting connections from unknown sources.
 o  separate resources if multiple authentication strengths are used,
    where the resources should be separated according to each class of
    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.  However, 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

Eardley, et al. Informational [Page 37] RFC 7594 LMAP Framework September 2015

 various security issues, such as how to operate through a NAT and how
 to protect the Controller and Collector from DoS attacks.
 The security mechanisms described above may not be strictly necessary
 if the network's design ensures the LMAP components and their
 communications are already secured, for example potentially if they
 are all part of an ISP's dedicated management network.
 Finally, there are three other issues related to security: privacy
 (considered in Section 8), availability, and "gaming the system".
 While the loss of some MAs may not be considered critical, the
 unavailability of the Collector could mean that valuable business
 data or data critical to a regulatory process is lost.  Similarly,
 the unavailability of a Controller could mean that the MAs do not
 operate a correct Measurement Schedule.
 A malicious party could "game the system".  For example, where a
 regulator is running a Measurement System in order to benchmark
 operators, an operator could try to identify the broadband lines that
 the regulator was measuring and prioritise that traffic.  Normally,
 this potential issue is handled by a code of conduct.  It is outside
 the scope of the initial LMAP work to consider the issue.

8. Privacy Considerations

 The LMAP work considers privacy a core requirement and will ensure
 that by default the Control and Report Protocols operate in a
 privacy-sensitive manner and that privacy features are well defined.
 This section provides a set of privacy considerations for LMAP.  This
 section benefits greatly from the publication of [RFC6973].  Privacy
 and security (Section 7) are related.  In some jurisdictions, privacy
 is called data protection.
 We begin with a set of assumptions related to protecting the
 sensitive information of individuals and organisations participating
 in LMAP-orchestrated measurement and data collection.

8.1. Categories of Entities with Information of Interest

 LMAP protocols need to protect the sensitive information of the
 following entities, including individuals and organisations who
 participate in measurement and collection of results.
 o  Individual Internet users: Persons who utilise Internet access
    services for communications tasks, according to the terms of
    service of a service agreement.  Such persons may be a service

Eardley, et al. Informational [Page 38] RFC 7594 LMAP Framework September 2015

    Subscriber, or have been given permission by the Subscriber to use
    the service.
 o  Internet service providers: Organisations that offer Internet
    access service subscriptions, and thus have access to sensitive
    information of individuals who choose to use the service.  These
    organisations desire to protect their Subscribers and their own
    sensitive information, which may be stored in the process of
    performing Measurement Tasks and collecting Results.
 o  Regulators: Public authorities responsible for exercising
    supervision of the electronic communications sector, and which may
    have access to sensitive information of individuals who
    participate in a measurement campaign.  Similarly, regulators
    desire to protect the participants and their own sensitive
    information.
 o  Other LMAP system operators: Organisations who operate Measurement
    Systems or participate in measurements in some way.
 Although privacy is a protection extended to individuals, we discuss
 data protection by 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 used in the LMAP system (for example, billing
 information), and there should be a benefit in considering all the
 needs and potential solutions coherently.

8.2. Examples of Sensitive Information

 This section gives examples of sensitive information that may be
 measured or stored in a Measurement System, and that is to be kept
 private by default in the LMAP core protocols.
 Examples of Subscriber or authorised Internet user sensitive
 information:
 o  Sub-IP-layer addresses and names (MAC address, base station ID,
    SSID)
 o  IP address in use
 o  Personal Identification (real name)
 o  Location (street address, city)
 o  Subscribed service parameters

Eardley, et al. Informational [Page 39] RFC 7594 LMAP Framework September 2015

 o  Contents of traffic (activity, DNS queries, destinations,
    equipment types, account info for other services, etc.)
 o  Status as a study volunteer and Schedule of Measurement Tasks
 Examples of Internet Service Provider sensitive information:
 o  Measurement device identification (equipment ID and IP address)
 o  Measurement Instructions (choice of measurements)
 o  Measurement Results (some may be shared, others may be private)
 o  Measurement Schedule (exact times)
 o  Network topology (locations, connectivity, redundancy)
 o  Subscriber billing information, and any of the above Subscriber
    information known to the provider.
 o  Authentication credentials (such as certificates)
 Other organisations will have some combination of the lists above.
 The LMAP system would not typically expose all of the information
 above, but could expose a combination of items that could be
 correlated with other pieces collected by an attacker (as discussed
 in Section 8.5 on Threats).

8.3. Different Privacy Issues Raised by Different Sorts of Measurement

    Methods
 Measurement Methods raise different privacy issues depending on
 whether they measure traffic created specifically for that purpose or
 whether they measure user traffic.
 Measurement Tasks conducted on user traffic store sensitive
 information, however briefly this storage may be.  We note that some
 authorities make a distinction on time of storage, and information
 that is kept only temporarily to perform a communications function is
 not subject to regulation (for example, active queue management, deep
 packet inspection).  Such Measurement Tasks could reveal all the
 websites a Subscriber visits and the applications and/or services
 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.

Eardley, et al. Informational [Page 40] RFC 7594 LMAP Framework September 2015

 In contrast to Measurement Tasks conducted on user traffic, other
 Measurement Tasks use traffic which is created specifically for the
 purpose of measurement.  Even if a user host generates Measurement
 Traffic, there is limited sensitive information about the Subscriber
 present and stored in the Measurement System:
 o  IP address in use (and possibly sub-IP addresses and names)
 o  Status as a study volunteer and Schedule of Measurement Tasks
 On the other hand, for a service provider, the sensitive information
 like Measurement Results is the same for all Measurement Tasks.
 From the Subscriber perspective, both types of Measurement Tasks
 potentially expose the description of Internet access service and
 specific service parameters, such as the Subscriber rate and type of
 access.

8.4. Privacy Analysis of the Communication Models

 This section examines each of the protocol exchanges described at a
 high level in Section 5 and some example Measurement Tasks, and it
 identifies specific sensitive information that must be secured during
 communication for each case.  With the protocol-related sensitive
 information identified, we can better consider the threats described
 in the following section.
 From the privacy perspective, all entities participating in LMAP
 protocols can be considered "observers" according to the definition
 in [RFC6973].  Their stored information potentially poses a threat to
 privacy, especially if one or more of these functional entities has
 been compromised.  Likewise, all devices on the paths used for
 control, reporting, and measurement are also observers.

8.4.1. MA Bootstrapping

 Section 5.1 provides the communication model for the Bootstrapping
 process.
 Although the specification of mechanisms for Bootstrapping the MA are
 beyond the scope of the initial LMAP work, designers should recognise
 that the Bootstrapping process is extremely powerful and could cause
 an MA to join a new or different LMAP system with a different
 Controller and Collector, or simply install new Metrics with
 associated Measurement Methods (for example, to record DNS queries).
 A Bootstrap attack could result in a breach of the LMAP system with
 significant sensitive information exposure depending on the

Eardley, et al. Informational [Page 41] RFC 7594 LMAP Framework September 2015

 capabilities of the MA, so sufficient security protections are
 warranted.
 The Bootstrapping process provides sensitive information about the
 LMAP system and the organisation that operates it, such as
 o  the MA's identifier (MA-ID)
 o  the address that identifies the Control Channel, such as the
    Controller's FQDN
 o  Security information for the Control Channel
 During the Bootstrap process for an MA located at a single
 Subscriber's service demarcation point, the MA receives an MA-ID,
 which is a persistent pseudonym for the Subscriber.  Thus, the MA-ID
 is considered sensitive information because it could provide the link
 between Subscriber identification and Measurements Results.
 Also, the Bootstrap process could assign a Group-ID to the MA.  The
 specific definition of information represented in a Group-ID is to be
 determined, but several examples are envisaged including use as a
 pseudonym for a set of Subscribers, a class of service, an access
 technology, or other important categories.  Assignment of a Group-ID
 enables anonymisation sets to be formed on the basis of service
 type/grade/rates.  Thus, the mapping between Group-ID and MA-ID is
 considered sensitive information.

8.4.2. Controller ↔ Measurement Agent

 The high-level communication model for interactions between the LMAP
 Controller and Measurement Agent is illustrated in Section 5.2.  The
 primary purpose of this exchange is to authenticate and task a
 Measurement Agent with Measurement Instructions, which the
 Measurement Agent then acts on autonomously.
 Primarily, IP addresses and pseudonyms (MA-ID, Group-ID) are
 exchanged with a capability request, then measurement-related
 information of interest such as the parameters, schedule, metrics,
 and IP addresses of measurement devices.  Thus, the measurement
 Instruction contains sensitive information that must be secured.  For
 example, the fact that an ISP is running additional measurements
 beyond the set reported externally is sensitive information, as are
 the additional Measurements Tasks themselves.  The Measurement
 Schedule is also sensitive, because an attacker intending to bias the
 results without being detected can use this information to great
 advantage.

Eardley, et al. Informational [Page 42] RFC 7594 LMAP Framework September 2015

 An organisation operating the Controller having no service
 relationship with a user who hosts the Measurement Agent *could* gain
 real-name mapping to a public IP address through user participation
 in an LMAP system (this applies to the Measurement Collection
 protocol, as well).

8.4.3. Collector ↔ Measurement Agent

 The high-level communication model for interactions between the
 Measurement Agent and Collector is illustrated in Section 5.4.  The
 primary purpose of this exchange is to authenticate and collect
 Measurement Results from an MA, which the MA has measured
 autonomously and stored.
 The Measurement Results are the additional sensitive information
 included in the Collector-MA exchange.  Organisations collecting LMAP
 measurements have responsibility for data control.  Thus, the Results
 and other information communicated in the Collector protocol must be
 secured.

8.4.4. Measurement Peer ↔ Measurement Agent

 A Measurement Method involving Measurement Traffic raises potential
 privacy issues, although the specification of the mechanisms is
 beyond the scope of the initial LMAP work.  The high-level
 communications model below illustrates the various exchanges to
 execute such a Measurement Method and store the Results.
 We note the potential for additional observers in the figures below
 by indicating the possible presence of a NAT, which has additional
 significance to the protocols and direction of initiation.
 The various messages are optional, depending on the nature of the
 Measurement Method.  It may involve sending Measurement Traffic from
 the Measurement Peer to MA, MA to Measurement Peer, or both.
 Similarly, a second (or more) MAs may be involved.  (Note: For
 simplicity, Figure 11 and the 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.)

Eardley, et al. Informational [Page 43] RFC 7594 LMAP Framework September 2015

  _________________                              _________________
 |                 |                            |                 |
 |Measurement Peer |=========== NAT ? ==========|Measurement Agent|
 |_________________|                            |_________________|
                                <-              (Key Negotiation &
                                                 Encryption Setup)
 (Encrypted Channel             ->
 Established)
 (Announce capabilities         ->
 & status)
                                <-             (Select capabilities)
 ACK                            ->
                                <-              (Measurement Request
                                               (MA+MP IPAddrs,set of
                                                 Metrics, Schedule))
 ACK                            ->
 Measurement Traffic            <>              Measurement Traffic
 (may/may not be encrypted)               (may/may not be encrypted)
                                <-           (Stop Measurement Task)
 Measurement Results            ->
 (if applicable)
                                <-                       ACK, Close
   Figure 11: Interactions between Measurement Peer and Measurement
                                 Agent
 This exchange primarily exposes the IP addresses of measurement
 devices and the inference of measurement participation from such
 traffic.  There may be sensitive information on key points in a
 service provider's network included.  There may also be access to
 measurement-related information of interest such as the Metrics,
 Schedule, and intermediate results carried in the Measurement Traffic
 (usually a set of timestamps).
 The Measurement Peer may be able to use traffic analysis (perhaps
 combined with traffic injection) to obtain interesting insights about
 the Subscriber.  As a simple example, if the Measurement Task
 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
 away on holiday.
 If the Measurement Traffic is unencrypted, as found in many systems
 today, then both timing and limited results are open to on-path
 observers.

Eardley, et al. Informational [Page 44] RFC 7594 LMAP Framework September 2015

8.4.5. Measurement Agent

 Some Measurement Methods only involve a single Measurement Agent
 observing existing traffic.  They raise potential privacy issues,
 although the specification of the mechanisms is beyond the scope of
 the initial LMAP work.
 The high-level communications model shown in Figure 12 illustrates
 the collection of user information of interest with the Measurement
 Agent performing the monitoring and storage of the Results.  This
 particular exchange is for measurement of DNS Response Time, which
 most frequently uses UDP transport.  (Note: For simplicity, Figure 12
 and its description do not show the non-LMAP functionality that is
 associated with the transfer (export) of the observed Measurement
 Traffic beyond the measurement devices located with the MA.)
_________________                                      ____________

| | | | | DNS Server |=========== NAT ? ==========*=======| User client| |_| ^ ||

                                        ______|_______
                                       |              |
                                       |  Measurement |
                                       |    Agent     |
                                       |______________|
                              <-              Name Resolution Required
                                             (MA+MP IPAddrs,
                                              Desired Domain Name)

Return Record →

MA: Measurement Agent MP: Measurement Peer

 Figure 12: LMAP deployment example, with Measurement Agent monitoring
                           DNS response time
 In this particular example, the MA monitors DNS messages in order to
 measure the DNS response time.  The Measurement Agent may be embedded
 in the user host, or it may be located in another device capable of
 observing user traffic.  The MA learns the IP addresses of
 measurement devices and the intent to communicate with or access the
 services of a particular domain name, and perhaps also information on
 key points in a service provider's network, such as the address of
 one of its DNS servers.

Eardley, et al. Informational [Page 45] RFC 7594 LMAP Framework September 2015

 In principle, any of the user sensitive information of interest
 (listed above) can be collected and stored in the monitoring scenario
 and so must be secured.
 It would also be possible for a Measurement Agent to source the DNS
 query itself, and then there are not many privacy concerns.

8.4.6. Storage and Reporting of Measurement Results

 Although the mechanisms for communicating results (beyond the initial
 Collector) are beyond the scope of the initial LMAP work, there are
 potential privacy issues related to a single organisation's storage
 and reporting of Measurement Results.  Both storage and reporting
 functions can help to preserve privacy by implementing the
 mitigations described below.

8.5. Threats

 This section indicates how each of the threats described in [RFC6973]
 apply to the LMAP entities and their communication and storage of
 "information of interest".  DoS and other attacks described in the
 Security section represent threats as well, and these attacks are
 more effective when sensitive information protections have been
 compromised.

8.5.1. Surveillance

 Section 5.1.1 of [RFC6973] describes surveillance as the "observation
 or monitoring of an individual's communications or activities."
 Hence, all Measurement Methods that measure user traffic are a form
 of surveillance, with inherent risks.
 Measurement Methods that avoid periods of user transmission
 indirectly produce a record of times when a subscriber or authorised
 user has used their network access service.
 Measurement Methods may also utilise and store a Subscriber's
 currently assigned IP address when conducting measurements that are
 relevant to a specific Subscriber.  Since the Measurement Results are
 timestamped, they could provide a record of IP address assignments
 over time.
 Either of the above pieces of information could be useful in
 correlation and identification, as described below.

Eardley, et al. Informational [Page 46] RFC 7594 LMAP Framework September 2015

8.5.2. Stored Data Compromise

 Section 5.1.2 of [RFC6973] describes Stored Data Compromise as
 resulting from inadequate measures to secure stored data from
 unauthorised or inappropriate access.  For LMAP systems, this
 includes deleting or modifying collected measurement records, as well
 as data theft.
 The primary LMAP entity subject to compromise is the repository,
 which stores the Measurement Results; extensive security and privacy
 threat mitigations are warranted.  The Collector and MA also store
 sensitive information temporarily and need protection.  The
 communications between the local storage of the Collector and the
 repository is beyond the scope of the initial LMAP work, though this
 communications channel will certainly need protection as will the
 mass storage itself.
 The LMAP Controller may have direct access to storage of Subscriber
 information (for example, location, billing, service parameters,
 etc.) and other information that the controlling organisation
 considers private and again needs protection.
 Note that there is tension between the desire to store all raw
 results in the LMAP Collector (for reproduction and custom analysis)
 and the need to protect the privacy of measurement participants.
 Many of the mitigations described in Section 8.6 are most efficient
 when deployed at the MA, therefore minimising the risks associated
 with stored results.

8.5.3. Correlation and Identification

 Sections 5.2.1 and 5.2.2 of [RFC6973] describe correlation as
 combining various pieces of information to obtain desired
 characteristics of an individual, and identification as using this
 combination to infer identity.
 The main risk is that the LMAP system could unwittingly provide a key
 piece of the correlation chain, starting with an unknown Subscriber's
 IP address and another piece of information.  For example, a
 Subscriber utilised Internet access from 2000 to 2310 UTC, because
 the Measurement Tasks were deferred or sent a name resolution for
 www.example.com at 2300 UTC.
 If a user's access with another system already gave away sensitive
 information, correlation is clearly easier and can result in
 re-identification, even when an LMAP system conserves sensitive
 information to great extent.

Eardley, et al. Informational [Page 47] RFC 7594 LMAP Framework September 2015

8.5.4. Secondary Use and Disclosure

 Sections 5.2.3 and 5.2.4 of [RFC6973] describe secondary use as
 unauthorised utilisation of an individual's information for a purpose
 the individual did not intend, and disclosure as when such
 information is revealed causing another's notions of the individual
 to change or confidentiality to be violated.
 Measurement Methods that measure user traffic are a form of secondary
 use, and the Subscribers' permission should be obtained beforehand.
 It may be necessary to obtain the measured ISP's permission to
 conduct measurements (for example, when required by the terms and
 conditions of the service agreement) and notification is considered
 good measurement practice.
 For Measurement Methods that measure Measurement Traffic the
 Measurement Results provide some limited information about the
 Subscriber or ISP and could result in secondary uses.  For example,
 the use of the Results in unauthorised marketing campaigns would
 qualify as secondary use.  Secondary use may break national laws and
 regulations, and may violate an individual's expectations or desires.

8.6. Mitigations

 This section examines the mitigations listed in Section 6 of
 [RFC6973] and their applicability to LMAP systems.  Note that each
 section in [RFC6973] identifies the threat categories that each
 technique mitigates.

8.6.1. Data Minimisation

 Section 6.1 of [RFC6973] encourages collecting and storing the
 minimal information needed to perform a task.
 LMAP Results can be useful for general reporting about performance
 and for specific troubleshooting.  They need different levels of
 information detail, as explained in the paragraphs below.
 For general reporting, the results can be aggregated into large
 categories (for example, the month of March, all US subscribers West
 of the Mississippi River).  In this case, all individual
 identifications (including IP address of the MA) can be excluded, and
 only relevant results are provided.  However, this implies a
 filtering process to reduce the information fields, because greater
 detail was needed to conduct the Measurement Tasks in the first
 place.

Eardley, et al. Informational [Page 48] RFC 7594 LMAP Framework September 2015

 For troubleshooting, so that a network operator or end user can
 identify a performance issue or failure, potentially all the network
 information (for example, IP addresses, equipment IDs, location),
 Measurement Schedules, service configurations, Measurement Results,
 and other information may assist in the process.  This includes the
 information needed to conduct the Measurements Tasks, and represents
 a need where the maximum relevant information is desirable;
 therefore, the greatest protections should be applied.  This level of
 detail is greater than needed for general performance monitoring.
 As regards Measurement Methods that measure user traffic, we note
 that a user may give temporary permission (to enable detailed
 troubleshooting), but withhold permission for them in general.  Here
 the greatest breadth of sensitive information is potentially exposed,
 and the maximum privacy protection must be provided.  The Collector
 may perform pre-storage minimisation and other mitigations
 (Section 8.6.4) to help preserve privacy.
 For MAs with access to the sensitive information of users (for
 example, within a home or a personal host/handset), it is desirable
 for the Results collection to minimise the data reported, but also to
 balance this desire with the needs of troubleshooting when a service
 subscription exists between the user and organisation operating the
 measurements.

8.6.2. Anonymity

 Section 6.1.1 of [RFC6973] describes an "anonymity set" as a way in
 which anonymity is achieved: "there must exist a set of individuals
 that appear to have the same attribute(s) as the individual."
 Experimental methods for anonymisation of user-identifiable data (and
 so particularly applicable to Measurement Methods that measure user
 traffic) have been identified in [RFC6235].  However, the findings of
 several of the same authors is that "there is increasing evidence
 that anonymization applied to network trace or flow data on its own
 is insufficient for many data protection applications as in [Bur10]."
 Essentially, the details of such Measurement Methods can only be
 accessed by closed organisations, and unknown injection attacks are
 always less expensive than the protections from them.  However, some
 forms of summary may protect the user's sensitive information
 sufficiently well, and so each Metric must be evaluated in the light
 of privacy.
 The techniques in [RFC6235] could be applied more successfully in
 Measurement Methods that generate Measurement Traffic, where there
 are protections from injection attack.  The successful attack would
 require breaking the integrity protection of the LMAP Reporting

Eardley, et al. Informational [Page 49] RFC 7594 LMAP Framework September 2015

 Protocol and injecting Measurement Results (known fingerprint, see
 Section 3.2 of [RFC6973]) for inclusion with the shared and
 anonymised results, then fingerprinting those records to ascertain
 the anonymisation process.
 Beside anonymisation of measured Results for a specific user or
 provider, the value of sensitive information can be further diluted
 by summarising the Results over many individuals or areas served by
 the provider.  There is an opportunity enabled by forming anonymity
 sets [RFC6973] based on the reference path measurement points in
 [RFC7398].  For example, all measurements from a Subscriber device
 can be identified as "mp000", instead of using the IP address or
 other device information.  The same anonymisation applies to the
 Internet Service Provider, where their Internet gateway would be
 referred to as "mp190".
 Another anonymisation technique is for the MA to include its Group-ID
 instead of its MA-ID in its Measurement Reports, with several MAs
 sharing the same Group-ID.

8.6.3. Pseudonymity

 Section 6.1.2 of [RFC6973] indicates that pseudonyms, or nicknames,
 are a possible mitigation to revealing one's true identity, since
 there is no requirement to use real names in almost all protocols.
 A pseudonym for a measurement device's IP address could be an
 LMAP-unique equipment ID.  However, this would likely be a permanent
 handle for the device, and long-term use weakens a pseudonym's power
 to obscure identity.

8.6.4. Other Mitigations

 Data can be depersonalised by blurring it, for example by adding
 synthetic data, data-swapping, or perturbing the values in ways that
 can be reversed or corrected.
 Sections 6.2 and 6.3 of [RFC6973] describe user participation and
 security, respectively.
 Where LMAP measurements involve devices on the subscriber's premises
 or Subscriber-owned equipment, it is essential to secure the
 Subscriber's permission with regard to the specific information that
 will be collected.  The informed consent of the Subscriber (and, if
 different, the end user) may be needed, including the specific
 purpose of the measurements.  The approval process could involve
 showing the Subscriber their measured information and results before
 instituting periodic collection, or before all instances of

Eardley, et al. Informational [Page 50] RFC 7594 LMAP Framework September 2015

 collection, with the option to cancel collection temporarily or
 permanently.
 It should also be clear who is legally responsible for data
 protection (privacy); in some jurisdictions, this role is called the
 'data controller'.  It is always good practice to limit the time that
 personal information is stored.
 Although the details of verification would be impenetrable to most
 subscribers, the MA could be architected as an "app" with open source
 code, pre-download and embedded terms of use and agreement on
 measurements, and protection from code modifications usually provided
 by the app stores.  Further, the app itself could provide data
 reduction and temporary storage mitigations as appropriate and
 certified through code review.
 LMAP protocols, devices, and the information they store clearly need
 to be secure from unauthorised access.  This is the hand-off between
 privacy and security considerations (Section 7).  The data controller
 is responsible (legally) for maintaining data protections described
 in the Subscriber's agreement and agreements with other
 organisations.
 Finally, it is recommended that each entity described in Section 8.1,
 (for example, individuals, ISPs, regulators, others) assess the risks
 of LMAP data collection by conducting audits of their data protection
 methods.

9. Informative References

 [Bur10]    Burkhart, M., Schatzmann, D., Trammell, B., and E. Boschi,
            "The Role of Network Trace anonymisation Under Attack",
            January 2010.
 [IPPM-REG] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
            Akhter, "Registry for Performance Metrics", Work in
            Progress, draft-ietf-ippm-metric-registry-04, July 2015.
 [LMAP-INFO]
            Burbridge, T., Eardley, P., Bagnulo, M., and J.
            Schoenwaelder, "Information Model for Large-Scale
            Measurement Platforms (LMAP)", Work in Progress,
            draft-ietf-lmap-information-model-06, July 2015.
 [REST]     Wikipedia, "Representational state transfer", July 2015,
            <https://en.wikipedia.org/w/index.php?
            title=Representational_state_transfer&oldid=673799183>.

Eardley, et al. Informational [Page 51] RFC 7594 LMAP Framework September 2015

 [RFC1035]  Mockapetris, P., "Domain names - implementation and
            specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
            November 1987, <http://www.rfc-editor.org/info/rfc1035>.
 [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
            Information Models and Data Models", RFC 3444,
            DOI 10.17487/RFC3444, January 2003,
            <http://www.rfc-editor.org/info/rfc3444>.
 [RFC4101]  Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
            DOI 10.17487/RFC4101, June 2005,
            <http://www.rfc-editor.org/info/rfc4101>.
 [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
            Unique IDentifier (UUID) URN Namespace", RFC 4122,
            DOI 10.17487/RFC4122, July 2005,
            <http://www.rfc-editor.org/info/rfc4122>.
 [RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
            Zekauskas, "A One-way Active Measurement Protocol
            (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
            <http://www.rfc-editor.org/info/rfc4656>.
 [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
            Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
            RFC 5357, DOI 10.17487/RFC5357, October 2008,
            <http://www.rfc-editor.org/info/rfc5357>.
 [RFC6235]  Boschi, E. and B. Trammell, "IP Flow Anonymization
            Support", RFC 6235, DOI 10.17487/RFC6235, May 2011,
            <http://www.rfc-editor.org/info/rfc6235>.
 [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
            and A. Bierman, Ed., "Network Configuration Protocol
            (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
            <http://www.rfc-editor.org/info/rfc6241>.
 [RFC6419]  Wasserman, M. and P. Seite, "Current Practices for
            Multiple-Interface Hosts", RFC 6419, DOI 10.17487/RFC6419,
            November 2011, <http://www.rfc-editor.org/info/rfc6419>.
 [RFC6887]  Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
            P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
            DOI 10.17487/RFC6887, April 2013,
            <http://www.rfc-editor.org/info/rfc6887>.

Eardley, et al. Informational [Page 52] RFC 7594 LMAP Framework September 2015

 [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
            Morris, J., Hansen, M., and R. Smith, "Privacy
            Considerations for Internet Protocols", RFC 6973,
            DOI 10.17487/RFC6973, July 2013,
            <http://www.rfc-editor.org/info/rfc6973>.
 [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
            "Specification of the IP Flow Information Export (IPFIX)
            Protocol for the Exchange of Flow Information", STD 77,
            RFC 7011, DOI 10.17487/RFC7011, September 2013,
            <http://www.rfc-editor.org/info/rfc7011>.
 [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
            Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258,
            May 2014, <http://www.rfc-editor.org/info/rfc7258>.
 [RFC7368]  Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
            Weil, "IPv6 Home Networking Architecture Principles",
            RFC 7368, DOI 10.17487/RFC7368, October 2014,
            <http://www.rfc-editor.org/info/rfc7368>.
 [RFC7398]  Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
            A. Morton, "A Reference Path and Measurement Points for
            Large-Scale Measurement of Broadband Performance",
            RFC 7398, DOI 10.17487/RFC7398, February 2015,
            <http://www.rfc-editor.org/info/rfc7398>.
 [RFC7536]  Linsner, M., Eardley, P., Burbridge, T., and F. Sorensen,
            "Large-Scale Broadband Measurement Use Cases", RFC 7536,
            DOI 10.17487/RFC7536, May 2015,
            <http://www.rfc-editor.org/info/rfc7536>.
 [TR-069]   The Broadband Forum, "CPE WAN Management Protocol", TR-069
            Amendment 5, November 2013,
            <https://www.broadband-forum.org/technical/download/
            TR-069_Amendment-5.pdf>.
 [UPnP]     UPnP Forum, "UPnP Device Architecture 2.0", February 2015,
            <http://www.iso.org/iso/home/store/catalogue_ics/
            catalogue_detail_ics.htm?csnumber=57195>.

Eardley, et al. Informational [Page 53] RFC 7594 LMAP Framework September 2015

Acknowledgments

 This document originated as a merger of three individual drafts:
 "Terminology for Large MeAsurement Platforms (LMAP)" (July 2013), "A
 Framework and Inventory for a Large Scale Measurement System" (July
 2013), and "A framework for large-scale measurements" (July 2013).
 Thanks to Juergen Schoenwaelder for his detailed review of the
 terminology.  Thanks to Charles Cook for a very detailed review of an
 early draft of this document.  Thanks to Barbara Stark and Ken Ko for
 many helpful comments about later draft versions.
 Thanks to numerous people for much discussion, directly and on the
 LMAP list (apologies to those unintentionally omitted): Alan Clark,
 Alissa Cooper, Andrea Soppera, Barbara Stark, Benoit Claise, Brian
 Trammell, Charles Cook, Dan Romascanu, Dave Thorne, Frode Soerensen,
 Greg Mirsky, Guangqing Deng, Jason Weil, Jean-Francois Tremblay,
 Jerome Benoit, Joachim Fabini, Juergen Schoenwaelder, Jukka Manner,
 Ken Ko, Lingli Deng, Mach Chen, Matt Mathis, Marc Ibrahim, Michael
 Bugenhagen, Michael Faath, Nalini Elkins, Radia Perlman, Rolf Winter,
 Sam Crawford, Sharam Hakimi, Steve Miller, Ted Lemon, Timothy Carey,
 Vaibhav Bajpai, Vero Zheng, and William Lupton.
 Philip Eardley, Trevor Burbridge and Marcelo Bagnulo worked in part
 on the Leone research project, which received funding from the
 European Union Seventh Framework Programme under grant agreement
 number 317647.

Authors' Addresses

 Philip Eardley
 BT
 Adastral Park, Martlesham Heath
 Ipswich
 England
 Email: philip.eardley@bt.com
 Al Morton
 AT&T Labs
 200 Laurel Avenue South
 Middletown, NJ
 United States
 Email: acmorton@att.com

Eardley, et al. Informational [Page 54] RFC 7594 LMAP Framework September 2015

 Marcelo Bagnulo
 Universidad Carlos III de Madrid
 Av. Universidad 30
 Leganes, Madrid  28911
 Spain
 Phone: 34 91 6249500
 Email: marcelo@it.uc3m.es
 URI:   http://www.it.uc3m.es
 Trevor Burbridge
 BT
 Adastral Park, Martlesham Heath
 Ipswich
 England
 Email: trevor.burbridge@bt.com
 Paul Aitken
 Brocade Communications Systems, Inc.
 19a Canning Street, Level 3
 Edinburgh, Scotland  EH3 8EG
 United Kingdom
 Email: paitken@brocade.com
 Aamer Akhter
 Consultant
 118 Timber Hitch
 Cary, NC
 United States
 Email: aakhter@gmail.com

Eardley, et al. Informational [Page 55]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7594.txt · Last modified: 2015/09/18 15:27 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki