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