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]