tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7594

 
 
 

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

Part 2 of 3, p. 13 to 36
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 13 
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).

Top      Up      ToC       Page 14 
   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.

Top      Up      ToC       Page 15 
   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.

Top      Up      ToC       Page 16 
   +-----------------+                                   +-------------+
   |                 |                                   | 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

Top      Up      ToC       Page 17 
   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.

Top      Up      ToC       Page 18 
   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.

Top      Up      ToC       Page 19 
   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).

Top      Up      ToC       Page 20 
   +-----------------+                              +-------------+
   |                 |                              | 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.

Top      Up      ToC       Page 21 
   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.

Top      Up      ToC       Page 22 
   +-----------------+                                  +-------------+
   |                 |                                  | 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.

Top      Up      ToC       Page 23 
   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.

Top      Up      ToC       Page 24 
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).

Top      Up      ToC       Page 25 
   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.

Top      Up      ToC       Page 26 
   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).

Top      Up      ToC       Page 27 
   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.

Top      Up      ToC       Page 28 
   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.

Top      Up      ToC       Page 29 
   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.

Top      Up      ToC       Page 30 
   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.

Top      Up      ToC       Page 31 
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]

Top      Up      ToC       Page 32 
   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

Top      Up      ToC       Page 33 
   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.

Top      Up      ToC       Page 34 
   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.

Top      Up      ToC       Page 35 
      +----------------+              +-------------------+    ^
      |                |              |                   | 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.

Top      Up      ToC       Page 36 
   +--------+   +------------------+            +--------+      ^
   |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



(page 36 continued on part 3)

Next RFC Part