<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc text-list-symbols="o*+-"?>

<rfc number="7398" category="info" submissionType="IETF" consensus="yes" ipr="trust200902">
<front>
<title abbrev="LMAP Reference Path">A Reference Path and Measurement
    Points for Large-Scale Measurement of Broadband Performance</title>

    <author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
      <organization abbrev="UC3M">Universidad Carlos III de Madrid</organization>
      <address>
        <postal>
          <street>Av. Universidad 30</street>
          <city>Leganes</city>
          <region>Madrid</region>
          <code>28911</code>
          <country>Spain</country>
        </postal>
        <phone>34 91 6249500</phone>
        <email>marcelo@it.uc3m.es</email>
        <uri>http://www.it.uc3m.es</uri>
      </address>
    </author>

    <author fullname="Trevor Burbridge" initials="T." surname="Burbridge">
      <organization abbrev="BT">BT</organization>
      <address>
        <postal>
          <street>Adastral Park, Martlesham Heath</street>
          <city>Ipswich</city>
          <country>United Kingdom</country>
        </postal>
        <email>trevor.burbridge@bt.com</email>
      </address>
    </author>

    <author fullname="Sam Crawford" initials="S." surname="Crawford">
      <organization abbrev="SamKnows">SamKnows</organization>
      <address>
        <email>sam@samknows.com</email>
      </address>
    </author>

    <author fullname="Philip Eardley" initials="P." surname="Eardley">
      <organization abbrev="BT">BT</organization>
      <address>
        <postal>
          <street>Adastral Park, Martlesham Heath</street>
          <city>Ipswich</city>
          <country>United Kingdom</country>
        </postal>
        <email>philip.eardley@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>United States</country>
        </postal>
        <email>acmorton@att.com</email>
      </address>
    </author>

    <date month="January" year="2015"/>

    <abstract>
      <t>This document defines a reference path for Large-scale Measurement of
      Broadband Access Performance (LMAP) and measurement points for commonly
      used performance metrics. Other similar measurement projects may also be
      able to use the extensions described here for measurement point
      location. The purpose is to create an efficient way to describe the
      location of the measurement point(s) used to conduct a particular
      measurement.
</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document defines a reference path for Large-scale Measurement of
      Broadband Access Performance (LMAP) or similar measurement projects. The
      series of IP Performance Metrics (IPPM) RFCs have developed terms that
      are generally useful for path description (see Section 5 of <xref
      target="RFC2330"/>). 
      There are a limited number of additional terms
      defined in this memo.</t>
      
      <t>The reference path (see Section 3.1 and Figure 1 of <xref
      target="Y.1541"/>, including the accompanying discussion) is usually
      needed when attempting to communicate precisely about the components
      that comprise the path, and is often expressed in terms of their number (hops) and
      geographic location. This memo takes the path definition further by
      establishing a set of measurement points along the path and ascribing a
      unique designation to each point. This topic has been previously
      developed in Section 5.1 of <xref target="RFC3432"/> and as part of the
      updated framework for composition and aggregation in Section 4 of <xref
      target="RFC5835"/>. Section 4.1 of <xref target="RFC5835"/> defines the
      term "measurement point".</t>

      <t>Measurement points and the paths they inhabit are often described in
      general terms, like "end-to-end", "user-to-user", or "access". 
