idnits 2.17.1 draft-ietf-ippm-lmap-path-06.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 17, 2014) is 3480 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-lmap-framework-08 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: March 21, 2015 BT 6 S. Crawford 7 SamKnows 8 P. Eardley 9 BT 10 A. Morton 11 AT&T Labs 12 September 17, 2014 14 A Reference Path and Measurement Points for Large-Scale Measurement of 15 Broadband Performance 16 draft-ietf-ippm-lmap-path-06 18 Abstract 20 This document defines a reference path for Large-scale Measurement of 21 Broadband Access Performance (LMAP) and measurement points for 22 commonly used performance metrics. Other similar measurement 23 projects may also be able to use the extensions described here for 24 measurement point location. The purpose is to create an efficient 25 way to describe the location of the measurement point(s) used to 26 conduct a particular measurement. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 21, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Reference Path . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.3. Dedicated Component (Links or Nodes) . . . . . . . . . . 5 69 3.4. Shared Component (Links or Nodes) . . . . . . . . . . . . 5 70 3.5. Resource Transition Point . . . . . . . . . . . . . . . . 5 71 3.6. Service Demarcation Point . . . . . . . . . . . . . . . . 5 72 3.7. Managed and Un-Managed Sub-paths . . . . . . . . . . . . 5 73 4. Reference Path . . . . . . . . . . . . . . . . . . . . . . . 6 74 5. Measurement Points . . . . . . . . . . . . . . . . . . . . . 7 75 6. Translation Between Reference Path and Various Technologies . 11 76 7. Example Resource Transition . . . . . . . . . . . . . . . . . 12 77 8. Security considerations . . . . . . . . . . . . . . . . . . . 13 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 82 11.2. Informative References . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 This document defines a reference path for Large-scale Measurement of 88 Broadband Access Performance (LMAP) or similar measurement projects. 89 The series of IP Performance Metrics (IPPM) RFCs have developed terms 90 that are generally useful for path description (section 5 of 91 [RFC2330]). There are a limited number of additional terms needing 92 definition here, and they will be defined in this memo. 94 The reference path (See section 3.1 and Figure 1 of [Y.1541], 95 including the accompanying discussion) is usually needed when 96 attempting to communicate precisely about the components that 97 comprise the path, often in terms of their number (hops) and 98 geographic location. This memo takes the path definition further, by 99 establishing a set of measurement points along the path and ascribing 100 a unique designation to each point. This topic has been previously 101 developed in section 5.1 of [RFC3432], and as part of the updated 102 framework for composition and aggregation, section 4 of [RFC5835]. 103 Section 4.1 of [RFC5835] defines the term "measurement point". 105 Measurement points and the paths they inhabit are often described in 106 general terms, like "end-to-end", "user-to-user", or "access". These 107 terms alone are insufficient for scientific method: What is an end? 108 Where is a user located? Is the home network included? 110 As an illustrative example, consider a measurement agent in an LMAP 111 system. When it reports its measurement results, rather than 112 detailing its IP address and that of its measurement peer, it may 113 prefer to describe the measured path segment abstractly (perhaps for 114 privacy reasons). For instance "from a measurement agent at a home 115 gateway to a measurement peer at a DSLAM". This memo provides the 116 definition for such abstract 'measurement points' and therefore the 117 portion of 'reference path' between them. 119 The motivation for this memo is to provide an unambiguous framework 120 to describe measurement coverage, or scope of the reference path. 121 This is an essential part of the meta-data to describe measurement 122 results. Measurements conducted over different path scopes are not a 123 valid basis for performance comparisons. We note that additional 124 measurement context information may be necessary to support a valid 125 comparison of results. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 2. Purpose and Scope 135 The scope of this memo is to define a reference path for LMAP 136 activities with sufficient level of detail to determine the location 137 of different measurement points along a path without ambiguity. 138 These conventions are likely to be useful in other measurement 139 projects as well, and in describing the applicable measurement scope 140 for some metrics. 142 The connection between the reference path and specific network 143 technologies (with differing underlying architectures) is within the 144 scope of this method, and examples are provided. Both wired and 145 wireless technologies are in-scope. 147 The purpose is to create an efficient way to describe the location of 148 the measurement point(s) used to conduct a particular measurement so 149 that the measurement result will adequately described in terms of 150 scope or coverage. This should serve many measurement uses, 151 including: 153 diagnostic: where the same metric would be measured on different 154 sub-paths bounded by measurement points (see Section 4.10 155 of[RFC5835]), for example to isolate the sub-path contributing the 156 majority of impairment levels observed on a path. 158 comparison: where the same metric may be measured on equivalent 159 portions of different network infrastructures, for example to 160 compare the performance of wired and wireless home network 161 technologies. 163 3. Terms and Definitions 165 This section defines key terms and concepts for the purposes of this 166 memo. 168 3.1. Reference Path 170 A reference path is a serial combination of hosts, routers, switches, 171 links, radios, and processing elements that comprise all the network 172 elements traversed by each packet in a flow between the source and 173 destination hosts. A reference path also indicates the various 174 boundaries present, such as administrative boundaries. A reference 175 path is intended to be equally applicable to all IP and link-layer 176 networking technologies. Therefore, the components are generically 177 defined but their functions should have a clear counterpart or be 178 obviously omitted in any network architecture. 180 3.2. Subscriber 182 An entity (associated with one or more users) that is engaged in a 183 subscription with a service provider. The subscriber is allowed to 184 subscribe and un-subscribe to services, and to register a user or a 185 list of users authorized to enjoy these services. [Q1741] Both the 186 subscriber and service provider are allowed to set the limits 187 relative to the use that associated users make of subscribed 188 services. 190 3.3. Dedicated Component (Links or Nodes) 192 All resources of a Dedicated Component (typically a link or node on 193 the Reference Path) are allocated to serving the traffic of an 194 individual Subscriber. Resources include transmission time-slots, 195 queue space, processing for encapsulation and address/port 196 translation, and others. A Dedicated Component can affect the 197 performance of the Reference Path, or the performance of any sub-path 198 where the component is involved. 200 3.4. Shared Component (Links or Nodes) 202 A component on the Reference Path is designated a Shared Component 203 when the traffic associated with multiple Subscribers is served by 204 common resources. 206 3.5. Resource Transition Point 208 A point between Dedicated and Shared Components on a Reference Path 209 that may be a point of significance, and is identified as a 210 transition between two types of resources. 212 3.6. Service Demarcation Point 214 This is the point where service managed by the service provider 215 begins (or ends), and varies by technology. For example, this point 216 is usually defined as the Ethernet interface on a residential gateway 217 or modem where the scope of a packet transfer service begins and 218 ends. In the case of a WiFi Service, this would be an Air Interface 219 within the intended service boundary (e.g., walls of the coffee 220 shop). The Demarcation Point may be within an integrated endpoint 221 using an Air Interface (e.g., Long-Term Evolution User Equipment, LTE 222 UE). Ownership does not necessarily affect the demarcation point; a 223 Subscriber may own all equipment on their premises, but it is likely 224 that the service provider will certify such equipment for connection 225 to their network, or a third-party will certify standards compliance. 227 3.7. Managed and Un-Managed Sub-paths 229 Service providers are responsible for the portion of the path they 230 manage. However, most paths involve a sub-path which is beyond the 231 management of the subscriber's service provider. This means that 232 private networks, wireless networks using unlicensed frequencies, and 233 the networks of other service are designated as Un-managed sub-paths. 234 The Service Demarcation Point always divides Managed and Un-managed 235 sub-paths. 237 4. Reference Path 239 This section defines a reference path for Internet communication. 241 Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit ... 242 device Net #1 Net #2 Demarc. Access GW GRA GW 244 ... Transit -- GRA -- Service -- Private -- Private -- Destination 245 GRA GW GW Demarc. Net #n Net #n+1 Host 247 GRA = Globally Routable Address, GW = Gateway 249 The following are descriptions of reference path components that may 250 not be clear from their name alone. 252 o Subsc. (Subscriber) device - This is a host that normally 253 originates and terminates communications conducted over the IP 254 packet transfer service. 256 o Private Net #x - This is a network of devices owned and operated 257 by the Internet Service Subscriber. In some configurations, one 258 or more private networks and the device that provides the Service 259 Demarcation point are collapsed in a single device (and ownership 260 may shift to the service provider), and this should be noted as 261 part of the path description. 263 o Intra IP Access - This is the first point in the access 264 architecture beyond the Service Demarc. where a globally routable 265 IP address is exposed and used for routing. In architectures that 266 use tunneling, this point may be equivalent to the Globally 267 Routable Address Gateway (GRA GW). This point could also collapse 268 to the device providing the Service Demarc., in principle. Only 269 one Intra IP Access point is shown, but they can be identified in 270 any access network. 272 o GRA GW - the point of interconnection between a Service Provider's 273 administrative domain and the rest of the Internet, where routing 274 will depend on the GRAs in the IP header. 276 o Transit GRA GW - If one or more networks intervene between the 277 Service Provider's access networks of the Subscriber and of the 278 Destination Host, then such networks are designated "transit" and 279 are bounded by two Transit GRA GW. 281 Use of multiple IP address families in the measurement path must be 282 noted, as the conversions between IPv4 and IPv6 certainly influence 283 the visibility of a GRA for each family. 285 In the case that a private address space is used throughout an access 286 architecture, then the Intra IP Access points must use the same 287 address space as the Service Demarcation point, and the Intra IP 288 Access points must be selected such that a test between these points 289 produces a useful assessment of access performance (e.g., includes 290 both shared and dedicated access link infrastructure). 292 5. Measurement Points 294 A key aspect of measurement points, beyond the definition in section 295 4.1 of [RFC5835], is that the innermost IP header and higher layer 296 information must be accessible through some means. This is essential 297 to measure IP metrics. There may be tunnels and/or other layers 298 which encapsulate the innermost IP header, even adding another IP 299 header of their own. 301 In general, measurement points cannot always be located exactly where 302 desired. However, the definition in [RFC5835] and the discussion in 303 section 5.1 of [RFC3432] indicate that allowances can be made: for 304 example, it is nearly ideal when there are deterministic errors that 305 can be quantified between desired and actual measurement point. 307 The Figure below illustrates the assignment of measurement points to 308 selected components of the reference path. 310 Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit ... 311 device Net #1 Net #2 Demarc. Access GW GRA GW 312 mp000 mp100 mp150 mp190 mp200 314 ... Transit -- GRA -- Service -- Private -- Private -- Destination 315 GRA GW GW Demarc. Net #n Net #n+1 Host 316 mpX90 mp890 mp800 mp900 318 GRA = Globally Routable Address, GW = Gateway 320 Figure 1 322 Each measurement point on a specific reference path MUST be assigned 323 a unique number. To facilitate interpretation of the results, the 324 measuring organisation (and whoever it shares results with) MUST have 325 an unambiguous understanding of what path or point was measured. In 326 order to achieve this, a set of numbering recommendations follow. 328 When communicating the results of measurements, the measuring 329 organization SHOULD supply a diagram similar to Figure 1 (with the 330 technology-specific information in examples that follow), and MUST 331 supply it when additional measurement point numbers have been defined 332 and used, with sufficient detail to identify measurement locations in 333 the path. 335 Ideally, the consumer of measurement results would know the location 336 of a measurement point on the reference path from the measurement 337 point number alone, and the recommendations below provide a way to 338 accomplish this goal. Although the initial numbering may be fully 339 compliant with this system, network growth, consolidation, and re- 340 arrangement, or circumstances such as ownership changes, could cause 341 gaps in network numbers or non-monotonic measurement point number 342 assignments along the path over time. These are examples of 343 reasonable causes for numbering deviations which must be identified 344 on the reference path diagram, as required above. 346 Whilst the numbering of a measurement point is in the context of a 347 particular path, for simplicity the measuring organisation SHOULD use 348 the same numbering for a device (playing the same role) on all the 349 measurement paths through it. Similarly, whilst the measurement 350 point numbering is in the context of a particular measuring 351 organisation, organizations with similar technologies and 352 architectures are encouraged to coordinate on local numbering and 353 diagrams. 355 The measurement point numbering system, mpXnn, has two independent 356 parts: 358 1. The X in mpXnn indicates the network number. The network with 359 the Subscriber's device is network 0. The network of a different 360 organization (administrative or ownership domains) SHOULD be 361 assigned a different number. Each successive network number 362 SHOULD be one greater than the previous network's number. Two 363 circumstances make it necessary to designate X=9 in the 364 Destination Host's network and X=8 for the Service Provider 365 network at the Destination: 367 A. The number of Transit networks is unknown. 369 B. The number of Transit networks varies over time. 371 2. The nn in mpXnn indicates the measurement point and is locally- 372 assigned by network X. The following conventions are suggested: 374 A. 00 SHOULD be used for a measurement point at the Subscriber's 375 device and at the Service Demarcation point or GW nearest to 376 the Subscriber's device for Transit Networks. 378 B. 90 SHOULD be used for a measurement point at the GW of a 379 network (opposite from the Subscriber's device or Service 380 Demarc.). 382 C. In most networks, measurement point numbers SHOULD 383 monotonically increase from the point nearest the 384 Subscriber's device to the opposite network boundary on the 385 path (see below). 387 D. When a Destination host is part of the path, 00 SHOULD be 388 used for a measurement point at the Destination host and at 389 the Destination's Service Demarcation point. Measurement 390 point numbers SHOULD monotonically increase from the point 391 nearest the Destination's host to the opposite network 392 boundary on the path ONLY in these networks. This 393 directional numbering reversal allows consistent 00 394 designation for end hosts and Service Demarcs. 396 E. 50 MAY be used for an intermediate measurement point of 397 significance, such as a Network Address Translator (NAT). 399 F. 20 MAY be used for a traffic aggregation point such as a 400 DSLAM within a network. 402 G. Any other measurement points SHOULD be assigned unused 403 integers between 01 and 99. The assignment SHOULD be stable 404 for at least the duration of a particular measurement study, 405 and SHOULD avoid numbers that have been assigned to other 406 locations within network X (unless the assignment is 407 considered sufficiently stale). Sub-networks or domains 408 within a network are useful locations for measurement points. 410 When supplying a diagram of the reference path and measurement 411 points, the operator of the measurement system MUST indicate: the 412 reference path, the numbers (mpXnn) of the measurement points, and 413 the technology-specific definition of any measurement point other 414 than X00 and X90 with sufficient detail to clearly define its 415 location (similar to the technology-specific examples in Section 6 of 416 this document). 418 If the number of intermediate networks (between the source and 419 destination) is not known or is unstable, then this SHOULD be 420 indicated on the diagram and results from measurement points within 421 those networks need to be treated with caution. 423 Notes: 425 o The terminology "on-net" and "off-net" is sometimes used when 426 referring to the Subscriber's Internet Service Provider (ISP) 427 measurement coverage. With respect to the reference path, tests 428 between mp100 and mp190 are "on-net". 430 o Widely deployed broadband Internet access measurements have used 431 pass-through devices[SK] (at the subscriber's location) directly 432 connected to the service demarcation point: this would be located 433 at mp100. 435 o The networking technology must be indicated for the measurement 436 points used, especially the interface standard and configured 437 speed (because the measurement connectivity itself can be a 438 limiting factor for the results). 440 o If it can be shown that a link connecting to a measurement point 441 has reliably deterministic performance or negligible impairments, 442 then the remote end of the connecting link is an equivalent point 443 for some methods of measurement (although those methods should 444 describe this possibility in detail; it is not in-scope to provide 445 such methods here). In any case, the presence of a link and 446 claimed equivalent measurement point must be reported. 448 o Some access network architectures may have an additional traffic 449 aggregation device between mp100 and mp150. Use of a measurement 450 point at this location would require a local number and diagram. 452 o A Carrier Grade NAT (CGN) deployed in the Service Provider's 453 access network would be positioned between mp100 and mp190, and 454 the egress side of the CGN may be designated mp150. mp150 is 455 generally an intermediate measurement point in the same address 456 space as mp190. 458 o In the case that private address space is used in an access 459 architecture, then mp100 may need to use the same address space as 460 its "on-net" measurement point counterpart, so that a test between 461 these points produces a useful assessment of network performance. 462 Tests between mp000 and mp100 could use a different private 463 address space, and when the globally-routable side of a CGN is at 464 mp150, then the private address side of the CGN could be 465 designated mp149 for tests with mp100. 467 o Measurement points at Transit GRA GWs are numbered mpX00 and 468 mpX90, where X is the lowest positive integer not already used in 469 the path. The GW of the first transit network is shown, with 470 point mp200 and the last transit network GW with mpX90. 472 6. Translation Between Reference Path and Various Technologies 474 This section and those that follow are intended to provide example 475 mappings between particular network technologies and the reference 476 path. 478 We provide an example for 3G Cellular access below. 480 Subscriber -- Private --- Service ------------- GRA --- Transit ... 481 device Net #1 Demarc. GW GRA GW 482 mp000 mp100 mp190 mp200 484 |_____________UE______________|___RAN+Core____|___GGSN__| 485 |_____Un-managed sub-path_____|____Managed sub-path_____| 487 GRA = Globally Routable Address, GW = Gateway, UE = User Equipment, 488 RAN = Radio Access Network, GGSN = Gateway GPRS Support Node. 490 We next provide an example of DSL access. Consider the case where: 492 o The Customer Premises Equipment (CPE) has a NAT device that is 493 configured with a public IP address. 495 o The CPE is a home router that has also an incorporated a WiFi 496 access point and this is the only networking device in the home 497 network, all endpoints attach directly to the CPE though the WiFi 498 access. 500 We believe this is a fairly common configuration in some parts of the 501 world and fairly simple as well. 503 This case would map into the defined reference measurement points as 504 follows: 506 Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit ... 507 device Net #1 Net #2 Demarc. Access GW GRA GW 508 mp000 mp100 mp150 mp190 mp200 509 |--UE--|------------CPE/NAT--------|------|-BRAS-|------| 510 |------DSL Network---| 511 |_______Un-managed sub-path________|__Managed sub-path__| 513 GRA = Globally Routable Address, GW = Gateway, BRAS = Broadband 514 Remote Access Server 516 Consider next another access network case where: 518 o The Customer Premises Equipment (CPE) is a NAT device that is 519 configured with a private IP address. 521 o There is a Carrier Grade NAT (CGN) located deep in the Access ISP 522 network. 524 o The CPE is a home router that has also an incorporated a WiFi 525 access point and this is the only networking device in the home 526 network, all endpoints attach directly to the CPE though the WiFi 527 access. 529 We believe this is becoming a fairly common configuration in some 530 parts of the world. 532 This case would map into the defined reference measurement points as 533 follows: 535 Subsc. -- Private ------------- Service-- Intra IP -- GRA -- Transit ... 536 device Net #1 Demarc. Access GW GRA GW 537 mp000 mp100 mp150 mp190 mp200 538 |--UE--|------------CPE/NAT--------|------|-CGN-|------| 539 |--Access Network---| 540 |_______Un-managed sub-path________|_Managed sub-path__| 542 GRA = Globally Routable Address, GW = Gateway 544 7. Example Resource Transition 546 This section gives an example of Shared and Dedicated portions with 547 the reference path. This example shows two Resource Transition 548 Points. 550 Consider the case where: 552 o The CPE consists of a wired Residential GW and modem (Private 553 Net#2) connected to a WiFi access point (Private Net#1). The 554 Subscriber device (UE) attaches to the CPE though the WiFi access. 556 o The WiFi subnetwork (Private Net#1) shares unlicensed radio 557 channel resources with other WiFi access networks (and potentially 558 other sources of interference), thus this is a Shared portion of 559 the path. 561 o The wired subnetwork (Private Net#2) and a portion of the Service 562 Provider's Network are Dedicated Resources (for a single 563 Subscriber), thus there is a Resource Transition Point between 564 (Private Net#1) and (Private Net#2). 566 o Subscriber traffic shares common resources with other subscribers 567 upon reaching the Carrier Grade NAT (CGN), thus there is a 568 Resource Transition Point and further network components are 569 designated as Shared Resources. 571 We believe this is a fairly common configuration in parts of the 572 world. 574 This case would map into the defined reference measurement points as 575 follows: 577 Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit ... 578 device Net #1 Net #2 Demarc. Access GW GRA GW 579 mp000 mp100 mp150 mp190 mp200 580 |--UE--|------------CPE/NAT--------|------|-CGN-|------| 581 | WiFi | 1000Base-T |--Access Network---| 583 |-Shared--|RT|------Dedicated------| RT |-----Shared------... 584 |_______Un-managed sub-path________|_Managed sub-path__| 586 GRA = Globally Routable Address, GW = Gateway, RT = Resource 587 Transition Point 589 8. Security considerations 591 Specification of a Reference Path and identification of measurement 592 points on the path represent agreements among interested parties, and 593 they present no threat to the implementors of this memo, or to the 594 Internet resulting from implementation of the guidelines provided 595 here. 597 Attacks at end hosts or identified measurement points are possible. 598 However, there is no requirement to include IP addresses of hosts or 599 other network devices in a reference path with measurement points 600 that is compliant with this memo. As a result, the path diagrams 601 with measurement point designation numbers do not aid such attacks. 603 Most network operators' diagrams of reference paths will bear a close 604 to the similar diagrams in relevant standards or other publicly 605 available documents. However, when an operator must include atypical 606 network details in their diagram, e.g., to explain why a longer 607 latency measurement is expected, then the diagram reveals some 608 topological details and should be marked as confidential and shared 609 with others under a specific agreement. 611 When considering privacy of those involved in measurement or those 612 whose traffic is measured, there may be sensitive information 613 communicated to recipients of the network diagrams illustrating paths 614 and measurement points described above. We refer the reader to the 615 privacy considerations described in the Large Scale Measurement of 616 Broadband Performance (LMAP) Framework [I-D.ietf-lmap-framework], 617 which covers active and passive measurement techniques and supporting 618 material on measurement context. For example, the value of sensitive 619 information can be further diluted by summarising measurement results 620 over many individuals or areas served by the provider. There is an 621 opportunity enabled by forming anonymity sets described in [RFC6973] 622 based on the reference path and measurement points in this memo. For 623 example, all measurements from the Subscriber device can be 624 identified as "mp000", instead of using the IP address or other 625 device information. The same anonymisation applies to the Internet 626 Service Provider, where their Internet gateway would be referred to 627 as "mp190". 629 9. IANA Considerations 631 This memo makes no requests for IANA consideration. 633 10. Acknowledgements 635 Thanks to Matt Mathis, Charles Cook, Dan Romascanu, Lingli Deng, and 636 Spencer Dawkins for review and comments. 638 11. References 640 11.1. Normative References 642 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 643 "Framework for IP Performance Metrics", RFC 2330, May 644 1998. 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, March 1997. 649 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 650 performance measurement with periodic streams", RFC 3432, 651 November 2002. 653 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 654 Composition", RFC 5835, April 2010. 656 11.2. Informative References 658 [I-D.ietf-lmap-framework] 659 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 660 Aitken, P., and A. Akhter, "A framework for large-scale 661 measurement platforms (LMAP)", draft-ietf-lmap- 662 framework-08 (work in progress), August 2014. 664 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 665 Morris, J., Hansen, M., and R. Smith, "Privacy 666 Considerations for Internet Protocols", RFC 6973, July 667 2013. 669 [SK] Crawford, Sam., "Test Methodology White Paper", SamKnows 670 Whitebox Briefing Note 671 http://www.samknows.com/broadband/index.php, July 2011. 673 [Q1741] Q.1741.7, , "IMT-2000 references to Release 9 of GSM- 674 evolved UMTS core network", 675 http://www.itu.int/rec/T-REC-Q.1741.7/en, November 2011. 677 [Y.1541] Y.1541, , "Network performance objectives for IP-based 678 services", http://www.itu.int/rec/T-REC-Y.1541/en, 679 November 2011. 681 Authors' Addresses 683 Marcelo Bagnulo 684 Universidad Carlos III de Madrid 685 Av. Universidad 30 686 Leganes, Madrid 28911 687 SPAIN 689 Phone: 34 91 6249500 690 Email: marcelo@it.uc3m.es 691 URI: http://www.it.uc3m.es 693 Trevor Burbridge 694 BT 695 Adastral Park, Martlesham Heath 696 Ipswich 697 ENGLAND 699 Email: trevor.burbridge@bt.com 700 Sam Crawford 701 SamKnows 703 Email: sam@samknows.com 705 Phil Eardley 706 BT 707 Adastral Park, Martlesham Heath 708 Ipswich 709 ENGLAND 711 Email: philip.eardley@bt.com 713 Al Morton 714 AT&T Labs 715 200 Laurel Avenue South 716 Middletown, NJ 717 USA 719 Email: acmorton@att.com