idnits 2.17.1 draft-morton-ippm-lmap-path-01.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 (February 24, 2013) is 4079 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 349, but no explicit reference was found in the text == Unused Reference: 'RFC6673' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'RFC5905' is defined on line 358, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'RFC3393' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'RFC5481' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'RFC4148' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC6248' is defined on line 383, 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 28, 2013 BT 6 S. Crawford 7 SamKnows 8 P. Eardley 9 BT 10 A. Morton 11 AT&T Labs 12 February 24, 2013 14 A Reference Path and Measurement Points for LMAP 15 draft-morton-ippm-lmap-path-01 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 28, 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 . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . 10 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 If it can be shown that a link connecting to a measurement point 237 has reliably deterministic or negilgible performance, then the 238 remote end of the connecting link is an equivalent point for some 239 methods of measurement (To Be Specified Elsewhere). In any case, 240 the presence of such a link must be reported. 241 o Many access network architectures have a traffic aggregation point 242 (e.g., CMTS or DSLAM) between mp100 and mp150. We designate this 243 point mp120, but it won't currently fit in the figure. 244 o A Carrier Grade NAT (CGN) deployed in the Subscriber's access 245 network would be positioned between mp100 and mp190, and the 246 egress side of the CGN will typically be designated mp150. 247 o In the case that a private address space is used in an access 248 architecture, then mp100 may need to use the same address space as 249 its remote measurement point counterpart, so that a test between 250 these points produces a useful assessment of network performance. 251 Tests between mp000 and mp100 could use private address space, and 252 when the egress side of a CGN is at mp150, then the private 253 address side of the CGN could be designated mp149 for tests with 254 mp100. 256 o Measurement points at Transit GRA GWs are numbered mpX00 and 257 mpX90, where X is the lowest positive integer not already used in 258 the path. 260 6. Translation Between Ref. Path and Tech. X 262 This section and those that follow are intended to provide a more 263 exact mapping between particular network technologies and the 264 reference path. 266 We provide an example for 3G Cellular access below. 267 Subscriber -- Private -- Access Srvc ----------- GRA --- Transit ... 268 device Net #1 Demarc. GW GRA GW 269 mp000 mp100 mp190 mp200 271 |_____________UE______________|___RAN+Core____|___GGSN__| 273 GRA = Globally Routable Address, GW = Gateway, UE = User Equipment, 274 RAN = Radio Access Network, GGSN = Gateway GPRS Support Node. 276 We next provide a few examples of DSL access. Consider first the 277 case where: 278 o The Customer Premises Equipment (CPE) is a NAT device that is 279 configured with a public IP address. 280 o The CPE is a home router that has also an incorporated a WiFi 281 access point and this is the only networking device in the home 282 network, all endpoints attach directly to the CPE though the WiFi 283 access. 284 We believe this is a fairly common configuration in some parts of the 285 world and fairly simple as well. 287 This case would map into the defined reference measurement points as 288 follows: 290 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 291 device Net #1 Net #2 Demarc. Access GW GRA GW 292 mp000 mp100 mp150 mp190 mp200 293 |--UE--|------------CPE/NAT--------|-------|BRAS-|------| 294 |----Access Network--| 296 GRA = Globally Routable Address, GW = Gateway 298 Consider next the case where: 300 o The Customer Premises Equipment (CPE) is a NAT device that is 301 configured with a private IP address. 302 o There is a Carrier Grade NAT (CGN) located deep into the Access 303 ISP network. 304 o The CPE is a home router that has also an incorporated a WiFi 305 access point and this is the only networking device in the home 306 network, all endpoints attach directly to the CPE though the WiFi 307 access. 308 We believe is becoming a fairly common configuration in some parts of 309 the world. 311 This case would map into the defined reference measurement points as 312 follows: 314 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 315 device Net #1 Net #2 Demarc. Access GW GRA GW 316 mp000 mp100 mp150 mp190 mp200 317 |--UE--|------------CPE/NAT--------|------|-CGN-|------| 318 |---Access Network--| 320 GRA = Globally Routable Address, GW = Gateway 322 7. Security considerations 324 Specification of a Reference Path and identification of measurement 325 points on the path represent agreements among interested parties, and 326 they present no threat to the readers of this memo or to the Internet 327 itself. 329 8. IANA Considerations 331 TBD 333 9. Acknowledgements 335 Thanks to Matt Mathis for review and comments. 337 10. References 339 10.1. Normative References 341 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 342 "Framework for IP Performance Metrics", RFC 2330, 343 May 1998. 345 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 346 performance measurement with periodic streams", RFC 3432, 347 November 2002. 349 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 350 Delay Metric for IPPM", RFC 2681, September 1999. 352 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 353 August 2012. 355 [RFC1035] Mockapetris, P., "Domain names - implementation and 356 specification", STD 13, RFC 1035, November 1987. 358 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 359 Time Protocol Version 4: Protocol and Algorithms 360 Specification", RFC 5905, June 2010. 362 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 363 Delay Metric for IPPM", RFC 2679, September 1999. 365 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 366 Packet Loss Metric for IPPM", RFC 2680, September 1999. 368 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 369 Metric for IP Performance Metrics (IPPM)", RFC 3393, 370 November 2002. 372 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 373 Applicability Statement", RFC 5481, March 2009. 375 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 376 Composition", RFC 5835, April 2010. 378 10.2. Informative References 380 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 381 Registry", BCP 108, RFC 4148, August 2005. 383 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 384 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, 385 April 2011. 387 [SK] Crawford, Sam., "Test Methodology White Paper", SamKnows 388 Whitebox Briefing 389 Note http://www.samknows.com/broadband/index.php, 390 July 2011. 392 Authors' Addresses 394 Marcelo Bagnulo 395 Universidad Carlos III de Madrid 396 Av. Universidad 30 397 Leganes, Madrid 28911 398 SPAIN 400 Phone: 34 91 6249500 401 Email: marcelo@it.uc3m.es 402 URI: http://www.it.uc3m.es 404 Trevor Burbridge 405 British Telecom 406 Adastral Park, Martlesham Heath 407 IPswitch 408 ENGLAND 410 Email: trevor.burbridge@bt.com 412 Sam Crawford 413 SamKnows 415 Email: sam@samknows.com 417 Phil Eardley 418 British Telecom 419 Adastral Park, Martlesham Heath 420 IPswitch 421 ENGLAND 423 Email: philip.eardley@bt.com 425 Al Morton 426 AT&T Labs 427 200 Laurel Avenue South 428 Middletown, NJ 429 USA 431 Email: acmorton@att.com