| < draft-ietf-ippm-lmap-path-02.txt | draft-ietf-ippm-lmap-path-03.txt > | |||
|---|---|---|---|---|
| Network Working Group M. Bagnulo | Network Working Group M. Bagnulo | |||
| Internet-Draft UC3M | Internet-Draft UC3M | |||
| Intended status: Standards Track T. Burbridge | Intended status: Informational T. Burbridge | |||
| Expires: August 17, 2014 BT | Expires: November 29, 2014 BT | |||
| S. Crawford | S. Crawford | |||
| SamKnows | SamKnows | |||
| P. Eardley | P. Eardley | |||
| BT | BT | |||
| A. Morton | A. Morton | |||
| AT&T Labs | AT&T Labs | |||
| February 13, 2014 | May 28, 2014 | |||
| A Reference Path and Measurement Points for LMAP | A Reference Path and Measurement Points for LMAP | |||
| draft-ietf-ippm-lmap-path-02 | draft-ietf-ippm-lmap-path-03 | |||
| 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. | commonly used performance metrics. The methods for measurement point | |||
| location may be applicable to similar measurement projects using the | ||||
| extensions described here. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on August 17, 2014. | This Internet-Draft will expire on November 29, 2014. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2014 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 | |||
| skipping to change at page 2, line 21 ¶ | skipping to change at page 2, line 23 ¶ | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 | 3. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3.1. Reference Path . . . . . . . . . . . . . . . . . . . . . 3 | 3.1. Reference Path . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3.2. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 4 | 3.2. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.3. Dedicated Component (Links or Nodes) . . . . . . . . . . 4 | 3.3. Dedicated Component (Links or Nodes) . . . . . . . . . . 4 | |||
| 3.4. Shared Component (Links or Nodes) . . . . . . . . . . . . 4 | 3.4. Shared Component (Links or Nodes) . . . . . . . . . . . . 4 | |||
| 3.5. Resource Transition Point . . . . . . . . . . . . . . . . 4 | 3.5. Resource Transition Point . . . . . . . . . . . . . . . . 4 | |||
| 3.6. Managed and Un-Managed Sub-paths . . . . . . . . . . . . 4 | 3.6. Managed and Un-Managed Sub-paths . . . . . . . . . . . . 4 | |||
| 4. Reference Path . . . . . . . . . . . . . . . . . . . . . . . 4 | 4. Reference Path . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 5. Measurement Points . . . . . . . . . . . . . . . . . . . . . 6 | 5. Measurement Points . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 6. Translation Between Ref. Path and Tech. X . . . . . . . . . . 8 | 6. Translation Between Reference Path and Various Technologies . 10 | |||
| 7. Example Resource Transition . . . . . . . . . . . . . . . . . 9 | 7. Example Resource Transition . . . . . . . . . . . . . . . . . 11 | |||
| 8. Security considerations . . . . . . . . . . . . . . . . . . . 10 | 8. Security considerations . . . . . . . . . . . . . . . . . . . 12 | |||
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 | |||
| 11.2. Informative References . . . . . . . . . . . . . . . . . 11 | 11.2. Informative References . . . . . . . . . . . . . . . . . 13 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 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). The series of IP Performance | Broadband Access Performance (LMAP) or similar measurement projects. | |||
| Metrics (IPPM) RFCs have developed terms that are generally useful | The series of IP Performance Metrics (IPPM) RFCs have developed terms | |||
| for path description (section 5 of [RFC2330]). There are a limited | that are generally useful for path description (section 5 of | |||
| number of additional terms needing definition here, and they will be | [RFC2330]). There are a limited number of additional terms needing | |||
| defined in this memo. | definition here, and they will be defined in this memo. | |||
| The reference path is usually needed when attempting to communicate | The reference path is usually needed when attempting to communicate | |||
| precisely about the components that comprise the path, often in terms | precisely about the components that comprise the path, often in terms | |||
| of their number (hops) and geographic location. This memo takes the | of their number (hops) and geographic location. This memo takes the | |||
| path definition further, by establishing a set of measurement points | path definition further, by establishing a set of measurement points | |||
| along the path and ascribing a unique designation to each point. | along the path and ascribing a unique designation to each point. | |||
| This topic has been previously developed in section 5.1 of [RFC3432], | This topic has been previously developed in section 5.1 of [RFC3432], | |||
| and as part of the updated framework for composition and aggregation, | and as part of the updated framework for composition and aggregation, | |||
| section 4 of [RFC5835] (which may also figure in the LMAP work | section 4 of [RFC5835] (which may also figure in the LMAP work | |||
| effort). Section 4.1 of [RFC5835] defines the term "measurement | effort). Section 4.1 of [RFC5835] defines the term "measurement | |||
| point". | point". | |||
| Measurement points and the paths they cover are often described in | Measurement points and the paths they cover 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 are insufficient for scientific method: What is an end? Where | terms alone are insufficient for scientific method: What is an end? | |||
| is a user located? Is the home network included? | Where is a user located? Is the home network included? | |||
| 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 metadata to describe measurement | This is an essential part of the meta-data 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. | valid basis for performance comparisons. | |||
| 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 sufficient level of detail to determine the location | |||
| of different measurement points without ambiguity. | of different measurement points along a path without ambiguity. | |||
| The bridge 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 effort. Both wired and wireless technologies are in- | scope of this method, and examples are provided. Both wired and | |||
| 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 this regard. | that the measurement result will adequately described in terms of | |||
| This should serve many measurement uses, including diagnostic (where | scope or coverage. This should serve many measurement uses, | |||
| the same metric may be measured over many different path scopes) and | including: | |||
| comparative (where the same metric may be measured on different | ||||
| network infrastructures). | diagnostic where the same metric may be measured over many different | |||
| path scopes | ||||
| comparison where the same metric may be measured on equivalent | ||||
| portions of different network infrastructures | ||||
| 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 the purposes of this | |||
| memo. | memo. | |||
| 3.1. Reference Path | 3.1. Reference Path | |||
| A reference path is a serial combination of routers, switches, links, | A reference path is a serial combination of routers, switches, links, | |||
| radios, and processing elements that comprise all the network | radios, and processing elements that comprise all the network | |||
| skipping to change at page 4, line 44 ¶ | skipping to change at page 4, line 47 ¶ | |||
| that may be a point of significance, and is identified as a | that may be a point of significance, and is identified as a | |||
| transition between two types of resources. | transition between two types of resources. | |||
| 3.6. Managed and Un-Managed Sub-paths | 3.6. Managed and Un-Managed 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 which 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 are designated as un-managed sub-paths. | |||
| The Access demarcation point always divides managed and un-managed | The Service demarcation point always divides managed and un-managed | |||
| sub-paths. | sub-paths. | |||
| 4. Reference Path | 4. Reference Path | |||
| This section defines a reference path for Internet Access. | This section defines a reference path for Internet communication. | |||
| Subsc. -- Private -- Private -- Access -- 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 | |||
| 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 Access Service Subscriber. In some | by the Internet Service Subscriber. In some configurations, one | |||
| configurations, one or more private networks and the device that | or more private networks and the device that provides the Service | |||
| provides the Access Service Demarcation point are collapsed in a | Demarcation point are collapsed in a single device (and ownership | |||
| single device (and ownership may shift to the service provider), | may shift to the service provider), and this should be noted as | |||
| and this should be noted as part of the path description. | part of the path description. | |||
| o Access (Service) Demarcation point - this varies by technology but | o Service Demarcation point - This is the point where service | |||
| is usually defined as the Ethernet interface on a residential | managed by the serivce provider begins (or ends), and varies by | |||
| gateway or modem where the scope of access packet transfer service | technology. For example, this point is usually defined as the | |||
| begins and ends. In the case of a WiFi Service, this would be an | Ethernet interface on a residential gateway or modem where the | |||
| Air Interface within the intended service boundary (e.g., walls of | scope of a packet transfer service begins and ends. In the case | |||
| the coffee shop). The Demarcation point may be within an | of a WiFi Service, this would be an Air Interface within the | |||
| integrated endpoint using an Air Interface (e.g., LTE UE). | intended service boundary (e.g., walls of the coffee shop). The | |||
| Ownership may not affect the demarcation point; a Subscriber may | Demarcation point may be within an integrated endpoint using an | |||
| own all equipment on their premises, but it is likely that the | Air Interface (e.g., LTE UE). Ownership may not affect the | |||
| service provider will certify such equipment for connection to | demarcation point; a Subscriber may own all equipment on their | |||
| their access network, or a third-party will certify standards | premises, but it is likely that the service provider will certify | |||
| compliance. | such equipment for connection to their network, or a third-party | |||
| will certify standards compliance. | ||||
| 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 Access Service Demarc. where a globally | architecture beyond the Service Demarc. where a globally routable | |||
| routable IP address is exposed and used for routing. In | IP address is exposed and used for routing. In architectures that | |||
| architectures that use tunneling, this point may be equivalent to | use tunneling, this point may be equivalent to the GRA GW. This | |||
| the GRA GW. This point could also collapse to the device | point could also collapse to the device providing the Service | |||
| providing the Access Service Demarc., in principle. Only one | Demarc., in principle. Only one Intra IP Access point is shown, | |||
| Intra IP Access point is shown, but they can be identified in any | but they can be identified in any access network. | |||
| access or transit network. | ||||
| o GRA GW - the point of interconnection between the access | o GRA GW - the point of interconnection between a Service Provider's | |||
| administrative domain and the rest of the Internet, where routing | administrative domain and the rest of the Internet, where routing | |||
| will depend on the GRAs in the IP header. | will depend on the GRAs in the IP header. | |||
| o Transit GRA GW - Networks that intervene between the Subscriber's | o Transit GRA GW - If one or more networks intervene between the | |||
| Access network and the Destination Host's network are designated | Service Provider's access networks of the Subscriber and of the | |||
| "transit" and involve two GRA GW. | Destination Host, then such networks are designated "transit" and | |||
| are bounded by two Transit GRA GW. | ||||
| 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 Access Service Demarc. and the Intra IP Access | architecture, then the Service Demarc. and the Intra IP Access points | |||
| points must use the same address space and be separated by the shared | must use the same address space and be separated by the shared and | |||
| and dedicated access link infrastructure, such that a test between | dedicated access link infrastructure, such that a test between these | |||
| these points produces a useful assessment of access performance. | points produces a useful assessment of access performance. | |||
| 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 section | |||
| 4.1 of [RFC5835], is that the innermost IP header and higher layer | 4.1 of [RFC5835], is that the innermost IP header and higher layer | |||
| information must be accessible through some means. This is essential | information must be accessible through some means. This is essential | |||
| to measure IP metrics. There may be tunnels and/or other layers | to measure IP metrics. There may be tunnels and/or other layers | |||
| which encapsulate the innermost IP header, even adding another IP | which encapsulate the innermost IP header, even adding another IP | |||
| header of their own. | 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, deterministic errors that can be quantified are ideal. | 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 | 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 -- Access -- 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 | |||
| The numbering for measurement points (mpNNN) allows for considerable | Figure 1 | |||
| local use of unallocated numbers. | ||||
| 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. | ||||
| The measurement point numbering system, mpXnn, has two independent | ||||
| parts: | ||||
| 1. 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: | ||||
| A. The number of Transit networks is unknown. | ||||
| B. The number of Transit networks varies over time. | ||||
| 2. The nn in mpXnn indicates the measurement point and is locally- | ||||
| assigned by network X. The following conventions are suggested: | ||||
| A. 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. | ||||
| B. 90 SHOULD be used for a measurement point at the GW of a | ||||
| network (opposite from the Subscriber's device or Service | ||||
| Demarc.). | ||||
| C. 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). | ||||
| D. 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. | ||||
| E. 50 MAY be used for an intermediate measurement point of | ||||
| significance, such as a Network Address Translator (NAT). | ||||
| F. 20 MAY be used for a traffic aggregation point such as a | ||||
| DSLAM within a network. | ||||
| G. 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. | ||||
| 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). | ||||
| 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: | Notes: | |||
| o Some use the terminology "on-net" and "off-net" when referring to | o Some use the terminology "on-net" and "off-net" when referring to | |||
| Internet Service Provider (ISP) measurement coverage. With | the Subscriber's Internet Service Provider (ISP) measurement | |||
| respect to the reference path, tests between mp100 and mp190 are | coverage. With respect to the reference path, tests between mp100 | |||
| "on-net". | and mp190 are "on-net". | |||
| o Widely deployed broadband access measurements have used pass- | o Widely deployed broadband Internet access measurements have used | |||
| 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 used at all measurement points must be | o The networking technology must be indicated for the measurement | |||
| indicated, especially the interface standard and configured speed. | points used, especially the interface standard and configured | |||
| speed (because the measurement connectivity itself can be a | ||||
| 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 or negligible performance, then the | has reliably deterministic performance or negligible impairments, | |||
| remote end of the connecting link is an equivalent point for some | then the remote end of the connecting link is an equivalent point | |||
| methods of measurement (To Be Specified Elsewhere). In any case, | for some methods of measurement (To Be Specified Elsewhere). In | |||
| the presence of such a link must be reported. | any case, the presence of a link and claimed equivalent | |||
| measurement point must be reported. | ||||
| o Many access network architectures have a traffic aggregation point | o Some access network architectures may have an additional traffic | |||
| (e.g., CMTS or DSLAM) between mp100 and mp150. We designate this | aggregation device between mp100 and mp150. Use of a measurement | |||
| point mp120, but it won't currently fit in the figure. | point at this location would require a local number and diagram. | |||
| o A Carrier Grade NAT (CGN) deployed in the Subscriber's access | o A Carrier Grade NAT (CGN) deployed in the Service Provider's | |||
| network would be positioned between mp100 and mp190, and the | access network would be positioned between mp100 and mp190, and | |||
| egress side of the CGN will typically be designated mp150. | the egress side of the CGN may be designated mp150. mp150 is | |||
| generally an intermediate measurement point in the same address | ||||
| space as mp190. | ||||
| o In the case that a 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, then mp100 may need to use the same address space as | |||
| its remote measurement point counterpart, so that a test between | its "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 private address space, and | Tests between mp000 and mp100 could use a different private | |||
| when the egress side of a CGN is at mp150, then the private | address space, and when the globally-routable side of a CGN is at | |||
| address side of the CGN could be designated mp149 for tests with | mp150, then the private address side of the CGN could be | |||
| mp100. | designated 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 path. The GW of first transit network is shown, with point | |||
| mp200 and the last transit network GW with mpX90. | ||||
| 6. Translation Between Ref. Path and Tech. X | 6. Translation Between Reference Path and Various Technologies | |||
| This section and those that follow are intended to provide a more | This section and those that follow are intended to provide a more | |||
| exact mapping between particular network technologies and the | exact mapping between particular network technologies and the | |||
| reference path. | reference path. | |||
| We provide an example for 3G Cellular access below. | We provide an example for 3G Cellular access below. | |||
| Subscriber -- Private -- Access Srvc ----------- 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_____| | |_____Un-managed sub-path_____|____Managed sub-path_____| | |||
| GRA = Globally Routable Address, GW = Gateway, UE = User Equipment, | GRA = Globally Routable Address, GW = Gateway, UE = User Equipment, | |||
| RAN = Radio Access Network, GGSN = Gateway GPRS Support Node. | RAN = Radio Access Network, GGSN = Gateway GPRS Support Node. | |||
| We next provide a few examples of DSL access. Consider first the | We next provide a few examples of DSL access. Consider first the | |||
| case where: | case where: | |||
| o The Customer Premises Equipment (CPE) is 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 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 though the WiFi | |||
| access. | access. | |||
| 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 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 -- Access -- 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-|------| | |||
| |----Access Network--| | |------DSL Network---| | |||
| |_______Un-managed sub-path________|__Managed sub-path__| | |_______Un-managed sub-path________|__Managed sub-path__| | |||
| GRA = Globally Routable Address, GW = Gateway | GRA = Globally Routable Address, GW = Gateway, BRAS = Broadband | |||
| Remote Acess Server | ||||
| Consider next the case where: | Consider next the case where: | |||
| o The Customer Premises Equipment (CPE) is a NAT device that is | o The Customer Premises Equipment (CPE) is a NAT device that is | |||
| configured with a private IP address. | configured with a private IP address. | |||
| o There is a Carrier Grade NAT (CGN) located deep into the Access | o There is a Carrier Grade NAT (CGN) located deep into the Access | |||
| ISP network. | 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 though the WiFi | |||
| access. | access. | |||
| We believe is becoming a fairly common configuration in some parts of | We believe this is becoming a fairly common configuration in some | |||
| 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 -- Private -- Access -- Intra IP -- GRA -- Transit | Subsc. -- Private ------------- Service-- Intra IP -- GRA -- Transit | |||
| device Net #1 Net #2 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--| | |-----DSL Network---| | |||
| |_______Un-managed sub-path________|_Managed sub-path__| | |_______Un-managed sub-path________|_Managed sub-path__| | |||
| GRA = Globally Routable Address, GW = Gateway | GRA = Globally Routable Address, GW = Gateway | |||
| 7. Example Resource Transition | 7. Example Resource Transition | |||
| This section gives an example of Shared and Dedicated portions with | This section gives an example of Shared and Dedicated portions with | |||
| the reference path. This example shows two Resource Transition | the reference path. This example shows two Resource Transition | |||
| Points. | Points. | |||
| skipping to change at page 9, line 48 ¶ | skipping to change at page 11, line 48 ¶ | |||
| o The CPE is wired Residential GW and modem (Private Net#2) | o The CPE is wired Residential GW and modem (Private Net#2) | |||
| connected to a WiFi access point (Private Net#1). The Subscriber | connected to a WiFi access point (Private Net#1). The Subscriber | |||
| device (UE) attaches to the CPE though the WiFi access. | device (UE) attaches to the CPE though the WiFi access. | |||
| o The Wi-Fi subnetwork (Private Net#1) shares unlicensed radio | o The Wi-Fi subnetwork (Private Net#1) shares unlicensed radio | |||
| channel resources with other W-Fi access networks (and potentially | channel resources with other W-Fi 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 Access | o The wired subnetwork (Private Net#2) and a portion of the Service | |||
| Network are Dedicated Resources (for a single Subscriber), thus | Provider's Network are Dedicated Resources (for a single | |||
| there is a Resource Transition Point between (Private Net#1) and | Subscriber), thus there is a Resource Transition Point between | |||
| (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 Carrier Grade NAT (CGN), thus there is a | |||
| Resource Transition Point and further network components are | Resource Transition Point and further network components are | |||
| designated as Shared Resources. | designated as Shared Resources. | |||
| We believe is becoming 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-|------| | |||
| Wi-Fi wired |---Access Network--| | | Wi-Fi | 1000Base-T |-----DSL Network---| | |||
| |-Shared--|RT|------Dedicated------| RT |-----Shared------... | |-Shared--|RT|------Dedicated------| RT |-----Shared------... | |||
| |_______Un-managed sub-path________|_Managed sub-path__| | |_______Un-managed sub-path________|_Managed sub-path__| | |||
| GRA = Globally Routable Address, GW = Gateway, RT = Resource | GRA = Globally Routable Address, GW = Gateway, RT = Resource | |||
| Transition Point | Transition Point | |||
| 8. Security considerations | 8. Security considerations | |||
| Specification of a Reference Path and identification of measurement | Specification of a Reference Path and identification of measurement | |||
| points on the path represent agreements among interested parties, and | points on the path represent agreements among interested parties, and | |||
| they present no threat to the readers of this memo or to the Internet | they present no threat to the readers of this memo or to the Internet | |||
| itself. | itself. | |||
| 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 [I-D.ietf-lmap-framework], | ||||
| which covers active and passive measurement techniques and supporting | ||||
| material on measurement context. | ||||
| 9. IANA Considerations | 9. IANA Considerations | |||
| TBD | This memo makes no requests for IANA consideration. | |||
| 10. Acknowledgements | 10. Acknowledgements | |||
| Thanks to Matt Mathis for review and comments. | Thanks to Matt Mathis, Charles Cook, Dan Romascanu, and Lingli Deng | |||
| for review and comments. | ||||
| 11. References | 11. References | |||
| 11.1. Normative References | 11.1. Normative References | |||
| [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. | |||
| [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. | |||
| [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip | ||||
| Delay Metric for IPPM", RFC 2681, September 1999. | ||||
| [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, | ||||
| August 2012. | ||||
| [RFC1035] Mockapetris, P., "Domain names - implementation and | ||||
| specification", STD 13, RFC 1035, November 1987. | ||||
| [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network | ||||
| Time Protocol Version 4: Protocol and Algorithms | ||||
| Specification", RFC 5905, June 2010. | ||||
| [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way | ||||
| Delay Metric for IPPM", RFC 2679, September 1999. | ||||
| [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way | ||||
| Packet Loss Metric for IPPM", RFC 2680, September 1999. | ||||
| [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation | ||||
| Metric for IP Performance Metrics (IPPM)", RFC 3393, | ||||
| November 2002. | ||||
| [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation | ||||
| Applicability Statement", RFC 5481, March 2009. | ||||
| [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. | |||
| 11.2. Informative References | 11.2. Informative References | |||
| [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics | [I-D.ietf-lmap-framework] | |||
| Registry", BCP 108, RFC 4148, August 2005. | Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., | |||
| Aitken, P., and A. Akhter, "A framework for large-scale | ||||
| [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics | measurement platforms (LMAP)", draft-ietf-lmap- | |||
| (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April | framework-05 (work in progress), May 2014. | |||
| 2011. | ||||
| [SK] Crawford, Sam., "Test Methodology White Paper", SamKnows | [SK] Crawford, Sam., "Test Methodology White Paper", SamKnows | |||
| Whitebox Briefing Note | Whitebox Briefing Note | |||
| http://www.samknows.com/broadband/index.php, July 2011. | http://www.samknows.com/broadband/index.php, July 2011. | |||
| [Q1741] Q.1741.7, , "IMT-2000 references to Release 9 of GSM- | [Q1741] Q.1741.7, , "IMT-2000 references to Release 9 of GSM- | |||
| evolved UMTS core network", | evolved UMTS core network", | |||
| http://www.itu.int/rec/T-REC-Q.1741.7/en, November 2011. | http://www.itu.int/rec/T-REC-Q.1741.7/en, November 2011. | |||
| Authors' Addresses | Authors' Addresses | |||
| skipping to change at page 12, line 20 ¶ | skipping to change at page 14, line 4 ¶ | |||
| 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 | |||
| British Telecom | BT | |||
| Adastral Park, Martlesham Heath | Adastral Park, Martlesham Heath | |||
| IPswitch | Ipswich | |||
| ENGLAND | ENGLAND | |||
| 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 | Phil Eardley | |||
| British Telecom | BT | |||
| Adastral Park, Martlesham Heath | Adastral Park, Martlesham Heath | |||
| IPswitch | Ipswich | |||
| ENGLAND | ENGLAND | |||
| 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 | USA | |||
| End of changes. 58 change blocks. | ||||
| 153 lines changed or deleted | 225 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||