draft-ietf-ippm-lmap-path-07.txt | rfc7398.txt | |||
---|---|---|---|---|
Network Working Group M. Bagnulo | Internet Engineering Task Force (IETF) M. Bagnulo | |||
Internet-Draft UC3M | Request for Comments: 7398 UC3M | |||
Intended status: Informational T. Burbridge | Category: Informational T. Burbridge | |||
Expires: April 10, 2015 BT | ISSN: 2070-1721 BT | |||
S. Crawford | S. Crawford | |||
SamKnows | SamKnows | |||
P. Eardley | P. Eardley | |||
BT | BT | |||
A. Morton | A. Morton | |||
AT&T Labs | AT&T Labs | |||
October 7, 2014 | February 2015 | |||
A Reference Path and Measurement Points for Large-Scale Measurement of | A Reference Path and Measurement Points for | |||
Broadband Performance | Large-Scale Measurement of Broadband Performance | |||
draft-ietf-ippm-lmap-path-07 | ||||
Abstract | Abstract | |||
This document defines a reference path for Large-scale Measurement of | This document defines a reference path for Large-scale Measurement of | |||
Broadband Access Performance (LMAP) and measurement points for | Broadband Access Performance (LMAP) and measurement points for | |||
commonly used performance metrics. Other similar measurement | commonly used performance metrics. Other similar measurement | |||
projects may also be able to use the extensions described here for | projects may also be able to use the extensions described here for | |||
measurement point location. The purpose is to create an efficient | measurement point location. The purpose is to create an efficient | |||
way to describe the location of the measurement point(s) used to | way to describe the location of the measurement point(s) used to | |||
conduct a particular measurement. | conduct a particular measurement. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This document is not an Internet Standards Track specification; it is | |||
provisions of BCP 78 and BCP 79. | published for informational purposes. | |||
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 | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Not all documents | |||
approved by the IESG are a candidate for any level of Internet | ||||
Standard; see Section 2 of RFC 5741. | ||||
This Internet-Draft will expire on April 10, 2015. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
http://www.rfc-editor.org/info/rfc7398. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 | |||
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 | 3. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1. Reference Path . . . . . . . . . . . . . . . . . . . . . 4 | 3.1. Reference Path . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.2. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 4 | 3.2. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.3. Dedicated Component (Links or Nodes) . . . . . . . . . . 5 | 3.3. Dedicated Component (Links or Nodes) . . . . . . . . . . 5 | |||
3.4. Shared Component (Links or Nodes) . . . . . . . . . . . . 5 | 3.4. Shared Component (Links or Nodes) . . . . . . . . . . . . 5 | |||
3.5. Resource Transition Point . . . . . . . . . . . . . . . . 5 | 3.5. Resource Transition Point . . . . . . . . . . . . . . . . 5 | |||
3.6. Service Demarcation Point . . . . . . . . . . . . . . . . 5 | 3.6. Service Demarcation Point . . . . . . . . . . . . . . . . 5 | |||
3.7. Managed and Un-Managed Sub-paths . . . . . . . . . . . . 5 | 3.7. Managed and Unmanaged Sub-paths . . . . . . . . . . . . . 6 | |||
4. Reference Path . . . . . . . . . . . . . . . . . . . . . . . 6 | 4. Reference Path . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
5. Measurement Points . . . . . . . . . . . . . . . . . . . . . 7 | 5. Measurement Points . . . . . . . . . . . . . . . . . . . . . 7 | |||
6. Translation Between Reference Path and Various Technologies . 11 | 6. Examples of Reference Paths with Various Technologies . . . . 11 | |||
7. Example Resource Transition . . . . . . . . . . . . . . . . . 12 | 7. Example of Reference Path with Resource Transition . . . . . 13 | |||
8. Security considerations . . . . . . . . . . . . . . . . . . . 13 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 9.2. Informative References . . . . . . . . . . . . . . . . . 16 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 14 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | ||||
1. Introduction | 1. Introduction | |||
This document defines a reference path for Large-scale Measurement of | This document defines a reference path for Large-scale Measurement of | |||
Broadband Access Performance (LMAP) or similar measurement projects. | Broadband Access Performance (LMAP) or similar measurement projects. | |||
The series of IP Performance Metrics (IPPM) RFCs have developed terms | The series of IP Performance Metrics (IPPM) RFCs have developed terms | |||
that are generally useful for path description (section 5 of | that are generally useful for path description (see Section 5 of | |||
[RFC2330]). There are a limited number of additional terms needing | [RFC2330]). There are a limited number of additional terms defined | |||
definition here, and they will be defined in this memo. | in this memo. | |||
The reference path (See section 3.1 and Figure 1 of [Y.1541], | The reference path (see Section 3.1 and Figure 1 of [Y.1541], | |||
including the accompanying discussion) is usually needed when | including the accompanying discussion) is usually needed when | |||
attempting to communicate precisely about the components that | attempting to communicate precisely about the components that | |||
comprise the path, often in terms of their number (hops) and | comprise the path, and is often expressed in terms of their number | |||
geographic location. This memo takes the path definition further, by | (hops) and geographic location. This memo takes the path definition | |||
establishing a set of measurement points along the path and ascribing | further by establishing a set of measurement points along the path | |||
a unique designation to each point. This topic has been previously | and ascribing a unique designation to each point. This topic has | |||
developed in section 5.1 of [RFC3432], and as part of the updated | been previously developed in Section 5.1 of [RFC3432] and as part of | |||
framework for composition and aggregation, section 4 of [RFC5835]. | the updated framework for composition and aggregation in Section 4 of | |||
Section 4.1 of [RFC5835] defines the term "measurement point". | [RFC5835]. Section 4.1 of [RFC5835] defines the term "measurement | |||
point". | ||||
Measurement points and the paths they inhabit are often described in | Measurement points and the paths they inhabit are often described in | |||
general terms, like "end-to-end", "user-to-user", or "access". These | general terms, like "end-to-end", "user-to-user", or "access". These | |||
terms alone are insufficient for scientific method: What is an end? | terms alone are insufficient for the scientific method, since we need | |||
Where is a user located? Is the home network included? | to clarify issues such as: 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 | As an illustrative example, consider a measurement agent in an LMAP | |||
system. When it reports its measurement results, rather than | system. When it reports its measurement results, rather than | |||
detailing its IP address and that of its measurement peer, it may | detailing its IP address and that of its measurement peer, it may | |||
prefer to describe the measured path segment abstractly (perhaps for | prefer to describe the measured path segment abstractly (perhaps for | |||
privacy reasons). For instance "from a measurement agent at a home | privacy reasons), e.g., 'from a measurement agent at a home gateway | |||
gateway to a measurement peer at a DSLAM". This memo provides the | to a measurement peer at a DSLAM.' This memo provides the definition | |||
definition for such abstract 'measurement points' and therefore the | for such abstract 'measurement points' and, therefore, the portion of | |||
portion of 'reference path' between them. | 'reference path' between them. | |||
The motivation for this memo is to provide an unambiguous framework | The motivation for this memo is to provide an unambiguous framework | |||
to describe measurement coverage, or scope of the reference path. | to describe measurement coverage or scope of the reference path. | |||
This is an essential part of the meta-data to describe measurement | This is an essential part of the metadata to describe measurement | |||
results. Measurements conducted over different path scopes are not a | results. Measurements conducted over different path scopes are not a | |||
valid basis for performance comparisons. We note that additional | valid basis for performance comparisons. We note that additional | |||
measurement context information may be necessary to support a valid | measurement context information may be necessary to support a valid | |||
comparison of results. | comparison of results. | |||
1.1. Requirements Language | 1.1. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
2. Purpose and Scope | 2. Purpose and Scope | |||
The scope of this memo is to define a reference path for LMAP | The scope of this memo is to define a reference path for LMAP | |||
activities with sufficient level of detail to determine the location | activities with a sufficient level of detail to determine the | |||
of different measurement points along a path without ambiguity. | location of different measurement points along a path without | |||
These conventions are likely to be useful in other measurement | ambiguity. These conventions are likely to be useful in other | |||
projects as well, and in describing the applicable measurement scope | measurement projects and to describe the applicable measurement scope | |||
for some metrics. | for some metrics. | |||
The connection between the reference path and specific network | The connection between the reference path and specific network | |||
technologies (with differing underlying architectures) is within the | technologies (with differing underlying architectures) is within the | |||
scope of this method, and examples are provided. Both wired and | scope of this memo, and examples are provided. Both wired and | |||
wireless technologies are in-scope. | wireless technologies are in scope. | |||
The purpose is to create an efficient way to describe the location of | The purpose is to create an efficient way to describe the location of | |||
the measurement point(s) used to conduct a particular measurement so | the measurement point(s) used to conduct a particular measurement so | |||
that the measurement result will adequately described in terms of | that the measurement result will be adequately described in terms of | |||
scope or coverage. This should serve many measurement uses, | scope or coverage. This should serve many measurement uses, | |||
including: | including: | |||
diagnostic: where the same metric would be measured on different | o diagnostic, where the same metric would be measured on different | |||
sub-paths bounded by measurement points (see Section 4.10 | sub-paths bounded by measurement points (see Section 4.10 of | |||
of[RFC5835]), for example to isolate the sub-path contributing the | [RFC5835]), for example, to isolate the sub-path contributing the | |||
majority of impairment levels observed on a path. | majority of impairment levels observed on a path. | |||
comparison: where the same metric may be measured on equivalent | o comparison, where the same metric may be measured on equivalent | |||
portions of different network infrastructures, for example to | portions of different network infrastructures, for example, to | |||
compare the performance of wired and wireless home network | compare the performance of wired and wireless home network | |||
technologies. | technologies. | |||
3. Terms and Definitions | 3. Terms and Definitions | |||
This section defines key terms and concepts for the purposes of this | This section defines key terms and concepts for this memo. | |||
memo. | ||||
3.1. Reference Path | 3.1. Reference Path | |||
A reference path is a serial combination of hosts, routers, switches, | A reference path is a serial combination of hosts, routers, switches, | |||
links, radios, and processing elements that comprise all the network | links, radios, and processing elements that comprise all the network | |||
elements traversed by each packet in a flow between the source and | elements traversed by each packet in a flow between the source and | |||
destination hosts. A reference path also indicates the various | destination hosts. A reference path also indicates the various | |||
boundaries present, such as administrative boundaries. A reference | boundaries present, such as administrative boundaries. A reference | |||
path is intended to be equally applicable to all IP and link-layer | path is intended to be equally applicable to all IP and link-layer | |||
networking technologies. Therefore, the components are generically | networking technologies. Therefore, the components are generically | |||
defined but their functions should have a clear counterpart or be | defined, but their functions should have a clear counterpart or be | |||
obviously omitted in any network architecture. | obviously omitted in any network architecture. | |||
3.2. Subscriber | 3.2. Subscriber | |||
An entity (associated with one or more users) that is engaged in a | A subscriber is an entity (associated with one or more users) that is | |||
subscription with a service provider. The subscriber is allowed to | engaged in a subscription with a service provider. The subscriber is | |||
subscribe and un-subscribe to services, and to register a user or a | allowed to subscribe and unsubscribe to services and to register a | |||
list of users authorized to enjoy these services. [Q1741] Both the | user or a list of users authorized to enjoy these services. [Q.1741] | |||
subscriber and service provider are allowed to set the limits | ||||
relative to the use that associated users make of subscribed | Both the subscriber and service provider are allowed to set the | |||
limits relative to the use that associated users make of subscribed | ||||
services. | services. | |||
3.3. Dedicated Component (Links or Nodes) | 3.3. Dedicated Component (Links or Nodes) | |||
All resources of a Dedicated Component (typically a link or node on | All resources of a dedicated component (typically a link or node on | |||
the Reference Path) are allocated to serving the traffic of an | the reference path) are allocated to serving the traffic of an | |||
individual Subscriber. Resources include transmission time-slots, | individual subscriber. Resources include transmission time-slots, | |||
queue space, processing for encapsulation and address/port | queue space, processing for encapsulation and address/port | |||
translation, and others. A Dedicated Component can affect the | translation, and others. A dedicated component can affect the | |||
performance of the Reference Path, or the performance of any sub-path | performance of the reference path or the performance of any sub-path | |||
where the component is involved. | where the component is involved. | |||
3.4. Shared Component (Links or Nodes) | 3.4. Shared Component (Links or Nodes) | |||
A component on the Reference Path is designated a Shared Component | A component on the reference path is designated a "shared component" | |||
when the traffic associated with multiple Subscribers is served by | when the traffic associated with multiple subscribers is served by | |||
common resources. | common resources. | |||
3.5. Resource Transition Point | 3.5. Resource Transition Point | |||
A point between Dedicated and Shared Components on a Reference Path | This is a point between dedicated and shared components on a | |||
that may be a point of significance, and is identified as a | reference path that may be a point of significance and is identified | |||
transition between two types of resources. | as a transition between two types of resources. | |||
3.6. Service Demarcation Point | 3.6. Service Demarcation Point | |||
This is the point where service managed by the service provider | This is the point where a service managed by the service provider | |||
begins (or ends), and varies by technology. For example, this point | begins (or ends) and varies by technology. For example, this point | |||
is usually defined as the Ethernet interface on a residential gateway | is usually defined as the Ethernet interface on a residential gateway | |||
or modem where the scope of a packet transfer service begins and | 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 | 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 | within the intended service boundary (e.g., walls of the coffee | |||
shop). The Demarcation Point may be within an integrated endpoint | shop). The demarcation point may be within an integrated endpoint | |||
using an Air Interface (e.g., Long-Term Evolution User Equipment, LTE | using an air interface (e.g., Long-Term Evolution User Equipment (LTE | |||
UE). Ownership does not necessarily affect the demarcation point; a | UE)). Ownership does not necessarily affect the demarcation point; a | |||
Subscriber may own all equipment on their premises, but it is likely | subscriber may own all equipment on their premises, but it is likely | |||
that the service provider will certify such equipment for connection | that the service provider will certify such equipment for connection | |||
to their network, or a third-party will certify standards compliance. | to their network or that a third-party will certify standards | |||
compliance. | ||||
3.7. Managed and Un-Managed Sub-paths | 3.7. Managed and Unmanaged Sub-paths | |||
Service providers are responsible for the portion of the path they | Service providers are responsible for the portion of the path they | |||
manage. However, most paths involve a sub-path which is beyond the | manage. However, most paths involve a sub-path that is beyond the | |||
management of the subscriber's service provider. This means that | management of the subscriber's service provider. This means that | |||
private networks, wireless networks using unlicensed frequencies, and | private networks, wireless networks using unlicensed frequencies, and | |||
the networks of other service are designated as Un-managed sub-paths. | the networks of other service providers are designated as unmanaged | |||
The Service Demarcation Point always divides Managed and Un-managed | sub-paths. The service demarcation point always divides managed and | |||
sub-paths. | unmanaged sub-paths. | |||
4. Reference Path | 4. Reference Path | |||
This section defines a reference path for Internet communication. | This section defines a reference path for Internet communication. | |||
Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit ... | Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit ... | |||
device Net #1 Net #2 Demarc. Access GW GRA GW | device Net #1 Net #2 Demarc. Access GW GRA GW | |||
... Transit -- GRA -- Service -- Private -- Private -- Destination | ... Transit -- GRA -- Service -- Private -- Private -- Destination | |||
GRA GW GW Demarc. Net #n Net #n+1 Host | GRA GW GW Demarc. Net #n Net #n+1 Host | |||
GRA = Globally Routable Address, GW = Gateway | GRA = Globally Routable Address | |||
GW = Gateway | ||||
Figure 1: Reference Path | ||||
The following are descriptions of reference path components that may | The following are descriptions of reference path components that may | |||
not be clear from their name alone. | not be clear from their name alone. | |||
o Subsc. (Subscriber) device - This is a host that normally | o Subsc. (Subscriber) device - This is a host that normally | |||
originates and terminates communications conducted over the IP | originates and terminates communications conducted over the IP | |||
packet transfer service. | packet transfer service. | |||
o Private Net #x - This is a network of devices owned and operated | o Private Net #x - This is a network of devices owned and operated | |||
by the Internet Service Subscriber. In some configurations, one | by the Internet service subscriber. In some configurations, one | |||
or more private networks and the device that provides the Service | or more private networks and the device that provides the service | |||
Demarcation point are collapsed in a single device (and ownership | demarcation point are collapsed in a single device (ownership may | |||
may shift to the service provider), and this should be noted as | shift to the service provider); this should be noted as part of | |||
part of the path description. | the path description. | |||
o Intra IP Access - This is the first point in the access | o Intra IP Access - This is the first point in the access | |||
architecture beyond the Service Demarc. where a globally routable | architecture, beyond the service demarcation, where a globally | |||
IP address is exposed and used for routing. In architectures that | routable IP address is exposed and used for routing. In | |||
use tunneling, this point may be equivalent to the Globally | architectures that use tunneling, this point may be equivalent to | |||
Routable Address Gateway (GRA GW). This point could also collapse | the Globally Routable Address Gateway (GRA GW). This point could | |||
to the device providing the Service Demarc., in principle. Only | also collapse to the device providing the service demarcation, in | |||
one Intra IP Access point is shown, but they can be identified in | principle. Only one Intra IP Access point is shown, but they can | |||
any access network. | be identified in any access network. | |||
o GRA GW - the point of interconnection between a Service Provider's | o GRA GW - This is the point of interconnection between a service | |||
administrative domain and the rest of the Internet, where routing | provider's administrative domain and the rest of the Internet, | |||
will depend on the GRAs in the IP header. | where routing will depend on the GRAs in the IP header. | |||
o Transit GRA GW - If one or more networks intervene between the | o Transit GRA GW - If one or more networks intervene between the | |||
Service Provider's access networks of the Subscriber and of the | service provider's access networks of the subscriber and of the | |||
Destination Host, then such networks are designated "transit" and | destination host, then such networks are designated "transit" and | |||
are bounded by two Transit GRA GW. | are bounded by two transit GRA GWs. | |||
Use of multiple IP address families in the measurement path must be | Use of multiple IP address families in the measurement path must be | |||
noted, as the conversions between IPv4 and IPv6 certainly influence | noted, as the conversions between IPv4 and IPv6 certainly influence | |||
the visibility of a GRA for each family. | the visibility of a GRA for each family. | |||
In the case that a private address space is used throughout an access | In the case that a private address space is used throughout an access | |||
architecture, then the Intra IP Access points must use the same | architecture, then the Intra IP Access points must use the same | |||
address space as the Service Demarcation point, and the Intra IP | address space as the service demarcation point, and the Intra IP | |||
Access points must be selected such that a test between these points | Access points must be selected such that a test between these points | |||
produces a useful assessment of access performance (e.g., includes | produces a useful assessment of access performance (e.g., includes | |||
both shared and dedicated access link infrastructure). | both shared and dedicated access link infrastructure). | |||
5. Measurement Points | 5. Measurement Points | |||
A key aspect of measurement points, beyond the definition in section | A key aspect of measurement points, beyond the definition in | |||
4.1 of [RFC5835], is that the innermost IP header and higher layer | Section 4.1 of [RFC5835], is that the innermost IP header and higher- | |||
information must be accessible through some means. This is essential | layer information must be accessible through some means. This is | |||
to measure IP metrics. There may be tunnels and/or other layers | essential to measure IP metrics. There may be tunnels and/or other | |||
which encapsulate the innermost IP header, even adding another IP | layers that encapsulate the innermost IP header, even adding another | |||
header of their own. | IP header of their own. | |||
In general, measurement points cannot always be located exactly where | In general, measurement points cannot always be located exactly where | |||
desired. However, the definition in [RFC5835] and the discussion in | desired. However, the definition in [RFC5835] and the discussion in | |||
section 5.1 of [RFC3432] indicate that allowances can be made: for | Section 5.1 of [RFC3432] indicate that allowances can be made; for | |||
example, it is nearly ideal when there are deterministic errors that | example, it is nearly ideal when there are deterministic errors that | |||
can be quantified between desired and actual measurement point. | can be quantified between desired and actual measurement points. | |||
The Figure below illustrates the assignment of measurement points to | The figure below illustrates the assignment of measurement points to | |||
selected components of the reference path. | selected components of the reference path. | |||
Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit ... | Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit ... | |||
device Net #1 Net #2 Demarc. Access GW GRA GW | device Net #1 Net #2 Demarc. Access GW GRA GW | |||
mp000 mp100 mp150 mp190 mp200 | mp000 mp100 mp150 mp190 mp200 | |||
... Transit -- GRA -- Service -- Private -- Private -- Destination | ... Transit -- GRA -- Service -- Private -- Private -- Destination | |||
GRA GW GW Demarc. Net #n Net #n+1 Host | GRA GW GW Demarc. Net #n Net #n+1 Host | |||
mpX90 mp890 mp800 mp900 | mpX90 mp890 mp800 mp900 | |||
GRA = Globally Routable Address, GW = Gateway | GRA = Globally Routable Address | |||
GW = Gateway | ||||
Figure 1 | Figure 2: Reference Path with Measurement Point Designations | |||
Each measurement point on a specific reference path MUST be assigned | Each measurement point on a specific reference path MUST be assigned | |||
a unique number. To facilitate interpretation of the results, the | a unique number. To facilitate interpretation of the results, the | |||
measuring organisation (and whoever it shares results with) MUST have | measuring organization (and whoever it shares results with) MUST have | |||
an unambiguous understanding of what path or point was measured. In | an unambiguous understanding of what path or point was measured. In | |||
order to achieve this, a set of numbering recommendations follow. | order to achieve this, a set of numbering recommendations follow. | |||
When communicating the results of measurements, the measuring | When communicating the results of measurements, the measuring | |||
organization SHOULD supply a diagram similar to Figure 1 (with the | organization SHOULD supply a diagram similar to Figure 2 (with the | |||
technology-specific information in examples that follow), and MUST | technology-specific information in examples that follow) and MUST | |||
supply it when additional measurement point numbers have been defined | supply it when additional measurement point numbers have been defined | |||
and used, with sufficient detail to identify measurement locations in | and used (with sufficient detail to identify measurement locations in | |||
the path. | the path). | |||
Ideally, the consumer of measurement results would know the location | Ideally, the consumer of measurement results would know the location | |||
of a measurement point on the reference path from the measurement | of a measurement point on the reference path from the measurement | |||
point number alone, and the recommendations below provide a way to | point number alone; the recommendations below provide a way to | |||
accomplish this goal. Although the initial numbering may be fully | accomplish this goal. Although the initial numbering may be fully | |||
compliant with this system, network growth, consolidation, and re- | compliant with this system, changing circumstances could, over time, | |||
arrangement, or circumstances such as ownership changes, could cause | lead to gaps in network numbers or non-monotonic measurement point | |||
gaps in network numbers or non-monotonic measurement point number | number assignments along the path. Such circumstances could include | |||
assignments along the path over time. These are examples of | growth, consolidation, re-arrangement, and change of ownership of the | |||
reasonable causes for numbering deviations which must be identified | network. These are examples of reasonable causes for numbering | |||
on the reference path diagram, as required above. | deviations that must be identified on the reference path diagram, as | |||
required above. | ||||
Whilst the numbering of a measurement point is in the context of a | While the numbering of a measurement point is in the context of a | |||
particular path, for simplicity the measuring organisation SHOULD use | particular path, for simplicity, the measuring organization SHOULD | |||
the same numbering for a device (playing the same role) on all the | use the same numbering for a device (playing the same role) on all | |||
measurement paths through it. Similarly, whilst the measurement | the measurement paths through it. Similarly, whilst the measurement | |||
point numbering is in the context of a particular measuring | point numbering is in the context of a particular measuring | |||
organisation, organizations with similar technologies and | organization, organizations with similar technologies and | |||
architectures are encouraged to coordinate on local numbering and | architectures are encouraged to coordinate on local numbering and | |||
diagrams. | diagrams. | |||
The measurement point numbering system, mpXnn, has two independent | The measurement point numbering system, mpXnn, has two independent | |||
parts: | parts: | |||
1. The X in mpXnn indicates the network number. The network with | 1. The X in mpXnn indicates the network number. The network with | |||
the Subscriber's device is network 0. The network of a different | the subscriber's device is network 0. The network of a different | |||
organization (administrative or ownership domains) SHOULD be | organization (administrative or ownership domains) SHOULD be | |||
assigned a different number. Each successive network number | assigned a different number. Each successive network number | |||
SHOULD be one greater than the previous network's number. Two | SHOULD be one greater than the previous network's number. Two | |||
circumstances make it necessary to designate X=9 in the | circumstances make it necessary to designate X=9 in the | |||
Destination Host's network and X=8 for the Service Provider | destination host's network and X=8 for the service provider | |||
network at the Destination: | network at the destination: | |||
A. The number of Transit networks is unknown. | A. The number of transit networks is unknown. | |||
B. The number of Transit networks varies over time. | B. The number of transit networks varies over time. | |||
2. The nn in mpXnn indicates the measurement point and is locally- | 2. The nn in mpXnn indicates the measurement point and is locally | |||
assigned by network X. The following conventions are suggested: | assigned by network X. The following conventions are suggested: | |||
A. 00 SHOULD be used for a measurement point at the Subscriber's | A. 00 SHOULD be used for a measurement point at the subscriber's | |||
device and at the Service Demarcation point or GW nearest to | device and at the service demarcation point or GW nearest to | |||
the Subscriber's device for Transit Networks. | the subscriber's device for transit networks. | |||
B. 90 SHOULD be used for a measurement point at the GW of a | B. 90 SHOULD be used for a measurement point at the GW of a | |||
network (opposite from the Subscriber's device or Service | network (opposite from the subscriber's device or service | |||
Demarc.). | demarcation). | |||
C. In most networks, measurement point numbers SHOULD | C. In most networks, measurement point numbers SHOULD | |||
monotonically increase from the point nearest the | monotonically increase from the point nearest the | |||
Subscriber's device to the opposite network boundary on the | subscriber's device to the opposite network boundary on the | |||
path (see below). | path (but see item D for an exception). | |||
D. When a Destination host is part of the path, 00 SHOULD be | D. When a destination host is part of the path, 00 SHOULD be | |||
used for a measurement point at the Destination host and at | used for a measurement point at the destination host and at | |||
the Destination's Service Demarcation point. Measurement | the destination's service demarcation point. Measurement | |||
point numbers SHOULD monotonically increase from the point | point numbers SHOULD monotonically increase from the point | |||
nearest the Destination's host to the opposite network | nearest the destination's host to the opposite network | |||
boundary on the path ONLY in these networks. This | boundary on the path ONLY in these networks. This | |||
directional numbering reversal allows consistent 00 | directional numbering reversal allows consistent 00 | |||
designation for end hosts and Service Demarcs. | designation for end hosts and service demarcation. | |||
E. 50 MAY be used for an intermediate measurement point of | E. 50 MAY be used for an intermediate measurement point of | |||
significance, such as a Network Address Translator (NAT). | significance, such as a Network Address Translator (NAT). | |||
F. 20 MAY be used for a traffic aggregation point such as a | F. 20 MAY be used for a traffic aggregation point, such as a | |||
DSLAM within a network. | Digital Subscriber Line Access Multiplexer (DSLAM) within a | |||
network. | ||||
G. Any other measurement points SHOULD be assigned unused | G. Any other measurement points SHOULD be assigned unused | |||
integers between 01 and 99. The assignment SHOULD be stable | integers between 01 and 99. The assignment SHOULD be stable | |||
for at least the duration of a particular measurement study, | for at least the duration of a particular measurement study | |||
and SHOULD avoid numbers that have been assigned to other | and SHOULD avoid numbers that have been assigned to other | |||
locations within network X (unless the assignment is | locations within network X (unless the assignment is | |||
considered sufficiently stale). Sub-networks or domains | considered sufficiently stale). Subnetworks or domains | |||
within a network are useful locations for measurement points. | within a network are useful locations for measurement points. | |||
When supplying a diagram of the reference path and measurement | When supplying a diagram of the reference path and measurement | |||
points, the operator of the measurement system MUST indicate: the | points, the operator of the measurement system MUST indicate the | |||
reference path, the numbers (mpXnn) of the measurement points, and | reference path, the numbers (mpXnn) of the measurement points, and | |||
the technology-specific definition of any measurement point other | the technology-specific definition of any measurement point other | |||
than X00 and X90 with sufficient detail to clearly define its | than X00 and X90 with sufficient detail to clearly define its | |||
location (similar to the technology-specific examples in Section 6 of | location (similar to the technology-specific examples in Section 6 of | |||
this document). | this document). | |||
If the number of intermediate networks (between the source and | If the number of intermediate networks (between the source and | |||
destination) is not known or is unstable, then this SHOULD be | destination) is not known or is unstable, then this SHOULD be | |||
indicated on the diagram and results from measurement points within | indicated on the diagram, and results from measurement points within | |||
those networks need to be treated with caution. | those networks need to be treated with caution. | |||
Notes: | Notes: | |||
o The terminology "on-net" and "off-net" is sometimes used when | o The terminology "on-net" and "off-net" is sometimes used when | |||
referring to the Subscriber's Internet Service Provider (ISP) | referring to the subscriber's Internet Service Provider (ISP) | |||
measurement coverage. With respect to the reference path, tests | measurement coverage. With respect to the reference path, tests | |||
between mp100 and mp190 are "on-net". | between mp100 and mp190 are "on-net". | |||
o Widely deployed broadband Internet access measurements have used | o Widely deployed broadband Internet access measurements have used | |||
pass-through devices[SK] (at the subscriber's location) directly | pass-through devices [SK] (at the subscriber's location) directly | |||
connected to the service demarcation point: this would be located | connected to the service demarcation point; this would be located | |||
at mp100. | at mp100. | |||
o The networking technology must be indicated for the measurement | o The networking technology must be indicated for the measurement | |||
points used, especially the interface standard and configured | points used, especially the interface standard and configured | |||
speed (because the measurement connectivity itself can be a | speed (because the measurement connectivity itself can be a | |||
limiting factor for the results). | limiting factor for the results). | |||
o If it can be shown that a link connecting to a measurement point | o If it can be shown that a link connecting to a measurement point | |||
has reliably deterministic performance or negligible impairments, | has reliably deterministic performance or negligible impairments, | |||
then the remote end of the connecting link is an equivalent point | then the remote end of the connecting link is an equivalent point | |||
for some methods of measurement (although those methods should | for some methods of measurement (although those methods should | |||
describe this possibility in detail; it is not in-scope to provide | describe this possibility in detail, it is not in scope to provide | |||
such methods here). In any case, the presence of a link and | such methods here). In any case, the presence of a link and | |||
claimed equivalent measurement point must be reported. | claimed equivalent measurement point must be reported. | |||
o Some access network architectures may have an additional traffic | o Some access network architectures may have an additional traffic | |||
aggregation device between mp100 and mp150. Use of a measurement | aggregation device between mp100 and mp150. Use of a measurement | |||
point at this location would require a local number and diagram. | point at this location would require a local number and diagram. | |||
o A Carrier Grade NAT (CGN) deployed in the Service Provider's | o A Carrier Grade NAT (CGN) deployed in the service provider's | |||
access network would be positioned between mp100 and mp190, and | access network would be positioned between mp100 and mp190, and | |||
the egress side of the CGN may be designated mp150. mp150 is | the egress side of the CGN may be designated mp150. mp150 is | |||
generally an intermediate measurement point in the same address | generally an intermediate measurement point in the same address | |||
space as mp190. | space as mp190. | |||
o In the case that private address space is used in an access | o In the case that private address space is used in an access | |||
architecture, then mp100 may need to use the same address space as | architecture, mp100 may need to use the same address space as its | |||
its "on-net" measurement point counterpart, so that a test between | "on-net" measurement point counterpart so that a test between | |||
these points produces a useful assessment of network performance. | these points produces a useful assessment of network performance. | |||
Tests between mp000 and mp100 could use a different private | Tests between mp000 and mp100 could use a different private | |||
address space, and when the globally-routable side of a CGN is at | address space, and when the globally routable side of a CGN is at | |||
mp150, then the private address side of the CGN could be | mp150, the private address side of the CGN could be designated | |||
designated mp149 for tests with mp100. | mp149 for tests with mp100. | |||
o Measurement points at Transit GRA GWs are numbered mpX00 and | o Measurement points at transit GRA GWs are numbered mpX00 and | |||
mpX90, where X is the lowest positive integer not already used in | mpX90, where X is the lowest positive integer not already used in | |||
the path. The GW of the first transit network is shown, with | the path. The GW of the first transit network is shown with point | |||
point mp200 and the last transit network GW with mpX90. | mp200 and the last transit network GW with mpX90. | |||
6. Translation Between Reference Path and Various Technologies | 6. Examples of Reference Paths with Various Technologies | |||
This section and those that follow are intended to provide example | This section and those that follow are intended to provide example | |||
mappings between particular network technologies and the reference | mappings between particular network technologies and the reference | |||
path. | path. | |||
We provide an example for 3G Cellular access below. | We provide an example for 3G cellular access below. | |||
Subscriber -- Private --- Service ------------- GRA --- Transit ... | Subscriber -- Private --- Service ------------- GRA --- Transit ... | |||
device Net #1 Demarc. GW GRA GW | device Net #1 Demarc. GW GRA GW | |||
mp000 mp100 mp190 mp200 | mp000 mp100 mp190 mp200 | |||
|_____________UE______________|___RAN+Core____|___GGSN__| | |_____________UE______________|___RAN+Core____|___GGSN__| | |||
|_____Un-managed sub-path_____|____Managed sub-path_____| | |_____Unmanaged sub-path_____|____Managed sub-path_____| | |||
GRA = Globally Routable Address, GW = Gateway, UE = User Equipment, | GRA = Globally Routable Address | |||
RAN = Radio Access Network, GGSN = Gateway GPRS Support Node. | GW = Gateway | |||
UE = User Equipment | ||||
RAN = Radio Access Network | ||||
GGSN = Gateway General Packet Radio Service (GPRS) Support Node | ||||
We next provide an example of DSL access. Consider the case where: | Figure 3: Example of Reference Path with 3G Cellular Access | |||
Next, we provide an example of DSL access. Consider the case where: | ||||
o The Customer Premises Equipment (CPE) has a NAT device that is | o The Customer Premises Equipment (CPE) has a NAT device that is | |||
configured with a public IP address. | configured with a public IP address. | |||
o The CPE is a home router that has also an incorporated a WiFi | o The CPE consists of a wired residential GW and modem internally | |||
access point and this is the only networking device in the home | connected (via Private Net #2) to an embedded home router and WiFi | |||
network, all endpoints attach directly to the CPE though the WiFi | access point (Private Net #1). All subscriber devices (UE) attach | |||
access. | to the CPE through the WiFi access. mp100 is on the modem side of | |||
Private Net #2. | ||||
We believe this is a fairly common configuration in some parts of the | We believe this is a fairly common configuration in some parts of the | |||
world and fairly simple as well. | world and is fairly simple as well. | |||
This case would map into the defined reference measurement points as | This case would map into the defined reference measurement points as | |||
follows: | follows: | |||
Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit ... | Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit ... | |||
device Net #1 Net #2 Demarc. Access GW GRA GW | device Net #1 Net #2 Demarc. Access GW GRA GW | |||
mp000 mp100 mp150 mp190 mp200 | mp000 mp100 mp150 mp190 mp200 | |||
|--UE--|------------CPE/NAT--------|------|-BRAS-|------| | |--UE--|------------CPE/NAT--------|------|-BRAS-|------| | |||
|------DSL Network---| | |------DSL Network---| | |||
|_______Un-managed sub-path________|__Managed sub-path__| | |________Unmanaged sub-path________|__Managed sub-path__| | |||
GRA = Globally Routable Address, GW = Gateway, BRAS = Broadband | GRA = Globally Routable Address | |||
Remote Access Server | GW = Gateway | |||
BRAS = Broadband Remote Access Server | ||||
Consider next another access network case where: | Figure 4: Example of Reference Path with DSL Access | |||
o The Customer Premises Equipment (CPE) is a NAT device that is | Consider another access network case where: | |||
configured with a private IP address. | ||||
o There is a Carrier Grade NAT (CGN) located deep in the Access ISP | o The CPE is a NAT device that is configured with a private IP | |||
network. | address. | |||
o There is a CGN located deep in the access ISP network. | ||||
o The CPE is a home router that has also an incorporated a WiFi | o 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 | access point and this is the only networking device in the home | |||
network, all endpoints attach directly to the CPE though the WiFi | network, all endpoints attach directly to the CPE through the WiFi | |||
access. | access. | |||
We believe this is becoming a fairly common configuration in some | We believe this is becoming a fairly common configuration in some | |||
parts of the world. | parts of the world. | |||
This case would map into the defined reference measurement points as | This case would map into the defined reference measurement points as | |||
follows: | follows: | |||
Subsc. -- Private ------------- Service-- Intra IP -- GRA -- Transit ... | Subsc. -- Private ------------- Service-- Intra IP -- GRA -- Transit ... | |||
device Net #1 Demarc. Access GW GRA GW | device Net #1 Demarc. Access GW GRA GW | |||
mp000 mp100 mp150 mp190 mp200 | mp000 mp100 mp150 mp190 mp200 | |||
|--UE--|------------CPE/NAT--------|------|-CGN-|------| | |--UE--|------------CPE/NAT--------|------|-CGN-|------| | |||
|--Access Network---| | |--Access Network---| | |||
|_______Un-managed sub-path________|_Managed sub-path__| | |________Unmanaged sub-path________|_Managed sub-path__| | |||
GRA = Globally Routable Address, GW = Gateway | GRA = Globally Routable Address | |||
GW = Gateway | ||||
CGN = Carrier Grade NAT | ||||
7. Example Resource Transition | Figure 5: Example of Reference Path with CGN | |||
This section gives an example of Shared and Dedicated portions with | 7. Example of Reference Path with Resource Transition | |||
the reference path. This example shows two Resource Transition | ||||
Points. | 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: | Consider the case where: | |||
o The CPE consists of a wired Residential GW and modem (Private | o The CPE consists of a wired residential GW and modem (Private Net | |||
Net#2) connected to a WiFi access point (Private Net#1). The | #2) connected to a WiFi access point (Private Net #1). The | |||
Subscriber device (UE) attaches to the CPE though the WiFi access. | subscriber device (UE) attaches to the CPE through the WiFi | |||
access. | ||||
o The WiFi subnetwork (Private Net#1) shares unlicensed radio | o The WiFi subnetwork (Private Net #1) shares unlicensed radio | |||
channel resources with other WiFi access networks (and potentially | channel resources with other WiFi access networks (and potentially | |||
other sources of interference), thus this is a Shared portion of | other sources of interference); thus, this is a shared portion of | |||
the path. | the path. | |||
o The wired subnetwork (Private Net#2) and a portion of the Service | o The wired subnetwork (Private Net #2) and a portion of the service | |||
Provider's Network are Dedicated Resources (for a single | provider's network are dedicated resources (for a single | |||
Subscriber), thus there is a Resource Transition Point between | subscriber); thus, there is a resource transition point between | |||
(Private Net#1) and (Private Net#2). | Private Net #1 and Private Net #2. | |||
o Subscriber traffic shares common resources with other subscribers | o Subscriber traffic shares common resources with other subscribers | |||
upon reaching the Carrier Grade NAT (CGN), thus there is a | upon reaching the CGN; thus, there is a resource transition point | |||
Resource Transition Point and further network components are | and further network components are designated as shared resources. | |||
designated as Shared Resources. | ||||
We believe this is a fairly common configuration in parts of the | We believe this is a fairly common configuration in parts of the | |||
world. | world. | |||
This case would map into the defined reference measurement points as | This case would map into the defined reference measurement points as | |||
follows: | follows: | |||
Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit ... | Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit ... | |||
device Net #1 Net #2 Demarc. Access GW GRA GW | device Net #1 Net #2 Demarc. Access GW GRA GW | |||
mp000 mp100 mp150 mp190 mp200 | mp000 mp100 mp150 mp190 mp200 | |||
|--UE--|------------CPE/NAT--------|------|-CGN-|------| | |--UE--|------------CPE/NAT--------|------|-CGN-|------| | |||
| WiFi | 1000Base-T |--Access Network---| | | WiFi | 1000Base-T |--Access Network---| | |||
|-Shared--|RT|------Dedicated------| RT |-----Shared------... | |-Shared--|RT|------Dedicated------| RT |-----Shared------... | |||
|_______Un-managed sub-path________|_Managed sub-path__| | |_______Unmanaged sub-path________|_Managed sub-path__| | |||
GRA = Globally Routable Address, GW = Gateway, RT = Resource | GRA = Globally Routable Address | |||
Transition Point | GW = Gateway | |||
RT = Resource Transition Point | ||||
8. Security considerations | Figure 6: Example of Reference Path with Two Reference Transition | |||
Points | ||||
Specification of a Reference Path and identification of measurement | 8. Security Considerations | |||
points on the path represent agreements among interested parties, and | ||||
they present no threat to the implementors of this memo, or to the | 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 | Internet resulting from implementation of the guidelines provided | |||
here. | here. | |||
Attacks at end hosts or identified measurement points are possible. | Attacks at end hosts or identified measurement points are possible. | |||
However, there is no requirement to include IP addresses of hosts or | However, there is no requirement to include IP addresses of hosts or | |||
other network devices in a reference path with measurement points | other network devices in a reference path with measurement points | |||
that is compliant with this memo. As a result, the path diagrams | that is compliant with this memo. As a result, the path diagrams | |||
with measurement point designation numbers do not aid such attacks. | with measurement point designation numbers do not aid such attacks. | |||
Most network operators' diagrams of reference paths will bear a close | Most network operators' diagrams of reference paths will bear a close | |||
skipping to change at page 14, line 7 | skipping to change at page 15, line 14 | |||
atypical network details in their diagram, e.g., to explain why a | atypical network details in their diagram, e.g., to explain why a | |||
longer latency measurement is expected, then the diagram reveals some | longer latency measurement is expected, then the diagram reveals some | |||
topological details and should be marked as confidential and shared | topological details and should be marked as confidential and shared | |||
with others under a specific agreement. | with others under a specific agreement. | |||
When considering privacy of those involved in measurement or those | When considering privacy of those involved in measurement or those | |||
whose traffic is measured, there may be sensitive information | whose traffic is measured, there may be sensitive information | |||
communicated to recipients of the network diagrams illustrating paths | communicated to recipients of the network diagrams illustrating paths | |||
and measurement points described above. We refer the reader to the | and measurement points described above. We refer the reader to the | |||
privacy considerations described in the Large Scale Measurement of | privacy considerations described in the Large Scale Measurement of | |||
Broadband Performance (LMAP) Framework [I-D.ietf-lmap-framework], | Broadband Performance (LMAP) Framework [LMAP-FRAMEWORK], which covers | |||
which covers active and passive measurement techniques and supporting | active and passive measurement techniques and supporting material on | |||
material on measurement context. For example, the value of sensitive | measurement context. For example, the value of sensitive information | |||
information can be further diluted by summarising measurement results | can be further diluted by summarizing measurement results over many | |||
over many individuals or areas served by the provider. There is an | individuals or areas served by the provider. There is an opportunity | |||
opportunity enabled by forming anonymity sets described in [RFC6973] | enabled by forming anonymity sets described in [RFC6973] based on the | |||
based on the reference path and measurement points in this memo. For | reference path and measurement points in this memo. For example, all | |||
example, all measurements from the Subscriber device can be | measurements from the subscriber device can be identified as "mp000", | |||
identified as "mp000", instead of using the IP address or other | instead of using the IP address or other device information. The | |||
device information. The same anonymisation applies to the Internet | same anonymization applies to the Internet service provider, where | |||
Service Provider, where their Internet gateway would be referred to | their Internet gateway would be referred to as "mp190". | |||
as "mp190". | ||||
9. IANA Considerations | ||||
This memo makes no requests for IANA consideration. | ||||
10. Acknowledgements | ||||
Thanks to Matt Mathis, Charles Cook, Dan Romascanu, Lingli Deng, and | 9. References | |||
Spencer Dawkins for review and comments. | ||||
11. References | 9.1. Normative References | |||
11.1. Normative References | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997, | ||||
<http://www.rfc-editor.org/info/rfc2119>. | ||||
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, | [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, | |||
"Framework for IP Performance Metrics", RFC 2330, May | "Framework for IP Performance Metrics", RFC 2330, May | |||
1998. | 1998, <http://www.rfc-editor.org/info/rfc2330>. | |||
[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 | [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network | |||
performance measurement with periodic streams", RFC 3432, | performance measurement with periodic streams", RFC 3432, | |||
November 2002. | November 2002, <http://www.rfc-editor.org/info/rfc3432>. | |||
[RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric | [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric | |||
Composition", RFC 5835, April 2010. | Composition", RFC 5835, April 2010, | |||
<http://www.rfc-editor.org/info/rfc5835>. | ||||
11.2. Informative References | 9.2. Informative References | |||
[I-D.ietf-lmap-framework] | [LMAP-FRAMEWORK] | |||
Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., | Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., | |||
Aitken, P., and A. Akhter, "A framework for large-scale | Aitken, P., and A. Akhter, "A framework for large-scale | |||
measurement platforms (LMAP)", draft-ietf-lmap- | measurement platforms (LMAP)", Work in Progress, | |||
framework-08 (work in progress), August 2014. | draft-ietf-lmap-framework-10, January 2015. | |||
[Q.1741] International Telecommunications Union, "IMT-2000 | ||||
references to Release 9 of GSM-evolved UMTS core network", | ||||
ITU-T Recommendation Q.1741.7, November 2011, | ||||
<http://www.itu.int/rec/T-REC-Q.1741.7/en>. | ||||
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., | [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., | |||
Morris, J., Hansen, M., and R. Smith, "Privacy | Morris, J., Hansen, M., and R. Smith, "Privacy | |||
Considerations for Internet Protocols", RFC 6973, July | Considerations for Internet Protocols", RFC 6973, July | |||
2013. | 2013, <http://www.rfc-editor.org/info/rfc6973>. | |||
[SK] Crawford, Sam., "Test Methodology White Paper", SamKnows | [SK] Crawford, S., "Test Methodology White Paper", SamKnows | |||
Whitebox Briefing Note | Whitebox Briefing Note , July 2011, | |||
http://www.samknows.com/broadband/index.php, July 2011. | <http://www.samknows.com/broadband/index.php>. | |||
[Q1741] Q.1741.7, , "IMT-2000 references to Release 9 of GSM- | [Y.1541] International Telecommunications Union, "Network | |||
evolved UMTS core network", | performance objectives for IP-based services", ITU-T | |||
http://www.itu.int/rec/T-REC-Q.1741.7/en, November 2011. | Recommendation Y.1541, November 2011, | |||
<http://www.itu.int/rec/T-REC-Y.1541/en>. | ||||
[Y.1541] Y.1541, , "Network performance objectives for IP-based | Acknowledgments | |||
services", http://www.itu.int/rec/T-REC-Y.1541/en, | ||||
November 2011. | Thanks to Matt Mathis, Charles Cook, Dan Romascanu, Lingli Deng, and | |||
Spencer Dawkins for review and comments. | ||||
Authors' Addresses | Authors' Addresses | |||
Marcelo Bagnulo | Marcelo Bagnulo | |||
Universidad Carlos III de Madrid | Universidad Carlos III de Madrid | |||
Av. Universidad 30 | Av. Universidad 30 | |||
Leganes, Madrid 28911 | Leganes, Madrid 28911 | |||
SPAIN | Spain | |||
Phone: 34 91 6249500 | Phone: 34 91 6249500 | |||
Email: marcelo@it.uc3m.es | EMail: marcelo@it.uc3m.es | |||
URI: http://www.it.uc3m.es | URI: http://www.it.uc3m.es | |||
Trevor Burbridge | Trevor Burbridge | |||
BT | BT | |||
Adastral Park, Martlesham Heath | Adastral Park, Martlesham Heath | |||
Ipswich | Ipswich | |||
ENGLAND | United Kingdom | |||
EMail: trevor.burbridge@bt.com | ||||
Email: trevor.burbridge@bt.com | ||||
Sam Crawford | Sam Crawford | |||
SamKnows | SamKnows | |||
Email: sam@samknows.com | EMail: sam@samknows.com | |||
Phil Eardley | Philip Eardley | |||
BT | BT | |||
Adastral Park, Martlesham Heath | Adastral Park, Martlesham Heath | |||
Ipswich | Ipswich | |||
ENGLAND | United Kingdom | |||
Email: philip.eardley@bt.com | EMail: philip.eardley@bt.com | |||
Al Morton | Al Morton | |||
AT&T Labs | AT&T Labs | |||
200 Laurel Avenue South | 200 Laurel Avenue South | |||
Middletown, NJ | Middletown, NJ | |||
USA | United States | |||
Email: acmorton@att.com | EMail: acmorton@att.com | |||
End of changes. 130 change blocks. | ||||
280 lines changed or deleted | 302 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |