Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 7594

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

Pages: 55
Informational
Part 2 of 3 – Pages 13 to 36
First   Prev   Next

Top   ToC   RFC7594 - Page 13   prevText

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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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   ToC   RFC7594 - 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 Section