These terms alone are insufficient for the scientific method, since we need to
clarify issues such as: What is an end?  Where is a user located? Is the home
network included?
</t>

      <t>As an illustrative example, consider a measurement agent in an LMAP
      system. When it reports its measurement results, rather than detailing
      its IP address and that of its measurement peer, it may prefer to
      describe the measured path segment abstractly (perhaps for privacy
      reasons), e.g.,
      'from a measurement agent at a home gateway to a
      measurement peer at a DSLAM.' This memo provides the definition for such
      abstract 'measurement points' and, therefore, the portion of 'reference
      path' between them.</t>

      <t>The motivation for this memo is to provide an unambiguous framework
      to describe measurement coverage or scope of the reference path. This
      is an essential part of the metadata to describe measurement results.
      Measurements conducted over different path scopes are not a valid basis
      for performance comparisons. We note that additional measurement context
      information may be necessary to support a valid comparison of
      results.</t>

      <section title="Requirements Language">
        <t>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 <xref
        target="RFC2119">RFC 2119</xref>.</t>
      </section>
    </section>

    <section title="Purpose and Scope">
      <t>The scope of this memo is to define a reference path for LMAP
      activities with a sufficient level of detail to determine the location of
      different measurement points along a path without ambiguity. These
      conventions are likely to be useful in other measurement projects
      and to describe the applicable measurement scope for some
      metrics.</t>

      <t>The connection between the reference path and specific network
      technologies (with differing underlying architectures) is within the
      scope of this memo, and examples are provided. Both wired and wireless
      technologies are in scope.

</t>

      <t>The purpose is to create an efficient way to describe the location of
      the measurement point(s) used to conduct a particular measurement so
      that the measurement result will be adequately described in terms of scope
      or coverage. This should serve many measurement uses, including:</t>

      <t><list style="symbols">
          <t>diagnostic, where the same metric would be measured on
          different sub-paths bounded by measurement points (see Section 4.10
          of <xref target="RFC5835"> </xref>), for example, to isolate the
          sub-path contributing the majority of impairment levels observed on
          a path.</t>

          <t>comparison, where the same metric may be measured on
          equivalent portions of different network infrastructures, for
          example, to compare the performance of wired and wireless home
          network technologies.</t>
        </list></t>
    </section>

    <section title="Terms and Definitions">
      <t>This section defines key terms and concepts for this
      memo.</t>

      <section title="Reference Path">
        <t>A reference path is a serial combination of hosts, routers,
        switches, links, radios, and processing elements that comprise all the
        network elements traversed by each packet in a flow between the source
        and destination hosts. A reference path also indicates the various
        boundaries present, such as administrative boundaries. A reference
        path is intended to be equally applicable to all IP and link-layer
        networking technologies. Therefore, the components are generically
        defined, but their functions should have a clear counterpart or be
        obviously omitted in any network architecture.</t>
      </section>

      <section title="Subscriber">
        <t>A subscriber is an entity (associated with one or more users) that is engaged in a
        subscription with a service provider. The subscriber is allowed to
        subscribe and unsubscribe to services and to register a user or a
        list of users authorized to enjoy these services. <xref
        target="Q.1741"/> </t>
<t>
Both the subscriber and service provider are allowed
        to set the limits relative to the use that associated users make of
        subscribed services.
</t>
      </section>

      <section title="Dedicated Component (Links or Nodes)">
        <t>All resources of a dedicated component (typically a link or node on
        the reference path) are allocated to serving the traffic of an
        individual subscriber. Resources include transmission time-slots,
        queue space, processing for encapsulation and address/port
        translation, and others. A dedicated component can affect the
        performance of the reference path or the performance of any sub-path
        where the component is involved.</t>
      </section>

      <section title="Shared Component (Links or Nodes) ">
        <t>A component on the reference path is designated a "shared component"
        when the traffic associated with multiple subscribers is served by
        common resources.</t>
      </section>

      <section title="Resource Transition Point">
        <t>This is a point between dedicated and shared components on a reference path
        that may be a point of significance and is identified as a transition
        between two types of resources.</t>
      </section>

      <section title="Service Demarcation Point">
        <t>This is the point where a service managed by the service provider
        begins (or ends) and varies by technology. For example, this point is
        usually defined as the Ethernet interface on a residential gateway or
        modem where the scope of a packet transfer service begins and ends. In
        the case of a WiFi service, this would be an air interface within the
        intended service boundary (e.g., walls of the coffee shop). The
        demarcation point may be within an integrated endpoint using an air
        interface (e.g., Long-Term Evolution User Equipment (LTE UE)).
        Ownership does not necessarily affect the demarcation point; a
        subscriber may own all equipment on their premises, but it is likely
        that the service provider will certify such equipment for connection
        to their network or that a third-party will certify standards
        compliance.</t>
      </section>

      <section title="Managed and Unmanaged Sub-paths">
        <t>Service providers are responsible for the portion of the path they
        manage. However, most paths involve a sub-path that is beyond the
        management of the subscriber's service provider. This means that
        private networks, wireless networks using unlicensed frequencies, and
        the networks of other service providers are designated as unmanaged sub-paths.
        The service demarcation point always divides managed and unmanaged
        sub-paths.</t>
      </section>
    </section>

    <section title="Reference Path">
      <t>This section defines a reference path for Internet communication.</t>

   <t><figure anchor="fig1" align="center" title="Reference Path">
