idnits 2.17.1 draft-morton-ippm-lmap-path-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 31, 2013) is 4074 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2681' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'RFC6673' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'RFC5905' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC3393' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'RFC5481' is defined on line 354, but no explicit reference was found in the text == Unused Reference: 'RFC4148' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC6248' is defined on line 365, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Downref: Normative reference to an Informational RFC: RFC 5481 ** Downref: Normative reference to an Informational RFC: RFC 5835 -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft UC3M 4 Intended status: Standards Track T. Burbridge 5 Expires: August 4, 2013 BT 6 S. Crawford 7 SamKnows 8 P. Eardley 9 BT 10 A. Morton 11 AT&T Labs 12 January 31, 2013 14 A Reference Path and Measurement Points for LMAP 15 draft-morton-ippm-lmap-path-00 17 Abstract 19 This document defines a reference path for Large-scale Measurement of 20 Broadband Access Performance (LMAP) and measurement points for 21 commonly used performance metrics. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 4, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Terms and Definitions . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Reference Path . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Reference Path . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Measurement Points . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Translation Between Ref. Path and Tech. X . . . . . . . . . . . 6 64 7. Security considerations . . . . . . . . . . . . . . . . . . . . 8 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 This document defines a reference path for Large-scale Measurement of 75 Broadband Access Performance (LMAP). The series of IP Performance 76 Metrics (IPPM) RFCs have developed terms that are generally useful 77 for path description (section 5 of [RFC2330]). There are a limited 78 number of additional terms needing definition here, and they will be 79 defined in this memo. 81 The reference path is usually needed when attempting to communicate 82 precisely about the components that comprise the path, often in terms 83 of their number (hops) and geographic location. This memo takes the 84 path definition further, by establishing a set of measurement points 85 along the path and ascribing a unique designation to each point. 86 This topic has been previously developed in section 5.1 of [RFC3432], 87 and as part of the updated framework for composition and aggregation, 88 section 4 of [RFC5835] (which may also figure in the LMAP work 89 effort). Section 4.1 of [RFC5835] defines the term "measurement 90 point". 92 Measurement points and the paths they cover are often described in 93 general terms, like "end-to-end", "user-to-user", or "access". These 94 terms are insufficient for scientific method: What is an end? Where 95 is a user located? Is the home network included? 97 The motivation for this memo is to provide an unambiguous framework 98 to describe measurement coverage, or scope of the reference path. 99 This is an essential part of the metadata to describe measurement 100 results. Measurements conducted over different path scopes are not a 101 valid basis for performance comparisons. 103 2. Purpose and Scope 105 The scope of this memo is to define a reference path for LMAP 106 activities with sufficient level of detail to determine the location 107 of different measurement points without ambiguity. 109 The bridge between the reference path and specific network 110 technologies (with differing underlying architectures) is within the 111 scope of this effort. Both wired and wireless technologies are in- 112 scope. 114 The purpose is to create an efficient way to describe the location of 115 the measurement point(s) used to conduct a particular measurement so 116 that the measurement result will adequately described in this regard. 117 This should serve many measurement uses, including diagnostic (where 118 the same metric may be measured over many different path scopes) and 119 comparative (where the same metric may be measured on different 120 network infrastructures). 122 3. Terms and Definitions 124 3.1. Reference Path 126 A reference path is a serial combination of routers, switches, links, 127 radios, and processing elements that comprise all the network 128 elements traversed by each packet between the source and destination 129 hosts. The reference path is intended to be equally applicable to 130 all networking technologies, therefore the components are generically 131 defined, but their functions should have a clear counterpart or be 132 obviously omitted in any network technology. 134 4. Reference Path 136 This section defines a reference path for Internet Access. 138 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 139 device Net #1 Net #2 Demarc. Access GW GRA GW 141 ... Transit -- GRA -- Service -- Private -- Private -- Destination 142 GRA GW GW Demarc. Net #n Net #n+1 Host 144 GRA = Globally Routable Address, GW = Gateway 146 The following are descriptions of reference path components that may 147 not be clear from their name alone. 149 o Subsc. (Subscriber) device - This is a host that normally 150 originates and terminates communications conducted over the IP 151 packet transfer service. 152 o Private Net #x - This is a network of devices owned and operated 153 by the Internet Access Service Subscriber. In some 154 configurations, one or more private networks and the device that 155 provides the Access Service Demarcation point are collapsed in a 156 single device (and ownership may shift to the service provider), 157 and this should be noted as part of the path description. 158 o Access (Service) Demarcation point - this varies by technology but 159 is usually defined as the Ethernet interface on a residential 160 gateway or modem where the scope of access packet transfer service 161 begins and ends. In the case of a WiFi Service, this would be an 162 Air Interface within the intended service boundary (e.g., walls of 163 the coffee shop). The Demarcation point may be within an 164 integrated endpoint using an Air Interface (e.g., LTE UE). 165 Ownership may not affect the demarcation point; a Subscriber may 166 own all equipment on their premises, but it is likely that the 167 service provider will certify such equipment for connection to 168 their access network, or a third-party will certify standards 169 compliance. 170 o Intra IP Access - This is the first point in the access 171 architecture beyond the Access Service Demarc. where a globally 172 routable IP address is exposed and used for routing. In 173 architectures that use tunneling, this point may be equivalent to 174 the GRA GW. This point could also collapse to the device 175 providing the Access Service Demarc., in principle. Only one 176 Intra IP Access point is shown, but they can be identified in any 177 access or transit network. 178 o GRA GW - the point of interconnection between the access 179 administrative domain and the rest of the Internet, where routing 180 will depend on the GRAs in the IP header. 181 o Transit GRA GW - Networks that intervene between the Subscriber's 182 Access network and the Destination Host's network are designated 183 "transit" and involve two GRA GW. 184 Use of multiple IP address families in the measurement path must be 185 noted, as the conversions between IPv4 and IPv6 certainly influence 186 the visibility of a GRA for each family. 188 In the case that a private address space is used throughout an access 189 architecture, then the Access Service Demarc. and the Intra IP Access 190 points must use the same address space and be separated by the shared 191 and dedicated access link infrastructure, such that a test between 192 these points produces a useful assessment of access performance. 194 5. Measurement Points 196 A key aspect of measurement points, beyond the definition in section 197 4.1 of [RFC5835], is that the innermost IP header and higher layer 198 information must be accessible through some means. This is essential 199 to measure IP metrics. There may be tunnels and/or other layers 200 which encapsulate the innermost IP header, even adding another IP 201 header of their own. 203 In general, measurement points cannot always be located exactly where 204 desired. However, the definition in [RFC5835] and the discussion in 205 section 5.1 of [RFC3432] indicate that allowances can be made: for 206 example, deterministic errors that can be quantified are ideal. 208 The Figure below illustrates the assignment of measurement points to 209 selected components of the reference path. 211 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 212 device Net #1 Net #2 Demarc. Access GW GRA GW 213 mp000 mp100 mp150 mp190 mp200 215 ... Transit -- GRA -- Service -- Private -- Private -- Destination 216 GRA GW GW Demarc. Net #n Net #n+1 Host 217 mpX90 mp890 mp800 mp900 219 GRA = Globally Routable Address, GW = Gateway 221 The numbering for measurement points (mpNNN) allows for considerable 222 local use of unallocated numbers. 224 Notes: 226 o Some use the terminology "on-net" and "off-net" when referring to 227 Internet Service Provider (ISP) measurement coverage. With 228 respect to the reference path, tests between mp100 and mp190 are 229 "on-net". 230 o Widely deployed broadband access measurements have used pass- 231 through devices[SK] (at the subscriber's location) directly 232 connected to the service demarcation point: this would be located 233 at mp100. 234 o The networking technology used at all measurement points must be 235 indicated, especially the interface standard and configured speed. 236 o A Carrier Grade NAT (CGN) deployed in the Subscriber's access 237 network would be positioned between mp100 and mp190, and the 238 egress side of the CGN will typically be designated mp150. 239 o Measurement points at Transit GRA GWs are numbered mpX00 and 240 mpX90, where X is the lowest positive integer not already used in 241 the path. 243 6. Translation Between Ref. Path and Tech. X 245 This section and those that follow are intended to provide a more 246 exact mapping between particular network technologies and the 247 reference path. 249 We provide an example for 3G Cellular access below. 251 Subscriber -- Private -- Access Srvc ----------- GRA --- Transit ... 252 device Net #1 Demarc. GW GRA GW 253 mp000 mp100 mp190 mp200 255 |_____________UE______________|___RAN+Core____|___GGSN__| 257 GRA = Globally Routable Address, GW = Gateway, UE = User Equipment, 258 RAN = Radio Access Network, GGSN = Gateway GPRS Support Node. 260 We next provide a few examples of DSL access. Consider first the 261 case where: 262 o The Customer Premises Equipment (CPE) is a NAT device that is 263 configured with a public IP address. 264 o The CPE is a home router that has also an incorporated a WiFi 265 access point and this is the only networking device in the home 266 network, all endpoints attach directly to the CPE though the WiFi 267 access. 268 We believe this is a fairly common configuration in some parts of the 269 world and fairly simple as well. 271 This case would map into the defined reference measurement points as 272 follows: 274 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 275 device Net #1 Net #2 Demarc. Access GW GRA GW 276 mp000 mp100 mp150 mp190 mp200 277 |--UE--|------------CPE/NAT---------------------|----Access--| 278 Network 280 GRA = Globally Routable Address, GW = Gateway 282 Consider next the case where: 283 o The Customer Premises Equipment (CPE) is a NAT device that is 284 configured with a private IP address. 285 o There is a Carrier Grade NAT (CGN) located deep into the Access 286 ISP network. 287 o The CPE is a home router that has also an incorporated a WiFi 288 access point and this is the only networking device in the home 289 network, all endpoints attach directly to the CPE though the WiFi 290 access. 291 We believe is becoming a fairly common configuration in some parts of 292 the world. 294 This case would map into the defined reference measurement points as 295 follows: 297 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 298 device Net #1 Net #2 Demarc. Access GW GRA GW 299 mp000 mp100 mp150 mp190 mp200 300 |--UE--|------------CPE/NAT-------------|----CGN--| 302 GRA = Globally Routable Address, GW = Gateway 304 7. Security considerations 306 Specification of a Reference Path and identification of measurement 307 points on the path represent agreements among interested parties, and 308 they present no threat to the readers of this memo or to the Internet 309 itself. 311 8. IANA Considerations 313 TBD 315 9. Acknowledgements 317 TBD 319 10. References 321 10.1. Normative References 323 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 324 "Framework for IP Performance Metrics", RFC 2330, 325 May 1998. 327 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 328 performance measurement with periodic streams", RFC 3432, 329 November 2002. 331 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 332 Delay Metric for IPPM", RFC 2681, September 1999. 334 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 335 August 2012. 337 [RFC1035] Mockapetris, P., "Domain names - implementation and 338 specification", STD 13, RFC 1035, November 1987. 340 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 341 Time Protocol Version 4: Protocol and Algorithms 342 Specification", RFC 5905, June 2010. 344 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 345 Delay Metric for IPPM", RFC 2679, September 1999. 347 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 348 Packet Loss Metric for IPPM", RFC 2680, September 1999. 350 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 351 Metric for IP Performance Metrics (IPPM)", RFC 3393, 352 November 2002. 354 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 355 Applicability Statement", RFC 5481, March 2009. 357 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 358 Composition", RFC 5835, April 2010. 360 10.2. Informative References 362 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 363 Registry", BCP 108, RFC 4148, August 2005. 365 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 366 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 367 April 2011. 369 [SK] Crawford, Sam., "Test Methodology White Paper", SamKnows 370 Whitebox Briefing 371 Note http://www.samknows.com/broadband/index.php, 372 July 2011. 374 Authors' Addresses 376 Marcelo Bagnulo 377 Universidad Carlos III de Madrid 378 Av. Universidad 30 379 Leganes, Madrid 28911 380 SPAIN 382 Phone: 34 91 6249500 383 Email: marcelo@it.uc3m.es 384 URI: http://www.it.uc3m.es 385 Trevor Burbridge 386 British Telecom 387 Adastral Park, Martlesham Heath 388 IPswitch 389 ENGLAND 391 Email: trevor.burbridge@bt.com 393 Sam Crawford 394 SamKnows 396 Email: sam@samknows.com 398 Phil Eardley 399 British Telecom 400 Adastral Park, Martlesham Heath 401 IPswitch 402 ENGLAND 404 Email: philip.eardley@bt.com 406 Al Morton 407 AT&T Labs 408 200 Laurel Avenue South 409 Middletown, NJ 410 USA 412 Email: acmorton@att.com