RFC 7594
A Framework for Large-Scale Measurement of Broadband Performance (LMAP)
Pages: 55
Informational
Informational
Part 2 of 3 – Pages 13 to 36
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).
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.
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.
+-----------------+ +-------------+ | | | Measurement | | Controller |===================================| Agent | +-----------------+ +-------------+ Configuration information: -> (MA-ID), (Group-ID), (Control Channel) <- Response(details) MA: Measurement Agent Figure 2: Outline of Configuration5.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
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.
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.
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).
+-----------------+ +-------------+ | | | Measurement | | Controller |==============================| Agent | +-----------------+ +-------------+ Suppress: [(Measurement Task), -> (Measurement Schedule), (start time), (end time), (on-going suppressed?)] Un-suppress -> Figure 4: Outline of Suppression5.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.
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.
+-----------------+ +-------------+ | | | 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 Information5.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.
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.
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).
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.
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).
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.
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.
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.
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.
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]
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
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.
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.
+----------------+ +-------------------+ ^ | | | | 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.
+--------+ +------------------+ +--------+ ^ |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)