Network Working Group | M. Bagnulo |
Internet-Draft | UC3M |
Intended status: Informational | T. Burbridge |
Expires: March 21, 2015 | BT |
S. Crawford | |
SamKnows | |
P. Eardley | |
BT | |
A. Morton | |
AT&T Labs | |
September 17, 2014 |
A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance
draft-ietf-ippm-lmap-path-06
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 21, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 [RFC2330]). There are a limited number of additional terms needing definition here, and they will be defined in this memo.
The reference path (See section 3.1 and Figure 1 of [Y.1541], including the accompanying discussion) 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 [RFC3432], and as part of the updated framework for composition and aggregation, section 4 of [RFC5835]. Section 4.1 of [RFC5835] defines the term "measurement point".
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 scientific method: What is an end? Where is a user located? Is the home network included?
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). For instance "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.
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
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, and in describing the applicable measurement scope for some metrics.
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.
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:
This section defines key terms and concepts for the purposes of this memo.
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.
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 to services, and to register a user or a list of users authorized to enjoy these services. [Q1741] Both the subscriber and service provider are allowed to set the limits relative to the use that associated users make of subscribed services.
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.
A component on the Reference Path is designated a Shared Component when the traffic associated with multiple Subscribers is served by common resources.
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.
This is the point where 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 a third-party will certify standards compliance.
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.
This section defines a reference path for Internet communication.
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
The following are descriptions of reference path components that may not be clear from their name alone.
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.
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).
A key aspect of measurement points, beyond the definition in section 4.1 of [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.
In general, measurement points cannot always be located exactly where desired. However, the definition in [RFC5835] and the discussion in section 5.1 of [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.
The Figure below illustrates the assignment of measurement points to selected components of the reference path.
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
Figure 1
Each measurement point on a specific reference path MUST be assigned a unique number. To facilitate interpretation of the results, the measuring organisation (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.
When communicating the results of measurements, the measuring organization SHOULD supply a diagram similar to Figure 1 (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.
Ideally, the consumer of measurement results would know the location of a measurement point on the reference path from the measurement point number alone, and the recommendations below provide a way to accomplish this goal. Although the initial numbering may be fully compliant with this system, network growth, consolidation, and re-arrangement, or circumstances such as ownership changes, could cause gaps in network numbers or non-monotonic measurement point number assignments along the path over time. These are examples of reasonable causes for numbering deviations which must be identified on the reference path diagram, as required above.
Whilst the numbering of a measurement point is in the context of a particular path, for simplicity the measuring organisation 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 organisation, organizations with similar technologies and architectures are encouraged to coordinate on local numbering and diagrams.
The measurement point numbering system, mpXnn, has two independent parts:
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).
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.
Notes:
This section and those that follow are intended to provide example mappings between particular network technologies and the reference path.
We provide an example for 3G Cellular access below.
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_____|
GRA = Globally Routable Address, GW = Gateway, UE = User Equipment, RAN = Radio Access Network, GGSN = Gateway GPRS Support Node.
We next provide an example of DSL access. Consider the case where:
We believe this is a fairly common configuration in some parts of the world and fairly simple as well.
This case would map into the defined reference measurement points as follows:
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__|
GRA = Globally Routable Address, GW = Gateway, BRAS = Broadband Remote Access Server
Consider next another access network case where:
We believe this is becoming a fairly common configuration in some parts of the world.
This case would map into the defined reference measurement points as follows:
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__|
GRA = Globally Routable Address, GW = Gateway
This section gives an example of Shared and Dedicated portions with the reference path. This example shows two Resource Transition Points.
Consider the case where:
We believe this is a fairly common configuration in parts of the world.
This case would map into the defined reference measurement points as follows:
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------... |_______Un-managed sub-path________|_Managed sub-path__|
GRA = Globally Routable Address, GW = Gateway, RT = Resource Transition Point
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 implementors of this memo, or to the Internet resulting from implementation of the guidelines provided here.
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.
Most network operators' diagrams of reference paths will bear a close to the 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.
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 [I-D.ietf-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 summarising measurement results over many individuals or areas served by the provider. There is an opportunity enabled by forming anonymity sets described in [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 anonymisation applies to the Internet Service Provider, where their Internet gateway would be referred to as "mp190".
This memo makes no requests for IANA consideration.
Thanks to Matt Mathis, Charles Cook, Dan Romascanu, Lingli Deng, and Spencer Dawkins for review and comments.
[RFC2330] | Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. |
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
[RFC3432] | Raisanen, V., Grotefeld, G. and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002. |
[RFC5835] | Morton, A. and S. Van den Berghe, "Framework for Metric Composition", RFC 5835, April 2010. |
[I-D.ietf-lmap-framework] | Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P. and A. Akhter, "A framework for large-scale measurement platforms (LMAP)", Internet-Draft draft-ietf-lmap-framework-08, August 2014. |
[RFC6973] | Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M. and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013. |
[SK] | Crawford, Sam., "Test Methodology White Paper", SamKnows Whitebox Briefing Note http://www.samknows.com/broadband/index.php, July 2011. |
[Q1741] | Q.1741.7, , "IMT-2000 references to Release 9 of GSM-evolved UMTS core network", http://www.itu.int/rec/T-REC-Q.1741.7/en, November 2011. |
[Y.1541] | Y.1541, , "Network performance objectives for IP-based services", http://www.itu.int/rec/T-REC-Y.1541/en, November 2011. |