A Framework and Inventory for a Large Scale Measurement System
Author(s): Paul Aitken, Aamer Akhter
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...
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 [RFC 2119]. 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. [RFC 2119] 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", RFC3444, January 2003. [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC4148, August 2005. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC4656, September 2006. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC5357, October 2008. [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC5470, March 2009. [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC5470, March 2009. [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC5474, March 2009. [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC5474, March 2009. [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC5476, March 2009. [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC5477, March 2009. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC5533, June 2009. [RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information Export (IPFIX) Mediation: Problem Statement", RFC5982, 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)", RFC6020, October 2010. [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC6183, April 2011. [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC6235, May 2011. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6248] Morton, A., "RFC4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete", RFC6248, April 2011. [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC6390, 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", RFC6728, October 2012. [RFC6759] Claise, B., Aitken, P., and N. Ben-Dvora, "Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)", RFC6759, November 2012. [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, S., and E. Yedavalli, "Cisco Service-Level Assurance Protocol", RFC6812, January 2013. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC6887, 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: firstname.lastname@example.org Paul Aitken Cisco Systems, Inc. 96 Commercial Street Edinburgh, Scotland EH6 6LX UK Email: email@example.com Akhter & Aitken Expires January 17, 2014 [Page 32]