idnits 2.17.00 (12 Aug 2021) /tmp/idnits24863/draft-ietf-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 (September 24, 2013) is 3160 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 451, but no explicit reference was found in the text == Unused Reference: 'RFC6673' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 457, but no explicit reference was found in the text == Unused Reference: 'RFC5905' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'RFC3393' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'RFC5481' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC4148' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC6248' is defined on line 485, 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: March 28, 2014 BT 6 S. Crawford 7 SamKnows 8 P. Eardley 9 BT 10 A. Morton 11 AT&T Labs 12 September 24, 2013 14 A Reference Path and Measurement Points for LMAP 15 draft-ietf-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 March 28, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Reference Path . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.3. Dedicated Component (Links or Nodes) . . . . . . . . . . 4 63 3.4. Shared Component (Links or Nodes) . . . . . . . . . . . . 4 64 3.5. Resource Transition Point . . . . . . . . . . . . . . . . 4 65 4. Reference Path . . . . . . . . . . . . . . . . . . . . . . . 4 66 5. Measurement Points . . . . . . . . . . . . . . . . . . . . . 6 67 6. Translation Between Ref. Path and Tech. X . . . . . . . . . . 7 68 7. Example Resource Transition . . . . . . . . . . . . . . . . . 9 69 8. Security considerations . . . . . . . . . . . . . . . . . . . 10 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 11.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 This document defines a reference path for Large-scale Measurement of 80 Broadband Access Performance (LMAP). The series of IP Performance 81 Metrics (IPPM) RFCs have developed terms that are generally useful 82 for path description (section 5 of [RFC2330]). There are a limited 83 number of additional terms needing definition here, and they will be 84 defined in this memo. 86 The reference path is usually needed when attempting to communicate 87 precisely about the components that comprise the path, often in terms 88 of their number (hops) and geographic location. This memo takes the 89 path definition further, by establishing a set of measurement points 90 along the path and ascribing a unique designation to each point. 91 This topic has been previously developed in section 5.1 of [RFC3432], 92 and as part of the updated framework for composition and aggregation, 93 section 4 of [RFC5835] (which may also figure in the LMAP work 94 effort). Section 4.1 of [RFC5835] defines the term "measurement 95 point". 97 Measurement points and the paths they cover are often described in 98 general terms, like "end-to-end", "user-to-user", or "access". These 99 terms are insufficient for scientific method: What is an end? Where 100 is a user located? Is the home network included? 102 The motivation for this memo is to provide an unambiguous framework 103 to describe measurement coverage, or scope of the reference path. 104 This is an essential part of the metadata to describe measurement 105 results. Measurements conducted over different path scopes are not a 106 valid basis for performance comparisons. 108 2. Purpose and Scope 110 The scope of this memo is to define a reference path for LMAP 111 activities with sufficient level of detail to determine the location 112 of different measurement points without ambiguity. 114 The bridge between the reference path and specific network 115 technologies (with differing underlying architectures) is within the 116 scope of this effort. Both wired and wireless technologies are in- 117 scope. 119 The purpose is to create an efficient way to describe the location of 120 the measurement point(s) used to conduct a particular measurement so 121 that the measurement result will adequately described in this regard. 122 This should serve many measurement uses, including diagnostic (where 123 the same metric may be measured over many different path scopes) and 124 comparative (where the same metric may be measured on different 125 network infrastructures). 127 3. Terms and Definitions 129 This section defines key terms and concepts for the purposes of this 130 memo. 132 3.1. Reference Path 134 A reference path is a serial combination of routers, switches, links, 135 radios, and processing elements that comprise all the network 136 elements traversed by each packet between the source and destination 137 hosts. The reference path is intended to be equally applicable to 138 all networking technologies, therefore the components are generically 139 defined, but their functions should have a clear counterpart or be 140 obviously omitted in any network technology. 142 3.2. Subscriber 143 An entity (associated with one or more users) that is engaged in a 144 subscription with a service provider. The subscriber is allowed to 145 subscribe and un-subscribe services, and to register a user or a list 146 of users authorized to enjoy these services. [Q1741] Both the 147 subscriber and service provider are allowed to set the limits 148 relative to the use that associated users make of subscribed 149 services. 151 3.3. Dedicated Component (Links or Nodes) 153 All resources of a Dedicated component (typically a link or node on 154 the Reference Path) are allocated to serving the traffic of an 155 individual Subscriber. Resources include transmission time-slots, 156 queue space, processing for encapsulation and address/port 157 translation, and others. A Dedicated component can affect the 158 performance of the Reference Path, or the performance of any sub-path 159 where the component is involved. 161 3.4. Shared Component (Links or Nodes) 163 A component on the Reference Path is designated a Shared component 164 when the traffic associated with multiple Subscribers is served by 165 common resources. 167 3.5. Resource Transition Point 169 A point between Dedicated and Shared components on a Reference Path 170 that may be a point of significance, and is identified as a 171 transition between two types of resources. 173 4. Reference Path 175 This section defines a reference path for Internet Access. 177 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 178 device Net #1 Net #2 Demarc. Access GW GRA GW 180 ... Transit -- GRA -- Service -- Private -- Private -- Destination 181 GRA GW GW Demarc. Net #n Net #n+1 Host 183 GRA = Globally Routable Address, GW = Gateway 185 The following are descriptions of reference path components that may 186 not be clear from their name alone. 188 o Subsc. (Subscriber) device - This is a host that normally 189 originates and terminates communications conducted over the IP 190 packet transfer service. 192 o Private Net #x - This is a network of devices owned and operated 193 by the Internet Access Service Subscriber. In some 194 configurations, one or more private networks and the device that 195 provides the Access Service Demarcation point are collapsed in a 196 single device (and ownership may shift to the service provider), 197 and this should be noted as part of the path description. 199 o Access (Service) Demarcation point - this varies by technology but 200 is usually defined as the Ethernet interface on a residential 201 gateway or modem where the scope of access packet transfer service 202 begins and ends. In the case of a WiFi Service, this would be an 203 Air Interface within the intended service boundary (e.g., walls of 204 the coffee shop). The Demarcation point may be within an 205 integrated endpoint using an Air Interface (e.g., LTE UE). 206 Ownership may not affect the demarcation point; a Subscriber may 207 own all equipment on their premises, but it is likely that the 208 service provider will certify such equipment for connection to 209 their access network, or a third-party will certify standards 210 compliance. 212 o Intra IP Access - This is the first point in the access 213 architecture beyond the Access Service Demarc. where a globally 214 routable IP address is exposed and used for routing. In 215 architectures that use tunneling, this point may be equivalent to 216 the GRA GW. This point could also collapse to the device 217 providing the Access Service Demarc., in principle. Only one 218 Intra IP Access point is shown, but they can be identified in any 219 access or transit network. 221 o GRA GW - the point of interconnection between the access 222 administrative domain and the rest of the Internet, where routing 223 will depend on the GRAs in the IP header. 225 o Transit GRA GW - Networks that intervene between the Subscriber's 226 Access network and the Destination Host's network are designated 227 "transit" and involve two GRA GW. 229 Use of multiple IP address families in the measurement path must be 230 noted, as the conversions between IPv4 and IPv6 certainly influence 231 the visibility of a GRA for each family. 233 In the case that a private address space is used throughout an access 234 architecture, then the Access Service Demarc. and the Intra IP Access 235 points must use the same address space and be separated by the shared 236 and dedicated access link infrastructure, such that a test between 237 these points produces a useful assessment of access performance. 239 5. Measurement Points 241 A key aspect of measurement points, beyond the definition in section 242 4.1 of [RFC5835], is that the innermost IP header and higher layer 243 information must be accessible through some means. This is essential 244 to measure IP metrics. There may be tunnels and/or other layers 245 which encapsulate the innermost IP header, even adding another IP 246 header of their own. 248 In general, measurement points cannot always be located exactly where 249 desired. However, the definition in [RFC5835] and the discussion in 250 section 5.1 of [RFC3432] indicate that allowances can be made: for 251 example, deterministic errors that can be quantified are ideal. 253 The Figure below illustrates the assignment of measurement points to 254 selected components of the reference path. 256 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 257 device Net #1 Net #2 Demarc. Access GW GRA GW 258 mp000 mp100 mp150 mp190 mp200 260 ... Transit -- GRA -- Service -- Private -- Private -- Destination 261 GRA GW GW Demarc. Net #n Net #n+1 Host 262 mpX90 mp890 mp800 mp900 264 GRA = Globally Routable Address, GW = Gateway 266 The numbering for measurement points (mpNNN) allows for considerable 267 local use of unallocated numbers. 269 Notes: 271 o Some use the terminology "on-net" and "off-net" when referring to 272 Internet Service Provider (ISP) measurement coverage. With 273 respect to the reference path, tests between mp100 and mp190 are 274 "on-net". 276 o Widely deployed broadband access measurements have used pass- 277 through devices[SK] (at the subscriber's location) directly 278 connected to the service demarcation point: this would be located 279 at mp100. 281 o The networking technology used at all measurement points must be 282 indicated, especially the interface standard and configured speed. 284 o If it can be shown that a link connecting to a measurement point 285 has reliably deterministic or negilgible performance, then the 286 remote end of the connecting link is an equivalent point for some 287 methods of measurement (To Be Specified Elsewhere). In any case, 288 the presence of such a link must be reported. 290 o Many access network architectures have a traffic aggregation point 291 (e.g., CMTS or DSLAM) between mp100 and mp150. We designate this 292 point mp120, but it won't currently fit in the figure. 294 o A Carrier Grade NAT (CGN) deployed in the Subscriber's access 295 network would be positioned between mp100 and mp190, and the 296 egress side of the CGN will typically be designated mp150. 298 o In the case that a private address space is used in an access 299 architecture, then mp100 may need to use the same address space as 300 its remote measurement point counterpart, so that a test between 301 these points produces a useful assessment of network performance. 302 Tests between mp000 and mp100 could use private address space, and 303 when the egress side of a CGN is at mp150, then the private 304 address side of the CGN could be designated mp149 for tests with 305 mp100. 307 o Measurement points at Transit GRA GWs are numbered mpX00 and 308 mpX90, where X is the lowest positive integer not already used in 309 the path. 311 6. Translation Between Ref. Path and Tech. X 313 This section and those that follow are intended to provide a more 314 exact mapping between particular network technologies and the 315 reference path. 317 We provide an example for 3G Cellular access below. 319 Subscriber -- Private -- Access Srvc ----------- GRA --- Transit ... 320 device Net #1 Demarc. GW GRA GW 321 mp000 mp100 mp190 mp200 323 |_____________UE______________|___RAN+Core____|___GGSN__| 325 GRA = Globally Routable Address, GW = Gateway, UE = User Equipment, 326 RAN = Radio Access Network, GGSN = Gateway GPRS Support Node. 328 We next provide a few examples of DSL access. Consider first the 329 case where: 331 o The Customer Premises Equipment (CPE) is a NAT device that is 332 configured with a public IP address. 334 o The CPE is a home router that has also an incorporated a WiFi 335 access point and this is the only networking device in the home 336 network, all endpoints attach directly to the CPE though the WiFi 337 access. 339 We believe this is a fairly common configuration in some parts of the 340 world and fairly simple as well. 342 This case would map into the defined reference measurement points as 343 follows: 345 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 346 device Net #1 Net #2 Demarc. Access GW GRA GW 347 mp000 mp100 mp150 mp190 mp200 348 |--UE--|------------CPE/NAT--------|-------|BRAS-|------| 349 |----Access Network--| 351 GRA = Globally Routable Address, GW = Gateway 353 Consider next the case where: 355 o The Customer Premises Equipment (CPE) is a NAT device that is 356 configured with a private IP address. 358 o There is a Carrier Grade NAT (CGN) located deep into the Access 359 ISP network. 361 o The CPE is a home router that has also an incorporated a WiFi 362 access point and this is the only networking device in the home 363 network, all endpoints attach directly to the CPE though the WiFi 364 access. 366 We believe is becoming a fairly common configuration in some parts of 367 the world. 369 This case would map into the defined reference measurement points as 370 follows: 372 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 373 device Net #1 Net #2 Demarc. Access GW GRA GW 374 mp000 mp100 mp150 mp190 mp200 375 |--UE--|------------CPE/NAT--------|------|-CGN-|------| 376 |---Access Network--| 378 GRA = Globally Routable Address, GW = Gateway 380 7. Example Resource Transition 382 This section gives an example of Shared and Dedicated portions with 383 the reference path. This example shows two Resource Transition 384 Points. 386 Consider the case where: 388 o The CPE is wired Residential GW and modem (Private Net#2) 389 connected to a WiFi access point (Private Net#1). The Subscriber 390 device (UE) attachs to the CPE though the WiFi access. 392 o The Wi-Fi subnetwork (Private Net#1) shares unliscened radio 393 channel resources with other W-Fi access networks (and potentially 394 other sources of interference), thus this is a Shared portion of 395 the path. 397 o The wired subnetwork (Private Net#2) and a portion of the Access 398 Network are Dedicated Resources (for a single Subscriber), thus 399 there is a Resource Transition Point between (Private Net#1) and 400 (Private Net#2). 402 o Subscriber traffic shares common resources with other subscribers 403 upon reaching the Carrier Grade NAT (CGN), thus there is a 404 Resource Transition Point and further network components are 405 designated as Shared Resources. 407 We believe is becoming a fairly common configuration in parts of the 408 world. 410 This case would map into the defined reference measurement points as 411 follows: 413 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit 414 device Net #1 Net #2 Demarc. Access GW GRA GW 415 mp000 mp100 mp150 mp190 mp200 416 |--UE--|------------CPE/NAT--------|------|-CGN-|------| 417 Wi-Fi wired |---Access Network--| 419 |-Shared--|RT|------Dedicated------| RT |-----Shared------... 421 GRA = Globally Routable Address, GW = Gateway, RT = Resource 422 Transition Point 424 8. Security considerations 426 Specification of a Reference Path and identification of measurement 427 points on the path represent agreements among interested parties, and 428 they present no threat to the readers of this memo or to the Internet 429 itself. 431 9. IANA Considerations 433 TBD 435 10. Acknowledgements 437 Thanks to Matt Mathis for review and comments. 439 11. References 441 11.1. Normative References 443 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 444 "Framework for IP Performance Metrics", RFC 2330, May 445 1998. 447 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 448 performance measurement with periodic streams", RFC 3432, 449 November 2002. 451 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 452 Delay Metric for IPPM", RFC 2681, September 1999. 454 [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, 455 August 2012. 457 [RFC1035] Mockapetris, P., "Domain names - implementation and 458 specification", STD 13, RFC 1035, November 1987. 460 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 461 Time Protocol Version 4: Protocol and Algorithms 462 Specification", RFC 5905, June 2010. 464 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 465 Delay Metric for IPPM", RFC 2679, September 1999. 467 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 468 Packet Loss Metric for IPPM", RFC 2680, September 1999. 470 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 471 Metric for IP Performance Metrics (IPPM)", RFC 3393, 472 November 2002. 474 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 475 Applicability Statement", RFC 5481, March 2009. 477 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 478 Composition", RFC 5835, April 2010. 480 11.2. Informative References 482 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 483 Registry", BCP 108, RFC 4148, August 2005. 485 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 486 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April 487 2011. 489 [SK] Crawford, Sam., "Test Methodology White Paper", SamKnows 490 Whitebox Briefing Note 491 http://www.samknows.com/broadband/index.php, July 2011. 493 [Q1741] Q.1741.7, ., "IMT-2000 references to Release 9 of GSM- 494 evolved UMTS core network", 495 http://www.itu.int/rec/T-REC-Q.1741.7/en, November 2011. 497 Authors' Addresses 498 Marcelo Bagnulo 499 Universidad Carlos III de Madrid 500 Av. Universidad 30 501 Leganes, Madrid 28911 502 SPAIN 504 Phone: 34 91 6249500 505 Email: marcelo@it.uc3m.es 506 URI: http://www.it.uc3m.es 508 Trevor Burbridge 509 British Telecom 510 Adastral Park, Martlesham Heath 511 IPswitch 512 ENGLAND 514 Email: trevor.burbridge@bt.com 516 Sam Crawford 517 SamKnows 519 Email: sam@samknows.com 521 Phil Eardley 522 British Telecom 523 Adastral Park, Martlesham Heath 524 IPswitch 525 ENGLAND 527 Email: philip.eardley@bt.com 529 Al Morton 530 AT&T Labs 531 200 Laurel Avenue South 532 Middletown, NJ 533 USA 535 Email: acmorton@att.com