One document matched: draft-ietf-ippm-lmap-path-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<rfc category="info" docName="draft-ietf-ippm-lmap-path-04" ipr="trust200902"
obsoletes="" updates="">
<front>
<title abbrev="LMAP Reference Path">A Reference Path and Measurement
Points for LMAP</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>ENGLAND</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="Phil Eardley" initials="P." surname="Eardley">
<organization abbrev="BT">BT</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="Al Morton" initials="A." surname="Morton">
<organization abbrev="AT&T Labs">AT&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="19" month="June" year="2014"/>
<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. The methods for measurement point location may
be applicable to similar measurement projects using the extensions
described here.</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 (section 5 of <xref
target="RFC2330"/>). There are a limited number of additional terms
needing definition here, and they will be defined in this memo.</t>
<t>The reference path is usually needed when attempting to communicate
precisely about the components that comprise the path, often 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, section 4 of <xref target="RFC5835"/> (which may also
figure in the LMAP work effort). Section 4.1 of <xref target="RFC5835"/>
defines the term "measurement point".</t>
<t>Measurement points and the paths they cover are often described in
general terms, like "end-to-end", "user-to-user", or "access". These
terms alone are insufficient for scientific method: What is an end?
Where is a user located? Is the home network included?</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 meta-data 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 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 as
well.</t>
<t>The connection between the reference path and specific network
technologies (with differing underlying architectures) is within the
scope of this method, 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 adequately described in terms of scope
or coverage. This should serve many measurement uses, including:</t>
<t><list style="hanging">
<t hangText="diagnostic:">where the same metric may be measured over
many different path scopes</t>
<t hangText="comparison:">where the same metric may be measured on
equivalent portions of different network infrastructures</t>
</list></t>
</section>
<section title="Terms and Definitions">
<t>This section defines key terms and concepts for the purposes of this
memo.</t>
<section title="Reference Path">
<t>A reference path is a serial combination of routers, switches,
links, radios, and processing elements that comprise all the network
elements traversed by each packet between the source and destination
hosts. The reference path is intended to be equally applicable to all
networking technologies, therefore the components are generically
defined, but their functions should have a clear counterpart or be
obviously omitted in any network technology.</t>
</section>
<section title="Subscriber">
<t>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 un-subscribe services, and to register a user or a list
of users authorized to enjoy these services. <xref target="Q1741"/>
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>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="Managed and Un-Managed Sub-paths">
<t>Service providers are responsible for the portion of the path they
manage. However, most paths involve a sub-path which 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 are designated as un-managed sub-paths.
The Service demarcation point always divides managed and un-managed
sub-paths.</t>
</section>
</section>
<section title="Reference Path">
<t>This section defines a reference path for Internet communication.</t>
<t><figure align="center">
<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
]]></artwork>
<postamble>GRA = Globally Routable Address, GW = Gateway</postamble>
</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 (and ownership
may shift to the service provider), and this should be noted as part
of the path description.</t>
<t>Service Demarcation point - This is the point where service
managed by the serivce 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., LTE
UE). Ownership may not 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 a third-party will certify standards compliance.</t>
<t>Intra IP Access - This is the first point in the access
architecture beyond the Service Demarc. where a globally routable IP
address is exposed and used for routing. In architectures that use
tunneling, this point may be equivalent to the GRA GW. This point
could also collapse to the device providing the Service Demarc., in
principle. Only one Intra IP Access point is shown, but they can be
identified in any access network.</t>
<t>GRA GW - 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 GW.</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 Service Demarc. and the Intra IP Access points
must use the same address space and be separated by the shared and
dedicated access link infrastructure, such that a test between these
points produces a useful assessment of access performance.</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 which 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 point.</t>
<t>The Figure below illustrates the assignment of measurement points to
selected components of the reference path.</t>
<t><figure align="center" title="Figure 1">
<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
]]></artwork>
<postamble>GRA = Globally Routable Address, GW = Gateway</postamble>
</figure></t>
<t>When communicating the results of measurements using the measurement
point designations described here, the measuring organization SHOULD
supply a diagram similar to Figure 1 (and the technology-specific
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. Organizations with similar
technologies and architectures are encouraged to coordinate on local
numbering and diagrams, when possible.</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
Demarc.).</t>
<t>In most networks, measurement point numbers SHOULD
monotonically increase from point nearest the Subscriber's
device to the opposite network boundary on the path (see
below).</t>
<t>When a Detination host is part of the path, 00 SHOULD be used
for a measurement point at the Destination host and at the the
Destination's Service Demarcation point. Measurement point
numbers SHOULD monotonically increase from 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
Demarcs.</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
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). Sub-networks or domains within a network
are useful locations for measurement points.</t>
</list></t>
</list></t>
<t>In order to define the measurement points and the scope of
measurements without ambiguity, the operator of the measurement system
SHOULD indicate on a diagram (similar to those in this document): the
reference path, the numbers (mpXnn) of the measurement points, and the
definition of any measurement point other than 00 and 90 (with
sufficient detail to clearly define its location).</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>Some use the terminology "on-net" and "off-net" 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 (To Be Specified Elsewhere). 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. 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, then 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,
then 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 first transit network is shown, with point mp200
and the last transit network GW with mpX90.</t>
</list></t>
</section>
<section title="Translation Between Reference Path and Various Technologies ">
<t>This section and those that follow are intended to provide a more
exact mapping between particular network technologies and the reference
path.</t>
<t>We provide an example for 3G Cellular access below.</t>
<figure align="center">
<artwork><![CDATA[Subscriber -- Private --- Service ------------- GRA --- Transit ...
device Net #1 Demarc. GW GRA GW
mp000 mp100 mp190 mp200
|_____________UE______________|___RAN+Core____|___GGSN__|
|_____Un-managed sub-path_____|____Managed sub-path_____|
]]></artwork>
<postamble>GRA = Globally Routable Address, GW = Gateway, UE = User
Equipment, RAN = Radio Access Network, GGSN = Gateway GPRS Support
Node.</postamble>
</figure>
<t/>
<t>We next 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 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 though the WiFi
access.</t>
</list>We believe this is a fairly common configuration in some parts
of the world and fairly simple as well.</t>
<t>This case would map into the defined reference measurement points as
follows:</t>
<t><figure align="center">
<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---|
|_______Un-managed sub-path________|__Managed sub-path__|
]]></artwork>
<postamble>GRA = Globally Routable Address, GW = Gateway, BRAS =
Broadband Remote Acess Server</postamble>
</figure></t>
<t>Consider next another access network case where: <list
style="symbols">
<t>The Customer Premises Equipment (CPE) is a NAT device that is
configured with a private IP address.</t>
<t>There is a Carrier Grade NAT (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 though 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 align="center">
<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---|
|_______Un-managed sub-path________|_Managed sub-path__|
]]></artwork>
<postamble>GRA = Globally Routable Address, GW = Gateway</postamble>
</figure></t>
</section>
<section title="Example 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 is 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 though the WiFi access.</t>
<t>The Wi-Fi subnetwork (Private Net#1) shares unlicensed radio
channel resources with other W-Fi 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 Carrier Grade NAT (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 align="center">
<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-|------|
| Wi-Fi | 1000Base-T |--Access Network---|
|-Shared--|RT|------Dedicated------| RT |-----Shared------...
|_______Un-managed sub-path________|_Managed sub-path__|
]]></artwork>
<postamble>GRA = Globally Routable Address, GW = Gateway, RT =
Resource Transition Point</postamble>
</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, and
they present no threat to the readers of this memo or to the Internet
itself.</t>
<t>When considering privacy of those involved in measurement or those
whose traffic is measured, there is 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="I-D.ietf-lmap-framework"/>,
which covers active and passive measurement techniques and supporting
material on measurement context.</t>
</section>
<section title="IANA Considerations">
<t>This memo makes no requests for IANA consideration.</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Matt Mathis, Charles Cook, Dan Romascanu, and Lingli Deng
for review and comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2330'?>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.3432'?>
<?rfc include='reference.RFC.5835'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-lmap-framework'?>
<reference anchor="SK">
<front>
<title>Test Methodology White Paper</title>
<author fullname="S, Crawford" initials="Sam" surname="Crawford">
<!---->
<organization abbrev="Boeing">Boeing Computer
Services</organization>
</author>
<date month="July" year="2011"/>
</front>
<seriesInfo name="SamKnows Whitebox Briefing Note"
value="http://www.samknows.com/broadband/index.php"/>
</reference>
<reference anchor="Q1741">
<front>
<title>IMT-2000 references to Release 9 of GSM-evolved UMTS core
network</title>
<author fullname="ITU-T Recommendation" initials=""
surname="Q.1741.7">
<!---->
<organization abbrev="Boeing">Boeing Computer
Services</organization>
</author>
<date month="November" year="2011"/>
</front>
<seriesInfo name="" value="http://www.itu.int/rec/T-REC-Q.1741.7/en"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:24:28 |