<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-eardley-lmap-framework-02"
     ipr="trust200902">
  <front>
    <title abbrev="LMAP Framework">A framework for large-scale
    measurements</title>

    <author fullname="Philip Eardley" initials="P." surname="Eardley">
      <organization abbrev="BT">British Telecom</organization>

      <address>
        <postal>
          <street>Adastral Park, Martlesham Heath</street>

          <city>Ipswich</city>

          <country>ENGLAND</country>
        </postal>

        <email>philip.eardley@bt.com</email>
      </address>
    </author>

    <author fullname="Trevor Burbridge" initials="T." surname="Burbridge">
      <organization abbrev="BT">British Telecom</organization>

      <address>
        <postal>
          <street>Adastral Park, Martlesham Heath</street>

          <city>Ipswich</city>

          <country>ENGLAND</country>
        </postal>

        <email>trevor.burbridge@bt.com</email>
      </address>
    </author>

    <author fullname="Al Morton" initials="A." surname="Morton">
      <organization abbrev="AT&amp;T Labs">AT&amp;T Labs</organization>

      <address>
        <postal>
          <street>200 Laurel Avenue South</street>

          <city>Middletown, NJ</city>

          <country>USA</country>
        </postal>

        <email>acmorton@att.com</email>
      </address>
    </author>

    <date day="15" month="July" year="2013"/>

    <abstract>
      <t>Measuring broadband service on a large scale requires standardisation
      of the logical architecture and a description of the key protocols that
      coordinate interactions between the components. The document presents an
      overall framework for large-scale measurements and discusses which
      elements could be standardised in the IETF. It is intended to assist the
      work of the LMAP working group.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The Large-Scale Measurement of Broadband Performance (LMAP) working
      group standardizes the LMAP measurement system for performance
      measurements of broadband access devices such as home and enterprise
      edge routers, personal computers, mobile devices, set top box, whether
      wired or wireless. Measuring portions of the Internet on a large scale
      is essential for accurate characterizations of performance over time and
      geography.</t>

      <t><xref target="use-cases"/> discusses several use cases have been
      proposed for large-scale measurements:</t>

      <t><list style="symbols">
          <t>Operators: to help plan their network and identify faults</t>

          <t>End Users: to run diagnostic checks, such as a network speed
          test</t>

          <t>Regulators: to benchmark several network operators and support
          public policy development</t>
        </list>The LMAP framework should be useful for all these.</t>

      <t>The goal is to have the measurements (made using the same metrics and
      mechanisms) for a large number of points on the Internet, and to have
      the results collected and stored in the same form.</t>

      <t>There are existing measurement systems. However, they typically lack
      some of the desirable features for a large-scale measurement system:</t>

      <t><list style="symbols">
          <t>Standardised - in terms of the tests that they perform, the
          components, the data models and protocols for transferring
          information between the components. For example so that it is
          meaningful to compare measurements made of the same metric at
          different times and places. For example so that the operator of a
          measurement system can buy the various components from different
          vendors. Today's systems are proprietary in some or all of these
          aspects.</t>

          <t>Extensible - it should be easy to add or modify tests, for
          example an improved test methodology or to measure a performance
          metric not previously considered important (e.g., bufferbloat).</t>

          <t>Large-scale - <xref target="use-cases"/> envisages Measurement
          Agents in every home gateway and edge device such as set-top-boxes
          and tablet computers. Existing systems have up to a few thousand
          Measurement Agents (without judging how much further they could
          scale).</t>

          <t>Diversity - a measurement system should handle different types of
          Measurement Agent - for example Measurement Agents may come from
          different vendors, be in wired and wireless networks and be on
          devices with IPv4 or IPv6 addresses.</t>
        </list></t>
    </section>

    <section title="Outline of framework">
      <t>The LMAP framework for large-scale measurements has four
      elements:</t>

      <t><list style="symbols">
          <t>Measurement Agent (MA)</t>

          <t>Measurement Peer</t>

          <t>Controller</t>

          <t>Collector</t>
        </list>In addition there are some components that are outside LMAP but
      useful within the context of a large scale measurement system:</t>

      <t><list style="symbols">
          <t>Initialiser</t>

          <t>Subscriber Parameter Database</t>

          <t>Results Database</t>

          <t>Data Analysis Tools</t>

          <t>Operator's OAM (Operations Administration and Management)</t>
        </list></t>

      <t>a large-scale measurement system essentially has three sets of
      communications:</t>

      <t><list style="symbols">
          <t>several measurement protocols between a Measurement Agent and a
          Measurement Peer</t>

          <t>a Control Protocol between a Controller and a MA</t>

          <t>a Report Protocol between a MA and a Collector.</t>
        </list></t>

      <t>A Measurement Agent and a Measurement Peer jointly perform an active
      measurement test, by generating test traffic and measuring some metric
      associated with its transfer over the path from one to the other; for
      example the time taken to transfer a &lsquo;test file&rsquo;. A MA may
      also conduct passive testing through the observation of traffic (i.e.
      without the involvement of a Measurement Peer); for example an end
      user's mix of applications.</t>

      <t>The MA interacts with the Controller and Collector, and a Measurement
      Peer only takes part in active tests (and does not interact with the
      Controller and Collector).</t>

      <t>The MA functions are implemented either in specialised hardware or as
      code on general purpose devices like a PC, tablet or smartphone. The
      Measurement Peer may be an LMAP device or a normal, non-LMAP device (for
      example if the MA measures the time for a DNS response or a webpage
      download from www.example.com).</t>

      <t>The Controller manages a MA by instructing it which tests it should
      perform and when. For example it may instruct a MA at a home gateway:
      &ldquo;Run the &lsquo;download speed test&rsquo; with the test server at
      the end user's first IP point in the network; if the end user is active
      then delay the test and re-try 1 minute later, with up to 3 re-tries;
      repeat every hour at xx.05 + Unif[0,180] seconds&rdquo;. The Controller
      also manages a MA by instructing it how to report the test results, for
      example: &ldquo;Report results once a day in a batch at 4am +
      Unif[0,180] seconds; if the end user is active then delay the report 5
      minutes&rdquo;. As well as regular tests, a Controller can initiate a
      one-off test ("Do test now", "Report as soon as possible"). These are
      called the Test and Report Schedule.</t>

      <t>The Collector accepts a Report from a MA with the results from its
      tests. It may also do some processing on the results &ndash; for
      instance to eliminate outliers, as they can severely impact the
      aggregated results.</t>

      <t>Therefore the MA is a LMAP-specific device that initiates the test,
      gets instructions from the Controller and reports to the Collector.</t>

      <t>It is possible that communications between two Collectors, two
      Controllers and a Controller and Collector may be useful in some use
      cases, perhaps to help a measurement system scale. Work on such a
      protocol is out of scope of LMAP (?)</t>

      <t>The Initialiser, Subscriber Parameter Database, Results Database,
      Data Analysis Tools and OAM are out of scope of LMAP. They may be
      provided through existing protocols or applications and are likely to be
      part of a complete large-scale measurement system. See Section 5 for
      further discussion.</t>

      <t><figure>
          <artwork><![CDATA[+------------+                 +-----------+               +-----------+
|            |   Instruction   |           | test traffic  |           |
| Controller | --------------> |Measurement| ............. |Measurement|
|            |                 |Agent (MA) |               |   Peer    |
+------------+                 +-----------+               +-----------+
                                     |
                                     | Report
                                     |
                                     V
                               +-------------+
                               |  Collector  |
                               +-------------+

Figure 1: Schematic of main elements of LMAP framework
]]></artwork>
        </figure></t>
    </section>

    <section title="Constraints">
      <t/>

      <section title="Measurement system is under the direction of a single organisation">
        <t>In the LMAP framework (as defined in the WG's charter) the
        measurement system is under the direction of a single organisation
        that is responsible both for the data and the quality of experience
        delivered to its users. Clear responsibility is critical given that a
        misbehaving large-scale measurement system could potentially harm user
        experience, user privacy and network security.</t>

        <t>However, the components of an LMAP measurement system can be
        deployed in administrative domains that are not owned by the measuring
        organisation. Thus, the system of functions deployed by a single
        organisation constitutes a single LMAP domain which may span ownership
        or other administrative boundaries.</t>

        <t>Note that different LMAP measurement systems may overlap, in the
        sense that the active measurement packets of one measurement system
        appear along with normal user traffic to another measurement system.
        For instance, imagine an operator with an MA on the home gateway and
        an end user with an MA on their laptop. Rather than making separate
        measurements, an organisation might share its measurement data, or a
        suitably anonymised version of it, with another organisation. However,
        any form of coordination between different organisation involves
        difficult commercial and technical issues and so, given the novelty of
        large-scale measurement efforts, any form of inter-organisation
        coordination is outside the scope of LMAP.</t>
      </section>

      <section title="Each MA may only have a single Controller at any point in time">
        <t>The constraint avoids different Controllers giving a MA conflicting
        instructions and so means that the MA does not have to manage
        contention between multiple Test (or Report) Schedules. This
        simplifies the design of MAs (critical for a large-scale
        infrastructure) and allows a Test Schedule to be tested on specific
        types of MA before deployment to ensure that the home user experience
        is not impacted (due to CPU, memory or broadband-product
        constraints).</t>

        <t>An operator may have several Controllers, perhaps with a Controller
        for different types of MA (home gateways, tablets) or location
        (Ipswich, Edinburgh).</t>

        <t>To avoid problems with NAT and firewalls, it is likely that the MA
        &lsquo;pulls&rsquo; the configuration from its Controller, as
        identified by the Initialiser.</t>

        <t><list style="symbols">
            <t>Open issue: Should there be negotiation between a Controller
            and its MA, or should the Controller simply instruct the MA by
            sending its Test and Report Schedules?<list style="symbols">
                <t>The argument for negotiation is that occasionally the MA
                may be updated with enhanced with versions of existing tests.
                It is easier for the Controller to learn the MAs capabilities
                directly from the MA than from a management system. It avoids
                any mis-synchronisation.</t>

                <t>The argument against negotiation is that it makes the
                Controller-MA protocol more complicated, increases the MAs
                resource requirements and increases the complexity of the
                Controller when it decides how to schedule tests across
                numerous MAs or when it deploys a new Test Schedule to
                potentially millions of MAs.</t>
              </list></t>

            <t>Open issue: what happens if a Controller fails, how is the MA
            is homed onto a new one?</t>
          </list></t>
      </section>

      <section title="A Measurement Agent acts autonomously">
        <t>Once the MA gets its Test and Report Schedules from its Controller
        then it acts autonomously, in terms of operation of the tests and
        reporting of the result.</t>

        <t>Firstly, this means that the MA initiates Measurement Tasks. For
        the typical case where the MA is on a home gateway or edge device,
        this means that the MA initiates a &lsquo;download speed test&rsquo;
        by asking a Measurement Peer to send the file. The main rationale is
        that, for a test that should be performed when there is no user
        traffic on the link, the MA knows whether the end user is active and
        therefore whether to start the test or delay it. Having the Schedule
        on the MA also avoids it having to check frequently with the
        Controller. Further, if the MA is behind a NAT then the Measurement
        Peer naturally learns its public-facing IP address.</t>

        <t>Secondly, it is useful for the MA and perhaps the Measurement Peer
        to make some 'admission control' checks at the initiation of the
        Measurement Task to ensure that desired test conditions are present.
        The exchange of initialization packets between the MA and Measurement
        Peer ensures basic connectivity between them. Also, the MA may delay
        Measurement Task may if the associated subscriber is active, or the
        Measurement Peer may reject a testing request if it is overloaded. It
        has also been suggested that, in extremis, the Controller may want the
        ability to send a Measurement Suppression message to an MA, which
        causes the Measurement Tasks to be temporarily stopped.</t>

        <t>Last, it is easier to secure the reporting process, for example
        with a unique certificate for each MA-Collector pair, so that the
        Collector is confident the results really do originate from the MA.
        All measurement results are sent from the MA.</t>
      </section>
    </section>

    <section title="Work items for LMAP WG">
      <t>This Section considers the work that the LMAP working group needs to
      tackle. Section 5 considers other work that needs doing that would be
      beyond the scope of the LMAP WG.</t>

      <t>The main work items are:<list style="symbols">
          <t>Information Model, the abstract definition of the information
          carried from the Controller to the MA and the information carried
          from the MA to the Collector.</t>

          <t>Control protocol and the associated data model: The definition of
          how instructions are delivered from a Controller to a MA; this
          includes a Data Model consistent with the Information Model plus a
          transport protocol.</t>

          <t>Report protocol and the associated data model: The definition of
          how the Report is delivered from a MA to a Collector; this includes
          a Data Model consistent with the Information Model plus a transport
          protocol.</t>
        </list></t>

      <section title="Information Model">
        <t>The Information Model provides a protocol and device independent
        view of the information carried from the Controller to the MA and the
        information carried from the MA to the Collector. It can be
        implemented via a Control Protocol and Report Protocol, as defined by
        the LMAP WG. It is also possible that other Control and Report
        Protocols could be defined by other standards bodies or proprietary,
        however it is important that they all implement the same Information
        Model, in order to ease the definition, operation and interoperability
        of large-scale measurement systems.</t>

        <t>The Information Model also includes information that is
        pre-configured on the MA in order that it can start communicating with
        a Controller.</t>

        <t>An initial proposal for the Information Model is in <xref
        target="information-model"/>.</t>

        <t>The Information Model is divided into two main parts, each of which
        may be broken down into sub-parts:<list style="symbols">
            <t>information about the Instruction: Information that is received
            by the MA from the Controller pertaining to the measurement and
            reporting configuration. This includes:<list style="symbols">
                <t>what measurements to do: the Measurement Task could be
                defined by reference to a registry entry, along with any
                parameters that need to be set (such as the address of the
                Measurement Peer) and any Environmental Constraint (such as,
                delay the test if the end user is active)</t>

                <t>when to do them: the Measurement Schedule details the
                timings of regular tests, one-off tests, and if regularly
                tests should be temporarily suppressed</t>

                <t>how to report the Measurement Results: via Reporting
                Channel(s), each of which defines a target Collector and
                Report Schedule</t>
              </list></t>

            <t>information about the Report: Information transmitted from the
            MA to the Collector including measurement results and the context
            in which they were conducted. This includes:<list style="symbols">
                <t>the MAs identifier, or perhaps a Group-ID to anonymise
                results</t>

                <t>the actual Measurement Results, including the time they
                were measured</t>

                <t>the details of the Measurement Task (to avoid the Collector
                having to ask the Controller for this information later)</t>
              </list></t>
          </list></t>

        <t>It is important to consider how to divide the Information Model
        into (sub-)parts, so that each (sub-)part can be updated independently
        at different times and regularities, as discussed in <xref
        target="information-model"/></t>
      </section>

      <section title="Control Protocol">
        <t>The Control protocol and its associated data model define how
        instructions are delivered from a Controller to a MA; 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).</t>
      </section>

      <section title="Report Protocol">
        <t>The Report protocol and the associated data model: The definition
        of how the Report is delivered from a MA 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).</t>
      </section>
    </section>

    <section title="Related work required but out of scope of LMAP">
      <t>This section considers the items that need to be agreed between
      deployers of large-scale measurement systems, but that are out of scope
      of the LMAP WG (Section 4 considers items within its scope).</t>

      <section title="Standard measurement tests">
        <t>Standardised methods are needed for each metric that is measured. A
        registry for commonly-used metrics <xref target="registry"/> is also
        required, so that a test can be defined simply by its identifier in
        the registry. The methods and registry would hopefully also be
        referenced by other standards organisations.</t>

        <t><list style="symbols">
            <t>Such activities are in scope of the IPPM working group
            (possibly re-chartered) and not LMAP.</t>
          </list>A new (or revised) test may need to be uploaded to MAs. How
        this is done is out of scope of the IETF; it could be as a firmware
        upgrade for a home hub, or new app for a PC, etc and may be
        device-specific.</t>
      </section>

      <section title="Characterisation plan">
        <t>Each organisation operating an LMAP system and collecting
        measurements for comparison purposes needs to conduct the same
        measurements according to the same sampling plan (ie size and
        schedule) and make the results available in the same format. The scope
        of comparison determines the set of organisations needing to agree on
        the common characterisation plan; for example those falling within the
        same regulatory environment in a particular country or region. Such
        agreements are certainly facilitated by IETF's work, but the details
        of the plan are beyond the scope of work in IETF.</t>
      </section>

      <section title="Other elements">
        <t>Other elements may be useful within the context of a large scale
        measurement system and worthy of standardisation, but are outside the
        scope of the LMAP WG: Initialiser, Subscriber Parameter Database,
        Results Database, Data Analysis Tools and operator's OAM.</t>

        <t>An Initialiser configures a MA with details about its Controller,
        including authentication credentials. A bootstrap protocol is likely
        to be technology specific and so for different types of device could
        be defined by the Broadband Forum, DOCSIS or IEEE. Possible protocols
        are SNMP, NETCONF or (for Home Gateways) CPE WAN Management Protocol
        (CWMP) from the Auto Configuration Server (ACS) (as specified in
        TR-069).</t>

        <t>A Subscriber Parameter Database contains information about the
        line, for example the customer's broadband contract (2, 40 or 80Mb/s),
        the line technology (DSL or fibre), the time zone where the MA is
        located, and the type of home gateway and MA. These are all factors
        which may affect the choice of what Measurement Tasks to run and how
        to interpret the Measurement Results. For example, a download test
        suitable for a line with an 80Mb/s contract may overwhelm a 2Mb/s
        line. Another example is if the Controller wants to run a one-off test
        to diagnose a fault, then it should understand what problem the
        customer is experiencing and what tests have already been run. The
        subscribers' service parameters are already gathered and stored by
        existing operations systems.</t>

        <t>A Results Database records all measurements in an equivalent form,
        for example an SQL database <xref target="schulzrinne"/>, so that they
        can be easily accessed by the Data Analysis Tools whilst the LMAP
        system implementor can choose local solutions for each component. The
        Data Analysis Tools also need to understand subscriber service
        information, for example the broadband contract.</t>

        <t>The Data Analysis Tools receive the results from the Collector or
        via the Results Database. They might visualise the data or identify
        which component or link is likely to be the cause of a fault or
        degradation.</t>

        <t>The operator's OAM (Operations, Administration and Management) uses
        the results from the tools.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The security of the LMAP framework should protect the interests of
      the measurement operator(s), the network user(s) and other actors who
      could be impacted by a compromised measurement deployment.</t>

      <t>We assume that each Measurement Agent will receive test
      configuration, scheduling and reporting instructions from a single
      organisation (operator of the Controller). These instructions must be
      authenticated (to ensure that they come from the trusted Controller),
      checked for integrity (to ensure no-one has tampered with them) and be
      prevented from replay. If a malicious party can gain control of the
      Measurement Agent they can use the MA capabilities to launch DoS attacks
      at targets, reduce the network user experience and corrupt the
      measurement results that are reported to the Collector. By altering the
      tests that are operated and/or the Collector address they can also
      compromise the confidentiality of the network user and the MA
      environment (such as information about the location of devices or their
      traffic).</t>

      <t>The reporting of the MA must also be secured to maintain
      confidentiality. The results must be encrypted such that only the
      authorised Collector can decrypt the results to prevent the leakage of
      confidential or private information. In addition it must be
      authenticated that the results have come from the expected MA and that
      they have not been tampered with. It must not be possible to spoof an MA
      to inject falsified data into the measurement platform or to corrupt the
      results of a real MA.</t>

      <t>Availability should also be considered. While the loss of some MAs
      may not be considered critical, the unavailability of the Collector
      could mean that valuable business data or data critical to a regulatory
      process is lost. Similarly, the unavailability of a Controller could
      mean that the MAs continue to operate an incorrect test schedule or fail
      to initiate.</t>

      <t>A malicious party could "game the system". For example, where a
      regulator is running a measurement system in order to benchmark
      operators, an operator could try to identify the broadband lines that
      the regulator was measuring and prioritise that traffic. This potential
      issue is currently handled by a code of conduct. It is outside the scope
      of the LMAP WG to consider the issue.</t>

      <t>Concerning privacy and data protection, the role of the LMAP
      framework should be to ensure that only authorised data is collected and
      that this data is returned securely to the framework operator. Data
      should be stored securely and onward sharing of data to other parties
      should be controlled according to local data protection regulations.
      Depending upon the ownership/placement of the MA, local data protection
      laws, the tests being operated and existing user agreements, it is
      possible that additional consent may need to be secured from parties
      such as the home broadband user. Having the measurement system under the
      direction of a single organisation clarifies the responsibility for data
      protection.</t>

      <t>The next versions of <xref target="lmap-yang"/> and <xref
      target="lmap-ipfix"/> will also include further consideration of
      security.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Thanks to numerous people for much discussion, directly and on the
      LMAP list. This document tries to capture the current conclusions.</t>

      <t>Philip Eardley and Trevor Burbridge work in part on the Leone
      research project, which receives funding from the European Union Seventh
      Framework Programme [FP7/2007-2013] under grant agreement number
      317647.</t>
    </section>

    <section title="Changes ">
      <t/>

      <section title="from -00 to -01">
        <t>aligned with terminology in draft-eardley-lmap-terminology</t>

        <t>introduced aspects mentioned in the LMAP WG charter</t>

        <t>introduced aspects from the Information model in
        draft-burbridge-lamp-information-model</t>
      </section>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <reference anchor="use-cases"
                 target="http://tools.ietf.org/html/draft-linsner-lmap-use-cases">
        <front>
          <title>Large-Scale Broadband Measurement Use Cases</title>

          <author fullname="Marc Linsner">
            <organization/>
          </author>

          <author fullname="Philip Eardley">
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="lmap-yang"
                 target="http://tools.ietf.org/html/draft-schoenw-lmap-yang">
        <front>
          <title>A YANG Data Model for LMAP Measurement Agents</title>

          <author fullname="Juergen Schoenwaelder">
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="lmap-netconf"
                 target="http://tools.ietf.org/html/draft-schoenw-lmap-netconf">
        <front>
          <title>Considerations on using NETCONF with LMAP Measurement
          Agents</title>

          <author fullname="Juergen Schoenwaelder">
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="lmap-ipfix"
                 target="http://tools.ietf.org/html/draft-bagnulo-lmap-ipfix">
        <front>
          <title>An LMAP application for IPFIX</title>

          <author fullname="Marcelo Bagnulo">
            <organization/>
          </author>

          <author fullname="Brian Trammell">
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="registry"
                 target="http://tools.ietf.org/html/draft-bagnulo-ippm-new-registry-independent">
        <front>
          <title>A registry for commonly used metrics. Independent
          registries</title>

          <author fullname="Marcelo Bagnulo">
            <organization/>
          </author>

          <author fullname="Trevor Burbridge">
            <organization/>
          </author>

          <author fullname="Sam Crawford">
            <organization/>
          </author>

          <author fullname="Philip Eardley">
            <organization/>
          </author>

          <author fullname="Al Morton">
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC6241" target="http://tools.ietf.org/html/rfc6241">
        <front>
          <title>Network Configuration Protocol (NETCONF)</title>

          <author fullname="R. Enns">
            <organization/>
          </author>

          <author fullname="M. Bjorklund">
            <organization/>
          </author>

          <author fullname="J. Schoenwaelder">
            <organization/>
          </author>

          <author fullname="A. Bierman">
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="yang-api" target="http://tools.ietf.org/html/rfc6241">
        <front>
          <title>YANG-API Protocol</title>

          <author fullname="A. Bierman">
            <organization/>
          </author>

          <author fullname="M. Bjorklund">
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="schulzrinne"
                 target="http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements">
        <front>
          <title>Large-Scale Measurement of Broadband Performance: Use Cases,
          Architecture and Protocol Requirements</title>

          <author fullname="Henning Schulzrinne">
            <organization/>
          </author>

          <author fullname="W Johnston">
            <organization/>
          </author>

          <author fullname="James Miller">
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="information-model"
                 target="http://tools.ietf.org/html/draft-burbridge-lmap-information-model">
        <front>
          <title>Information Model for Large-Scale Measurement Platforms
          (LMAP)</title>

          <author fullname="Trevor Burbridge" initials="T."
                  surname="Burbridge">
            <organization/>
          </author>

          <author fullname="Philip Eardley" initials="P." surname="Eardley">
            <organization/>
          </author>

          <author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
            <organization/>
          </author>

          <author fullname="Juergen Schoenwaelder" initials="J."
                  surname="Schoenwaelder">
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