<artwork><![CDATA[
Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit ...
device     Net #1     Net #2    Demarc.    Access     GW     GRA GW     


... Transit -- GRA -- Service -- Private -- Private -- Destination 
    GRA GW     GW     Demarc.    Net #n     Net #n+1   Host

                GRA = Globally Routable Address
                 GW = Gateway
]]></artwork>

        </figure></t>

      <t>The following are descriptions of reference path components that may
      not be clear from their name alone.</t>

      <t><list style="symbols">
          <t>Subsc. (Subscriber) device - This is a host that normally
          originates and terminates communications conducted over the IP
          packet transfer service.</t>

          <t>Private Net #x - This is a network of devices owned and operated
          by the Internet service subscriber. In some configurations, one or
          more private networks and the device that provides the service
          demarcation point are collapsed in a single device (ownership
          may shift to the service provider); this should be noted as part
          of the path description.</t>

          <t>Intra IP Access - This is the first point in the access
          architecture, beyond the service demarcation, where a globally routable IP
          address is exposed and used for routing. In architectures that use
          tunneling, this point may be equivalent to the Globally Routable
          Address Gateway (GRA GW). This point could also collapse to the
          device providing the service demarcation, in principle. Only one Intra
          IP Access point is shown, but they can be identified in any access
          network.</t>

          <t>GRA GW - This is the point of interconnection between a service
          provider's administrative domain and the rest of the Internet, where
          routing will depend on the GRAs in the IP header.</t>

          <t>Transit GRA GW - If one or more networks intervene between the
          service provider's access networks of the subscriber and of the
          destination host, then such networks are designated "transit" and
          are bounded by two transit GRA GWs.</t>

        </list>Use of multiple IP address families in the measurement path
	must be noted, as the conversions between IPv4 and IPv6 certainly
      influence the visibility of a GRA for each family.</t>

      <t>In the case that a private address space is used throughout an access
      architecture, then the Intra IP Access points must use the same address
      space as the service demarcation point, and the Intra IP Access points
      must be selected such that a test between these points produces a useful
      assessment of access performance (e.g., includes both shared and
      dedicated access link infrastructure).</t>
    </section>

    <section title="Measurement Points">
      <t>A key aspect of measurement points, beyond the definition in Section
      4.1 of <xref target="RFC5835"/>, is that the innermost IP header and
      higher-layer information must be accessible through some means. This is
      essential to measure IP metrics. There may be tunnels and/or other
      layers that encapsulate the innermost IP header, even adding another IP
      header of their own.</t>

      <t>In general, measurement points cannot always be located exactly where
      desired. However, the definition in <xref target="RFC5835"/> and the
      discussion in Section 5.1 of <xref target="RFC3432"/> indicate that
      allowances can be made; for example, it is nearly ideal when there are
      deterministic errors that can be quantified between desired and actual
      measurement points.</t>

      <t>The figure below illustrates the assignment of measurement points to
      selected components of the reference path.</t>

      <t><figure anchor="fig2" align="center" title="Reference Path with Measurement Point Designations">
