idnits 2.17.00 (12 Aug 2021) /tmp/idnits50917/draft-ietf-ippm-lmap-path-05.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 (August 5, 2014) is 2845 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-lmap-framework has been published as RFC 7594 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: Informational T. Burbridge 5 Expires: February 6, 2015 BT 6 S. Crawford 7 SamKnows 8 P. Eardley 9 BT 10 A. Morton 11 AT&T Labs 12 August 5, 2014 14 A Reference Path and Measurement Points for LMAP 15 draft-ietf-ippm-lmap-path-05 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. Other similar measurement 22 projects may also be able to use the extensions described here for 23 measurement point location. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 6, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Reference Path . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.3. Dedicated Component (Links or Nodes) . . . . . . . . . . 4 66 3.4. Shared Component (Links or Nodes) . . . . . . . . . . . . 4 67 3.5. Resource Transition Point . . . . . . . . . . . . . . . . 5 68 3.6. Managed and Un-Managed Sub-paths . . . . . . . . . . . . 5 69 4. Reference Path . . . . . . . . . . . . . . . . . . . . . . . 5 70 5. Measurement Points . . . . . . . . . . . . . . . . . . . . . 6 71 6. Translation Between Reference Path and Various Technologies . 10 72 7. Example Resource Transition . . . . . . . . . . . . . . . . . 12 73 8. Security considerations . . . . . . . . . . . . . . . . . . . 13 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 11.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 This document defines a reference path for Large-scale Measurement of 84 Broadband Access Performance (LMAP) or similar measurement projects. 85 The series of IP Performance Metrics (IPPM) RFCs have developed terms 86 that are generally useful for path description (section 5 of 87 [RFC2330]). There are a limited number of additional terms needing 88 definition here, and they will be defined in this memo. 90 The reference path is usually needed when attempting to communicate 91 precisely about the components that comprise the path, often in terms 92 of their number (hops) and geographic location. This memo takes the 93 path definition further, by establishing a set of measurement points 94 along the path and ascribing a unique designation to each point. 95 This topic has been previously developed in section 5.1 of [RFC3432], 96 and as part of the updated framework for composition and aggregation, 97 section 4 of [RFC5835] (which may also figure in the LMAP work 98 effort). Section 4.1 of [RFC5835] defines the term "measurement 99 point". 101 Measurement points and the paths they cover are often described in 102 general terms, like "end-to-end", "user-to-user", or "access". These 103 terms alone are insufficient for scientific method: What is an end? 104 Where is a user located? Is the home network included? 106 The motivation for this memo is to provide an unambiguous framework 107 to describe measurement coverage, or scope of the reference path. 108 This is an essential part of the meta-data to describe measurement 109 results. Measurements conducted over different path scopes are not a 110 valid basis for performance comparisons. We note that additional 111 measurement context information may be necessary to support a valid 112 comparison of results. 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 2. Purpose and Scope 122 The scope of this memo is to define a reference path for LMAP 123 activities with sufficient level of detail to determine the location 124 of different measurement points along a path without ambiguity. 125 These conventions are likely to be useful in other measurement 126 projects as well. 128 The connection between the reference path and specific network 129 technologies (with differing underlying architectures) is within the 130 scope of this method, and examples are provided. Both wired and 131 wireless technologies are in-scope. 133 The purpose is to create an efficient way to describe the location of 134 the measurement point(s) used to conduct a particular measurement so 135 that the measurement result will adequately described in terms of 136 scope or coverage. This should serve many measurement uses, 137 including: 139 diagnostic: where the same metric would be measured on different 140 sub-paths bounded by measurement points (see Section 4.10 141 of[RFC5835]), for example to isolate the sub-path contributing the 142 majority of impairment levels observed on a path. 144 comparison: where the same metric may be measured on equivalent 145 portions of different network infrastructures, for example to 146 compare the performance of wired and wireless home network 147 technologies. 149 3. Terms and Definitions 151 This section defines key terms and concepts for the purposes of this 152 memo. 154 3.1. Reference Path 156 A reference path is a serial combination of routers, switches, links, 157 radios, and processing elements that comprise all the network 158 elements traversed by each packet between the source and destination 159 hosts. The reference path is intended to be equally applicable to 160 all networking technologies, therefore the components are generically 161 defined, but their functions should have a clear counterpart or be 162 obviously omitted in any network technology. 164 3.2. Subscriber 166 An entity (associated with one or more users) that is engaged in a 167 subscription with a service provider. The subscriber is allowed to 168 subscribe and un-subscribe to services, and to register a user or a 169 list of users authorized to enjoy these services. [Q1741] Both the 170 subscriber and service provider are allowed to set the limits 171 relative to the use that associated users make of subscribed 172 services. 174 3.3. Dedicated Component (Links or Nodes) 176 All resources of a Dedicated component (typically a link or node on 177 the Reference Path) are allocated to serving the traffic of an 178 individual Subscriber. Resources include transmission time-slots, 179 queue space, processing for encapsulation and address/port 180 translation, and others. A Dedicated component can affect the 181 performance of the Reference Path, or the performance of any sub-path 182 where the component is involved. 184 3.4. Shared Component (Links or Nodes) 186 A component on the Reference Path is designated a Shared component 187 when the traffic associated with multiple Subscribers is served by 188 common resources. 190 3.5. Resource Transition Point 192 A point between Dedicated and Shared components on a Reference Path 193 that may be a point of significance, and is identified as a 194 transition between two types of resources. 196 3.6. Managed and Un-Managed Sub-paths 198 Service providers are responsible for the portion of the path they 199 manage. However, most paths involve a sub-path which is beyond the 200 management of the subscriber's service provider. This means that 201 private networks, wireless networks using unlicensed frequencies, and 202 the networks of other service are designated as un-managed sub-paths. 203 The Service demarcation point always divides managed and un-managed 204 sub-paths. 206 4. Reference Path 208 This section defines a reference path for Internet communication. 210 Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit ... 211 device Net #1 Net #2 Demarc. Access GW GRA GW 213 ... Transit -- GRA -- Service -- Private -- Private -- Destination 214 GRA GW GW Demarc. Net #n Net #n+1 Host 216 GRA = Globally Routable Address, GW = Gateway 218 The following are descriptions of reference path components that may 219 not be clear from their name alone. 221 o Subsc. (Subscriber) device - This is a host that normally 222 originates and terminates communications conducted over the IP 223 packet transfer service. 225 o Private Net #x - This is a network of devices owned and operated 226 by the Internet Service Subscriber. In some configurations, one 227 or more private networks and the device that provides the Service 228 Demarcation point are collapsed in a single device (and ownership 229 may shift to the service provider), and this should be noted as 230 part of the path description. 232 o Service Demarcation point - This is the point where service 233 managed by the service provider begins (or ends), and varies by 234 technology. For example, this point is usually defined as the 235 Ethernet interface on a residential gateway or modem where the 236 scope of a packet transfer service begins and ends. In the case 237 of a WiFi Service, this would be an Air Interface within the 238 intended service boundary (e.g., walls of the coffee shop). The 239 Demarcation point may be within an integrated endpoint using an 240 Air Interface (e.g., LTE UE). Ownership does not necessarily 241 affect the demarcation point; a Subscriber may own all equipment 242 on their premises, but it is likely that the service provider will 243 certify such equipment for connection to their network, or a 244 third-party will certify standards compliance. 246 o Intra IP Access - This is the first point in the access 247 architecture beyond the Service Demarc. where a globally routable 248 IP address is exposed and used for routing. In architectures that 249 use tunneling, this point may be equivalent to the GRA GW. This 250 point could also collapse to the device providing the Service 251 Demarc., in principle. Only one Intra IP Access point is shown, 252 but they can be identified in any access network. 254 o GRA GW - the point of interconnection between a Service Provider's 255 administrative domain and the rest of the Internet, where routing 256 will depend on the GRAs in the IP header. 258 o Transit GRA GW - If one or more networks intervene between the 259 Service Provider's access networks of the Subscriber and of the 260 Destination Host, then such networks are designated "transit" and 261 are bounded by two Transit GRA GW. 263 Use of multiple IP address families in the measurement path must be 264 noted, as the conversions between IPv4 and IPv6 certainly influence 265 the visibility of a GRA for each family. 267 In the case that a private address space is used throughout an access 268 architecture, then the Intra IP Access points must use the same 269 address space as the Service Demarcation point, and the Intra IP 270 Access points must be selected such that a test between these points 271 produces a useful assessment of access performance (e.g., includes 272 both shared and dedicated access link infrastructure). 274 5. Measurement Points 276 A key aspect of measurement points, beyond the definition in section 277 4.1 of [RFC5835], is that the innermost IP header and higher layer 278 information must be accessible through some means. This is essential 279 to measure IP metrics. There may be tunnels and/or other layers 280 which encapsulate the innermost IP header, even adding another IP 281 header of their own. 283 In general, measurement points cannot always be located exactly where 284 desired. However, the definition in [RFC5835] and the discussion in 285 section 5.1 of [RFC3432] indicate that allowances can be made: for 286 example, it is nearly ideal when there are deterministic errors that 287 can be quantified between desired and actual measurement point. 289 The Figure below illustrates the assignment of measurement points to 290 selected components of the reference path. 292 Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit ... 293 device Net #1 Net #2 Demarc. Access GW GRA GW 294 mp000 mp100 mp150 mp190 mp200 296 ... Transit -- GRA -- Service -- Private -- Private -- Destination 297 GRA GW GW Demarc. Net #n Net #n+1 Host 298 mpX90 mp890 mp800 mp900 300 GRA = Globally Routable Address, GW = Gateway 302 Figure 1 304 Each measurement point on a specific reference path MUST be assigned 305 a unique number. To facilitate interpretation of the results, the 306 measuring organisation (and whoever it shares results with) MUST have 307 an unambiguous understanding of what path or point was measured. In 308 order to achieve this, a set of numbering recommendations follow. 310 When communicating the results of measurements, the measuring 311 organization SHOULD supply a diagram similar to Figure 1 (with the 312 technology-specific information in examples that follow), and MUST 313 supply it when additional measurement point numbers have been defined 314 and used, with sufficient detail to identify measurement locations in 315 the path. 317 Ideally, the consumer of measurement results would know the location 318 of a measurement point on the reference path from the measurement 319 point number alone, and the recommendations below provide a way to 320 accomplish this goal. Although the initial numbering may be fully 321 compliant with this system, network growth, consolidation, and re- 322 arrangement, or circumstances such as ownership changes, could cause 323 gaps in network numbers or non-monotonic measurement point number 324 assignments along the path over time. These are examples of 325 reasonable causes for numbering deviations which must be identified 326 on the reference path diagram, as required above. 328 Whilst the numbering of a measurement point is in the context of a 329 particular path, for simplicity the measuring organisation SHOULD use 330 the same numbering for a device (playing the same role) on all the 331 measurement paths through it. Similarly, whilst the measurement 332 point numbering is in the context of a particular measuring 333 organisation, organizations with similar technologies and 334 architectures are encouraged to coordinate on local numbering and 335 diagrams. 337 The measurement point numbering system, mpXnn, has two independent 338 parts: 340 1. The X in mpXnn indicates the network number. The network with 341 the Subscriber's device is network 0. The network of a different 342 organization (administrative or ownership domains) SHOULD be 343 assigned a different number. Each successive network number 344 SHOULD be one greater than the previous network's number. Two 345 circumstances make it necessary to designate X=9 in the 346 Destination Host's network and X=8 for the Service Provider 347 network at the Destination: 349 A. The number of Transit networks is unknown. 351 B. The number of Transit networks varies over time. 353 2. The nn in mpXnn indicates the measurement point and is locally- 354 assigned by network X. The following conventions are suggested: 356 A. 00 SHOULD be used for a measurement point at the Subscriber's 357 device and at the Service Demarcation point or GW nearest to 358 the Subscriber's device for Transit Networks. 360 B. 90 SHOULD be used for a measurement point at the GW of a 361 network (opposite from the Subscriber's device or Service 362 Demarc.). 364 C. In most networks, measurement point numbers SHOULD 365 monotonically increase from point nearest the Subscriber's 366 device to the opposite network boundary on the path (see 367 below). 369 D. When a Destination host is part of the path, 00 SHOULD be 370 used for a measurement point at the Destination host and at 371 the Destination's Service Demarcation point. Measurement 372 point numbers SHOULD monotonically increase from point 373 nearest the Destination's host to the opposite network 374 boundary on the path ONLY in these networks. This 375 directional numbering reversal allows consistent 00 376 designation for end hosts and Service Demarcs. 378 E. 50 MAY be used for an intermediate measurement point of 379 significance, such as a Network Address Translator (NAT). 381 F. 20 MAY be used for a traffic aggregation point such as a 382 DSLAM within a network. 384 G. Any other measurement points SHOULD be assigned unused 385 integers between 01 and 99. The assignment SHOULD be stable 386 for at least the duration of a particular measurement study, 387 and SHOULD avoid numbers that have been assigned to other 388 locations within network X (unless the assignment is 389 considered sufficiently stale). Sub-networks or domains 390 within a network are useful locations for measurement points. 392 When supplying a diagram of the reference path and measurement 393 points, the operator of the measurement system MUST indicate: the 394 reference path, the numbers (mpXnn) of the measurement points, and 395 the technology-specific definition of any measurement point other 396 than X00 and X90 with sufficient detail to clearly define its 397 location (similar to the technology-specific examples in Section 6 of 398 this document). 400 If the number of intermediate networks (between the source and 401 destination) is not known or is unstable, then this SHOULD be 402 indicated on the diagram and results from measurement points within 403 those networks need to be treated with caution. 405 Notes: 407 o Some use the terminology "on-net" and "off-net" when referring to 408 the Subscriber's Internet Service Provider (ISP) measurement 409 coverage. With respect to the reference path, tests between mp100 410 and mp190 are "on-net". 412 o Widely deployed broadband Internet access measurements have used 413 pass-through devices[SK] (at the subscriber's location) directly 414 connected to the service demarcation point: this would be located 415 at mp100. 417 o The networking technology must be indicated for the measurement 418 points used, especially the interface standard and configured 419 speed (because the measurement connectivity itself can be a 420 limiting factor for the results). 422 o If it can be shown that a link connecting to a measurement point 423 has reliably deterministic performance or negligible impairments, 424 then the remote end of the connecting link is an equivalent point 425 for some methods of measurement (To Be Specified Elsewhere). In 426 any case, the presence of a link and claimed equivalent 427 measurement point must be reported. 429 o Some access network architectures may have an additional traffic 430 aggregation device between mp100 and mp150. Use of a measurement 431 point at this location would require a local number and diagram. 433 o A Carrier Grade NAT (CGN) deployed in the Service Provider's 434 access network would be positioned between mp100 and mp190, and 435 the egress side of the CGN may be designated mp150. mp150 is 436 generally an intermediate measurement point in the same address 437 space as mp190. 439 o In the case that private address space is used in an access 440 architecture, then mp100 may need to use the same address space as 441 its "on-net" measurement point counterpart, so that a test between 442 these points produces a useful assessment of network performance. 443 Tests between mp000 and mp100 could use a different private 444 address space, and when the globally-routable side of a CGN is at 445 mp150, then the private address side of the CGN could be 446 designated mp149 for tests with mp100. 448 o Measurement points at Transit GRA GWs are numbered mpX00 and 449 mpX90, where X is the lowest positive integer not already used in 450 the path. The GW of first transit network is shown, with point 451 mp200 and the last transit network GW with mpX90. 453 6. Translation Between Reference Path and Various Technologies 455 This section and those that follow are intended to provide example 456 mappings between particular network technologies and the reference 457 path. 459 We provide an example for 3G Cellular access below. 461 Subscriber -- Private --- Service ------------- GRA --- Transit ... 462 device Net #1 Demarc. GW GRA GW 463 mp000 mp100 mp190 mp200 465 |_____________UE______________|___RAN+Core____|___GGSN__| 466 |_____Un-managed sub-path_____|____Managed sub-path_____| 468 GRA = Globally Routable Address, GW = Gateway, UE = User Equipment, 469 RAN = Radio Access Network, GGSN = Gateway GPRS Support Node. 471 We next provide an example of DSL access. Consider the case where: 473 o The Customer Premises Equipment (CPE) has a NAT device that is 474 configured with a public IP address. 476 o The CPE is a home router that has also an incorporated a WiFi 477 access point and this is the only networking device in the home 478 network, all endpoints attach directly to the CPE though the WiFi 479 access. 481 We believe this is a fairly common configuration in some parts of the 482 world and fairly simple as well. 484 This case would map into the defined reference measurement points as 485 follows: 487 Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit ... 488 device Net #1 Net #2 Demarc. Access GW GRA GW 489 mp000 mp100 mp150 mp190 mp200 490 |--UE--|------------CPE/NAT--------|------|-BRAS-|------| 491 |------DSL Network---| 492 |_______Un-managed sub-path________|__Managed sub-path__| 494 GRA = Globally Routable Address, GW = Gateway, BRAS = Broadband 495 Remote Access Server 497 Consider next another access network case where: 499 o The Customer Premises Equipment (CPE) is a NAT device that is 500 configured with a private IP address. 502 o There is a Carrier Grade NAT (CGN) located deep in the Access ISP 503 network. 505 o The CPE is a home router that has also an incorporated a WiFi 506 access point and this is the only networking device in the home 507 network, all endpoints attach directly to the CPE though the WiFi 508 access. 510 We believe this is becoming a fairly common configuration in some 511 parts of the world. 513 This case would map into the defined reference measurement points as 514 follows: 516 Subsc. -- Private ------------- Service-- Intra IP -- GRA -- Transit ... 517 device Net #1 Demarc. Access GW GRA GW 518 mp000 mp100 mp150 mp190 mp200 519 |--UE--|------------CPE/NAT--------|------|-CGN-|------| 520 |--Access Network---| 521 |_______Un-managed sub-path________|_Managed sub-path__| 523 GRA = Globally Routable Address, GW = Gateway 525 7. Example Resource Transition 527 This section gives an example of Shared and Dedicated portions with 528 the reference path. This example shows two Resource Transition 529 Points. 531 Consider the case where: 533 o The CPE is wired Residential GW and modem (Private Net#2) 534 connected to a WiFi access point (Private Net#1). The Subscriber 535 device (UE) attaches to the CPE though the WiFi access. 537 o The Wi-Fi subnetwork (Private Net#1) shares unlicensed radio 538 channel resources with other W-Fi access networks (and potentially 539 other sources of interference), thus this is a Shared portion of 540 the path. 542 o The wired subnetwork (Private Net#2) and a portion of the Service 543 Provider's Network are Dedicated Resources (for a single 544 Subscriber), thus there is a Resource Transition Point between 545 (Private Net#1) and (Private Net#2). 547 o Subscriber traffic shares common resources with other subscribers 548 upon reaching the Carrier Grade NAT (CGN), thus there is a 549 Resource Transition Point and further network components are 550 designated as Shared Resources. 552 We believe this is a fairly common configuration in parts of the 553 world. 555 This case would map into the defined reference measurement points as 556 follows: 558 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit ... 559 device Net #1 Net #2 Demarc. Access GW GRA GW 560 mp000 mp100 mp150 mp190 mp200 561 |--UE--|------------CPE/NAT--------|------|-CGN-|------| 562 | Wi-Fi | 1000Base-T |--Access Network---| 564 |-Shared--|RT|------Dedicated------| RT |-----Shared------... 565 |_______Un-managed sub-path________|_Managed sub-path__| 567 GRA = Globally Routable Address, GW = Gateway, RT = Resource 568 Transition Point 570 8. Security considerations 572 Specification of a Reference Path and identification of measurement 573 points on the path represent agreements among interested parties, and 574 they present no threat to the readers of this memo or to the Internet 575 itself. 577 When considering privacy of those involved in measurement or those 578 whose traffic is measured, there is sensitive information 579 communicated to recipients of the network diagrams illustrating paths 580 and measurement points described above. We refer the reader to the 581 privacy considerations described in the Large Scale Measurement of 582 Broadband Performance (LMAP) Framework [I-D.ietf-lmap-framework], 583 which covers active and passive measurement techniques and supporting 584 material on measurement context. 586 9. IANA Considerations 588 This memo makes no requests for IANA consideration. 590 10. Acknowledgements 592 Thanks to Matt Mathis, Charles Cook, Dan Romascanu, and Lingli Deng 593 for review and comments. 595 11. References 597 11.1. Normative References 599 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 600 "Framework for IP Performance Metrics", RFC 2330, May 601 1998. 603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, March 1997. 606 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 607 performance measurement with periodic streams", RFC 3432, 608 November 2002. 610 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 611 Composition", RFC 5835, April 2010. 613 11.2. Informative References 615 [I-D.ietf-lmap-framework] 616 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 617 Aitken, P., and A. Akhter, "A framework for large-scale 618 measurement platforms (LMAP)", draft-ietf-lmap- 619 framework-07 (work in progress), June 2014. 621 [SK] Crawford, Sam., "Test Methodology White Paper", SamKnows 622 Whitebox Briefing Note 623 http://www.samknows.com/broadband/index.php, July 2011. 625 [Q1741] Q.1741.7, , "IMT-2000 references to Release 9 of GSM- 626 evolved UMTS core network", 627 http://www.itu.int/rec/T-REC-Q.1741.7/en, November 2011. 629 Authors' Addresses 631 Marcelo Bagnulo 632 Universidad Carlos III de Madrid 633 Av. Universidad 30 634 Leganes, Madrid 28911 635 SPAIN 637 Phone: 34 91 6249500 638 Email: marcelo@it.uc3m.es 639 URI: http://www.it.uc3m.es 641 Trevor Burbridge 642 BT 643 Adastral Park, Martlesham Heath 644 Ipswich 645 ENGLAND 647 Email: trevor.burbridge@bt.com 648 Sam Crawford 649 SamKnows 651 Email: sam@samknows.com 653 Phil Eardley 654 BT 655 Adastral Park, Martlesham Heath 656 Ipswich 657 ENGLAND 659 Email: philip.eardley@bt.com 661 Al Morton 662 AT&T Labs 663 200 Laurel Avenue South 664 Middletown, NJ 665 USA 667 Email: acmorton@att.com