Internet DRAFT - draft-akhter-lmap-framework
draft-akhter-lmap-framework
LMAP Working Group A. Akhter
Internet-Draft P. Aitken
Intended status: Informational Cisco Systems
Expires: January 17, 2014 July 16, 2013
A Framework and Inventory for a Large Scale Measurement System
draft-akhter-lmap-framework-00.txt
Abstract
This LMAP framework document reviews the LMAP Working Group charter,
considers the necessary building blocks, and looks at what we already
have in the IETF and what's missing, so that LMAP Working Group
attention can be focused on where the gaps are.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 17, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Akhter & Aitken Expires January 17, 2014 [Page 1]
Internet-Draft LMAP-framework July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Working Group Scope . . . . . . . . . . . . . . . . . . . 4
1.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 5
1.3. LMAP Working Group Goals . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Measurement Agent . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Measurement Agent Embedded in Site Gateway . . . . . 9
3.1.2. Measurement Agent behind Site NAT/Firewall . . . . . 9
3.1.3. Measurement Agent in-line with Site Gateway . . . . . 9
3.1.4. Measurement Agent in Multi Homed Site . . . . . . . . 10
3.2. Remote Measurement Test Target . . . . . . . . . . . . . 11
3.3. Controller . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Collector . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. Information Model . . . . . . . . . . . . . . . . . . . . 12
3.6. Transport Protocols . . . . . . . . . . . . . . . . . . . 13
3.7. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.8. Device Discovery . . . . . . . . . . . . . . . . . . . . 14
4. Active Measurements . . . . . . . . . . . . . . . . . . . . . 15
4.1. What building blocks exist today? . . . . . . . . . . . . 15
4.1.1. Single Sided Client Tests . . . . . . . . . . . . . . 15
4.1.2. OWAMP - One Way Active Measurement Protocol . . . . . 15
4.1.3. TWAMP - Two Way Active Measurement Protocol . . . . . 17
4.1.4. Cisco Service-Level Assurance Protocol . . . . . . . 18
4.1.5. IPPM Performance Metrics . . . . . . . . . . . . . . 18
4.2. Missing building blocks . . . . . . . . . . . . . . . . . 18
4.2.1. Time Synchronization . . . . . . . . . . . . . . . . 18
4.2.2. Shared Secret Distribution . . . . . . . . . . . . . 19
4.2.3. NAT/Firewall Traversal for Control and Test Protocols 19
4.2.4. IPPM Metrics Registry . . . . . . . . . . . . . . . . 19
4.2.5. OWAMP/TWAMP configuration . . . . . . . . . . . . . . 19
5. Passive Measurements . . . . . . . . . . . . . . . . . . . . 20
5.1. What building blocks exist today? . . . . . . . . . . . . 20
5.1.1. Measuring Packets . . . . . . . . . . . . . . . . . . 20
5.1.2. Measuring Flows . . . . . . . . . . . . . . . . . . . 20
5.1.3. Defining new Information Elements . . . . . . . . . . 22
5.1.4. Exporting Process . . . . . . . . . . . . . . . . . . 22
5.1.5. Mediation . . . . . . . . . . . . . . . . . . . . . . 23
5.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 23
5.2. Missing building blocks . . . . . . . . . . . . . . . . . 23
5.2.1. Performance metrics definition in the IPFIX registry 23
5.2.2. Mediation Configuration . . . . . . . . . . . . . . . 24
6. LMAP: Standards Re-usability . . . . . . . . . . . . . . . . 24
6.1. Existing Building Blocks . . . . . . . . . . . . . . . . 24
6.2. Missing Building Blocks . . . . . . . . . . . . . . . . . 24
6.2.1. Task Definitions . . . . . . . . . . . . . . . . . . 24
Akhter & Aitken Expires January 17, 2014 [Page 2]
Internet-Draft LMAP-framework July 2013
6.2.2. Instructions Setup . . . . . . . . . . . . . . . . . 25
6.2.3. Task Scheduling . . . . . . . . . . . . . . . . . . . 26
6.2.4. Combining Active and Passive Measurements . . . . . . 26
7. Security considerations . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction
There is a desire to be able to coordinate the execution of broadband
measurements and the collection of measurement results across a large
scale set of diverse devices. These devices could be software based
agents on PCs, embedded agents in consumer devices (e.g. blu-ray
players), service provider controlled devices such as set-top players
and home gateways, or simply dedicated probes. It is expected that
such a system could easily comprise 100k devices. Such a scale
presents unique problems in coordination, execution and measurement
result collection. Broad users of such a system include governmental
regulators looking for service compliance; network and service
operators (including over the top content providers) for diagnostics,
compliance and planning; and end users for diagnostics and service
compliance. The various detailed uses of such a large scale
measurement system are covered in [I-D.linsner-lmap-use-cases].
Over the years various efforts inside and outside the IETF have
worked on independent components of such a system. There are also
existing systems that are deployed today. However, these are either
proprietary, closed, and/or not standardized. The IETF Large-Scale
Measurement of Broadband Performance (LMAP) Working Group is
chartered to specify the information model, associated data models,
and select/extend one or more protocols for secure measurement
control and measurement result collection.
With standardization, LMAP compliant Measurement Agents will be more
pervasive in gateways and end systems and offer a base common service
across vendor implementations.
Akhter & Aitken Expires January 17, 2014 [Page 3]
Internet-Draft LMAP-framework July 2013
A set of Measurement Agents is to be controlled by a single
organization. The Measurement Agents do not coordinate with
Measurement Agents under the control of other organisations. While
some of the capabilities are meant for end users, an end user is not
meant to directly control Measurement Agents, except for his own
Measurement Agent. The end user may interact with a service provider
portal to schedule and execute a measurement task using the
Measurement Agent on their premises.
The measurements themselves may be on IPv4, IPv6, and on various
services (DNS, HTTP, XMPP, FTP, VoIP, etc.). The Measurement Agents
may have multiple interfaces (WiFi, Ethernet, DSL, fiber, etc.) and
the measurements may specify any one of these. The measurement tasks
may generate synthetic traffic to perform the measurement (active
measurement), only observe existing traffic (passive measurement), or
may do a combination of both active and passive measurement.
Given the usage of passive measurements (and even in the case of
active measurement) there are valid concerns regarding privacy of the
measurement results and any user identifiable information.
1.1. Working Group Scope
The Large-Scale Measurement of Broadband Performance (LMAP) Working
Group is chartered to standardize the LMAP measurement system for
performance measurements of broadband access devices.
The Working Group is chartered to specify an information model, the
associated data models, and select/extend one or more protocols for
secure communication:
o A Control Protocol, from a Controller to instruct Measurement
Agents what performance metrics to measure, when to measure them,
and when and how to report the measurement results to a Collector.
o A Report Protocol, for a Measurement Agent to report the results
to the Collector.
The data models should be extensible for new and additional
measurements. LMAP will consider re-use of existing data models
languages.
The LMAP architecture will allow for measurements that utilize either
IPv4 or IPv6, or possibly both. Devices containing Measurement
Agents may have several interfaces using different link technologies.
Multiple address families and interfaces must be considered in the
Control and Report protocols.
Akhter & Aitken Expires January 17, 2014 [Page 4]
Internet-Draft LMAP-framework July 2013
Both active and passive measurements are in scope, although there may
be differences in their applicability to specific use cases, or in
the security measures needed according to the threats specific to
each measurement category. LMAP will not standardize performance
metrics.
The LMAP Working Group will consider privacy as a core requirement
and will ensure that by default measurement and collection mechanisms
and protocols operate in a privacy-sensitive manner, ie that privacy
features are at least well-defined.
1.2. Out of Scope
There are a number of items that are currently explicitly out of
scope for the LMAP Working Group:
o Inter-organization coordination and sharing of results is out of
scope
o Discovery of service parameters on Measurement Agents is out of
scope
o Sharing the service parameters between Measurement Agents is out
of the scope.
o Decision on the set of measurements to run is out of scope
o Protection against intentional / malicious gaming is out of scope
o Standardizing control of end users Measurement Agents is out of
scope.
o The management protocol to bootstrap the Measurement Agents in
measurement devices is out of scope.
1.3. LMAP Working Group Goals
The LMAP Working Group will produce the following work items:
1. The LMAP Framework - provides common terminology, basic
architecture elements, and justifies the simplifying constraints
2. The LMAP Use Cases - provides the motivating use cases as a basis
for the work
Akhter & Aitken Expires January 17, 2014 [Page 5]
Internet-Draft LMAP-framework July 2013
3. Information Model, the abstract definition of the information
carried from the Controller to the Measurement Agent and the
information carried from the Measurement Agent to the Collector.
It includes:
* The metric(s) that can be measured and values for its
parameters such as the Peer Measurement Agent participating in
the measurement and the desired environmental conditions (for
example, only conduct the measurement when there is no user
traffic observed)
* The schedule: when the measurement should be run and how the
results should be reported (when and to which Collector)
* The report: the metric(s) measured and when, the actual
result, and supporting metadata such as location. Result
reports may be organized in batches or may be reported
immediately, such as for an on-demand measurement.
4. The Control protocol and the associated data model: The
definition of how instructions are delivered from a Controller to
a Measurement Agent; this includes a Data Model consistent with
the Information Model plus a transport protocol. This may be a
simple instruction - response protocol, and LMAP will specify how
it operates over an existing protocol (to be selected, perhaps
REST-style HTTP(s) or NETCONF).
5. The Report protocol and the associated data model: The definition
of how the Report is delivered from a Measurement Agent to a
Collector; this includes a Data Model consistent with the
Information Model plus a transport protocol (to be selected,
perhaps REST-style HTTP(s) or IPFIX).
2. Terminology
Terms used in this document and are to be interpreted as defined in
the following documents:
o LMAP terms used in this document are defined in
[I-D.eardley-lmap-terminology].
o IPFIX terms are defined in the Terminology section of the IPFIX
Architecture [RFC5470]
o PSAMP terms are defined in the Terminology section of the PSAMP
Protocol [RFC5476]
o TODO: where are IPPM terms defined?
Akhter & Aitken Expires January 17, 2014 [Page 6]
Internet-Draft LMAP-framework July 2013
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Architecture
A large scale measurement system is composed of several basic parts:
o Measurement Agents
o Remote Measurement Test Target(s)
o Controller(s)
o Collector(s)
+-------------------+
|Remote Measurement |
|Test Target(s) |
+-------------------+
^
|B
v
+----------+ A +-----------------+ C +------------+
|Controller|<--->|Measurement Agent|----->|Collector(s)|
+----------+ +-----------------+ +------------+
^ ^
|------------------------------------------|
D
Figure 1: LMAP Basic Parts
A full system would include other components such as a data parsing
module, report generation module, and subscriber database module.
However, these are not covered by the high level Figure 1.
There is also the concept of the measurement task and the measurement
result.
A measurement task generates a measurement result, which is composed
of one or many metrics as well as supplemental information from the
process of the task. A measurement task might time the download of a
specific web page. The measurement results might include the DNS
query time, query result used (IP address), the time to download the
web page and individual times for associated objects, the maximum bit
rate, and average bit rate. Note that some of the results are
derived metrics (based on other measurements, like maximum bit rate),
Akhter & Aitken Expires January 17, 2014 [Page 7]
Internet-Draft LMAP-framework July 2013
while others may not be not metrics at all (IP address used). Also
note that it is possible that the size of the result is not known at
the time of measurement task scheduling - the number of objects on
the web page might change, or if the measurement task includes a
traceroute the path will be different from many of the Measurement
Agents.
The measurement task is scheduled by the Controller via an
instruction.
3.1. Measurement Agent
The Measurement Agent is the component that is responsible for
executing a test. The Measurement Agent could take a number of
forms: a dedicated probe, software on a PC, embedded into an
appliance, or even embedded into a gateway. A single site (home,
branch office etc.) that is participating in a test could make use of
one or multiple Measurement Agents in a single measurement test.
e.g., if there are multiple output interfaces, there might be a
Measurement Agent per interface.
The Measurement Agent's configuration (specifically which Controller
to initially connect to), is out of scope within LMAP. However,
depending on the type of probe, it could be manually configured by
the user, pre-configured before shipment to the end user, or
configured by the application (in the case of some PC based
Measurement Agents). For example, a Measurement Agent that is
included in the app for a content provider might be configured
automatically by the content provider to use the content provider's
LMAP Controller. That said, there should be an element of local
premises configuration that allows the Measurement Agent (especially
in the case of active measurements) to mimic performance of user
applications at the same site. For example, making use of the same
DNS server as the remainder of the site.
The Measurement Agent could be deployed in a variety of locations.
Not all deployment locations are available to every kind of
Measurement Agent operator. 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 of the below may also
apply.
Akhter & Aitken Expires January 17, 2014 [Page 8]
Internet-Draft LMAP-framework July 2013
3.1.1. Measurement Agent Embedded in Site Gateway
A Measurement Agent embedded with the site gateway (e.g. in the case
of a a branch office in a managed service environment) is one of
better places the Measurement Agent could be deployed.
All site to ISP traffic would traverse through the gateway and
passive measurements could easily be performed. Similarly, due to
this user traffic visibility, an active measurement task could be
rescheduled so as not to 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 for instructions.
However, if the site gateway is owned and operated by the service
provider, the Measurement Agent will generally not be available for
over the top providers, the regulator, end users or enterprises.
3.1.2. Measurement Agent behind Site NAT/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 configuration or firewall pin holing is configured. This
would require user intervention, and ultimately might not be an
option available to the user (perhaps due to permissions).
The Measurement Agent may originate a session towards the Controller
and maintain the session for bidirectional communications. This
would alleviate the need to have user intervention on the gateway,
but would reduce the overall scalability of the Controller as it
would have to maintain a higher number of active sessions.
That said, sending keepalives to prop open the firewall could serve a
dual purpose in testing network reachability for the Measurement
Agent.
An alternative would be to use a protocol such as UPnP or PCP
[RFC6887] to control the NAT/firewall if the gateway supports this
kind of control.
3.1.3. Measurement Agent in-line with Site Gateway
As mentioned earlier, there are benefits in the Measurement Agent's
ability to observe the site's user traffic. In the case of active
Akhter & Aitken Expires January 17, 2014 [Page 9]
Internet-Draft LMAP-framework July 2013
measurement it allows the Measurement Agent to back-off on a
potentially disruptive measurement task to avoid impacting the user.
For the case of passive measurement, access to the user traffic
allows the Measurement Agent to gather data without a traffic
footprint (of interest to both the site user and network operator) as
well as potentially provide a greater number of samples for a
measurement task.
A Measurement Agent behind the gateway would generally not be privy
to observation of the user traffic unless the Measurement Agent was
placed in-line with the site gateway or the site gateway traffic was
replicated to the Measurement Agent (a capability generally not found
in home broadband gateways).
3.1.4. Measurement Agent in Multi Homed Site
A broadband site may be multi-homed. For example, the site may be
connected to multiple broadband ISPs (perhaps for redundancy or load-
sharing), or have a broadband as well as mobile/WiFi connectivity.
It may also be helpful to think of dual stack IPv4 and IPv6 broadband
sites as multi-homed.
In these cases, there needs to be clarity on which network
connectivity option is being measured. Sometimes this is easily
resolved by the location of measurement agent itself. For example,
if the measurement agent is built into the gateway (and the gateway
only has a single WAN side interface), there is little confusion or
choice. However, for multi-homed gateways or devices behind the
gateway(s) of multi-homed sites it would be preferable to explicitly
select the network to measure (e.g. [RFC5533]) but the network
measured should be included in the Measurement Result.
Section 3.2 of [I-D.ietf-homenet-arch] describes dual-stack and
multi-homing topologies that might be encountered in a home network
(which is generally a broadband connected site). The Multiple
Interfaces (mif) working group covers cases where hosts are either
directly attached to multiple networks (physical or virtual) or
indirectly (multiple default routers, etc.). xref target="RFC6419"/>
provides the current practices of multi-interfaces hosts today. As
some of the end goals of a LMAP Measurement Agent is to replicate the
network experience as an end user would, it is important to
understand the current practices.
Akhter & Aitken Expires January 17, 2014 [Page 10]
Internet-Draft LMAP-framework July 2013
3.2. Remote Measurement Test Target
A remote measurement test target is the other side of the measurement
test - the test target of the Measurement Agent. The remote
measurement test target could also take many different forms: a web
site, a service (VoIP), a DNS server, an application specific server
(e.g., webex), a well known web site (e.g., youtube, Google Search),
another Measurement Agent in another home, a powerful Measurement
Agent that is well network connected (Anchor Measurement Agent), or
even a collection of home based Measurement Agents.
An Anchor Measurement Agent is a remote measurement test target that
is well placed bandwidth-wise and is meant to handle test traffic in
a highly scaled (1000s of test sessions) environment. Similar to the
measurement agent sitting at a broadband site, it is under the
direction of an LMAP Controller, but might support multi-tenancy. It
is generally expected to respond to broadband site Measurement Agents
rather than initiate tests.
As illustrated in Figure 2, a measurement task may not only involve a
similar LMAP Measurement Agent, but multiple such Measurement Agents.
An example where this arrangement would be useful is when an Anchor
Measurement Agent in a path capacity measurement is unable to
saturate a path, while horizontal scaling properties of multiple
Measurement Agents can. This arrangement also alleviates any one
remote Measurement Agent from saturating its own access link as the
load is distributed.
+------------------+
| | +--------------------------+
| |<---->|Remote Measurement Agent 1|
| | +--------------------------+
|Measurement Agent |
| | +--------------------------+
| |<---->|Remote Measurement Agent 2|
| | +--------------------------+
+------------------+
Figure 2: Measurement Task Involving Multiple Remote Measurement
Agents
3.3. Controller
A Controller is responsible for providing the Measurement Agent with
instructions which include the test schedule, test parameters, etc.
It is basically the entity controlling the Measurement Agents in a
LMAP domain.
Akhter & Aitken Expires January 17, 2014 [Page 11]
Internet-Draft LMAP-framework July 2013
For scaling purposes there may be several Collectors as well as
several Controllers, perhaps regionally located. A large scale test
making use of multiple Controllers would need a master Controller
that is the ultimate source of direction.
3.4. Collector
A Collector is responsible for receiving the test results from the
Measurement Agent at the end of a test. It may have additional
features such as aggregating the results across multiple Measurement
Agents, remove outliers, create additional statistics, (depending on
usage of data) anonymization of results for privacy reasons (if not
done already in the Measurement Agents) etc. The work of
anonymization of user identifiable data has been addressed for IPFIX
via RFC6235 [RFC6235].
For scaling purposes there may be several Collectors as well as
several Controllers, perhaps regionally located. A large scale test
making use of multiple Collectors would need to aggregate/consolidate
their results for the complete picture.
3.5. Information Model
For definitions and examples of Information Models and Data Models,
refer to [RFC3444]
The information shared between LMAP devices would be organized into
an LMAP information model [I-D.burbridge-lmap-information-model]
covering:
o Controlling the Measurement Agent (from the Controller)
o The Measurement Agent submitting the results (to the Collector)
In some cases, the Collector and Controller could be co-resident on
the same device but the information models would continue to be
separate.
The IETF IPFIX working group has defined an extensible information
model in [I-D.ietf-ipfix-information-model-rfc5102bis] which could be
used to organize the result metrics back to the LMAP Collector.
Akhter & Aitken Expires January 17, 2014 [Page 12]
Internet-Draft LMAP-framework July 2013
3.6. Transport Protocols
The information shared between the components that is in the
information model needs a transport protocol. Similar to the
information model the transport protocols would map to the following
main functions:
o Control of the Measurement Agent by the Controller
o Submission of measurement test results to the Collector
o Controller to Collector Test Configuration synchronization
Note that each of these could use different transport protocols.
However, for implementation simplification and keeping a small memory
footprint having the option of a single transport protocol can be
helpful.
The Controller to Controller Test Configuration Synchronization
provides a direct way for the Controller to communicate test
configuration information to the Collector. An alternate would have
been for the Measurement Agent to echo back the configuration to the
Controller. However, given several hundred thousand reports this
would to much duplication of data. It would be optimal to transfer
the test identification and configuration information directly to the
Collector(s) a single time. In this case, the Controller to
Collector Test Configuration Synchronization would be no different in
communications that with a Measurement Agent, except the Collector
would not execute the test-- it would simply understand it. Explicit
Collector directives (if they exist) by the Controller should not be
sent via the Measurement Agent.
The collated results from the Collector would have a pre-configured
path to publication or data storage.
To reduce the complexity and memory footprint needs of the
Measurement Agent it is possible that the control and report protocol
are the same (but still using the independent information models).
There are a number of transport candidate transport protocols.
Depending on the placement and use of the Measurement Agent certain
transport protocols may be preferred over others. For example if the
Measurement Agent is behind a NAT or firewall, it would be difficult
to make use of SNMP, or for the Controller to connect to the
Measurement Agent if REST were used. Regardless of transport
protocol used, the information model MUST be consistent.
Akhter & Aitken Expires January 17, 2014 [Page 13]
Internet-Draft LMAP-framework July 2013
3.7. Scaling
Scalability is a key issue, since LMAP is expected to scale to
10,000's of Measurement Agents. Therefore the architecture shown in
Figure 1 may include a hierarchy of Controllers and a hierarchy of
Collectors, e.g. with sub-controllers and sub-collectors distributed
topographically or geographically. Note that sub-collectors are
effectively IPFIX mediators [RFC6183].
Separating the Control Protocol and Report Protocol allows these
hierarchies to scale independently, which would not be possible with
a single command-response protocol which requires a co-hosted
Controller/Collector implementation.
A scalability optimisation is discussed in Section 6.2.2.
3.8. Device Discovery
In a large-scale system, an LMAP controller must somehow discover
which Measurement Agents are available in the LMAP domain, and which
is the most appropriate collector for these agents to report test
results to. ie, for each LMAP Measurement Agent, which LMAP domain
is it in?
Possibilities include:
o The call home mechanism from netconf
[I-D.ietf-netconf-reverse-ssh]
o DNS SRV
o DNS anycast, selecting the nearest
o ALTO
o DHCP
Also note one corner case: a Collector may have to ignore test
results from a Measurement Agent which is mis-configured, or which
has been moved from one LMAP domain to another. ie, where the test
results are being reported out of scope.
Akhter & Aitken Expires January 17, 2014 [Page 14]
Internet-Draft LMAP-framework July 2013
4. Active Measurements
4.1. What building blocks exist today?
4.1.1. Single Sided Client Tests
A good number of active measurement tasks simply require that the
Measurement Agent perform client side duties and interact with a
Remote Measurement Test Target as a general user application would
have. Examples of single sided client tests include HTTP GETs from
private or public servers, DNS queries, FTP transfers etc. The
metrics are generally based on response time, bit rate of transfer
etc.
There are no requirements against the server and in fact it is likely
that the server might even be under the operational control of an
entirely different entity. Generally the servers in this will be
providing a user side function (a new website, DNS services, etc.) so
care must be taken in running too many synthetic tests as Denial of
Service (DoS) may be achieved or (more likely) automated DoS
protection mechanisms may come into play ultimately rejecting traffic
from that broadband site.
4.1.2. OWAMP - One Way Active Measurement Protocol
The One Way Active Measurement Protocol [RFC4656] allows for the
generation of a unidirectional test stream (by the Session-Sender)
and the measurement of that test stream by a remote entity (Session-
Receiver). The test stream is known as OWAMP-Test. The OWAMP-
Control protocol is used to (at the time of the test) negotiate
OWAMP-Test port numbers (for example UDP or TCP port numbers) between
the Session-Sender and Session-Receiver. As the test stream in OWAMP
is unidirectional the Session-Receiver has to compute the metrics.
The OWAMP-Control protocol is then used to retrieve the metrics.
Depending on the metrics being computed, it may be necessary for the
Session-Sender and Session-Receiver to the time synchronized. The
one-way-latency measurement is an example of this case. The OWAMP-
Control protocol is also used to covey from the Session-Sender to the
Session-Receiver any packets that were unable to be sent so the
Session-Receiver does not mistakenly count these non-existent packets
as loss.
Figure 3 describes the individual roles and relationships in OWAMP.
Any unlabeled links are unspecified by OWAMP and may be proprietary
protocols.
Akhter & Aitken Expires January 17, 2014 [Page 15]
Internet-Draft LMAP-framework July 2013
+----------------+ +------------------+
| Session-Sender |--OWAMP-Test-->| Session-Receiver |
+----------------+ +------------------+
^ ^
| |
| |
| |
| +----------------+<----------------+
| | Server |<-------+
| +----------------+ |
| ^ |
| | |
| OWAMP-Control OWAMP-Control
| | |
v v v
+----------------+ +-----------------+
| Control-Client | | Fetch-Client |
+----------------+ +-----------------+
Figure 3: OWAMP Individual Roles and Relationships
Figure 4 describes simplified individual roles and relationships in
OWAMP such that only two hosts are used.
+-----------------+ +------------------+
| Control-Client |<--OWAMP-Control-->| Server |
| Fetch-Client | | |
| Session-Sender |---OWAMP-Test----->| Session-Receiver |
+-----------------+ +------------------+
Figure 4: OWAMP Two Host Implementation
For the cases of many IPPM defined metrics the OWAMP is a natural fit
and the OWAMP-Test stream could certainly be utilized between two
Measurement Agents. The Session-Sender would be the local broadband
site Measurement Agent, while the Session-Receiver would be a Remote
Measurement Test Target, perhaps an anchor Measurement Agent or a
Measurement Agent at a broadband site.
In the case that Session-Receiver/Server is behind a firewall, it
would be challenging for the OWAMP-Control protocol to reach the
OWAMP Server. The usage of PCP by the Session-Receiver/Server might
be utilized. Another solution would be for the LMAP Controller to
take on the role of the OWAMP server-- with the understanding that
the LMAP server has open lines of communication to all Measurement
Agents. The case of the OWAMP-Test stream would also be challenged
in crossing such a firewall. The OWAMP-Test transport ports are
dynamically negotiated to prevent special handling by the underlying
Akhter & Aitken Expires January 17, 2014 [Page 16]
Internet-Draft LMAP-framework July 2013
network. The LMAP Controller line of communication may be of little
help in this case and other techniques would need to be used.
The OWAMP-Control protocol provides an authenticated control channel
that prevents unauthorized usage (and thereby conserving test
resources and bandwidth) as well as tampering with the results as
they are fetched from the Session-Receiver. Additionally, encryption
is also offered to prevent a third-party from improving the results
that reality. If authentication and encryption is to be used in an
LMAP scenario, the shared-secret would need to be deployed to both
the Session-Sender and the Session-Receiver.
4.1.3. TWAMP - Two Way Active Measurement Protocol
The Two-Way Active Measurement Protocol [RFC5357] builds on top of
the OWAMP work to allow two-way active measurement. In TWAMP, the
Session-Receiver becomes a Session-Reflector that does not keep state
for the test metric and simply reflects back the received test stream
(with some additions and modifications to account for the reverse
direction trip. The metric computation is performed at the Session-
Sender.
Figure 5 describes the individual roles and relationships in TWAMP.
Note that due to the Session-Reflector, the diagram is simplified
compared to OWAMP. Any unlabeled links are unspecified by OWAMP and
may be proprietary protocols.
+----------------+ +-------------------+
| Session-Sender |<-TWAMP-Test-->| Session-Reflector |
+----------------+ +-------------------+
^ ^
| |
| |
| |
| +----------------+<----------------+
| | Server |
| +----------------+
| ^
| |
| TWAMP-Control
| |
v v
+----------------+
| Control-Client |
+----------------+
Figure 5: TWAMP Individual Roles and Relationships
Akhter & Aitken Expires January 17, 2014 [Page 17]
Internet-Draft LMAP-framework July 2013
Figure 6 describes simplified individual roles and relationships in
TWAMP such that only two hosts are used.
+-----------------+ +-------------------+
| Control-Client |<--TWAMP-Control-->| Server |
| | | |
| Session-Sender |<--TWAMP-Test----->| Session-Reflector |
+-----------------+ +-------------------+
Figure 6: TWAMP Two Host Implementation
For the cases of many IPPM defined metrics the TWAMP is a natural fit
and the TWAMP-Test stream could certainly be utilized between two
Measurement Agents. The Session-Sender would be the local broadband
site Measurement Agent, while the Session-Reflector would be a Remote
Measurement Test Target, perhaps an anchor Measurement Agent or a
Measurement Agent at a broadband site.
In the case that Session-Reflector/Server is behind a firewall, the
same challenges for TWAMP-Control and TWAMP-Test as described for
OWAMP earlier would apply to TWAMP.
4.1.4. Cisco Service-Level Assurance Protocol
The Cisco Service Level Assurance Protocol [RFC6812] is similar to
OWAMP and TWAMP in that there is a control phase that negotiates
transport port usage and a measurement phase. The issues described
previously to remote test targets situated behind a firewall would
continue to apply to CSLA.
4.1.5. IPPM Performance Metrics
A good number of performance methodologies and metrics exist today
and have been defined via various works by the IETF IPPM working
group. Recently, guidelines have been published for new performance
metrics in [RFC6390]. These guidelines are applied by the
Performance Metrics Directorate [pm-dir] when reviewing new metrics.
4.2. Missing building blocks
4.2.1. Time Synchronization
A variety of the metrics require the time synchronization to a common
clock. This time synchronization is not guaranteed, especially at
broadcast sites. Given that the Measurement Agents are communicating
to a common set of Controller(s) this should present an opportunity
to provide a fall-back common clock. In this particular case it may
not be in the best interest of the test to use broadband site local
Akhter & Aitken Expires January 17, 2014 [Page 18]
Internet-Draft LMAP-framework July 2013
NTP server configuration as the disparate Measurement Agents might be
on different NTP hierarchies.
4.2.2. Shared Secret Distribution
A secured control protocol and test stream between the Measurement
Agents requires the distribution of a shared key. Such a shared key
might be distributed by the Controller or by the Measurement Agent
provisioning system.
4.2.3. NAT/Firewall Traversal for Control and Test Protocols
A NAT or firewall in between the Measurement Agents can become
problematic. In this case the traditional method of control
communications between the Measurement Agents would be impaired.
Whereas the control protocols are on well known ports, the test
streams are on negotiated port values. In this case, the test
traffic may need to also be well known port values. There may be
alternative mechanisms to reach the Measurement Agent behind the
firewall such as via the Controller line of communication or the use
of PCP.
4.2.4. IPPM Metrics Registry
The IPPM WG defined an IPPM Metrics Registry [RFC4148] . However this
was obsoleted by [RFC6248] as the registry was found to be
insufficiently detailed to uniquely identify IPPM metrics. Calls to
the community regarding the registry were unanswered in 2010.
Such a registry (and the unique identification issue resolved) will
be needed to by the LMAP system as the controller needs to designate
which test (or to be more precise, which metric within a test) is to
be run by the measurement agent. There's currently no IPPM metrics
registry since [RFC4148] was obsoleted by [RFC6248]. Proposals for
such a registry can be found at [I-D.claise-ippm-perf-metric-
registry-00], [I-D.bagnulo-ippm-new-registry], and
[I-D.bagnulo-ippm-new-registry-independent]. The first provides a
simplified model, taking into account PMOL [RFC6390] and the IPFIX
Information Model [I-D.ietf-ipfix-information-model-rfc5102bis]. The
second has a single registry with sub-registries while the third
proposes a more distributed registry for the components involved. As
this new registry is created it would be extremely helpful that the
metrics added to the registry confirm to the performance metrics
guidelines outlined in [RFC6390].
4.2.5. OWAMP/TWAMP configuration
Akhter & Aitken Expires January 17, 2014 [Page 19]
Internet-Draft LMAP-framework July 2013
Currently there are no standardised way to configure OWAMP and TWAMP.
An information model is required. A YANG module (data model) would
be a plus, if NETCONF is chosen as the LMAP Configuration Protocol.
5. Passive Measurements
5.1. What building blocks exist today?
5.1.1. Measuring Packets
The PSAMP Framework [RFC5474] specifies a framework for Packet
Sampling ("PSAMP").
The PSAMP protocol [RFC5476] selects packets from a stream according
to a set of standardized selectors, forms a stream of reports on the
selected packets, and exports the reports to a Collector. The PSAMP
Framework [RFC5474] defines packet selection processes, with various
types of filtering and sampling. It defines the exporting process
and packet reports.
The architecture shown in section 3.1 of the PSAMP Framework
[RFC5474] corresponds well to the LMAP architecture discussed in
Section 3 above. The PSAMP Metering Process corresponds to LMAP
Measurement Agents; the PSAMP protocol corresponds to the LMAP Report
Protocol; the PSAMP Collector corresponds to the LMAP Collector.
[RFC5477] defines an Information Model for Packet Sampling Exports
which is used by the PSAMP protocol for encoding sampled packet data
and information related to the sampling process. This includes
confidence intervals, measurement error, and observation timestamps.
In PSAMP, a Selector ID identifies a Primitive Selector, and a
Selection Sequence ID identifies a combination of Selectors. LMAP
should follow a similar model, using a global ID to identify a
complex test built up from a set of test primitives.
5.1.2. Measuring Flows
The IPFIX Metering Process defined in [RFC5470] is designed to meter
flows, which are defined as:
A Flow is defined as a set of IP packets passing an Observation
Point in the network during a certain time interval. All packets
belonging to a particular Flow have a set of common properties.
Inserting IPFIX terminology into Figure 1 above gives the
architecture shown in Figure 7:
Akhter & Aitken Expires January 17, 2014 [Page 20]
Internet-Draft LMAP-framework July 2013
+---------------------------------+
|Remote Measurement Test Target(s)|
| IPFIX Observation Point(s) |
+---------------------------------+
^
|
v
+-------------------------+
| IPFIX Metering Process |
+----------+ |.........................| +--------------------------+
|Controller|<--->| Measurement Agent | | Collector(s) |
+----------+ |.........................| |..........................|
| IPFIX Exporting Process |---->| IPFIX Collecting Process |
+-------------------------+ +--------------------------+
Figure 7: LMAP IPFIX Architecture
The only component of the LMAP architecture which doesn't have a
parallel in IPFIX is the LMAP Controller. Therefore the IPFIX
Architecture is clearly a key component for passive measurements in
an LMAP Measurement Agent.
Inputs to the IPFIX Metering Process are packet headers, packet
characteristics, and packet treatment. The Metering Process consists
of a set of functions that includes packet header capture,
timestamping, sampling, classifying, and maintaining Flow Records.
A packet belongs to a Flow if it completely satisfies all the defined
properties of the Flow. This definition covers the range from a Flow
containing all packets observed at a network interface to a Flow
consisting of just a single packet between two applications. It
includes packets selected by a sampling mechanism.
[I-D.ietf-ipfix-protocol-rfc5101bis] specifies the IPFIX Protocol
which transmits information from the IPFIX Metering Process over the
network, from an Exporting Process to a Collecting Process. The
Protocol defines a common data representation and a standard means of
communicating information over a number of transport protocols from
an Exporting Process to a Collecting Process.
The IPFIX protocol is a candidate for the LMAP Report Protocol
between Measurement Agents and Collectors.
[I-D.ietf-ipfix-information-model-rfc5102bis] defines the Information
Model for IPFIX export, for which IANA's IPFIX registry
[iana-ipfix-assignments]) is now the normative reference. The
information model encodes measured traffic information and
information related to the traffic Observation Point, the traffic
Akhter & Aitken Expires January 17, 2014 [Page 21]
Internet-Draft LMAP-framework July 2013
Metering Process, and the Exporting Process - ie, both details of the
measured traffic and metadata about the Measurement Agent.
Although developed for the IPFIX Protocol, the information model is
defined in an open way that readily allows it to be used in other
protocols and applications. The information model is maintained as
an IANA registry [iana-ipfix-assignments]).
[I-D.ietf-ipfix-ie-doctors] provides guidelines for how define new
IPFIX Information Elements. It provides instructions on using the
proper conventions for Information Elements to be registered in the
IANA IPFIX Information Element registry, and provides guidelines for
expert reviewers to evaluate new registrations.
[RFC6759] specifies an extension to the IPFIX information model to
export application information, including application ID, name,
description, and classification which would be useful if the test
needs to be run, or test results must be reported, per application.
5.1.3. Defining new Information Elements
The IPFIX Information Model defined in
[I-D.ietf-ipfix-information-model-rfc5102bis] is extensible: new
elements may be defined by following the process defined in
[I-D.ietf-ipfix-ie-doctors]. New Information Elements may be
registered in IANA's IPFIX Information Element registry, or may be
enterprise specific.
The IPFIX protocol supports export of both standard Information
Elements (as defined in IANA's IPFIX registry
[iana-ipfix-assignments]), and enterprise-specific Information
Elements which allows non-standard (ie, proprietary) information to
be carried in the protocol.
This extensibility allows new information to be carried in the IPFIX
protocol without any modification to the underlying protocol.
5.1.4. Exporting Process
An IPFIX Exporting Process [RFC5470] transmits information generated
by one or more IPFIX [RFC5470] or PSAMP [RFC5474] Metering Processes
to one or more Collecting Processes. IPFIX export is specified over
SCTP, UDP, and TCP, with authentication and security.
In LMAP terms, the Exporting Process uses the Reporting Protocol to
transmit test information from Measurement Agents to the Collector.
Akhter & Aitken Expires January 17, 2014 [Page 22]
Internet-Draft LMAP-framework July 2013
5.1.5. Mediation
The sharing of information for monitoring applications having
different requirements raises issues in terms of measurement system
scalability, measurement flexibility, and export reliability which
are described in [RFC5982]. Mediation fills the gap between
restricted metering capabilities and the requirements of measurement
applications by introducing an intermediate device called the
Mediator.
[RFC6183] describes a framework for IPFIX Mediation. It introduces a
generalized concept for intermediate entities, describes the high-
level Mediation architecture, key architectural components, and
mediation characteristics.
Mediation could be anonymization [RFC6235], aggregation
[I-D.ietf-ipfix-a9n], or flow selection
[I-D.ietf-ipfix-flow-selection-tech]. Removing user identifiable
information eg by aggregation is especially important for passive
measurements.
Aggregation is needed in the ISP use case, when the ISP needs to
report the information to the regulator.
Note that IPFIX is required to report the output of any mediation
function, possibly with stricter rules to support LMAP.
5.1.6. Configuration
[RFC6728] specifies the Configuration Data Model for IPFIX and PSAMP
exporting and metering process configuration, and for Collecting
Processes. The model is specified using YANG [RFC6020]. The
configuration data is encoded in Extensible Markup Language (XML).
YANG is a data modeling language used to model configuration and
state data manipulated by the Network Configuration Protocol
(NETCONF), NETCONF remote procedure calls, and NETCONF notifications.
5.2. Missing building blocks
5.2.1. Performance metrics definition in the IPFIX registry
IANA's IPFIX Information Elements registry [iana-ipfix-assignments])
defines around 400 elements, ranging from layer 2, 3, and 4 packet
fields to layer 7 application details, and including timestamps, pre/
post NAT fields, sampling and filtering details. However, the
registry includes very few performance metrics.
Akhter & Aitken Expires January 17, 2014 [Page 23]
Internet-Draft LMAP-framework July 2013
The IPPM WG defined an IPPM Metrics Registry [RFC4148]. However this
was obsoleted by [RFC6248].
LMAP requires a standardised performance metrics registry, i.e. a
PMOL IANA registry based on section 5.4.4 of [RFC6390]. See [I-D
.claise-ippm-perf-metric-registry-00],
5.2.2. Mediation Configuration
In the Collector infrastructure, mediation changes traffic
granularity, provides time and/or spatial data composition, data
anonymization, and data retention.
[RFC5982] indicates that increasing numbers of data exporters,
traffic, and the variety of treatments expected to be performed on
the data make it more and more difficult to implement all measurement
applications within a single Collector. To increase the collecting
bandwidth capacity and processing capacity, distributed Collectors
need to be deployed close to Exporters. In this case, those
Collectors become mediators, re-exporting data on demand to
centralized applications.
Although the IPFIX WG has published a Mediation Problem Statement
[RFC5982] and a Mediation Framework [RFC6183], and is currently
working on a mediation protocol [I-D.ietf-ipfix-mediation-protocol],
there's currently no configuration model for mediation.
6. LMAP: Standards Re-usability
6.1. Existing Building Blocks
The LAMP charter has been defined [lmap-wg-charter]. The Working
Group is in the process of defining the framework.
6.2. Missing Building Blocks
6.2.1. Task Definitions
The central part of LMAP is the Measurement Task itself which
performs the measurement and generates the Measurement Result that is
shared with the Collector.
An information model is needed to organize the Measurement Task
configuration, scheduling, and result posting of measurement tasks.
A proposal of such an information model can be found at
[I-D.burbridge-lmap-information-model].
Akhter & Aitken Expires January 17, 2014 [Page 24]
Internet-Draft LMAP-framework July 2013
The Measurement Task is an instance of the Measurement Method at
specific time (schedule) and place (Measurement Agent). The
Measurement Method is the methodology used to generate the metrics.
Therefore for comparable metrics the Measurement Method needs to be
well understood and agreed upon. Additionally, the manner to
reference the Measurement Method in the Instruction setup should be
from a well-known registry. From experience, there are a number of
existing methods to generate similarly named metrics. However, the
results of these methods is not comparable as the algorithm used is
not the same. The well-known registry should not simply list the
measurement methods but also clearly define scope and usability of
such metrics to avoid result comparison confusion.
A Measurement Task would include not only the Measurement Method but
also configuration parameters such as (in the case of passive
monitoring) what traffic to monitor or (in the case of active
monitoring) that Remote Measurement Test Target(s) and test
parameters etc. Some of these configuration parameters may not be
explicit but implicit based on local state on the Measurement Agent.
For example, the Controller may give Instruction to provide
reachability (e.g. ping) information from the 1st and 2nd hop device
towards a destination IP address. In this case, each 1st and 2nd hop
device would not be known to the Controller and would be different at
each Measurement Agent. Another example is the selection of the
specific Controllers to which the Measurement Results should be
posted to. The Controller may use ALTO [I-D.ietf-alto-protocol] to
discover which Collector is the best one to use for each specific
Measurement Agent, or the Controller may delegate the Controller
selection to the Measurement Agent (ALTO, DNS SRV, etc.).
A Measurement Method could include a multi-part set of tests which
chain information together to replicate a user workflow. For example
the method might start with a DNS query to a specific website, a
measurement on the DNS response time, and the DNS query result used
in a HTTP GET (while using the VHOST of the website) and the download
bitrate measured.
The Measurement Task could be spread across multiple Measurement
Agents each generating and submitting their Measurement Results to
the Collector(s). A Measurement Task ID would need to be allocated
by the Controller to identify the Task to the Collector which would
further aggregating the results from Measurement Agents. This Task
ID would need to be unique across Controller reboots to prevent
collision of different Measurement Tasks on to the Collector.
6.2.2. Instructions Setup
Akhter & Aitken Expires January 17, 2014 [Page 25]
Internet-Draft LMAP-framework July 2013
The Controller uses the Control Protocol to communicate with the
Measurement Agents, to schedule tests. (As a scalability
optimisation, the Controller may also use the Control Protocol to
inform the Collector of the requested test(s). Else, every
Measurement Agent would have to repeat the Test details to the
Collector, along with the Test results.)
Which protocol should be used as the Control Protocol? Several
possibilities exist, including NetConf [RFC6241], and YANG [RFC6020],
Apache thrift, REST-style HTTP(s), TR-069, ALTO, ...
The Control Protocol should be transport independent, and available
over a variety of transports. e.g., SCTP, TCP, and UDP, in both IPv4
and IPv6 networks, since Measurement Agents will be located in
different kinds of networks. e.g., Home router versus branch office.
6.2.3. Task Scheduling
In one use case, tests are run immediately upon receipt of a command
and reported immediately to the Collector. In a different use case,
tests are configured ahead of time, perhaps across multiple
Measurement Agents with the intention that all the Agents run the
test at about the same time. In yet another case, a test may be run
repeatedly or may otherwise make observations at several discrete
times.
Therefore the Control Protocol must be able to clearly indicate to
the Measurement Agent(s) when the test is scheduled, and the
Reporting Protocol must be able to clearly indicate when the test was
run.
These time indications may be either absolute ("at 10:23") or
relative ("in 300 seconds"). Absolute timestamps require good clock
synchronisation between the Controller, Measurement Agents, and
Collector. Relative timestamps don't require any clock
synchronisation. However, they're susceptible to delays.
The IPFIX WG has standardised many timestamps
[iana-ipfix-assignments]). Each time stamp is available in multiple
resolutions: seconds, milliseconds, microseconds, nanoseconds, being
a trade-off between range and resolution.
6.2.4. Combining Active and Passive Measurements
The balanced use of both active and passive measurements would be
needed in a large scale measurement system. While it is certainly
possible to run active measurements to variety of test targets this
can be disruptive to user traffic (and to the test if the active
Akhter & Aitken Expires January 17, 2014 [Page 26]
Internet-Draft LMAP-framework July 2013
measurement backs off) but also the remote measurement test targets
that have user facing services. Additionally, active measurement
would be taking away bandwidth certainly from the broadband site but
potentially also from the ISP if the remote measurement test target
is outside of the ISP.
Many questions can be answered by simple observation rather than
explicit active measurement. For example, response times for DNS
queries can be gleaned by observation of user traffic rather than
explicit probing. In fact, it is possible to gather more samples of
measurement that would have been acceptable under active measurement.
Similarly, observation of user traffic of a Video on Demand stream to
well known content provider can reveal information about the network
conditions along the path to the content provider's server.
One proposal for making use of both active and passive measurement is
to allow the Measurement Agent to make local decisions on which
technique to use to deliver a particular metric-- as long as the
specific method is included in the report. For example, DNS response
time could be answered by passive monitoring as well as active
monitoring. The Measurement Task could provide guidelines along how
long to delay an active measurement in case passive measurement is
unable to provide the result. If passive measurement is unable to
provide a result, active measurement would be engaged.
Similarly, rather than completely backing off on an last mile path
capacity active measurement in the presence of user traffic the
Measurement Agent might keep a historical record of the high
watermark of user traffic utilization and attempt to actively probe
the delta current utilization and the high-water mark or the
configured service profile (that the broadband site is 20mbps
connected).
In all cases of the combined usage of active and passive measurement
the results need to clearly indicate which method was used to what
extent.
7. Security considerations
The privacy aspects of the end user measurements are important. The
potentially large number of Measurement Agents capable of driving
network traffic can be an attractive target for taking control of
utilized for Denial of Service (DoS) attacks. The sizable resources
associated also with the anchor Measurement Agents needs to be
protected from unauthorized usage. Finally, as the Measurement
Results could have potentially damaging commercial and regulatory
effects they need to protected as well.
Akhter & Aitken Expires January 17, 2014 [Page 27]
Internet-Draft LMAP-framework July 2013
The security considerations related to LMAP will be completed in the
future.
8. IANA Considerations
There are no IANA considerations in this memo.
9. Acknowledgements
Thanks to all the authors of all the referenced works, and to the
experts at Cisco who helped to make this draft possible.
Thanks to our families for their patience and understanding while we
wrote this draft.
10. References
10.1. Normative References
[I-D.burbridge-lmap-information-model]
Burbridge, T., Eardley, P., Bagnulo, M., and J.
Schoenwaelder, "Information Model for Large-Scale
Measurement Platforms (LMAP)", draft-burbridge-lmap-
information-model-00 (work in progress), July 2013.
[I-D.eardley-lmap-terminology]
Eardley, P., Morton, A., Bagnulo, M., and T. Burbridge,
"Terminology for Large MeAsurement Platforms (LMAP)",
draft-eardley-lmap-terminology-02 (work in progress), July
2013.
[I-D.linsner-lmap-use-cases]
Linsner, M., Eardley, P., and T. Burbridge, "Large-Scale
Broadband Measurement Use Cases", draft-linsner-lmap-use-
cases-03 (work in progress), July 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[I-D.bagnulo-ippm-new-registry-independent]
Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
A. Morton, "A registry for commonly used metrics.
Independent registries", draft-bagnulo-ippm-new-registry-
independent-01 (work in progress), July 2013.
[I-D.bagnulo-ippm-new-registry]
Akhter & Aitken Expires January 17, 2014 [Page 28]
Internet-Draft LMAP-framework July 2013
Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
A. Morton, "A registry for commonly used metrics", draft-
bagnulo-ippm-new-registry-01 (work in progress), July
2013.
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-
ietf-alto-protocol-17 (work in progress), July 2013.
[I-D.ietf-homenet-arch]
Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"Home Networking Architecture for IPv6", draft-ietf-
homenet-arch-09 (work in progress), July 2013.
[I-D.ietf-ipfix-a9n]
Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation
for the IP Flow Information Export (IPFIX) Protocol",
draft-ietf-ipfix-a9n-08 (work in progress), November 2012.
[I-D.ietf-ipfix-flow-selection-tech]
D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow
Selection Techniques", draft-ietf-ipfix-flow-selection-
tech-18 (work in progress), May 2013.
[I-D.ietf-ipfix-ie-doctors]
Trammell, B. and B. Claise, "Guidelines for Authors and
Reviewers of IPFIX Information Elements", draft-ietf-
ipfix-ie-doctors-07 (work in progress), October 2012.
[I-D.ietf-ipfix-information-model-rfc5102bis]
Claise, B. and B. Trammell, "Information Model for IP Flow
Information eXport (IPFIX)", draft-ietf-ipfix-information-
model-rfc5102bis-10 (work in progress), February 2013.
[I-D.ietf-ipfix-mediation-protocol]
Claise, B., Kobayashi, A., and B. Trammell, "Operation of
the IP Flow Information Export (IPFIX) Protocol on IPFIX
Mediators", draft-ietf-ipfix-mediation-protocol-05 (work
in progress), June 2013.
[I-D.ietf-ipfix-protocol-rfc5101bis]
Claise, B. and B. Trammell, "Specification of the IP Flow
Information eXport (IPFIX) Protocol for the Exchange of
Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-10
(work in progress), July 2013.
[I-D.ietf-netconf-reverse-ssh]
Akhter & Aitken Expires January 17, 2014 [Page 29]
Internet-Draft LMAP-framework July 2013
Watsen, K., "Reverse Secure Shell (Reverse SSH)", draft-
ietf-netconf-reverse-ssh-01 (work in progress), June 2013.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, January
2003.
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics
Registry", BCP 108, RFC 4148, August 2005.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, October 2008.
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
"Architecture for IP Flow Information Export", RFC 5470,
March 2009.
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
"Architecture for IP Flow Information Export", RFC 5470,
March 2009.
[RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A.,
Grossglauser, M., and J. Rexford, "A Framework for Packet
Selection and Reporting", RFC 5474, March 2009.
[RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A.,
Grossglauser, M., and J. Rexford, "A Framework for Packet
Selection and Reporting", RFC 5474, March 2009.
[RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling
(PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
Carle, "Information Model for Packet Sampling Exports",
RFC 5477, March 2009.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information Export
(IPFIX) Mediation: Problem Statement", RFC 5982, August
2010.
Akhter & Aitken Expires January 17, 2014 [Page 30]
Internet-Draft LMAP-framework July 2013
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi,
"IP Flow Information Export (IPFIX) Mediation: Framework",
RFC 6183, April 2011.
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization
Support", RFC 6235, May 2011.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics
(IPPM) Registry of Metrics Are Obsolete", RFC 6248, April
2011.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390,
October 2011.
[RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration Data
Model for the IP Flow Information Export (IPFIX) and
Packet Sampling (PSAMP) Protocols", RFC 6728, October
2012.
[RFC6759] Claise, B., Aitken, P., and N. Ben-Dvora, "Cisco Systems
Export of Application Information in IP Flow Information
Export (IPFIX)", RFC 6759, November 2012.
[RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare,
S., and E. Yedavalli, "Cisco Service-Level Assurance
Protocol", RFC 6812, January 2013.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
2013.
[iana-ipfix-assignments]
Internet Assigned Numbers Authority, ., "IP Flow
Information Export Information Elements
(http://www.iana.org/assignments/ipfix/ipfix.xml)", .
[lmap-wg-charter]
, "LMAP Working Group Charter
(http://tools.ietf.org/wg/lmap/charters)", .
Akhter & Aitken Expires January 17, 2014 [Page 31]
Internet-Draft LMAP-framework July 2013
[pm-dir] , "Performance Metrics Directorate (http://www.ietf.org/
iesg/directorate/performance-metrics.html)", .
Authors' Addresses
Aamer Akhter
Cisco Systems, Inc.
7025 Kit Creek Road
RTP, NC 27709
USA
Email: aakhter@cisco.com
Paul Aitken
Cisco Systems, Inc.
96 Commercial Street
Edinburgh, Scotland EH6 6LX
UK
Email: paitken@cisco.com
Akhter & Aitken Expires January 17, 2014 [Page 32]