<artwork><![CDATA[
Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit ...
device     Net #1     Net #2    Demarc.    Access     GW     GRA GW     
mp000                            mp100      mp150    mp190    mp200     


... Transit -- GRA -- Service -- Private -- Private -- Destination 
    GRA GW     GW     Demarc.    Net #n     Net #n+1   Host
    mpX90     mp890   mp800                            mp900     

                GRA = Globally Routable Address
                 GW = Gateway
]]></artwork>

        </figure></t>

      <t>Each measurement point on a specific reference path MUST be assigned
      a unique number. To facilitate interpretation of the results, the
      measuring organization (and whoever it shares results with) MUST have an
      unambiguous understanding of what path or point was measured. In order
      to achieve this, a set of numbering recommendations follow.</t>

      <t>When communicating the results of measurements, the measuring
      organization SHOULD supply a diagram similar to <xref target="fig2" /> (with the
      technology-specific information in examples that follow) and MUST
      supply it when additional measurement point numbers have been defined
      and used (with sufficient detail to identify measurement locations in
      the path).</t>

      <t>Ideally, the consumer of measurement results would know the location
      of a measurement point on the reference path from the measurement point
      number alone; the recommendations below provide a way to accomplish
      this goal. Although the initial numbering may be fully compliant with
      this system, changing circumstances could, over time, lead to gaps in
      network numbers or non-monotonic measurement point number assignments
      along the path. Such circumstances could include growth, consolidation,
      re-arrangement, and change of ownership of the network.
These are examples of reasonable causes for numbering
      deviations that must be identified on the reference path diagram, as
      required above.</t>

      <t>While the numbering of a measurement point is in the context of a
      particular path, for simplicity, the measuring organization SHOULD use
      the same numbering for a device (playing the same role) on all the
      measurement paths through it. Similarly, whilst the measurement point
      numbering is in the context of a particular measuring organization,
      organizations with similar technologies and architectures are encouraged
      to coordinate on local numbering and diagrams.</t>

      <t>The measurement point numbering system, mpXnn, has two independent
      parts:</t>

      <t><list style="numbers">
          <t>The X in mpXnn indicates the network number. The network with the
          subscriber's device is network 0. The network of a different
          organization (administrative or ownership domains) SHOULD be
          assigned a different number. Each successive network number SHOULD
          be one greater than the previous network's number. Two circumstances
          make it necessary to designate X=9 in the destination host's network
          and X=8 for the service provider network at the destination:<list
              style="letters">
              <t>The number of transit networks is unknown.</t>

              <t>The number of transit networks varies over time.</t>
            </list></t>

          <t>The nn in mpXnn indicates the measurement point and is
          locally assigned by network X. The following conventions are
          suggested:<list style="letters">
              <t>00 SHOULD be used for a measurement point at the subscriber's
              device and at the service demarcation point or GW nearest to the
              subscriber's device for transit networks.</t>

              <t>90 SHOULD be used for a measurement point at the GW of a
              network (opposite from the subscriber's device or service
              demarcation).</t>

              <t>In most networks, measurement point numbers SHOULD
              monotonically increase from the point nearest the subscriber's
              device to the opposite network boundary on the path (but see item D
	      for an exception).
</t>

              <t>When a destination host is part of the path, 00 SHOULD be
              used for a measurement point at the destination host and at the
              destination's service demarcation point. Measurement point
              numbers SHOULD monotonically increase from the point nearest the
              destination's host to the opposite network boundary on the path
              ONLY in these networks. This directional numbering reversal
              allows consistent 00 designation for end hosts and service
              demarcation.</t>

              <t>50 MAY be used for an intermediate measurement point of
              significance, such as a Network Address Translator (NAT).</t>

              <t>20 MAY be used for a traffic aggregation point, such as a
              Digital Subscriber Line Access Multiplexer (DSLAM) within a network.</t>

              <t>Any other measurement points SHOULD be assigned unused
              integers between 01 and 99. The assignment SHOULD be stable for
              at least the duration of a particular measurement study and
              SHOULD avoid numbers that have been assigned to other locations
              within network X (unless the assignment is considered
              sufficiently stale). Subnetworks or domains within a network
              are useful locations for measurement points.</t>
            </list></t>
        </list></t>

      <t>When supplying a diagram of the reference path and measurement
      points, the operator of the measurement system MUST indicate the
      reference path, the numbers (mpXnn) of the measurement points, and the
      technology-specific definition of any measurement point other than X00
      and X90 with sufficient detail to clearly define its location (similar
      to the technology-specific examples in Section 6 of this document).</t>

      <t>If the number of intermediate networks (between the source and
      destination) is not known or is unstable, then this SHOULD be indicated
      on the diagram, and results from measurement points within those networks
      need to be treated with caution.</t>

      <t>Notes:</t>

      <t><list style="symbols">
          <t>The terminology "on-net" and "off-net" is sometimes used when
          referring to the subscriber's Internet Service Provider (ISP)
          measurement coverage. With respect to the reference path, tests
          between mp100 and mp190 are "on-net".</t>

          <t>Widely deployed broadband Internet access measurements have used
          pass-through devices <xref target="SK"/> (at the subscriber's
          location) directly connected to the service demarcation point; this
          would be located at mp100.</t>

          <t>The networking technology must be indicated for the measurement
          points used, especially the interface standard and configured speed
          (because the measurement connectivity itself can be a limiting
          factor for the results).</t>

          <t>If it can be shown that a link connecting to a measurement point
          has reliably deterministic performance or negligible impairments,
          then the remote end of the connecting link is an equivalent point
          for some methods of measurement (although those methods should
          describe this possibility in detail, it is not in scope to provide
          such methods here). In any case, the presence of a link and claimed
          equivalent measurement point must be reported.</t>

          <t>Some access network architectures may have an additional traffic
          aggregation device between mp100 and mp150. Use of a measurement
          point at this location would require a local number and diagram.</t>

          <t>A Carrier Grade NAT (CGN) deployed in the service provider's
          access network would be positioned between mp100 and mp190, and the
          egress side of the CGN may be designated mp150. &nbsp;mp150 is generally
          an intermediate measurement point in the same address space as
          mp190.</t>

          <t>In the case that private address space is used in an access
          architecture, mp100 may need to use the same address space as
          its "on-net" measurement point counterpart so that a test between
          these points produces a useful assessment of network performance.
          Tests between mp000 and mp100 could use a different private address
          space, and when the globally routable side of a CGN is at mp150,
          the private address side of the CGN could be designated mp149
          for tests with mp100.</t>

          <t>Measurement points at transit GRA GWs are numbered mpX00 and
          mpX90, where X is the lowest positive integer not already used in
          the path. The GW of the first transit network is shown with point
          mp200 and the last transit network GW with mpX90.</t>
        </list></t>
    </section>

    <section title="Examples of Reference Paths with Various Technologies">
      <t>This section and those that follow are intended to provide example
      mappings between particular network technologies and the reference
      path.</t>

      <t>We provide an example for 3G cellular access below.</t>

      <figure anchor="fig3" align="center" title="Example of Reference Path
	with 3G Cellular Access">
        <artwork><![CDATA[
Subscriber -- Private ---  Service ------------- GRA --- Transit ... 
device         Net #1      Demarc.                GW     GRA GW
mp000                       mp100                mp190    mp200

|_____________UE______________|___RAN+Core____|___GGSN__|
|_____Unmanaged sub-path_____|____Managed sub-path_____|  

   GRA = Globally Routable Address
    GW = Gateway 
    UE = User Equipment
   RAN = Radio Access Network
  GGSN = Gateway General Packet Radio Service (GPRS) Support Node
]]></artwork>

      </figure>

      <t/>

      <t>Next, we provide an example of DSL access. Consider the case where:
      <list style="symbols">
          <t>The Customer Premises Equipment (CPE) has a NAT device that is
          configured with a public IP address.</t>

          <t>The CPE consists of a wired residential GW and modem internally
  connected (via Private Net #2) to an embedded home router and WiFi
  access point (Private Net #1).  All subscriber devices (UE) attach
  to the CPE through the WiFi access. mp100 is on the modem side of
  Private Net #2.

</t>
        </list>We believe this is a fairly common configuration in some parts
      of the world and is fairly simple as well.</t>

      <t>This case would map into the defined reference measurement points as
      follows:</t>

      <t><figure anchor="fig4" align="center" title="Example of Reference Path
	with DSL Access">
<artwork><![CDATA[
Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit ...
device     Net #1     Net #2    Demarc.    Access     GW     GRA GW     
mp000                            mp100      mp150    mp190    mp200     
|--UE--|------------CPE/NAT--------|------|-BRAS-|------|               
                                   |------DSL Network---|               
|________Unmanaged sub-path________|__Managed sub-path__|               

                GRA = Globally Routable Address
                 GW = Gateway
               BRAS = Broadband Remote Access Server
]]></artwork>
        </figure></t>

      <t>Consider another access network case where: <list
          style="symbols">
          <t>The CPE is a NAT device that is
          configured with a private IP address.</t>

          <t>There is a CGN located deep in the access ISP
          network.</t>

          <t>The CPE is a home router that has also an incorporated a WiFi
          access point and this is the only networking device in the home
          network, all endpoints attach directly to the CPE through the WiFi
          access.</t>
        </list>We believe this is becoming a fairly common configuration in
      some parts of the world.</t>

      <t>This case would map into the defined reference measurement points as
      follows:</t>

      <t><figure anchor="fig5" align="center" title="Example of Reference Path
	with CGN">
<artwork><![CDATA[
Subsc. -- Private ------------- Service-- Intra IP -- GRA -- Transit ...
device     Net #1               Demarc.    Access     GW     GRA GW     
mp000                            mp100      mp150    mp190    mp200     
|--UE--|------------CPE/NAT--------|------|-CGN-|------|                
                                   |--Access Network---|                
|________Unmanaged sub-path________|_Managed sub-path__|

                GRA = Globally Routable Address
                 GW = Gateway
                CGN = Carrier Grade NAT
]]></artwork>
        </figure></t>
    </section>

    <section title="Example of Reference Path with Resource Transition">
      <t>This section gives an example of shared and dedicated portions with
      the reference path. This example shows two resource transition
      points.</t>

      <t>Consider the case where: <list style="symbols">
          <t>The CPE consists of a wired residential GW and modem (Private
          Net #2) connected to a WiFi access point (Private Net #1). The
          subscriber device (UE) attaches to the CPE through the WiFi
          access.</t>

          <t>The WiFi subnetwork (Private Net #1) shares unlicensed radio
          channel resources with other WiFi access networks (and potentially
          other sources of interference); thus, this is a shared portion of the
          path.</t>

          <t>The wired subnetwork (Private Net #2) and a portion of the service
          provider's network are dedicated resources (for a single
          subscriber); thus, there is a resource transition point between
          Private Net #1 and Private Net #2.</t>

          <t>Subscriber traffic shares common resources with other subscribers
          upon reaching the CGN; thus, there is a resource
          transition point and further network components are designated as
          shared resources.</t>
        </list>We believe this is a fairly common configuration in parts of
      the world.</t>

      <t>This case would map into the defined reference measurement points as
      follows:</t>

      <t><figure anchor="fig6" align="center" title="Example of Reference Path
	with Two Reference Transition Points">
          <artwork><![CDATA[Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit ...
device     Net #1     Net #2    Demarc.    Access     GW     GRA GW     
mp000                            mp100      mp150    mp190    mp200     
|--UE--|------------CPE/NAT--------|------|-CGN-|------|                
       |   WiFi   |  1000Base-T    |--Access Network---|                
                  
       |-Shared--|RT|------Dedicated------| RT  |-----Shared------...   
|_______Unmanaged sub-path________|_Managed sub-path__|                

                GRA = Globally Routable Address
                 GW = Gateway
                 RT = Resource Transition Point
]]></artwork>
        </figure></t>
    </section>

    <section title="Security Considerations">
      <t>Specification of a reference path and identification of measurement
      points on the path represent agreements among interested parties.
      They present no threat to the implementors of this memo, or to the
      Internet resulting from implementation of the guidelines provided
      here.</t>

      <t>Attacks at end hosts or identified measurement points are possible.
      However, there is no requirement to include IP addresses of hosts or
      other network devices in a reference path with measurement points that
      is compliant with this memo. As a result, the path diagrams with
      measurement point designation numbers do not aid such attacks.</t>

      <t>Most network operators' diagrams of reference paths will bear a close
      resemblance to similar diagrams in relevant standards or other publicly
      available documents. However, when an operator must include atypical
      network details in their diagram, e.g., to explain why a longer latency
      measurement is expected, then the diagram reveals some topological
      details and should be marked as confidential and shared with others
      under a specific agreement.</t>

      <t>When considering privacy of those involved in measurement or those
      whose traffic is measured, there may be sensitive information
      communicated to recipients of the network diagrams illustrating paths
      and measurement points described above. We refer the reader to the
      privacy considerations described in the Large Scale Measurement of
      Broadband Performance (LMAP) Framework <xref
      target="LMAP-FRAMEWORK"/>, which covers active and passive
      measurement techniques and supporting material on measurement context.
      For example, the value of sensitive information can be further diluted
      by summarizing measurement results over many individuals or areas served
      by the provider. There is an opportunity enabled by forming anonymity
      sets described in <xref target="RFC6973"/> based on the reference path
      and measurement points in this memo. For example, all measurements from
      the subscriber device can be identified as "mp000", instead of using the
      IP address or other device information. The same anonymization applies
      to the Internet service provider, where their Internet gateway would be
      referred to as "mp190".</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">

<reference anchor='RFC2330' target="http://www.rfc-editor.org/info/rfc2330">
<front>
<title>Framework for IP Performance Metrics</title>
<author initials='V.' surname='Paxson' fullname='Vern Paxson'>
<organization>MS 50B/2239</organization>
<address>
<postal>
<street>Lawrence Berkeley National Laboratory</street>
<street>University of California</street>
<city>Berkeley</city>
<region>CA</region>
<code>94720</code>
<country>USA</country></postal>
<phone>+1 510/486-7504</phone>
<email>vern@ee.lbl.gov</email></address></author>
<author initials='G.' surname='Almes' fullname='Guy Almes'>
<organization>Advanced Network &amp; Services, Inc.</organization>
<address>
<postal>
<street>200 Business Park Drive</street>
<city>Armonk</city>
<region>NY</region>
<code>10504</code>
<country>USA</country></postal>
<phone>+1 914/765-1120</phone>
<email>almes@advanced.org</email></address></author>
<author initials='J.' surname='Mahdavi' fullname='Jamshid Mahdavi'>
<organization>Pittsburgh Supercomputing Center</organization>
<address>
<postal>
<street>4400 5th Avenue</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>USA</country></postal>
<phone>+1 412/268-6282</phone>
<email>mahdavi@psc.edu</email></address></author>
<author initials='M.' surname='Mathis' fullname='Matt Mathis'>
<organization>Pittsburgh Supercomputing Center</organization>
<address>
<postal>
<street>4400 5th Avenue</street>
<city>Pittsburgh</city>
<region>PA</region>
<code>15213</code>
<country>USA</country></postal>
<phone>+1 412/268-3319</phone>
<email>mathis@psc.edu</email></address></author>
<date year='1998' month='May' />
</front>
<seriesInfo name='RFC' value='2330' />
<format type='TXT' octets='94387' target='http://www.rfc-editor.org/rfc/rfc2330.txt' />
<format type='XML' octets='92729' target='http://xml.resource.org/public/rfc/xml/rfc2330.xml' />
</reference>

<reference anchor='RFC2119' target="http://www.rfc-editor.org/info/rfc2119">
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>

<reference anchor='RFC3432' target="http://www.rfc-editor.org/info/rfc3432">
<front>
<title>Network performance measurement with periodic streams</title>
<author initials='V.' surname='Raisanen' fullname='V. Raisanen'>
<organization /></author>
<author initials='G.' surname='Grotefeld' fullname='G. Grotefeld'>
<organization /></author>
<author initials='A.' surname='Morton' fullname='A. Morton'>
<organization /></author>
<date year='2002' month='November' />
</front>
<seriesInfo name='RFC' value='3432' />
<format type='TXT' octets='52493' target='http://www.rfc-editor.org/rfc/rfc3432.txt' />
</reference>

<reference anchor='RFC5835' target="http://www.rfc-editor.org/info/rfc5835">
<front>
<title>Framework for Metric Composition</title>
<author initials='A.' surname='Morton' fullname='A. Morton'>
<organization /></author>
<author initials='S.' surname='Van den Berghe' fullname='S. Van den Berghe'>
<organization /></author>
<date year='2010' month='April' />
</front>
<seriesInfo name='RFC' value='5835' />
<format type='TXT' octets='38138' target='http://www.rfc-editor.org/rfc/rfc5835.txt' />
</reference>
    </references>

    <references title="Informative References">

<!--draft-ietf-lmap-framework-08: I-D Exists-->
<reference anchor='LMAP-FRAMEWORK'>
<front>
<title>A framework for large-scale measurement platforms (LMAP)</title>

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

<author initials='A' surname='Morton' fullname='Al Morton'>
    <organization />
</author>

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

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

<author initials='P' surname='Aitken' fullname='Paul Aitken'>
    <organization />
</author>

<author initials='A' surname='Akhter' fullname='Aamer Akhter'>
    <organization />
</author>

<date month='August' year='2014' />
</front>

<seriesInfo name='Work in Progress,' value='draft-ietf-lmap-framework-08' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-lmap-framework-08.txt' />
</reference>

<reference anchor='RFC6973' target="http://www.rfc-editor.org/info/rfc6973">
<front>
<title>Privacy Considerations for Internet Protocols</title>
<author initials='A.' surname='Cooper' fullname='A. Cooper'>
<organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'>
<organization /></author>
<author initials='B.' surname='Aboba' fullname='B. Aboba'>
<organization /></author>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<author initials='J.' surname='Morris' fullname='J. Morris'>
<organization /></author>
<author initials='M.' surname='Hansen' fullname='M. Hansen'>
<organization /></author>
<author initials='R.' surname='Smith' fullname='R. Smith'>
<organization /></author>
<date year='2013' month='July' />
</front>
<seriesInfo name='RFC' value='6973' />
<format type='TXT' octets='89198' target='http://www.rfc-editor.org/rfc/rfc6973.txt' />
</reference>

      <reference anchor="SK" target="http://www.samknows.com/broadband/index.php">
        <front>
          <title>Test Methodology White Paper</title>
          <author fullname="Sam Crawford" initials="S." surname="Crawford">
            <organization abbrev="Boeing">Boeing Computer
            Services</organization>
          </author>
          <date month="July" year="2011"/>
        </front>
        <seriesInfo name="SamKnows Whitebox Briefing Note" value=""/>
                   
      </reference>
<!-- We updated the following citation "Q1741" to "Y.1541" because the 
subsequent citation, affiliated with the same institution
and in the same format, reads "Y.1541". Please let us know if we should revert
this change.
-->
      <reference anchor="Q.1741" target="http://www.itu.int/rec/T-REC-Q.1741.7/en">
        <front>
          <title>IMT-2000 references to Release 9 of GSM-evolved UMTS core
          network</title>
          <author>
          <organization>International Telecommunications Union</organization>
          </author>
          <date month="November" year="2011"/>
        </front>
        <seriesInfo name="ITU-T" value="Recommendation Q.1741.7"/>
      </reference>

      <reference anchor="Y.1541" target="http://www.itu.int/rec/T-REC-Y.1541/en">
        <front>
          <title>Network performance objectives for IP-based services</title>
          <author>
            <organization>International Telecommunications Union</organization>
          </author>
          <date month="November" year="2011"/>
        </front>
        <seriesInfo name="ITU-T" value="Recommendation Y.1541"/>
      </reference>
    </references>

<section anchor="app-acknowledgments" title="Acknowledgments">
<t>Thanks to Matt Mathis, Charles Cook, Dan Romascanu, Lingli Deng, and
   Spencer Dawkins for review and comments.</t>
</section>

</back>
</rfc>
