idnits 2.17.1 draft-ietf-alto-deployments-12.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 20, 2015) is 3233 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-dnsop-edns-client-subnet-01 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-09 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-11 == Outdated reference: A later version (-02) exists of draft-kiesel-alto-xdom-disc-00 == Outdated reference: A later version (-10) exists of draft-seedorf-cdni-request-routing-alto-08 == Outdated reference: A later version (-09) exists of draft-wu-alto-te-metrics-06 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO M. Stiemerling 3 Internet-Draft NEC Europe Ltd. 4 Intended status: Informational S. Kiesel 5 Expires: December 22, 2015 University of Stuttgart 6 S. Previdi 7 Cisco 8 M. Scharf 9 Alcatel-Lucent Bell Labs 10 June 20, 2015 12 ALTO Deployment Considerations 13 draft-ietf-alto-deployments-12 15 Abstract 17 Many Internet applications are used to access resources such as 18 pieces of information or server processes that are available in 19 several equivalent replicas on different hosts. This includes, but 20 is not limited to, peer-to-peer file sharing applications. The goal 21 of Application-Layer Traffic Optimization (ALTO) is to provide 22 guidance to applications that have to select one or several hosts 23 from a set of candidates, which are able to provide a desired 24 resource. This memo discusses deployment related issues of ALTO. It 25 addresses different use cases of ALTO such as peer-to-peer file 26 sharing and CDNs and presents corresponding examples. The document 27 also includes recommendations for network administrators and 28 application designers planning to deploy ALTO. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 22, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. General Considerations . . . . . . . . . . . . . . . . . . . 4 66 2.1. ALTO Entities . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1.1. Baseline Scenario . . . . . . . . . . . . . . . . . . 4 68 2.1.2. Placement of ALTO Entities . . . . . . . . . . . . . 5 69 2.2. Classification of Deployment Scenarios . . . . . . . . . 7 70 2.2.1. Roles in ALTO Deployments . . . . . . . . . . . . . . 7 71 2.2.2. Information Exposure . . . . . . . . . . . . . . . . 9 72 2.2.3. More Advanced Deployments . . . . . . . . . . . . . . 10 73 3. Deployment Considerations by ISPs . . . . . . . . . . . . . . 13 74 3.1. Objectives for the Guidance to Applications . . . . . . . 13 75 3.1.1. General Objectives for Traffic Optimization . . . . . 13 76 3.1.2. Inter-Network Traffic Localization . . . . . . . . . 14 77 3.1.3. Intra-Network Traffic Localization . . . . . . . . . 15 78 3.1.4. Network Off-Loading . . . . . . . . . . . . . . . . . 16 79 3.1.5. Application Tuning . . . . . . . . . . . . . . . . . 17 80 3.2. Provisioning of ALTO Topology Data . . . . . . . . . . . 18 81 3.2.1. Data Sources . . . . . . . . . . . . . . . . . . . . 18 82 3.2.2. Privacy Requirements . . . . . . . . . . . . . . . . 20 83 3.2.3. Partitioning and Grouping of IP Address Ranges . . . 21 84 3.2.4. Rating Criteria and/or Cost Calculation . . . . . . . 22 85 3.3. Known Limitations of ALTO . . . . . . . . . . . . . . . . 25 86 3.3.1. General Limitations . . . . . . . . . . . . . . . . . 25 87 3.3.2. Limitations of Map-based Approaches . . . . . . . . . 26 88 3.3.3. Limitations of Non-Map-based Approaches . . . . . . . 28 89 3.4. Monitoring ALTO . . . . . . . . . . . . . . . . . . . . . 29 90 3.4.1. Impact and Observation on Network Operation . . . . . 29 91 3.4.2. Measurement of the Impact . . . . . . . . . . . . . . 30 92 3.4.3. System and Service Performance . . . . . . . . . . . 31 93 3.4.4. Monitoring Infrastructures . . . . . . . . . . . . . 31 94 3.5. Map Examples for Different Types of ISPs . . . . . . . . 32 95 3.5.1. Small ISP with Single Internet Uplink . . . . . . . . 32 96 3.5.2. ISP with Several Fixed Access Networks . . . . . . . 35 97 3.5.3. ISP with Fixed and Mobile Network . . . . . . . . . . 36 98 3.6. Deployment Experiences . . . . . . . . . . . . . . . . . 38 99 4. Using ALTO for P2P Traffic Optimization . . . . . . . . . . . 38 100 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 38 101 4.1.1. Usage Scenario . . . . . . . . . . . . . . . . . . . 38 102 4.1.2. Applicability of ALTO . . . . . . . . . . . . . . . . 39 103 4.2. Deployment Recommendations . . . . . . . . . . . . . . . 41 104 4.2.1. ALTO Services . . . . . . . . . . . . . . . . . . . . 41 105 4.2.2. Guidance Considerations . . . . . . . . . . . . . . . 42 106 5. Using ALTO for CDNs . . . . . . . . . . . . . . . . . . . . . 44 107 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 44 108 5.1.1. Usage Scenario . . . . . . . . . . . . . . . . . . . 45 109 5.1.2. Applicability of ALTO . . . . . . . . . . . . . . . . 46 110 5.2. Deployment Recommendations . . . . . . . . . . . . . . . 48 111 5.2.1. ALTO Services . . . . . . . . . . . . . . . . . . . . 48 112 5.2.2. Guidance Considerations . . . . . . . . . . . . . . . 49 113 6. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 50 114 6.1. Application Guidance in Virtual Private Networks (VPNs) . 50 115 6.2. In-Network Caching . . . . . . . . . . . . . . . . . . . 53 116 6.3. Other Application-based Network Operations . . . . . . . 54 117 7. Security Considerations . . . . . . . . . . . . . . . . . . . 54 118 7.1. ALTO as a Protocol Crossing Trust Boundaries . . . . . . 55 119 7.2. Information Leakage from the ALTO Server . . . . . . . . 55 120 7.3. ALTO Server Access . . . . . . . . . . . . . . . . . . . 57 121 7.4. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . 58 122 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 123 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 58 124 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 125 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 126 11.1. Normative References . . . . . . . . . . . . . . . . . . 59 127 11.2. Informative References . . . . . . . . . . . . . . . . . 60 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 130 1. Introduction 132 Many Internet applications are used to access resources such as 133 pieces of information or server processes that are available in 134 several equivalent replicas on different hosts. This includes, but 135 is not limited to, peer-to-peer (P2P) file sharing applications and 136 Content Delivery Networks (CDNs). The goal of Application-Layer 137 Traffic Optimization (ALTO) is to provide guidance to applications 138 that have to select one or several hosts from a set of candidates, 139 which are able to provide a desired resource. The basic ideas and 140 problem space of ALTO is described in [RFC5693] and the set of 141 requirements is discussed in [RFC6708]. The ALTO protocol is 142 specified in [RFC7285]. An ALTO server discovery procedure is 143 defined in [RFC7286]. 145 This document discusses use cases and operational issues that can be 146 expected when ALTO gets deployed. This includes, but is not limited 147 to, location of the ALTO server, imposed load to the ALTO server, and 148 from whom the queries are performed. The document also provides 149 guidance which ALTO services to use, and it summarizes known 150 challenges. It thereby complements the management considerations in 151 the protocol specification [RFC7285], which are independent of any 152 specific use of ALTO. 154 2. General Considerations 156 2.1. ALTO Entities 158 2.1.1. Baseline Scenario 160 The ALTO protocol [RFC7285] is a client/server protocol, operating 161 between a number of ALTO clients and an ALTO server, as sketched in 162 Figure 1. 164 +----------+ 165 | ALTO | 166 | Server | 167 +----------+ 168 ^ 169 _.-----|------. 170 ,-'' | `--. 171 ,' | `. 172 ( Network | ) 173 `. | ,' 174 `--. | _.-' 175 `------|-----'' 176 v 177 +----------+ +----------+ +----------+ 178 | ALTO | | ALTO |...| ALTO | 179 | Client | | Client | | Client | 180 +----------+ +----------+ +----------+ 182 Figure 1: Baseline deployment scenario of the ALTO protocol 184 This document uses the terminology introduced in [RFC5693]. In 185 particular, the following terms are defined by [RFC5693]: 187 o ALTO Service: Several resource providers may be able to provide 188 the same resource. The ALTO service gives guidance to a resource 189 consumer and/or resource directory about which resource 190 provider(s) to select in order to optimize the client's 191 performance or quality of experience, while improving resource 192 consumption in the underlying network infrastructure. 194 o ALTO Server: A logical entity that provides interfaces to the 195 queries to the ALTO service. 197 o ALTO Client: The logical entity that sends ALTO queries. 198 Depending on the architecture of the application, one may embed it 199 in the resource consumer and/or in the resource directory. 201 According to that definition, both an ALTO server and an ALTO client 202 are logical entities. An ALTO service may be offered by more than 203 one ALTO servers. In ALTO deployments, the functionality of an ALTO 204 server can therefore be realized by several server instances, e.g., 205 by using load balancing between different physical servers. The term 206 ALTO server should not be confused with use of a single physical 207 server. 209 2.1.2. Placement of ALTO Entities 211 The ALTO server and ALTO clients can be situated at various entities 212 in a network deployment. The first differentiation is whether the 213 ALTO client is located on the actual host that runs the application, 214 as shown in Figure 2, or if the ALTO client is located on a resource 215 directory, as shown in Figure 3. 217 +--------------+ 218 | App | 219 +-----------+ | 220 ===>|ALTO Client| |**** 221 === +-----------+--+ * 222 === * * 223 === * * 224 +-------+ +-------+<=== +--------------+ * 225 | | | | | App | * 226 | |.....| |<======== +-----------+ | * 227 | | | | ========>|ALTO Client| | * 228 +-------+ +-------+<=== +-----------+--+ * 229 Source of ALTO == * * 230 topological Server == * * 231 information == +--------------+ * 232 == | App | * 233 == +-----------+ |**** 234 ==>|ALTO Client| | 235 +-----------+--+ 236 Application 237 Legend: 238 === ALTO protocol 239 *** Application protocol 240 ... Provisioning protocol 242 Figure 2: Overview of protocol interaction between ALTO elements 243 without a resource directory 245 Figure 2 shows the operational model for an ALTO client running at 246 endpoints. An example would be a peer-to-peer file sharing 247 application that does not use a tracker, such as edonkey. In 248 addition, ALTO clients at peers could also be used in a similar way 249 even if there is a tracker, as further discussed in Section 4.1.2. 251 +-----+ 252 **| App |**** 253 ** +-----+ * 254 ** * * 255 ** * * 256 +-------+ +-------+ +--------------+ * * 257 | | | | | | +-----+ * 258 | |.....| | +-----------+ |*****| App | * 259 | | | |<===>|ALTO Client| | +-----+ * 260 +-------+ +-------+ +-----------+--+ * * 261 Source of ALTO Resource ** * * 262 topological Server directory ** * * 263 information ** +-----+ * 264 **| App |**** 265 +-----+ 266 Application 267 Legend: 268 === ALTO protocol 269 *** Application protocol 270 ... Provisioning protocol 272 Figure 3: Overview of protocol interaction between ALTO elements with 273 a resource directory 275 In Figure 3, a use case with a resource directory is illustrated, 276 e.g., a tracker in peer-to-peer file-sharing. Both deployment 277 scenarios may differ in the number of ALTO clients that access an 278 ALTO service: If an ALTO client is implemented in a resource 279 directory, an ALTO server may be accessed by a limited and less 280 dynamic set of clients, whereas in the general case any host could be 281 an ALTO client. This use case is further detailed in Section 4. 283 Using ALTO in CDNs may be similar to a resource directory 284 [I-D.jenkins-alto-cdn-use-cases]. The ALTO server can also be 285 queried by CDN entities to get guidance about where the a particular 286 client accessing data in the CDN is exactly located in the Internet 287 Service Provider's network, as discussed in Section 5. 289 2.2. Classification of Deployment Scenarios 291 2.2.1. Roles in ALTO Deployments 293 ALTO is a general-purpose protocol and it is intended to be used by a 294 wide range of applications. This implies that there are different 295 possibilities where the ALTO entities are actually located, i.e., if 296 the ALTO clients and the ALTO server are in the same Internet Service 297 Provider (ISP) domain, or if the clients and the ALTO server are 298 managed/owned/located in different domains. 300 An ALTO deployment involves four kinds of entities: 302 1. Source of topological information 304 2. ALTO server 306 3. ALTO client 308 4. Resource consumer (using the ALTO guidance) 310 Each of these entities corresponds to a certain role, which results 311 in requirements and constraints on the interaction between the 312 entities. 314 A key design objective of the ALTO service is that each these four 315 roles can be separated, i.e., they can be realized by different 316 organizations or disjoint system components. ALTO is inherently 317 designed for use in multi-domain environments. Most importantly, 318 ALTO is designed to enable deployments in which the ALTO server and 319 the ALTO client are not located within the same administrative 320 domain. 322 As explained in [RFC5693], from this follows that at least three 323 different kinds of entities can operate an ALTO server: 325 1. Network operators. Network Service Providers (NSPs) such as 326 Internet Service Providers (ISPs) may have detailed knowledge of 327 their network topology and policies. In this case, the source of 328 the topology information and the provider of the ALTO server may 329 be part of the same organization. 331 2. Third parties. Topology information could also be collected by 332 entities separate from network operators but that may either have 333 collected network information or have arrangements with network 334 operators to learn the network information. Examples of such 335 entities could be Content Delivery Network (CDN) operators or 336 companies specialized on offering ALTO services on behalf of 337 ISPs. 339 3. User communities. User communities could run distributed 340 measurements for estimating the topology of the Internet. In 341 this case the topology information may not originate from ISP 342 data. 344 Regarding the interaction between ALTO server and client, ALTO 345 deployments can be differentiated according to the following aspects: 347 1. Applicable trust model: The deployment of ALTO can differ 348 depending on whether ALTO client and ALTO server are operated 349 within the same organization and/or network, or not. This 350 affects a lot of constraints, because the trust model is very 351 different. For instance, as discussed later in this memo, the 352 level-of-detail of maps can depend on who the involved parties 353 actually are. 355 2. Composition of the user group: The main use case of ALTO is to 356 provide guidance to any Internet application. However, an 357 operator of an ALTO server could also decide to offer guidance 358 only to a set of well-known ALTO clients, e. g., after 359 authentication and authorization. In the peer-to-peer 360 application use case, this could imply that only selected 361 trackers are allowed to access the ALTO server. The security 362 implications of using ALTO in closed groups differ from the 363 public Internet. 365 3. Covered destinations: In general, an ALTO server has to be able 366 to provide guidance for all potential destinations. Yet, in 367 practice a given ALTO client may only be interested in a subset 368 of destinations, e.g., only in the network cost between a limited 369 set of resource providers. For instance, CDN optimization may 370 not need the full ALTO cost maps, because traffic between 371 individual residential users is not in scope. This may imply 372 that an ALTO server only has to provide the costs that matter for 373 a given user, e. g., by customized maps. 375 The following sections enumerate different classes of use cases for 376 ALTO, and they discuss deployment implications of each of them. An 377 ALTO server can in principle be operated by any organization, and 378 there is no requirement that an ALTO server is deployed and operated 379 by an ISP. Yet, since the ALTO solution is designed for ISPs, most 380 examples in this document assume that the operator of an ALTO server 381 is a network operator (e.g., an ISP or the network department in a 382 large enterprise) that offers ALTO guidance in particular to users of 383 this network. 385 It must be emphasized that any application using ALTO must also work 386 if no ALTO servers can be found or if no responses to ALTO queries 387 are received, e.g., due to connectivity problems or overload 388 situations (see also [RFC6708]). 390 2.2.2. Information Exposure 392 There are basically two different approaches how an ALTO server can 393 provide network information and guidance: 395 1. The ALTO server provides maps that contain provider-defined cost 396 values between network location groupings (e.g., sets of IP 397 prefixes). These maps can be retrieved by clients via the ALTO 398 protocol, and the actual processing of the map data is done 399 inside the client. Since the maps contain (aggregated) cost 400 information for all endpoints, the client does not have to reveal 401 any internal operational data, such as the IP addresses of 402 candidate resource providers. The ALTO protocol supports this 403 mode of operation by the Network and Cost Map Service. 405 2. The ALTO server provides a query interface that returns costs or 406 rankings for explicitly specified endpoints. This means that the 407 query of the ALTO client has to include additional information 408 (e.g., a list of IP addresses). The server then calculates and 409 returns costs or rankings for the endpoints specified in the 410 request (e.g., a sorted list of the IP addresses). In ALTO, this 411 method can be realized by the Endpoint Cost Service. 413 Both approaches have different privacy implications for the server 414 and client: 416 For the client, approach 1 has the advantage that all operational 417 information stays within the client and is not revealed to the 418 provider of the server. However, this service implies that a network 419 operator providing an ALTO server has to expose a certain amount of 420 information about its network structure (e.g., IP prefixes or 421 topology information in general). 423 For the operator of a server, approach 2 has the advantage that the 424 query responses reveal less topology information to ALTO clients. 425 But this method requires that client sends internal operational 426 information to the server, such as the IP addresses of hosts also 427 running the application. For clients, such data can be sensitive. 429 As a result, both approaches have their pros and cons, as further 430 detailed in Section 3.3. 432 2.2.3. More Advanced Deployments 434 From an ALTO client's perspective, there are different ways to use 435 ALTO: 437 1. Single service instance with single metric guidance: An ALTO 438 client only obtains guidance regarding a single metric from a 439 single ALTO service, e.g., an ALTO server that is offered by the 440 network service provider of the corresponding access network. 441 Corresponding ALTO server instances can be discovered e.g. by 442 ALTO server discovery [RFC7286] [I-D.kiesel-alto-xdom-disc]. 444 Being a REST-ful protocol, an ALTO service can use known methods 445 to balance the load between different server instances or between 446 clusters of servers, i.e., an ALTO server can be realized by many 447 instances with a load balancing scheme. The ALTO protocol also 448 supports the use of different URIs for different ALTO features. 450 2. Single service instance with multiple metric guidance: An ALTO 451 client could also query an ALTO service for different kinds of 452 information, e.g., cost maps with different metrics. The ALTO 453 protocol is extensible and permits such operation. However, ALTO 454 does not define how a client shall deal with different forms of 455 guidance, and it is up to the client to determine what provided 456 information may indeed be useful. 458 3. Multiple service instances: An ALTO client can also decide to 459 access multiple ALTO servers providing guidance, possibly from 460 different operators or organizations. Each of these services may 461 only offer partial guidance, e.g., for a certain network 462 partition. In that case, it may be difficult for an ALTO client 463 to compare the guidance from different services. Different 464 organization may use different methods to determine maps, and 465 they may also have different (possibly even contradicting or 466 competing) guidance objectives. How to discover multiple ALTO 467 servers and how to deal with conflicting guidance is an open 468 issue. 470 There are also different options regarding the synchronization of 471 guidance offered by an ALTO service: 473 1. Authoritative servers: An ALTO server instance can provide 474 guidance for all destinations for all kinds of ALTO clients. 476 2. Cascaded servers: An ALTO server may itself include an ALTO 477 client and query other ALTO servers, e.g., for certain 478 destinations. This results is a cascaded deployment of ALTO 479 servers, as further explained below. 481 3. Inter-server synchronization: Different ALTO servers my 482 communicate by other means. This approach is not further 483 discussed in this document. 485 An assumption of the ALTO design is that ISP operate ALTO servers 486 independently, irrespectively of other ISPs. This may true for most 487 envisioned deployments of ALTO but there may be certain deployments 488 that may have different settings. Figure 4 shows such setting with a 489 university network that is connected to two upstream providers. NREN 490 is a National Research and Education Network, which provides cheap 491 high-speed connectivity to specific destinations, e.g., other 492 universities. ISP is a commercial upstream provider from which the 493 university buys connectivity to all destinations that cannot be 494 reached via the NREN. The university, as well as ISP, are operating 495 their own ALTO server. The ALTO clients, located on the peers will 496 contact the ALTO server located at the university. 498 +-----------+ 499 | ISP | 500 | ALTO |<==========================++ 501 | Server | || 502 +-----------+ || 503 ,-------. ,------. || 504 ,-' `-. ,-' `-. || 505 / Commercial \ / \ || 506 ( Upstream ) ( NREN ) || 507 \ ISP / \ / || 508 `-. ,-' `-. ,-' || 509 `---+---' `+------' || 510 | | || 511 | | || 512 |,-------------. | \/ 513 ,-+ `-+ +-----------+ 514 ,' University `. |University | 515 ( Network ) | ALTO | 516 `. / | Server | 517 `-. +--' +-----------+ 518 `+------------'| /\ /\ 519 | | || || 520 +--------+-+ +-+--------+ || || 521 | Peer1 | | PeerN |<====++ || 522 +----------+ +----------+ || 523 /\ || 524 || || 525 ++======================================++ 527 Legend: 528 === ALTO protocol 530 Figure 4: Example of a cascaded ALTO server 532 In this setting all "destinations" useful for the peers within NREN 533 are free-of-charge for the peers located in the university network 534 (i.e., they are preferred in the rating of the ALTO server). 535 However, all traffic that is not towards NREN will be handled by the 536 ISP upstream provider. Therefore, the ALTO server at the university 537 may also include the guidance given by the ISP ALTO server in its 538 replies to the ALTO clients. This is an example for cascaded ALTO 539 servers. 541 3. Deployment Considerations by ISPs 543 3.1. Objectives for the Guidance to Applications 545 3.1.1. General Objectives for Traffic Optimization 547 The Internet consists of many networks. The networks are operated by 548 Network Service Providers (NSP) or Internet Service Providers (ISP), 549 which also include e.g. universities, enterprises, or other 550 organizations. The Internet provides network connectivity, e.g., by 551 access networks, such as cable networks, xDSL networks, 3G/4G mobile 552 networks, etc. Network operators need to manage, to control and to 553 audit the traffic. Therefore, it is important to understand how to 554 deploy an ALTO service and its expected impact. 556 The general objective of ALTO is to give guidance to applications on 557 what endpoints (e.g., IP addresses or IP prefixes) are to be 558 preferred according to the operator of the ALTO server. The ALTO 559 protocol gives means to let the ALTO server operator express its 560 preference, whatever this preference is. 562 ALTO enables ISPs to support application-level traffic engineering by 563 influencing application resource provider selection. This traffic 564 engineering can have different objectives: 566 1. Inter-network traffic localization: ALTO can help to reduce 567 inter-domain traffic. The networks of ISPs are interconnected 568 through peering points. From a business view, the inter-network 569 settlement is needed for exchanging traffic between these 570 networks. These peering agreements can be costly. To reduce 571 these costs, a simple objective is to decrease the traffic 572 exchange across the peering points and thus keep the traffic in 573 the own network or Autonomous System (AS) as far as possible. 575 2. Intra-network traffic localization: In case of large ISPs, the 576 network may be grouped into several networks, domains, or 577 Autonomous Systems (ASs). The core network includes one or 578 several backbone networks, which are connected to multiple 579 aggregation, metro, and access networks. If traffic can be 580 limited to certain areas such as access networks, this decreases 581 the usage of backbone and thus helps to save resources and costs. 583 3. Network off-loading: Compared to fixed networks, mobile networks 584 have some special characteristics, including smaller link 585 bandwidth, high cost, limited radio frequency resource, and 586 limited terminal battery. In mobile networks, wireless links 587 should be used efficiently. For example, in the case of a P2P 588 service, it is likely that hosts should prefer retrieving data 589 from hosts in fixed networks, and avoid retrieving data from 590 mobile hosts. 592 4. Application tuning: ALTO is also a tool to optimize the 593 performance of applications that depend on the network and 594 perform resource provider selection decisions among network 595 endpoints. And example is the network-aware selection of Content 596 Delivery Network (CDN) caches. 598 In the following, these objectives are explained in more detail with 599 examples. 601 3.1.2. Inter-Network Traffic Localization 603 ALTO guidance can be used to keep traffic local in a network, for 604 instance in order to reduce peering costs. An ALTO server can let 605 applications prefer other hosts within the same network operator's 606 network instead of randomly connecting to other hosts that are 607 located in another operator's network. Here, a network operator 608 would always express its preference for hosts in its own network, 609 while hosts located outside its own network are to be avoided (i.e., 610 they are undesired to be considered by the applications). Figure 5 611 shows such a scenario where hosts prefer hosts in the same network 612 (e.g., Host 1 and Host 2 in ISP1 and Host 3 and Host 4 in ISP2). 614 ,-------. +-----------+ 615 ,---. ,-' `-. | Host 1 | 616 ,-' `-. / ISP 1 ########|ALTO Client| 617 / \ / # \ +-----------+ 618 / ISP X \ | # | +-----------+ 619 / \ \ ########| Host 2 | 620 ; +----------------------------|ALTO Client| 621 | | | `-. ,-' +-----------+ 622 | | | `-------' 623 | Inter- | | ,-------. +-----------+ 624 : network | ; ,-' `########| Host 3 | 625 \ traffic | / / ISP 2 # \ |ALTO Client| 626 \ | / / # \ +-----------+ 627 \ |/ | # | +-----------+ 628 `-. ,-| \ ########| Host 4 | 629 `---' +----------------------------|ALTO Client| 630 `-. ,-' +-----------+ 631 `-------' 633 Legend: 634 ### preferred "connections" 635 --- non-preferred "connections" 637 Figure 5: Inter-network traffic localization 639 Examples for corresponding ALTO maps can be found in Section 3.5. 640 Depending on the application characteristics, it may not be possible 641 or even not be desirable to completely localize all traffic. 643 3.1.3. Intra-Network Traffic Localization 645 The previous section describes the results of the ALTO guidance on an 646 inter-network level. In the same way, ALTO can also be used for 647 intra-network localization. In this case, ALTO provides guidance 648 which internal hosts are to be preferred inside a single network 649 (e.g., one AS). This application-level traffic engineering can 650 reduce the capacity requirements in the core network of an ISP. 651 Figure 6 shows such a scenario where Host 1 and Host 2 are located in 652 an access net 1 of ISP 1 and connect via a low capacity link to the 653 core of the same ISP 1. If Host 1 and Host 2 exchange their data 654 with remote hosts, they would probably congest the bottleneck link. 656 Bottleneck ,-------. +-----------+ 657 ,---. | ,-' `-. | Host 1 | 658 ,-' `-. | / ISP 1 ########|ALTO Client| 659 / \ | / (Access # \ +-----------+ 660 / ISP 1 \| | net 1) # | +-----------+ 661 / (Core V \ ########| Host 2 | 662 ; network) +--X~~~X---------------------|ALTO Client| 663 | | | `-. ,-' +-----------+ 664 | | | `-------' 665 | | | ,-------. +-----------+ 666 : | ; ,-' `########| Host 3 | 667 \ | / / ISP 1 # \ |ALTO Client| 668 \ | / / (Access # \ +-----------+ 669 \ |/ | net 2) # | +-----------+ 670 `-. ,-X \ ########| Host 4 | 671 `---' ~~~~~~~X---------------------|ALTO Client| 672 ^ `-. ,-' +-----------+ 673 | `-------' 674 Bottleneck 675 Legend: 676 ### preferred "connections" 677 --- non-preferred "connections" 679 Figure 6: Intra-network traffic localization 681 The operator can guide the hosts in such a situation to try first 682 local hosts in the same network islands, avoiding or at least 683 lowering the effect on the bottleneck link, as shown in Figure 6. 685 The objective is to avoid bottlenecks by optimized endpoint selection 686 at application level. ALTO is not a method to deal with the 687 congestion at the bottleneck. 689 3.1.4. Network Off-Loading 691 Another scenario is off-loading traffic from networks. This use of 692 ALTO can be beneficial in particular in mobile networks. A network 693 operator may have the desire to guide hosts in its own mobile network 694 to use hosts outside this mobile network. One reason can be that the 695 wireless network is not made for the load cause by, e.g., peer-to- 696 peer applications, and it therefore makes sense when peers fetch 697 their data from remote peers in other parts of the Internet. 699 ,-------. +-----------+ 700 ,---. ,-' `-. | Host 1 | 701 ,-' `-. / ISP 1 +-------|ALTO Client| 702 / \ / (Mobile | \ +-----------+ 703 / ISP X \ | network) | | +-----------+ 704 / \ \ +-------| Host 2 | 705 ; #############################|ALTO Client| 706 | # | `-. ,-' +-----------+ 707 | # | `-------' 708 | # | ,-------. 709 : # ; ,-' `-. 710 \ # / / ISP 2 \ 711 \ # / / (Fixed \ 712 \ #/ | network) | +-----------+ 713 `-. ,-# \ / | Host 3 | 714 `---' #############################|ALTO Client| 715 `-. ,-' +-----------+ 716 `-------' 718 Legend: 719 ### preferred "connections" 720 --- non-preferred "connections" 722 Figure 7: ALTO traffic network de-localization 724 Figure 7 shows the result of such a guidance process where Host 2 725 prefers a connection with Host 3 instead of Host 1, as shown in 726 Figure 5. 728 A realization of this scenario may have certain limitations and may 729 not be possible in all cases. For instance, it may require that the 730 ALTO server can distinguish mobile and non-mobile hosts, e.g., based 731 on their IP address. This may depend on mobility solutions and may 732 not be possible or accurate. In general, ALTO is not intended as a 733 fine-grained traffic engineering solution for individual hosts. 734 Instead, it typically works on aggregates (e.g., if it is known that 735 certain IP prefixes are often assigned to mobile users). 737 3.1.5. Application Tuning 739 ALTO can also provide guidance to optimize the application-level 740 topology of networked applications, e.g., by exposing network 741 performance information. Applications can often run their own 742 measurements to determine network performance, e.g., by active delay 743 measurements or bandwidth probing, but such measurements result in 744 overhead and complexity. Accessing an ALTO server can be a simpler 745 alternative. In addition, an ALTO server may also expose network 746 information that applications cannot easily measure or reverse- 747 engineer. 749 3.2. Provisioning of ALTO Topology Data 751 3.2.1. Data Sources 753 An ALTO server can collect topological information from a variety of 754 sources in the network and provides a cohesive, abstracted view of 755 the network topology to applications using an ALTO client. Sources 756 that may include routing protocols, network policies, state and 757 performance information, geo-location, etc. Based on the input, the 758 ALTO server builds an ALTO-specific network topology that represents 759 the network as it should be understood and utilized by applications 760 (resource consumers) at endpoints using ALTO services (e.g., Network/ 761 Cost Map Service or ECS). 763 The ALTO protocol does not assume a specific network topology. In 764 principle, ALTO can be used with various types of addresses (Endpoint 765 Addresses). [RFC7285] defines the use of IPv4/IPv6 addresses or 766 prefixes in ALTO, but further address types could be added by 767 extensions. In this document, only the use of IPv4/IPv6 addresses is 768 considered. 770 The exposure of network topology information is controlled and 771 managed by the ALTO server. ALTO abstract network topologies can be 772 automatically generated from the physical or logical topology of the 773 network. The generation would typically be based on policies and 774 rules set by the network operator. The maps and the guidance can 775 significantly differ depending on the use case, the network 776 architecture, and the trust relationship between ALTO server and ALTO 777 client, etc. Besides the security requirements that consist of not 778 delivering any confidential or critical information about the 779 infrastructure, there are efficiency requirements in terms of what 780 aspects of the network are visible and required by the given use case 781 and/or application. 783 The ALTO server operator has to ensure that the ALTO topology does 784 not reveal any details that would endanger the network integrity and 785 security. For instance, ALTO is not intended to leak raw Interior 786 Gateway Protocol (IGP) or Border gateway Protocol (BGP) databases to 787 ALTO clients. 789 +--------+ +--------+ 790 | ALTO | | ALTO | 791 | Client | | Client | 792 +--------+ +--------+ 793 /\ /\ 794 || || ALTO protocol 795 || || 796 \/ \/ 797 +---------+ 798 | ALTO | 799 | Server | 800 +---------+ 801 : : : 802 : : : 803 +........+ : +........+ Provisioning 804 : : : protocol 805 : : : 806 +---------+ +---------+ +---------+ 807 | BGP | | I2RS | | NMS | Potential 808 | Speaker | | Client | | OSS | data sources 809 +---------+ +---------+ +---------+ 810 ^ ^ ^ 811 | | | 812 Link-State I2RS SNMP/NETCONF, 813 NLRI for data traffic statistics, 814 IGP/BGP IPFIX, etc. 816 Figure 8: Potential data sources for ALTO 818 As illustrated in Figure 8, the topology data used by an ALTO server 819 can originate from different data sources: 821 o The document [I-D.ietf-idr-ls-distribution] describes a mechanism 822 by which links state and traffic engineering information can be 823 collected from networks and shared with external components using 824 the BGP routing protocol. This is achieved using a new BGP 825 Network Layer Reachability Information (NLRI) encoding format. 826 The mechanism is applicable to physical and virtual IGP links and 827 can also include Traffic Engineering (TE) data. For instance, 828 prefix data can be carried and originated in BGP, while TE data is 829 originated and carried in an IGP. The mechanism described is 830 subject to policy control. An ALTO server can also use other 831 mechanisms to get network data, for example, peering with multiple 832 IGP and BGP speakers. 834 o The Interface to the Routing System (I2RS) is a solution for state 835 transfer in and out of the Internet's routing system 837 [I-D.ietf-i2rs-architecture]. An ALTO server could use an I2RS 838 client to observe routing-related information. 840 o An ALTO server can also leverage a Network Management System (NMS) 841 or an Operations Support System (OSS) as data sources. NMS or OSS 842 solutions are used to control, operate, and manage a network, 843 e.g., using the Simple Network Management Protocol (SNMP) or 844 NETCONF. As explained for instance in [RFC7491], the NMS and OSS 845 can be consumers of network events reported and can act on these 846 reports as well as displaying them to users and raising alarms. 847 The NMS and OSS can also access the Traffic Engineering Database 848 (TED) and Label Switched Path Database (LSP-DB) to show the users 849 the current state of the network. In addition, NMS and OSS 850 systems may have access to IGP/BGP routing information, network 851 inventory data (e.g., links, nodes, or link properties not visible 852 to routing protocols, such as Shared Risk Link Groups), statistics 853 collection system that provides traffic information, such as 854 traffic demands or link utilization obtained from IP Flow 855 Information Export (IPFIX), as well as other Operations, 856 Administration, and Maintenance (OAM) information (e.g., syslog). 857 NMS or OSS systems also may have functions to correlate and 858 orchestrate information originating from other data sources. For 859 instance, it could be required to correlate IP prefixes with 860 routers (Provider, Provider Edge, Customer Edge, etc.), IGP areas, 861 VLAN IDs, or policies. 863 3.2.2. Privacy Requirements 865 Providing ALTO guidance can result in a win-win situation both for 866 network providers and users of the ALTO information. Applications 867 possibly get a better performance, while the network provider has 868 means to optimize the traffic engineering and thus its costs. Yet, 869 there can be security concerns with exposing topology data. 870 Corresponding limitations are discussed in Section 7.2. 872 ISPs may have important privacy requirements when deploying ALTO. In 873 particular, an ISP may not be willing to expose sensitive operational 874 details of its network. The topology abstraction of ALTO enables an 875 ISP to expose the network topology at a desired granularity only, 876 determined by security policies. 878 With the Endpoint Cost Service (ECS), the ALTO client does not to 879 have to implement any specific algorithm or mechanism in order to 880 retrieve, maintain and process network topology information (of any 881 kind). The complexity of the network topology (computation, 882 maintenance and distribution) is kept in the ALTO server and ECS is 883 delivered on demand. This allows the ALTO server to enhance and 884 modify the way the topology information sources are used and 885 combined. This simplifies the enforcement of privacy policies of the 886 ISP. 888 The ALTO Network Map and Cost Map service expose an abstracted view 889 on the ISP network topology. Therefore, in this case care is needed 890 when constructing those maps in order to take into account privacy 891 policies, as further discussed in Section 3.2.3. The ALTO protocol 892 also supports further features such as endpoint properties, which 893 could also be used to expose topology guidance. The privacy 894 considerations for ALTO maps also apply to such ALTO extensions. 896 3.2.3. Partitioning and Grouping of IP Address Ranges 898 ALTO introduces provider-defined network location identifiers called 899 Provider-defined Identifiers (PIDs) to aggregate network endpoints in 900 the Map Services. Endpoints within one PID may be treated as single 901 entity, assuming proximity based on network topology or other 902 similarity. A key use case of PIDs is to specify network preferences 903 (costs) between PIDs instead of individual endpoints. It is up to 904 the operator of the ALTO server how to group endpoints and how to 905 assign PIDs. For example, a PID may denote a subnet, a set of 906 subnets, a metropolitan area, a POP, an autonomous system, or a set 907 of autonomous systems. 909 This document only considers deployment scenarios in which PIDs 910 expand to a set of IP address ranges (CIDR). A PID is characterized 911 by a string identifier and its associated set of endpoint addresses 912 [RFC7285]. If an ALTO server offers the Map Service, corresponding 913 identifiers have to be configured. 915 An automated ALTO implementation may use dynamic algorithms to 916 aggregate network topology. However, it is often desirable to have a 917 mechanism through which the network operator can control the level 918 and details of network aggregation based on a set of requirements and 919 constraints. This will typically be governed by policies that 920 enforce a certain level of abstraction and prevent leakage of 921 sensitive operational data. 923 For instance, an ALTO server may leverage BGP information that is 924 available in a networks service provider network layer and compute 925 the group of prefix. An example are BGP communities, which are used 926 in MPLS/IP networks as a common mechanism to aggregate and group 927 prefixes. A BGP community is an attribute used to tag a prefix to 928 group prefixes based on mostly any criteria (as an example, most ISP 929 networks originate BGP prefixes with communities identifying the 930 Point of Presence (PoP) where the prefix has been originated). These 931 BGP communities could be used to map IP address ranges to PIDs. By 932 an additional policy, the ALTO server operator may decide an 933 arbitrary cost defined between groups. Alternatively, there are 934 algorithms that allow the dynamic computation of costs between 935 groups. The ALTO protocol itself is independent of such algorithms 936 and policies. 938 3.2.4. Rating Criteria and/or Cost Calculation 940 An ALTO server indicates preferences amongst network locations in the 941 form of path costs. Path costs are generic costs and can be 942 internally computed by the operator of the ALTO server according to 943 its own policy. For a given ALTO network map, an ALTO cost map 944 defines directional path costs pairwise amongst the set of source and 945 destination network locations defined by the PIDs. 947 The ALTO protocol permits the use of different cost types. An ALTO 948 cost type is defined by the combination of a cost metric and a cost 949 mode. The cost metric identifies what the costs represent. The cost 950 mode identifies how the costs should be interpreted, e.g., whether 951 returned costs should be interpreted as numerical values or ordinal 952 rankings. The ALTO protocol also allows the definition of additional 953 constraints defining which elements of a cost map shall be returned. 955 The ALTO protocol specification [RFC7285] defines the "routingcost" 956 cost metric as basic set of rating criteria, which has to be 957 supported by all implementations. This cost metric conveys a generic 958 measure for the cost of routing traffic from a source to a 959 destination. A lower value indicates a higher preference for traffic 960 to be sent from a source to a destination. It is up to the ALTO 961 server how that metric is calculated. 963 There is also an extension procedure for adding new ALTO cost types. 964 The following list gives an overview on further rating criteria that 965 have been proposed or which are in use by ALTO-related prototype 966 implementations. This list is not intended as normative text; a 967 definition of further metrics can be found for instance in 968 [I-D.wu-alto-te-metrics]. Instead, the only purpose of the following 969 list is to document and discuss rating criteria that have been 970 proposed so far. It can also depend on the use case of ALTO whether 971 such rating criteria are useful, and whether the corresponding 972 information would indeed be made available by ISPs. 974 Distance-related rating criteria: 976 o Relative topological distance: The term relative means that a 977 larger numerical value means greater distance, but it is up to the 978 ALTO service how to compute the values, and the ALTO client will 979 not be informed about the nature of the information. One way of 980 generating this kind of information may be counting AS hops, but 981 when querying this parameter, the ALTO client must not assume that 982 the numbers actually are AS hops. In addition to the AS path, a 983 relative cost value could also be calculated taking into account 984 other routing protocol parameters, such as BGP local preference or 985 multi-exit discriminator (MED) attributes. 987 o Absolute topological distance, expressed in the number of 988 traversed autonomous systems (AS). 990 o Absolute topological distance, expressed in the number of router 991 hops (i.e., how much the TTL value of an IP packet will be 992 decreased during transit). 994 o Absolute physical distance, based on knowledge of the approximate 995 geo-location (e.g., continent, country) of an IP address. 997 Performance-related rating criteria: 999 o The minimum achievable throughput between the resource consumer 1000 and the candidate resource provider, which is considered useful by 1001 the application (only in ALTO queries). 1003 o An arbitrary upper bound for the throughput from/to the candidate 1004 resource provider (only in ALTO responses). This may be, but is 1005 not necessarily the provisioned access bandwidth of the candidate 1006 resource provider. 1008 o The maximum round-trip time (RTT) between resource consumer and 1009 the candidate resource provider, which is acceptable for the 1010 application for useful communication with the candidate resource 1011 provider (only in ALTO queries). 1013 o An arbitrary lower bound for the RTT between resource consumer and 1014 the candidate resource provider (only in ALTO responses). This 1015 may be, for example, based on measurements of the propagation 1016 delay in a completely unloaded network. 1018 Charging-related rating criteria: 1020 o Traffic volume caps, in case the Internet access of the resource 1021 consumer is not charged by "flat rate". For each candidate 1022 resource provider, the ALTO service could indicate the amount of 1023 data that may be transferred from/to this resource provider until 1024 a given point in time, and how much of this amount has already 1025 been consumed. Furthermore, it would have to be indicated how 1026 excess traffic would be handled (e.g., blocked, throttled, or 1027 charged separately at an indicated price). The interaction of 1028 several applications running on a host, out of which some use this 1029 criterion while others don't, as well as the evaluation of this 1030 criterion in resource directories, which issue ALTO queries on 1031 behalf of other endpoints, are for further study. 1033 o Other metrics representing an abstract cost, e.g., determined by 1034 policies that distinguish "cheap" from "expensive" IP subnet 1035 ranges without detailing the cost function. 1037 These rating criteria are subject to the remarks below: 1039 The ALTO client must be aware that with high probability the actual 1040 performance values will differ from whatever an ALTO server exposes. 1041 In particular, an ALTO client must not consider a throughput 1042 parameter as a permission to send data at the indicated rate without 1043 using congestion control mechanisms. 1045 The discrepancies are due to various reasons, including, but not 1046 limited to the facts that 1048 o the ALTO service is not an admission control system 1050 o the ALTO service may not know the instantaneous congestion status 1051 of the network 1053 o the ALTO service may not know all link bandwidths, i.e., where the 1054 bottleneck really is, and there may be shared bottlenecks 1056 o the ALTO service may not have all information about the actual 1057 routing 1059 o the ALTO service may not know whether the candidate endpoint 1060 itself is overloaded 1062 o the ALTO service may not know whether the candidate endpoint 1063 throttles the bandwidth it devotes for the considered application 1065 o the ALTO service may not know whether the candidate endpoint will 1066 throttle the data it sends to the client (e.g., because of some 1067 fairness algorithm, such as tit-for-tat). 1069 Because of these inaccuracies and the lack of complete, instantaneous 1070 state information, which are inherent to the ALTO service, the 1071 application must use other mechanisms (such as passive measurements 1072 on actual data transmissions) to assess the currently achievable 1073 throughput, and it must use appropriate congestion control mechanisms 1074 in order to avoid a congestion collapse. Nevertheless, the rating 1075 criteria may provide a useful shortcut for quickly excluding 1076 candidate resource providers from such probing, if it is known in 1077 advance that connectivity is in any case worse than what is 1078 considered the minimum useful value by the respective application. 1080 Rating criteria that should not be defined for and used by the ALTO 1081 service include: 1083 o Performance metrics that are closely related to the instantaneous 1084 congestion status. The definition of alternate approaches for 1085 congestion control is explicitly out of the scope of ALTO. 1086 Instead, other appropriate means, such as using TCP based 1087 transport, have to be used to avoid congestion. 1089 o Performance metrics that raise privacy concerns. For instance, it 1090 has been questioned whether an ALTO service could publicly expose 1091 the provisioned access bandwidth, e.g. of cable / DSL customers, 1092 because this could enables identification of "premium" customers. 1094 3.3. Known Limitations of ALTO 1096 3.3.1. General Limitations 1098 ALTO is designed as a protocol between clients integrated in 1099 applications and servers that provide network information and 1100 guidance (e.g., basic network location structure and preferences of 1101 network paths). The objective is to modify network resource 1102 consumption patterns at application level while maintaining or 1103 improving application performance. This design focus results in a 1104 number of characteristics of ALTO: 1106 o Endpoint focus: In typical ALTO use cases, neither the consumer of 1107 the topology information (i.e., the ALTO client) nor the 1108 considered resources (e.g., files at endpoints) are part of the 1109 network. The ALTO server presents an abstract network topology 1110 containing only information relevant to an application overlay for 1111 better-than-random resource provider selection among its 1112 endpoints. The ALTO protocol specification [RFC7285] is not 1113 designed to expose network internals such as routing tables or 1114 configuration data that are not relevant for application-level 1115 resource provider selection decisions in network endpoints. 1117 o Abstraction: The ALTO services such as the Network/Cost Map 1118 Service or the ECS provide an abstract view of the network only. 1119 The operator of the ALTO server has full control over the 1120 granularity (e.g., by defining policies how to aggregate subnets 1121 into PIDs) and the level-of-detail of the abstract network 1122 representation (e.g., by deciding what cost types to support). 1124 o Multiple administrative domains: The ALTO protocol is designed for 1125 use cases where the ALTO server and client can be located in 1126 different organizations or trust domains. ALTO assumes a loose 1127 coupling between server and client. In addition, ALTO does not 1128 assume that an ALTO client has any a priori knowledge about the 1129 ALTO server and its supported features. An ALTO server can be 1130 discovered automatically. 1132 o Read-only: ALTO is a query/response protocol to retrieve guidance 1133 information. Neither network/cost map queries nor queries to the 1134 endpoint cost service are designed to affect state in the network. 1136 If ALTO shall be deployed for use cases violating these assumptions, 1137 the protocol design may result in limitations. 1139 For instance, in an Application-Based Network Operation (ABNO) 1140 environment the application could issue explicit service request to 1141 the network [RFC7491]. In this case, the application would require 1142 detailed knowledge about the internal network topology and the actual 1143 state. A network configuration would also require a corresponding 1144 security solution for authentication and authorization. ALTO is not 1145 designed for operations to control, operate, and manage a network. 1147 Such deployments could be addressed by network management solutions, 1148 e.g., based on SNMP [RFC3411] or NETCONF [RFC6241] and YANG [RFC6020] 1149 that are typically designed to manipulate configuration state. 1150 Reference [RFC7491] contains a more detailed discussion of interfaces 1151 between components such as Element Management System (EMS), Network 1152 Management System (NMS), Operations Support System (OSS), Traffic 1153 Engineering Database (TED), Label Switched Path Database (LSP-DB), 1154 Path Computation Element (PCE), and other Operations, Administration, 1155 and Maintenance (OAM) components. 1157 3.3.2. Limitations of Map-based Approaches 1159 The specification of the Map Service in the ALTO protocol [RFC7285] 1160 is based on the concept of network maps. A network map partitions 1161 the network into Provider-defined Identifiers (PIDs) that group one 1162 or more endpoints (e.g., subnetworks) to a single aggregate. The 1163 "costs" between the various PIDs are stored in a cost map. Map-based 1164 approaches lower the signaling load on the server as maps have to be 1165 retrieved only if they change. 1167 One main assumption for map-based approaches is that the information 1168 provided in these maps is static for a long period of time. This 1169 assumption is fine as long as the network operator does not change 1170 any parameter, e.g., routing within the network and to the upstream 1171 peers, IP address assignment stays stable (and thus the mapping to 1172 the partitions). However, there are several cases where this 1173 assumption is not valid: 1175 1. ISPs reallocate IP subnets from time to time; 1177 2. ISPs reallocate IP subnets on short notice; 1179 3. IP prefix blocks may be assigned to a router that serves a 1180 variety of access networks; 1182 4. Network costs between IP prefixes may change depending on the 1183 ISP's routing and traffic engineering. 1185 These effects can be explained as follows: 1187 Case 1: ISPs may reallocate IP subnets within their infrastructure 1188 from time to time, partly to ensure the efficient usage of IPv4 1189 addresses (a scarce resource), and partly to enable efficient route 1190 tables within their network routers. The frequency of these 1191 "renumbering events" depend on the growth in number of subscribers 1192 and the availability of address space within the ISP. As a result, a 1193 subscriber's household device could retain an IP address for as short 1194 as a few minutes, or for months at a time or even longer. 1196 It has been suggested that ISPs providing ALTO services could sub- 1197 divide their subscribers' devices into different IP subnets (or 1198 certain IP address ranges) based on the purchased service tier, as 1199 well as based on the location in the network topology. The problem 1200 is that this sub-allocation of IP subnets tends to decrease the 1201 efficiency of IP address allocation, in particular for IPv4. A 1202 growing ISP that needs to maintain high efficiency of IP address 1203 utilization may be reluctant to jeopardize their future acquisition 1204 of IP address space. 1206 However, this is not an issue for map-based approaches if changes are 1207 applied in the order of days. 1209 Case 2: ISPs can use techniques that allow the reallocation of IP 1210 prefixes on very short notice, i.e., within minutes. An IP prefix 1211 that has no IP address assignment to a host anymore can be 1212 reallocated to areas where there is currently a high demand for IP 1213 addresses. 1215 Case 3: In residential access networks (e.g., DSL, cable), IP 1216 prefixes are assigned to broadband gateways, which are the first IP- 1217 hop in the access-network between the Customer Premises Equipment 1218 (CPE) and the Internet. The access-network between CPE and broadband 1219 gateway (called aggregation network) can have varying characteristics 1220 (and thus associated costs), but still using the same IP prefix. For 1221 instance one IP address IP1 out of a given CIDR prefix can be 1222 assigned to a VDSL access line (e.g., 2 MBit/s uplink) while another 1223 IP address IP2 within the same given CIDR prefix is assigned to a 1224 slow ADSL line (e.g., 128 kbit/s uplink). These IP addresses may be 1225 assigned on a first come first served basis, i.e., a single IP 1226 address out of the same CIDR prefix can change its associated costs 1227 quite fast. This may not be an issue with respect to the used 1228 upstream provider (thus the cross ISP traffic) but depending on the 1229 capacity of the aggregation-network this may raise to an issue. 1231 Case 4: The routing and traffic engineering inside an ISP network, as 1232 well as the peering with other autonomous systems, can change 1233 dynamically and affect the information exposed by an ALTO server. As 1234 a result, cost maps and possibly also network maps can change. 1236 3.3.3. Limitations of Non-Map-based Approaches 1238 The specification of the ALTO protocol [RFC7285] also includes the 1239 Endpoint Cost Service (ECS) mechanism. ALTO clients can ask the ALTO 1240 server for guidance for specific IP addresses, thereby avoiding the 1241 need of processing maps. This can mitigate some of the problems 1242 mentioned in the previous section. 1244 However frequent requests, particularly with long lists of IP 1245 addresses, may overload the ALTO server. The server has to rank each 1246 received IP address, which causes load at the server. This may be 1247 amplified when not only a single ALTO client is asking for guidance, 1248 but a larger number of them. The results of the ECS are also more 1249 difficult to cache than ALTO maps. Therefore, the ALTO client may 1250 have to await the server response before starting a communication, 1251 which results in an additional delay. 1253 Caching of IP addresses at the ALTO client or the usage of the H12 1254 approach [I-D.kiesel-alto-h12] in conjunction with caching may lower 1255 the query load on the ALTO server. 1257 When ALTO server receives an ECS request, it may not have the most 1258 appropriate topology information in order to accurately determine the 1259 ranking. [RFC7285] generally assumes that a server can always offer 1260 some guidance. In such a case the ALTO server could adopt one of the 1261 following strategies: 1263 o Reply with available information (best effort). 1265 o Query another ALTO server presumed to have better topology 1266 information and return that response (cascaded servers). 1268 o Redirect the request to another ALTO server presumed to have 1269 better topology information (redirection). 1271 The protocol mechanisms and decision processes that would be used to 1272 determine if redirection is necessary and which mode to use is out of 1273 the scope of this document, since protocol extensions could be 1274 required. 1276 3.4. Monitoring ALTO 1278 3.4.1. Impact and Observation on Network Operation 1280 ALTO presents a new opportunity for managing network traffic by 1281 providing additional information to clients. In particular, the 1282 deployment of an ALTO server may shift network traffic patterns, and 1283 the potential impact to network operation can be large. An ISP 1284 providing ALTO may want to assess the benefits of ALTO as part of the 1285 management and operations (cf. [RFC7285]). For instance, the ISP 1286 might be interested in understanding whether the provided ALTO maps 1287 are effective, and in order to decide whether an adjustment of the 1288 ALTO configuration would be useful. Such insight can be obtained 1289 from a monitoring infrastructure. An ISP offering ALTO could 1290 consider the impact on (or integration with) traffic engineering and 1291 the deployment of a monitoring service to observe the effects of ALTO 1292 operations. The measurement of impacts can be challenging because 1293 ALTO-enabled applications may not provide related information back to 1294 the ALTO service provider. 1296 To construct an effective monitoring infrastructure, the ALTO service 1297 provider should decide how to monitor the performance of ALTO and 1298 identify and deploy data sources to collect data to compute the 1299 performance metrics. In certain trusted deployment environments, it 1300 may be possible to collect information directly from ALTO clients. 1301 It may also be possible to vary or selectively disable ALTO guidance 1302 for a portion of ALTO clients either by time, geographical region, or 1303 some other criteria to compare the network traffic characteristics 1304 with and without ALTO. Monitoring an ALTO service could also be 1305 realized by third parties. In this case, insight into ALTO data may 1306 require a trust relationship between the monitoring system operator 1307 and the network service provider offering an ALTO service. 1309 The required monitoring depends on the network infrastructure and the 1310 use of ALTO, and an exhaustive description is outside the scope of 1311 this document. 1313 3.4.2. Measurement of the Impact 1315 ALTO realizes an interface between the network and applications. 1316 This implies that an effective monitoring infrastructure may have to 1317 deal with both network and application performance metrics. This 1318 document does not comprehensively list all performance metrics that 1319 could be relevant, nor does it formally specify metrics. 1321 The impact of ALTO can be classified regarding a number of different 1322 criteria: 1324 o Total amount and distribution of traffic: ALTO enables ISPs to 1325 influence and localize traffic of applications that use the ALTO 1326 service. An ISP may therefore be interested in analyzing the 1327 impact on the traffic, i.e., whether network traffic patterns are 1328 shifted. For instance, if ALTO shall be used to reduce the inter- 1329 domain P2P traffic, it makes sense to evaluate the total amount of 1330 inter-domain traffic of an ISP. Then, one possibility is to study 1331 how the introduction of ALTO reduces the total inter-domain 1332 traffic (inbound and/our outbound). If the ISPs intention is to 1333 localize the traffic inside his network, the network-internal 1334 traffic distribution will be of interest. Effectiveness of 1335 localization can be quantified in different ways, e.g., by the 1336 load on core routers and backbone links, or by considering more 1337 advanced effects, such as the average number of hops that traffic 1338 traverses inside a domain. 1340 o Application performance: The objective of ALTO is improve 1341 application performance. ALTO can be used by very different types 1342 applications, with different communication characteristics and 1343 requirements. For instance, if ALTO guidance achieves traffic 1344 localization, one would expect that applications achieve a higher 1345 throughput and/or smaller delays to retrieve data. If 1346 application-specific performance characteristics (e.g., video or 1347 audio quality) can be monitored, such metrics related to user 1348 experience could also help to analyze the benefit of an ALTO 1349 deployment. If available, selected statistics from the TCP/IP 1350 stack in hosts could be leveraged, too. 1352 Of potential interest can also be the share of applications or 1353 customers that actually use an offered ALTO service, i.e., the 1354 adoption of the service. 1356 Monitoring statistics can be aggregated, averaged, and normalized in 1357 different ways. This document does not mandate specific ways how to 1358 calculate metrics. 1360 3.4.3. System and Service Performance 1362 A number of interesting parameters can be measured at the ALTO 1363 server. [RFC7285] suggests certain ALTO-specific metrics to be 1364 monitored: 1366 o Requests and responses for each service listed in a Information 1367 Directory (total counts and size in bytes). 1369 o CPU and memory utilization 1371 o ALTO map updates 1373 o Number of PIDs 1375 o ALTO map sizes (in-memory size, encoded size, number of entries) 1377 This data characterizes the workload, the system performance as well 1378 as the map data. Obviously, such data will depend on the 1379 implementation and the actual deployment of the ALTO service. 1380 Logging is also recommended in [RFC7285]. 1382 3.4.4. Monitoring Infrastructures 1384 Understanding the impact of ALTO may require interaction between 1385 different systems, operating at different layers. Some information 1386 discussed in the preceding sections is only visible to an ISP, while 1387 application-level performance can hardly be measured inside the 1388 network. It is possible that not all information of potential 1389 interest can directly be measured, either because no corresponding 1390 monitoring infrastructure or measurement method exists, or because it 1391 is not easily accessible. 1393 One way to quantify the benefit of deploying ALTO is to measure 1394 before and after enabling the ALTO service. In addition to passive 1395 monitoring, some data could also be obtained by active measurements, 1396 but due to the resulting overhead, the latter should be used with 1397 care. Yet, in all monitoring activities an ALTO service provider has 1398 to take into account that ALTO clients are not bound to ALTO server 1399 guidance as ALTO is only one source of information, and any 1400 measurement result may thus be biased. 1402 Potential sources for monitoring the use of ALTO include: 1404 o Network Operations, Administration, and Maintenance (OAM) systems: 1405 Many ISPs deploy OAM systems to monitor the network traffic, which 1406 may have insight into traffic volumes, network topology, and 1407 bandwidth information inside the management area. Data can be 1408 obtained by SNMP, NETCONF, IP Flow Information Export (IPFIX), 1409 syslog, etc. 1411 o Applications/clients: Relevant data could be obtained by 1412 instrumentation of applications. 1414 o ALTO server: If available, log files or other statistics data 1415 could be analyzed. 1417 o Other application entities: In several use cases, there are other 1418 application entities that could provide data as well. For 1419 instance, there may be centralized log servers that collect data. 1421 In many ALTO use cases some data sources are located within an ISP 1422 network while some other data is gathered at application level. 1423 Correlation of data could require a collaboration agreement between 1424 the ISP and an application owner, including agreements of data 1425 interchange formats, methods of delivery, etc. In practice, such a 1426 collaboration may not be possible in all use cases of ALTO, because 1427 the monitoring data can be sensitive, and because the interacting 1428 entities may have different priorities. Details of how to build an 1429 over-arching monitoring system for evaluating the benefits of ALTO 1430 are outside the scope of this memo. 1432 3.5. Map Examples for Different Types of ISPs 1434 3.5.1. Small ISP with Single Internet Uplink 1436 The ALTO protocol does not mandate how to determine costs between 1437 endpoints and/or determine map data. In complex usage scenarios this 1438 can be a non-trivial problem. In order to show the basic principle, 1439 this and the following sections explain for different deployment 1440 scenarios how ALTO maps could be structured. 1442 For a small ISP, the inter-domain traffic optimizing problem is how 1443 to decrease the traffic exchanged with other ISPs, because of high 1444 settlement costs. By using the ALTO service to optimize traffic, a 1445 small ISP can define two "optimization areas": one is its own 1446 network; the other one consists of all other network destinations. 1447 The cost map can be defined as follows: the cost of a link between 1448 clients of the inner ISP's network is lower than between clients of 1449 the outer ISP's network and clients of inner ISP's network. As a 1450 result, a host with an ALTO client inside the network of this ISP 1451 will prefer retrieving data from hosts connected to the same ISP. 1453 An example is given in Figure 9. It is assumed that ISP A is a small 1454 ISP only having one access network. As operator of the ALTO service, 1455 ISP A can define its network to be one optimization area, named as 1456 PID1, and define other networks to be the other optimization area, 1457 named as PID2. C1 is denoted as the cost inside the network of ISP 1458 A. C2 is denoted as the cost from PID2 to PID1, and C3 from PID1 to 1459 PID2. For the sake of simplicity, in the following C2=C3 is assumed. 1460 In order to keep traffic local inside ISP A, it makes sense to 1461 define: C1| | 1471 | | C3 (=C2) \\\\ //// 1472 \\ // \-----------/ 1473 \\ // 1474 \\\\ //// 1475 ----------- 1477 Figure 9: Example ALTO deployment in small ISPs 1479 A simplified extract of the corresponding ALTO network and cost maps 1480 is listed in Figure 10 and Figure 11, assuming that the network of 1481 ISP A has the IPv4 address ranges 192.0.2.0/24 and 198.51.100.0/25. 1482 In this example, the cost values C1 and C2 can be set to any number 1483 C1|PID 2 |<--->+PID 3 | | 1594 | |C1 | |C2 | |C3 | | +----------------+ 1595 | +---+--+ +------+ +--+---+ | | | 1596 | ^ ^ | C8 | Other Networks | 1597 | | | |<--------+ PID 5 | 1598 | +------------------------+ | | | 1599 | C6 | | | 1600 +------------------------------------+ +----------------+ 1602 Figure 12: ALTO deployment in large ISPs with layered fixed network 1603 structures 1605 3.5.3. ISP with Fixed and Mobile Network 1607 An ISP with both mobile network and fixed network may focus on 1608 optimizing the mobile traffic by keeping traffic in the fixed network 1609 as much as possible, because wireless bandwidth is a scarce resource 1610 and traffic is costly in mobile network. In such a case, the main 1611 requirement of traffic optimization could be decreasing the usage of 1612 radio resources in the mobile network. An ALTO service can be 1613 deployed to meet these needs. 1615 Figure 13 shows an example: ISP A operates one mobile network, which 1616 is connected to a backbone network. The ISP also runs two fixed 1617 access networks AN A and AN B, which are also connected to the 1618 backbone network. In this network structure, the mobile network can 1619 be defined as one optimization area, and PID 1 can be assigned to it. 1620 Access networks AN A and B can also be defined as optimization areas, 1621 and PID 2 and PID 3 can be assigned, respectively. The cost values 1622 are then defined as shown in Figure 13. 1624 To decrease the usage of wireless link, the relationship of these 1625 costs can be defined as follows: 1627 From view of mobile network: C4 < C1. This means that clients in 1628 mobile network requiring data resources from other clients will 1629 prefer clients in AN A to clients in the mobile network. This policy 1630 can decrease the usage of wireless link and power consumption in 1631 terminals. 1633 From view of AN A: C2 < C6, C5 = maximum cost. This means that 1634 clients in other optimization area will avoid retrieving data from 1635 the mobile network. 1637 +-----------------------------------------------------------------+ 1638 | | 1639 | ISP A +-------------+ | 1640 | +--------+ ALTO +---------+ | 1641 | | | Service | | | 1642 | | +------+------+ | | 1643 | | | | | 1644 | | | | | 1645 | | | | | 1646 | +-------+-------+ | C6 +--------+------+ | 1647 | | AN A |<--------------| AN B | | 1648 | | PID 2 | C7 | | PID 3 | | 1649 | | C2 |-------------->| C3 | | 1650 | +---------------+ | +---------------+ | 1651 | ^ | | | ^ | 1652 | | | | | | | 1653 | | |C4 | | | | 1654 | C5 | | | | | | 1655 | | | +--------+---------+ | | | 1656 | | +-->| Mobile Network |<---+ | | 1657 | | | PID 1 | | | 1658 | +------- | C1 |----------+ | 1659 | +------------------+ | 1660 +-----------------------------------------------------------------+ 1662 Figure 13: ALTO deployment in ISPs with mobile network 1664 These examples show that for ALTO in particular the relationships 1665 between different costs matter; the operator of the server has 1666 several degrees of freedom how to set the absolute values. 1668 3.6. Deployment Experiences 1670 The examples in the previous section are simple and do not consider 1671 specific requirements inside access networks, such as different link 1672 types. Deploying an ALTO service in a real network may require 1673 dealing with additional network conditions and requirements. One 1674 real example is described in greater detail in reference 1675 [I-D.lee-alto-chinatelecom-trial]. 1677 Also, experiments have been conducted with ALTO-like deployments in 1678 Internet Service Provider (ISP) networks. For instance, NTT 1679 performed tests with their HINT server implementation and dummy nodes 1680 to gain insight on how an ALTO-like service can influence peer-to- 1681 peer systems [RFC6875]. The results of an early experiment conducted 1682 in the Comcast network are documented in [RFC5632]. 1684 4. Using ALTO for P2P Traffic Optimization 1686 4.1. Overview 1688 4.1.1. Usage Scenario 1690 Originally, peer-to-peer (P2P) applications were the main driver for 1691 the development of ALTO. In this use case it is assumed that one 1692 party (usually the operator of a "managed" IP network domain) will 1693 disclose information about the network through ALTO. The application 1694 overlay will query this information and optimize its behavior in 1695 order to improve performance or Quality of Experience in the 1696 application while reducing the utilization of the underlying network 1697 infrastructure. The resulting win-win situation is assumed to be the 1698 incentive for both parties to provide or consume the ALTO 1699 information, respectively. 1701 P2P systems can be built without or with use of a centralized 1702 resource directory ("tracker"). The scope of this section is the 1703 interaction of P2P applications with the ALTO service. In this 1704 scenario, the resource consumer ("peer") asks the resource directory 1705 for a list of candidates that can provide the desired resource. 1706 There are different options for how ALTO can be deployed in such use 1707 cases with a centralized resource directory. 1709 For efficiency reasons (i.e., message size), usually only a subset of 1710 all resource providers known to the resource directory will be 1711 returned to the resource consumer. Some or all of these resource 1712 providers, plus further resource providers learned by other means 1713 such as direct communication between peers, will be contacted by the 1714 resource consumer for accessing the resource. The purpose of ALTO is 1715 giving guidance on this peer selection, which is supposed to yield 1716 better-than-random results. The tracker response as well as the ALTO 1717 guidance are most beneficial in the initial phase after the resource 1718 consumer has decided to access a resource, as long as only few 1719 resource providers are known. Later, when the resource consumer has 1720 already exchanged some data with other peers and measured the 1721 transmission speed, the relative importance of ALTO may dwindle. 1723 4.1.2. Applicability of ALTO 1725 A tracker-based P2P application can leverage ALTO in different ways. 1726 In the following, the different alternatives and their pros and cons 1727 are discussed. 1729 ,-------. +-----------+ 1730 ,---. ,-' ========>| Peer 1 |******** 1731 ,-' `-. / ISP 1 V \ |ALTO Client| * 1732 / \ / +-------------+ \ +-----------+ * 1733 / ISP X \ | + ALTO Server | | +-----------+ * 1734 / \ \ +-------------+<====>| Peer 2 | * 1735 ; +---------+ : \ / |ALTO Client|****** * 1736 | | Global | | `-. ,-' +-----------+ * * 1737 | | Tracker | | `-------' * * 1738 | +---------+ | ,-------. +-----------+ * * 1739 : * ; ,-' ========>| Peer 3 | * * 1740 \ * / / ISP 2 V \ |ALTO Client|**** * * 1741 \ * / / +-------------+ \ +-----------+ * * * 1742 \ * / | | ALTO Server | | +-----------+ * * * 1743 `-. * ,-' \ +-------------+<====>| Peer 4 |** * * * 1744 `-*-' \ / |ALTO Client| * * * * 1745 * `-. ,-' +-----------+ * * * * 1746 * `-------' * * * * 1747 * * * * * 1748 ******************************************************* 1749 Legend: 1750 === ALTO protocol 1751 *** Application protocol 1753 Figure 14: Global tracker and local ALTO servers 1755 Figure 14 depicts a tracker-based P2P system with several peers. The 1756 peers (i.e., resource consumers) embed an ALTO client to improve the 1757 resource provider selection. The tracker (i.e., resource directory) 1758 itself may be hosted and operated by another entity. A tracker 1759 outside the networks of the ISPs of the peers may be a typical use 1760 case. For instance, a tracker like Pirate Bay can serve Bittorrent 1761 peers world-wide. The figure only shows one tracker instance, but 1762 deployments with several trackers could be possible, too. 1764 The scenario depicted in Figure 14 lets the peers directly 1765 communicate with their ISP's ALTO server (i.e., ALTO client embedded 1766 in the peers), thus giving the peers the most control on which 1767 information they query for, as they can integrate information 1768 received from one tracker or several trackers and through direct 1769 peer-to-peer knowledge exchange. For instance, the latter approach 1770 is called peer exchange (PEX) in bittorent. In this deployment 1771 scenarios, the peers have to discover a suitable ALTO server (e.g., 1772 offered by their ISP, as described in [RFC7286]). 1774 There are also tracker-less P2P system architectures that do not rely 1775 on centralized resource directories, e.g., unstructured P2P networks. 1776 Regarding the use of ALTO, their deployment would be similar to 1777 Figure 14, since the ALTO client would be embedded in the peers as 1778 well. This option is not further considered in this memo. 1780 ,-------. 1781 ,---. ,-' `-. +-----------+ 1782 ,-' `-. / ISP 1 \ | Peer 1 |******** 1783 / \ / +-------------+ \ | | * 1784 / ISP X \ ++====>| ALTO Server | )+-----------+ * 1785 / \ || \ +-------------+ / +-----------+ * 1786 ; +-----------+ : || \ / | Peer 2 | * 1787 | | Tracker |<====++ `-. ,-' | |****** * 1788 | |ALTO Client| | `-------' +-----------+ * * 1789 | +-----------+<====++ ,-------. * * 1790 : * ; || ,-' `-. +-----------+ * * 1791 \ * / || / ISP 2 \ | Peer 3 | * * 1792 \ * / || / +-------------+ \ | |**** * * 1793 \ * / ++====>| ALTO Server | )+-----------+ * * * 1794 `-. * ,-' \ +-------------+ / +-----------+ * * * 1795 `-*-' \ / | Peer 4 |** * * * 1796 * `-. ,-' | | * * * * 1797 * `-------' +-----------+ * * * * 1798 * * * * * 1799 * * * * * 1800 ********************************************************* 1801 Legend: 1802 === ALTO protocol 1803 *** Application protocol 1805 Figure 15: Global tracker accessing ALTO server at various ISPs 1807 An alternative deployment scenario for a tracker-based system is 1808 depicted in Figure 15. Here, the tracker embeds the ALTO client. As 1809 already explained, the tracker itself may be hosted and operated by 1810 an entity different than the ISP hosting and operating the ALTO 1811 server. The key difference to the previously discussed use case is 1812 that the ALTO client is different from the resource consumer. 1813 Initially, the tracker has to discover the handling ALTO server for 1814 each new peer [RFC7286] [I-D.kiesel-alto-xdom-disc]. The peers do 1815 not query the ALTO servers themselves. This gives the peers a better 1816 initial selection of candidates, but does not consider peers learned 1817 through direct peer-to-peer knowledge exchange. 1819 ISP 1 ,-------. +-----------+ 1820 ,---. +-------------+******| Peer 1 | 1821 ,-' `-. /| Tracker |\ | | 1822 / \ / +-------------+**** +-----------+ 1823 / ISP X \ | === | * +-----------+ 1824 / \ \ +-------------+ / * | Peer 2 | 1825 ; +---------+ : \| AlTO Server |/ ***| | 1826 | | Global | | +-------------+ +-----------+ 1827 | | Tracker | | `-------' 1828 | +---------+ | +-----------+ 1829 : * ; ,-------. | Peer 3 | 1830 \ * / +-------------+ ****| | 1831 \ * / /| Tracker |*** +-----------+ 1832 \ * / / +-------------+ \ +-----------+ 1833 `-. * ,-' | === | | Peer 4 |** 1834 `-*-' \ +-------------+ / | | * 1835 * \| ALTO Server |/ +-----------+ * 1836 * +-------------+ * 1837 * ISP 2 `-------' * 1838 ************************************************* 1839 Legend: 1840 === ALTO protocol 1841 *** Application protocol 1843 Figure 16: Local trackers and local ALTO servers (P4P approach) 1845 There are some attempts to let ISPs deploy their own trackers, as 1846 shown in Figure 16. In this case, the client cannot get guidance 1847 from the ALTO server, other than by talking to the ISP's tracker. 1848 However, the peers would have still chance the contact other 1849 trackers, deployed by entities other than the peer's ISP. 1851 4.2. Deployment Recommendations 1853 4.2.1. ALTO Services 1855 The ALTO protocol specification [RFC7285] details how an ALTO client 1856 can query an ALTO server for guiding information and receive the 1857 corresponding replies. In case of peer-to-peer networks, two 1858 different ALTO services can be used: The Cost Map Service is often 1859 preferred as solution by peer-to-peer software implementors and 1860 users, since it avoids disclosing peer IP addresses to a centralized 1861 entity. Alternatively, network operators may have a preference for 1862 the Endpoint Cost Service (ECS), since it does not require exposure 1863 of the network topology. 1865 For actual use of ALTO in P2P applications, both software vendors and 1866 network operators have to agree which ALTO services to use. The ALTO 1867 protocol is flexible and supports both services. Note that for other 1868 use cases of ALTO, in particular in more controlled environments, 1869 both the Cost Map Service as well as Endpoint Cost Service might be 1870 feasible and it is more an engineering trade-off whether to use a 1871 map-based or query-based ALTO service. 1873 4.2.2. Guidance Considerations 1875 As explained in Section 4.1.2, for a tracker-based P2P application 1876 there are two fundamentally different possibilities where to place 1877 the ALTO client: 1879 1. ALTO client in the resource consumer ("peer") 1881 2. ALTO client in the resource directory ("tracker") 1883 Both approaches have advantages and drawbacks that have to be 1884 considered. If the ALTO client is in the resource consumer 1885 (Figure 14), a potentially very large number of clients has to be 1886 deployed. Instead, when using an ALTO client in the resource 1887 directory (Figure 15 and Figure 16), ostensibly peers do not have to 1888 directly query the ALTO server. In this case, an ALTO server could 1889 even not permit access to peers. 1891 However, it seems to be beneficial for all participants to let the 1892 peers directly query the ALTO server. Considering the plethora of 1893 different applications that could use ALTO, e.g. multiple tracker or 1894 non-tracker based P2P systems or other applications searching for 1895 relays, this renders the ALTO service more useful. The peers are 1896 also the single point having all operational knowledge to decide 1897 whether to use the ALTO guidance and how to use the ALTO guidance. 1898 For a given peer one can also expect that an ALTO server of the 1899 corresponding ISP provides useful guidance and can be discovered. 1901 Yet, ALTO clients in the resource consumer also have drawbacks 1902 compared to use in the resource directory. In the following, both 1903 scenarios are compared more in detail in order to explain the impact 1904 on ALTO guidance and the need for third-party ALTO queries. 1906 In the first scenario (see Figure 17), the peer (resource consumer) 1907 queries the tracker (resource directory) for the desired resource 1908 (F1). The resource directory returns a list of potential resource 1909 providers without considering ALTO (F2). It is then the duty of the 1910 resource consumer to invoke ALTO (F3/F4), in order to solicit 1911 guidance regarding this list. 1913 Peer w. ALTO cli. Tracker ALTO Server 1914 --------+-------- --------+-------- --------+-------- 1915 | F1 Tracker query | | 1916 |======================>| | 1917 | F2 Tracker reply | | 1918 |<======================| | 1919 | F3 ALTO protocol query | 1920 |---------------------------------------------->| 1921 | F4 ALTO protocol reply | 1922 |<----------------------------------------------| 1923 | | | 1925 ==== Application protocol (i.e., tracker-based P2P app protocol) 1926 ---- ALTO protocol 1928 Figure 17: Basic message sequence chart for resource consumer- 1929 initiated ALTO query 1931 In the second scenario (see Figure 18), the resource directory has an 1932 embedded ALTO client, which we will refer to as Resource Directory 1933 ALTO Client (RDAC) in this document. After receiving a query for a 1934 given resource (F1) the resource directory invokes the RDAC to 1935 evaluate all resource providers it knows (F2/F3). Then it returns a, 1936 possibly shortened, list containing the "best" resource providers to 1937 the resource consumer (F4). 1939 Peer Tracker w. RDAC ALTO Server 1940 --------+-------- --------+-------- --------+-------- 1941 | F1 Tracker query | | 1942 |======================>| | 1943 | | F2 ALTO cli. p. query | 1944 | |---------------------->| 1945 | | F3 ALTO cli. p. reply | 1946 | |<----------------------| 1947 | F4 Tracker reply | | 1948 |<======================| | 1949 | | | 1951 ==== Application protocol (i.e., tracker-based P2P app protocol) 1952 ---- ALTO protocol 1954 Figure 18: Basic message sequence chart for third-party ALTO query 1956 Note: The message sequences depicted in Figure 17 and Figure 18 may 1957 occur both in the target-aware and the target-independent query mode 1958 (cf. [RFC6708]). In the target-independent query mode no message 1959 exchange with the ALTO server might be needed after the tracker 1960 query, because the candidate resource providers could be evaluated 1961 using a locally cached "map", which has been retrieved from the ALTO 1962 server some time ago. 1964 The first approach has the following problem: While the resource 1965 directory might know thousands of peers taking part in a swarm, the 1966 list returned to the resource consumer is usually shortened for 1967 efficiency reasons. Therefore, the "best" (in the sense of ALTO) 1968 potential resource providers might not be contained in that list 1969 anymore, even before ALTO can consider them. 1971 Much better traffic optimization could be achieved if the tracker 1972 would evaluate all known peers using ALTO. This list would then 1973 include a significantly higher fraction of "good" peers. If the 1974 tracker returned "good" peers only, there might be a risk that the 1975 swarm might disconnect and split into several disjunct partitions. 1976 However, finding the right mix of ALTO-biased and random peer 1977 selection is out of the scope of this document. 1979 Therefore, from an overall optimization perspective, the second 1980 scenario with the ALTO client embedded in the resource directory is 1981 advantageous, because it is ensured that the addresses of the "best" 1982 resource providers are actually delivered to the resource consumer. 1983 An architectural implication of this insight is that the ALTO server 1984 discovery procedures must support third-party discovery. That is, as 1985 the tracker issues ALTO queries on behalf of the peer which contacted 1986 the tracker, the tracker must be able to discover an ALTO server that 1987 can give guidance suitable for that respective peer (see 1988 [I-D.kiesel-alto-xdom-disc]). 1990 In principle, a combined approach could also be possible. For 1991 instance, a tracker could use a coarse-grained "global" ALTO server 1992 to find the peers in the general vicinity of the requesting peer, 1993 while peers could use "local" ALTO servers for a more fine-grained 1994 guidance. Yet, there is no known deployment experience for such a 1995 combined approach. 1997 5. Using ALTO for CDNs 1999 5.1. Overview 2000 5.1.1. Usage Scenario 2002 This section briefly introduces the usage of ALTO for Content 2003 Delivery Networks (CDNs), as explained in 2004 [I-D.jenkins-alto-cdn-use-cases]. CDNs are used in the delivery of 2005 some Internet services (e.g. delivery of websites, software updates 2006 and video delivery) from a location closer to the location of the 2007 user. A CDN typically consists of a network of servers often 2008 attached to Internet Service Provider (ISP) networks. The point of 2009 attachment is often as close to content consumers and peering points 2010 as economically or operationally feasible in order to decrease 2011 traffic load on the ISP backbone and to provide better user 2012 experience measured by reduced latency and higher throughput. 2014 CDNs use several techniques to redirect a client to a server 2015 (surrogate). A request routing function within a CDN is responsible 2016 for receiving content requests from user agents, obtaining and 2017 maintaining necessary information about a set of candidate 2018 surrogates, and for selecting and redirecting the user agent to the 2019 appropriate surrogate. One common way is relying on the DNS system, 2020 but there are many other ways, see [RFC3568]. 2022 +--------------------+ 2023 | CDN Request Router | 2024 | with ALTO Client | 2025 +--------------------+ 2026 /\ 2027 || ALTO protocol 2028 || 2029 \/ 2030 +---------+ 2031 | ALTO | 2032 | Server | 2033 +---------+ 2034 : 2035 : Provisioning protocol 2036 : 2037 ,-----------. 2038 ,-' Source of `-. 2039 ( topological ) 2040 `-. information ,-' 2041 `-----------' 2043 Figure 19: Use of ALTO information for CDN request routing 2045 In order to derive the optimal benefit from a CDN it is preferable to 2046 deliver content from the servers (caches) that are "closest" to the 2047 end user requesting the content. "closest" may be as simple as 2048 geographical or IP topology distance, but it may also consider other 2049 combinations of metrics and CDN or Internet Service Provider (ISP) 2050 policies. As illustrated in Figure 19, ALTO could provide this 2051 information. 2053 User Agent Request Router Surrogate 2054 | | | 2055 | F1 Initial Request | | 2056 +---------------------------->| | 2057 | +--+ | 2058 | | | F2 Surrogate Selection | 2059 | |<-+ (using ALTO) | 2060 | F3 Redirection Response | | 2061 |<----------------------------+ | 2062 | | | 2063 | F4 Content Request | | 2064 +-------------------------------------------------------->| 2065 | | | 2066 | | F5 Content | 2067 |<--------------------------------------------------------+ 2068 | | | 2070 Figure 20: Example of CDN surrogate selection 2072 Figure 20 illustrates the interaction between a user agent, a request 2073 router, and a surrogate for the delivery of content in a single CDN. 2074 As explained in [I-D.jenkins-alto-cdn-use-cases], the user agent 2075 makes an initial request to the CDN (F1). This may be an 2076 application-level request (e.g., HTTP) or a DNS request. In the 2077 second step (F2), the request router selects an appropriate surrogate 2078 (or set of surrogates) based on the user agent's (or its proxy's) IP 2079 address, the request router's knowledge of the network topology 2080 (which can be obtained by ALTO) and reachability cost between CDN 2081 caches and end users, and any additional CDN policies. Then (F3), 2082 the request router responds to the initial request with an 2083 appropriate response containing a redirection to the selected cache, 2084 for example by returning an appropriate DNS A/AAAA record, a HTTP 302 2085 redirect, etc. The user agent uses this information to connect 2086 directly to the surrogate and request the desired content (F4), which 2087 is then delivered (F5). 2089 5.1.2. Applicability of ALTO 2091 The most simple use case for ALTO in a CDN context is to improve the 2092 selection of a CDN surrogate or origin. In this case, the CDN makes 2093 use of an ALTO server to choose a better CDN surrogate or origin than 2094 would otherwise be the case. Although it is possible to obtain raw 2095 network map and cost information in other ways, for example passively 2096 listening to the ISP's routing protocols or use of active probing, 2097 the use of an ALTO service to expose that information may provide 2098 additional control to the ISP over how their network map/cost is 2099 exposed. Additionally it may enable the ISP to maintain a functional 2100 separation between their routing plane and network map computation 2101 functions. This may be attractive for a number of reasons, for 2102 example: 2104 o The ALTO service could provide a filtered view of the network and/ 2105 or cost map that relates to CDN locations and their proximity to 2106 end users, for example to allow the ISP to control the level of 2107 topology detail they are willing to share with the CDN. 2109 o The ALTO service could apply additional policies to the network 2110 map and cost information to provide a CDN-specific view of the 2111 network map/cost, for example to allow the ISP to encourage the 2112 CDN to use network links that would not ordinarily be preferred by 2113 a Shortest Path First routing calculation. 2115 o The routing plane may be operated and controlled by a different 2116 operational entity (even within a single ISP) than the CDN. 2117 Therefore, the CDN may not be able to passively listen to routing 2118 protocols, nor may it have access to other network topology data 2119 (e.g., inventory databases). 2121 When CDN servers are deployed outside of an ISP's network or in a 2122 small number of central locations within an ISP's network, a 2123 simplified view of the ISP's topology or an approximation of 2124 proximity is typically sufficient to enable the CDN to serve end 2125 users from the optimal server/location. As CDN servers are deployed 2126 deeper within ISP networks it becomes necessary for the CDN to have 2127 more detailed knowledge of the underlying network topology and costs 2128 between network locations in order to enable the CDN to serve end 2129 users from the most optimal servers for the ISP. 2131 The request router in a CDN will typically also take into account 2132 criteria and constraints that are not related to network topology, 2133 such as the current load of CDN surrogates, content owner policies, 2134 end user subscriptions, etc. This document only discusses use of 2135 ALTO for network information. 2137 A general issue for CDNs is that the CDN logic has to match the 2138 client's IP address with the closest CDN surrogate, both for DNS or 2139 HTTP redirect based approaches (see, for instance, 2140 [I-D.penno-alto-cdn]). This matching is not trivial, for instance, 2141 in DNS based approaches, where the IP address of the DNS original 2142 requester is unknown (see [I-D.ietf-dnsop-edns-client-subnet] for a 2143 discussion of this and a solution approach). 2145 In addition to use by a single CDN, ALTO can also be used in 2146 scenarios that interconnect several CDNs. This use case is detailed 2147 in [I-D.seedorf-cdni-request-routing-alto]. 2149 5.2. Deployment Recommendations 2151 5.2.1. ALTO Services 2153 In its simplest form an ALTO server would provide an ISP with the 2154 capability to offer a service to a CDN that provides network map and 2155 cost information. The CDN can use that data to enhance its surrogate 2156 and/or origin selection. If an ISP offers an ALTO network and cost 2157 map service to expose a cost mapping/ranking between end user IP 2158 subnets (within that ISP's network) and CDN surrogate IP subnets/ 2159 locations, periodic updates of the maps may be needed. As introduced 2160 in Section 3.3), it is common for broadband subscribers to obtain 2161 their IP addresses dynamically and in many deployments the IP subnets 2162 allocated to a particular network region can change relatively 2163 frequently, even if the network topology itself is reasonably static. 2165 An alternative would be to use the ALTO Endpoint Cost Service (ECS): 2166 When an end user requests a given content, the CDN request router 2167 issues an ECS request with the endpoint address (IPv4/IPv6) of the 2168 end user (content requester) and the set of endpoint addresses of the 2169 surrogate (content targets). The ALTO server receives the request 2170 and ranks the addresses based on their distance from the content 2171 requester. Once the request router obtained from the ALTO server the 2172 ranked list of locations (for the specific user), it can incorporate 2173 this information into its selection mechanisms in order to point the 2174 user to the most appropriate surrogate. 2176 Since CDNs operate in a controlled environment, the ALTO network/cost 2177 map service and ECS have a similar level of security and 2178 confidentiality of network-internal information. However, the 2179 network/cost map service and ECS differ in the way the ALTO service 2180 is delivered and address a different set of requirements in terms of 2181 topology information and network operations. 2183 If a CDN already has means to model connectivity policies, the map- 2184 based approaches could possibly be integrated into that. If the ECS 2185 service is preferred, a request router that uses ECS could cache the 2186 results of ECS queries for later usage in order to address the 2187 scalability limitations of ECS and to reduce the number of 2188 transactions between CDN and ALTO server. The ALTO server may 2189 indicate in the reply message how long the content of the message is 2190 to be considered reliable and insert a lifetime value that will be 2191 used by the CDN in order to cache (and then flush or refresh) the 2192 entry. 2194 5.2.2. Guidance Considerations 2196 In the following it is discussed how a CDN could make use of ALTO 2197 services. 2199 In one deployment scenario, ALTO could expose ISP end user 2200 reachability to a CDN. The request router needs to have information 2201 about which end user IP subnets are reachable via which networks or 2202 network locations. The network map services offered by ALTO could be 2203 used to expose this topology information while avoiding routing plane 2204 peering between the ISP and the CDN. For example, if CDN surrogates 2205 are deployed within the access or aggregation network, the ISP is 2206 likely to want to utilize the surrogates deployed in the same access/ 2207 aggregation region in preference to surrogates deployed elsewhere, in 2208 order to alleviate the cost and/or improve the user experience. 2210 In addition, CDN surrogates could also use ALTO guidance, e.g., if 2211 there is more than one upstream source of content or several origins. 2212 In this case, ALTO could help a surrogate with the decision about 2213 which upstream source to use. This specific variant of using ALTO is 2214 not further detailed in this document. 2216 If content can be provided by several CDNs, there may be a need to 2217 interconnect these CDNs. In this case, ALTO can be uses as an 2218 interface [I-D.seedorf-cdni-request-routing-alto], in particular for 2219 footprint and capabilities advertisement. 2221 Other and more advanced scenarios of deploying ALTO are also listed 2222 in [I-D.jenkins-alto-cdn-use-cases] and [I-D.penno-alto-cdn]. 2224 The granularity of ALTO information required depends on the specific 2225 deployment of the CDN. For example, an "over-the-top" CDN whose 2226 surrogates are deployed only within the Internet backbone may only 2227 require knowledge of which end user IP subnets are reachable via 2228 which ISPs' networks, whereas a CDN deployed within a particular 2229 ISP's network requires a finer granularity of knowledge. 2231 An ALTO server ranks addresses based on topology information it 2232 acquires from the network. By default, according to [RFC7285], 2233 distance in ALTO represents an abstract "routingcost" that can be 2234 computed for instance from routing protocol information. But an ALTO 2235 server may also take into consideration other criteria or other 2236 information sources for policy, state, and performance information 2237 (e.g., geo-location), as explained in Section 3.2.1. 2239 The different methods and algorithms through which the ALTO server 2240 computes topology information and rankings is out of the scope of 2241 this document. If rankings are based on routing protocol 2242 information, it is obvious that network events may impact the ranking 2243 computation. Due to internal redundancy and resilience mechanisms 2244 inside current networks, most of the network events happening in the 2245 infrastructure will be handled internally in the network, and they 2246 should have limited impact on a CDN. However, catastrophic events 2247 such as main trunks failures or backbone partitioning will have to be 2248 taken into account by the ALTO server to redirect traffic away from 2249 the impacted area. 2251 An ALTO server implementation may want to keep state about ALTO 2252 clients so to inform and signal to these clients when a major network 2253 event happened, e.g., by a notification mechanism. In a CDN/ALTO 2254 interworking architecture with few CDN components interacting with 2255 the ALTO server there are less scalability issues in maintaining 2256 state about clients in the ALTO server, compared to ALTO guidance to 2257 any Internet user. 2259 6. Other Use Cases 2261 This section briefly surveys and references other use cases that have 2262 been tested or suggested for ALTO deployments. 2264 6.1. Application Guidance in Virtual Private Networks (VPNs) 2266 Virtual Private Network (VPN) technology is widely used in public and 2267 private networks to create groups of users that are separated from 2268 other users of the network and allows these users to communicate 2269 among themselves as if they were on a private network. Network 2270 Service Providers (NSPs) offer different types of VPNs. [RFC4026] 2271 distinguishes between Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) 2272 using different sub-types. In the following, the term "VPN" is used 2273 to refer to provider supplied virtual private networking. 2275 From the perspective of an application at an endpoint, a VPN may not 2276 be very different to any other IP connectivity solution, but there 2277 are a number of specific applications that could benefit from ALTO 2278 topology exposure and guidance in VPNs. As in the general Internet, 2279 one advantage is that applications do not have to perform excessive 2280 measurements on their own. For instance, potential use cases for 2281 ALTO application guidance in VPN environments are: 2283 o Enterprise application optimization: Enterprise customers often 2284 run distributed applications that exchange large amounts of data, 2285 e.g., for synchronization of replicated data bases. Network 2286 topology information could be useful for placement of replicas as 2287 well as for the scheduling of transfers. 2289 o Private cloud computing solution: An enterprise customer could run 2290 its own data centers at the four sites. The cloud management 2291 system could want to understand the network costs between 2292 different sites for intelligent routing and placement decisions of 2293 Virtual Machines (VMs) among the VPN sites. 2295 o Cloud-bursting: One or more VPN endpoints could be located in a 2296 public cloud. If an enterprise customer needs additional 2297 resources, they could be provided by a public cloud, which is 2298 accessed through the VPN. Network topology awareness would help 2299 to decide in which data center of the public cloud those resources 2300 should be allocated. 2302 These examples focus on enterprises, which are typical users of VPNs. 2303 VPN customers typically have no insight into the network topology 2304 that transports the VPN. Similar to other ALTO use cases, better- 2305 than-random application-level decisions would be enabled by an ALTO 2306 server offered by the NSP, as illustrated in Figure 21. 2308 +---------------+ 2309 | Customer's | 2310 | management | 2311 | application |. 2312 | (ALTO client) | . 2313 +---------------+ . VPN provisioning 2314 /\ . (out-of-scope) 2315 || ALTO . 2316 \/ . 2317 +---------------------+ +----------------+ 2318 | ALTO server | | VPN portal/OSS | 2319 | provided by NSP | | (out-of-scope) | 2320 +---------------------+ +----------------+ 2321 : VPN network 2322 : and cost maps 2323 : 2324 /---------:---------\ Network service provider 2325 | : | 2326 +-------+ _______________________ +-------+ 2327 | App a | ()_____. .________. .____() | App d | 2328 +-------+ | | | | | | +-------+ 2329 \---| |--------| |--/ 2330 | | | | 2331 |^| |^| Customer VPN 2332 V V 2333 +-------+ +-------+ 2334 | App b | | App c | 2335 +-------+ +-------+ 2337 Figure 21: Using ALTO in VPNs 2339 A common characteristic of these use cases is that applications will 2340 not necessarily run in the public Internet, and that the relationship 2341 between the provider and customer of the VPN is rather well-defined. 2342 Since VPNs often run in a managed environment, an ALTO server may 2343 have access to topology information (e.g., traffic engineering data) 2344 that would not be available for the public Internet, and it may 2345 expose it to the customer of the VPN only. 2347 Also, a VPN will not necessarily be static. The customer could 2348 possibly modify the VPN and add new VPN sites by a Web portal, 2349 network management systems, or other Operation Support Systems (OSS) 2350 solutions. Prior to adding a new VPN site, an application will not 2351 have connectivity to that site, i.e., an ALTO server could offer 2352 access to information that an application cannot measure on its own 2353 (e.g., expected delay to a new VPN site). 2355 The VPN use cases, requirements, and solutions are further detailed 2356 in [I-D.scharf-alto-vpn-service]. 2358 6.2. In-Network Caching 2360 Deployment of intra-domain P2P caches has been proposed for 2361 cooperation between the network operator and the P2P service 2362 providers, e.g., to reduce the bandwidth consumption in access 2363 networks [I-D.deng-alto-p2pcache]. 2365 +--------------+ +------+ 2366 | ISP 1 network+----------------+Peer 1| 2367 +-----+--------+ +------+ 2368 | 2369 +--------+------------------------------------------------------+ 2370 | | ISP 2 network | 2371 | +---------+ | 2372 | |L1 Cache | | 2373 | +-----+---+ | 2374 | +--------------------+----------------------+ | 2375 | | | | | 2376 | +------+------+ +------+-------+ +------+-------+ | 2377 | | AN1 | | AN2 | | AN3 | | 2378 | | +---------+ | | +----------+ | | | | 2379 | | |L2 Cache | | | |L2 Cache | | | | | 2380 | | +---------+ | | +----------+ | | | | 2381 | +------+------+ +------+-------+ +------+-------+ | 2382 | | | | 2383 | +--------------------+ | | 2384 | | | | | 2385 | +------+------+ +------+-------+ +------+-------+ | 2386 | | SUB-AN11 | | SUB-AN12 | | SUB-AN31 | | 2387 | | +---------+ | | | | | | 2388 | | |L3 Cache | | | | | | | 2389 | | +---------+ | | | | | | 2390 | +------+------+ +------+-------+ +------+-------+ | 2391 | | | | | 2392 +--------+--------------------+----------------------+----------+ 2393 | | | 2394 +---+---+ +---+---+ | 2395 | | | | | 2396 +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ 2397 |Peer2| |Peer3| |Peer4| |Peer5| |Peer6| 2398 +-----+ +-----+ +-----+ +-----+ +-----+ 2400 Figure 22: General architecture of intra-ISP caches 2402 Figure 22 depicts the overall architecture of potential P2P cache 2403 deployments inside an ISP 2 with various access network types. As 2404 shown in the figure, P2P caches may be deployed at various levels, 2405 including the interworking gateway linking with other ISPs, internal 2406 access network gateways linking with different types of accessing 2407 networks (e.g. WLAN, cellular and wired), and even within an 2408 accessing network at the entries of individual WLAN sub-networks. 2409 Moreover, depending on the network context and the operator's policy, 2410 each cache can be a Forwarding Cache or a Bidirectional Cache 2411 [I-D.deng-alto-p2pcache]. 2413 In such a cache architecture, the locations of caches could be used 2414 as dividers of different PIDs to guide intra-ISP network abstraction 2415 and mark costs among them according to the location and type of 2416 relevant caches. 2418 Further details and deployment considerations can be found in 2419 [I-D.deng-alto-p2pcache]. 2421 6.3. Other Application-based Network Operations 2423 An ALTO server can be part of an overall framework for Application- 2424 Based Network Operations (ABNO) [RFC7491] that brings together 2425 different technologies for gathering information about the resources 2426 available in a network, for consideration of topologies and how those 2427 topologies map to underlying network resources, for requesting path 2428 computation, and for provisioning or reserving network resources. 2429 Such an architecture may include additional components such as a Path 2430 Computation Element (PCE) for on-demand and application-specific 2431 reservation of network connectivity, reliability, and resources (such 2432 as bandwidth). Some use cases how to leverage ALTO for joint network 2433 and application-layer optimization are explained in [RFC7491]. 2435 7. Security Considerations 2437 Security concerns were extensively discussed from the very beginning 2438 of the development of the ALTO protocol, and they have been 2439 considered in detail in the ALTO requirements document [RFC6708] as 2440 well as in the ALTO protocol specification document [RFC7285]. The 2441 two main security concerns are related to the unwanted disclosure of 2442 information through ALTO and the negative impact of specially 2443 crafted, wrong ("faked") guidance presented to an ALTO client. In 2444 addition to this, the usual concerns related to the operation of any 2445 networked application apply. 2447 This section focuses on the peer-to-peer use case, which is - from a 2448 security perspective - probably the most difficult ALTO use case that 2449 has been considered. Special attention is given to the two main 2450 security concerns. 2452 7.1. ALTO as a Protocol Crossing Trust Boundaries 2454 The optimization of peer-to-peer applications was the first use case 2455 and the impetus for the development of the ALTO protocol, in 2456 particular file sharing applications such as BitTorrent [RFC5594]. 2458 As explained in Section 4.1.1, for the publisher of the ALTO 2459 information (i.e., the ALTO server operator) it is not always clear 2460 who is in charge of the P2P application overlay. Some P2P 2461 applications do not have any central control entity and the whole 2462 overlay consists only of the peers, which are under control of the 2463 individual users. Other P2P applications may have some control 2464 entities such as super peers or trackers, but these may be located in 2465 foreign countries and under the control of unknown organizations. As 2466 outlined in Section 4.2.2, in some scenarios it may be very 2467 beneficial to forward ALTO information to such trackers, super peers, 2468 etc. located in remote networks. This situation is aggravated by the 2469 vast number of different P2P applications which are evolving quickly 2470 and often without any coordination with the network operators. 2472 In summary it can be said that in many instances of the P2P use case, 2473 the ALTO protocol bridges the border between the "managed" IP network 2474 infrastructure under strict administrative control and one or more 2475 "unmanaged" application overlays, i.e., overlays for which it is hard 2476 to tell who is in charge of them. This differs from more controlled 2477 environments (e.g., in the CDN use case), in which bilateral 2478 agreements between the producer and consumer of guidance are 2479 possible. 2481 7.2. Information Leakage from the ALTO Server 2483 An ALTO server will be provisioned with information about the ISP's 2484 network and possibly also with information about neighboring ISPs. 2485 This information (e.g., network topology, business relations, etc.) 2486 is often considered to be confidential to the ISP and can include 2487 very sensitive information. ALTO does not require any particular 2488 level of details of information disclosure, and hence the provider 2489 should evaluate how much information is revealed and the associated 2490 risks. 2492 Furthermore, if the ALTO information is very fine grained, it may 2493 also be considered sensitive with respect to user privacy. For 2494 example, consider a hypothetical endpoint property "provisioned 2495 access link bandwidth" or "access technology (ADSL, VDSL, FTTH, 2496 etc.)" and an ALTO service that publishes this property for 2497 individual IP addresses. This information could not only be used for 2498 traffic optimization but, for example, also for targeted advertising 2499 to residential users with exceptionally good (or bad) connectivity, 2500 such as special banner ads. For an advertisement system it would be 2501 more complex to obtain such information otherwise, e.g., by bandwidth 2502 probing. 2504 Different scenarios related to the unwanted disclosure of an ALTO 2505 server's information have been itemized and categorized in RFC 6708, 2506 Section 5.2.1., cases (1)-(3) [RFC6708]. 2508 In some use cases it is not possible to use access control (see 2509 Section 7.3) to limit the distribution of ALTO knowledge to a small 2510 set of trusted clients. In these scenarios it seems tempting not to 2511 use network maps and cost maps at all, and instead completely rely on 2512 endpoint cost service and endpoint ranking in the ALTO server. While 2513 this practice may indeed reduce the amount of information that is 2514 disclosed to an individual ALTO client, some issues should be 2515 considered: First, when using the map based approach, it is trivial 2516 to analyze the maximum amount of information that could be disclosed 2517 to a client: the full maps. In contrast, when providing endpoint 2518 cost service only, the ALTO server operator could be prone to a false 2519 feeling of security, while clients use repeated queries and/or 2520 collaboration to gather more information than they are expected to 2521 get (see Section 5.2.1., case (3) in [RFC6708]). Second, the 2522 endpoint cost service reveals more information about the user or 2523 application behavior to the ALTO server, e.g., which other hosts are 2524 considered as peers for the exchange of a significant amount of data 2525 (see Section 5.2.1., cases (4)-(6) in [RFC6708]). 2527 Consequently, users may be more reluctant to use the ALTO service at 2528 all if it is based on the endpoint cost service instead of providing 2529 network and cost maps. Given that some popular P2P applications are 2530 sometimes used for purposes such as distribution of files without the 2531 explicit permission from the copyright owner, it may also be in the 2532 interest of the ALTO server operator that an ALTO server cannot infer 2533 the behavior of the application to be optimized. One possible 2534 conclusion could be to publish network and cost maps through ALTO 2535 that are so coarse-grained that they do not violate the network 2536 operator's or the user's interests. 2538 In other use cases in more controlled environments (e.g., in the CDN 2539 use case) bilateral agreements, access control (see Section 7.3), and 2540 encryption could be used to reduce the risk of information leakage. 2542 7.3. ALTO Server Access 2544 Depending on the use case of ALTO, it may be desired to apply access 2545 restrictions to an ALTO server, i.e., by requiring client 2546 authentication. According to [RFC7285], ALTO requires that HTTP 2547 Digest Authentication is supported, in order to achieve client 2548 authentication and possibly to limit the number of parties with whom 2549 ALTO information is directly shared. TLS Client Authentication may 2550 also be supported. 2552 In general, well-known security management techniques and best 2553 current practices [RFC4778] for operational ISP infrastructure also 2554 apply to an ALTO service, including functions to protect the system 2555 from unauthorized access, key management, reporting security-relevant 2556 events, and authorizing user access and privileges. 2558 For peer-to-peer applications, a potential deployment scenario is 2559 that an ALTO server is solely accessible by peers from the ISP 2560 network (as shown in Figure 14). For instance, the source IP address 2561 can be used to grant only access from that ISP network to the server. 2562 This will "limit" the number of peers able to attack the server to 2563 the user's of the ISP (however, including botnet computers). 2565 If the ALTO server has to be accessible by parties not located in the 2566 ISP's network (see Figure 15), e.g., by a third-party tracker or by a 2567 CDN system outside the ISP's network, the access restrictions have to 2568 be looser. In the extreme case, i.e., no access restrictions, each 2569 and every host in the Internet can access the ALTO server. This 2570 might no be the intention of the ISP, as the server is not only 2571 subject to more possible attacks, but also the server load could 2572 increase, since possibly more ALTO clients have to be served. 2574 There are also use cases where the access to the ALTO server has to 2575 be much more strictly controlled, i. e., where an authentication and 2576 authorization of the ALTO client to the server may be needed. For 2577 instance, in case of CDN optimization the provider of an ALTO service 2578 as well as potential users are possibly well-known. Only CDN 2579 entities may need ALTO access; access to the ALTO servers by 2580 residential users may neither be necessary nor be desired. 2582 Access control can also help to prevent Denial-of-Service attacks by 2583 arbitrary hosts from the Internet. Denial-of-Service (DoS) can both 2584 affect an ALTO server and an ALTO client. A server can get 2585 overloaded if too many requests hit the server, or if the query load 2586 of the server surpasses the maximum computing capacity. An ALTO 2587 client can get overloaded if the responses from the sever are, either 2588 intentionally or due to an implementation mistake, too large to be 2589 handled by that particular client. 2591 7.4. Faking ALTO Guidance 2593 The ALTO services enables an ALTO service provider to influence the 2594 behavior of network applications. An attacker who is able to 2595 generate false replies, or e.g. an attacker who can intercept the 2596 ALTO server discovery procedure, can provide faked ALTO guidance. 2598 Here is a list of examples how the ALTO guidance could be faked and 2599 what possible consequences may arise: 2601 Sorting: An attacker could change to sorting order of the ALTO 2602 guidance (given that the order is of importance, otherwise the 2603 ranking mechanism is of interest), i.e., declaring peers located 2604 outside the ISP as peers to be preferred. This will not pose a 2605 big risk to the network or peers, as it would mimic the "regular" 2606 peer operation without traffic localization, apart from the 2607 communication/processing overhead for ALTO. However, it could 2608 mean that ALTO is reaching the opposite goal of shuffling more 2609 data across ISP boundaries, incurring more costs for the ISP. In 2610 another example, fake guidance could give unrealistically low 2611 costs to devices in an ISP's mobile network, thus encouraging 2612 other devices to contact them, thereby degrading the ISP's mobile 2613 network and causing customer dissatisfaction. 2615 Preference of a single peer: A single IP address (thus a peer) could 2616 be marked as to be preferred all over other peers. This peer can 2617 be located within the local ISP or also in other parts of the 2618 Internet (e.g., a web server). This could lead to the case that 2619 quite a number of peers to trying to contact this IP address, 2620 possibly causing a Denial-of-Service (DoS) attack. 2622 It has not yet been investigated how a faked or wrong ALTO guidance 2623 by an ALTO server can impact the operation of the network and also 2624 the applications, e.g., peer-to-peer applications. 2626 8. IANA Considerations 2628 This document makes no specific request to IANA. 2630 9. Conclusion 2632 This document discusses how the ALTO protocol can be deployed in 2633 different use cases and provides corresponding guidance and 2634 recommendations to network administrators and application developers. 2636 10. Acknowledgments 2638 This memo is the result of contributions made by several people: 2640 o Xianghue Sun, Lee Kai, and Richard Yang contributed text on ISP 2641 deployment requirements and monitoring. 2643 o Stefano Previdi contributed parts of the Section 5 on "Using ALTO 2644 for CDNs". 2646 o Rich Woundy contributed text to Section 3.3. 2648 o Lingli Deng, Wei Chen, Qiuchao Yi, and Yan Zhang contributed 2649 Section 6.2. 2651 Thomas-Rolf Banniza, Vinayak Hegde, Qin Wu, and Wendy Roome provided 2652 very useful comments and reviewed the document. 2654 Martin Stiemerling is partially supported by the CHANGE project 2655 (http://www.change-project.eu), a research project supported by the 2656 European Commission under its 7th Framework Program (contract no. 2657 257422). The views and conclusions contained herein are those of the 2658 authors and should not be interpreted as necessarily representing the 2659 official policies or endorsements, either expressed or implied, of 2660 the CHANGE project or the European Commission. 2662 11. References 2664 11.1. Normative References 2666 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 2667 Optimization (ALTO) Problem Statement", RFC 5693, October 2668 2009. 2670 [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 2671 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 2672 Requirements", RFC 6708, September 2012. 2674 [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 2675 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 2676 Traffic Optimization (ALTO) Protocol", RFC 7285, September 2677 2014. 2679 [RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 2680 H. Song, "Application-Layer Traffic Optimization (ALTO) 2681 Server Discovery", RFC 7286, November 2014. 2683 11.2. Informative References 2685 [I-D.deng-alto-p2pcache] 2686 Lingli, D., Chen, W., Yi, Q., and Y. Zhang, 2687 "Considerations for ALTO with network-deployed P2P 2688 caches", draft-deng-alto-p2pcache-03 (work in progress), 2689 February 2014. 2691 [I-D.ietf-dnsop-edns-client-subnet] 2692 Contavalli, C., Gaast, W., Lawrence, D., and W. Kumari, 2693 "Client Subnet in DNS Querys", draft-ietf-dnsop-edns- 2694 client-subnet-01 (work in progress), May 2015. 2696 [I-D.ietf-i2rs-architecture] 2697 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 2698 Nadeau, "An Architecture for the Interface to the Routing 2699 System", draft-ietf-i2rs-architecture-09 (work in 2700 progress), March 2015. 2702 [I-D.ietf-idr-ls-distribution] 2703 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 2704 Ray, "North-Bound Distribution of Link-State and TE 2705 Information using BGP", draft-ietf-idr-ls-distribution-11 2706 (work in progress), June 2015. 2708 [I-D.jenkins-alto-cdn-use-cases] 2709 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 2710 S. Previdi, "Use Cases for ALTO within CDNs", draft- 2711 jenkins-alto-cdn-use-cases-03 (work in progress), June 2712 2012. 2714 [I-D.kiesel-alto-h12] 2715 Kiesel, S. and M. Stiemerling, "ALTO H12", draft-kiesel- 2716 alto-h12-02 (work in progress), March 2010. 2718 [I-D.kiesel-alto-xdom-disc] 2719 Kiesel, S. and M. Stiemerling, "Application Layer Traffic 2720 Optimization (ALTO) Cross-Domain Server Discovery", draft- 2721 kiesel-alto-xdom-disc-00 (work in progress), July 2014. 2723 [I-D.lee-alto-chinatelecom-trial] 2724 Li, K. and G. Jian, "ALTO and DECADE service trial within 2725 China Telecom", draft-lee-alto-chinatelecom-trial-04 (work 2726 in progress), March 2012. 2728 [I-D.penno-alto-cdn] 2729 Penno, R., Medved, J., Alimi, R., Yang, R., and S. 2730 Previdi, "ALTO and Content Delivery Networks", draft- 2731 penno-alto-cdn-03 (work in progress), March 2011. 2733 [I-D.scharf-alto-vpn-service] 2734 Scharf, M., Gurbani, V., Soprovich, G., and V. Hilt, "The 2735 Virtual Private Network (VPN) Service in ALTO: Use Cases, 2736 Requirements and Extensions", draft-scharf-alto-vpn- 2737 service-02 (work in progress), February 2014. 2739 [I-D.seedorf-cdni-request-routing-alto] 2740 Seedorf, J., Yang, Y., and J. Peterson, "CDNI Footprint 2741 and Capabilities Advertisement using ALTO", draft-seedorf- 2742 cdni-request-routing-alto-08 (work in progress), March 2743 2015. 2745 [I-D.wu-alto-te-metrics] 2746 Wu, W., Yang, Y., Lee, Y., Dhody, D., and S. Randriamasy, 2747 "ALTO Traffic Engineering Cost Metrics", draft-wu-alto-te- 2748 metrics-06 (work in progress), April 2015. 2750 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 2751 Architecture for Describing Simple Network Management 2752 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 2753 December 2002. 2755 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 2756 Content Network (CN) Request-Routing Mechanisms", RFC 2757 3568, July 2003. 2759 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 2760 Private Network (VPN) Terminology", RFC 4026, March 2005. 2762 [RFC4778] Kaeo, M., "Operational Security Current Practices in 2763 Internet Service Provider Environments", RFC 4778, January 2764 2007. 2766 [RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop 2767 on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", RFC 2768 5594, July 2009. 2770 [RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and 2771 Y. Yang, "Comcast's ISP Experiences in a Proactive Network 2772 Provider Participation for P2P (P4P) Technical Trial", RFC 2773 5632, September 2009. 2775 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 2776 Network Configuration Protocol (NETCONF)", RFC 6020, 2777 October 2010. 2779 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 2780 Bierman, "Network Configuration Protocol (NETCONF)", RFC 2781 6241, June 2011. 2783 [RFC6875] Kamei, S., Momose, T., Inoue, T., and T. Nishitani, "The 2784 P2P Network Experiment Council's Activities and 2785 Experiments with Application-Layer Traffic Optimization 2786 (ALTO) in Japan", RFC 6875, February 2013. 2788 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 2789 Application-Based Network Operations", RFC 7491, March 2790 2015. 2792 Authors' Addresses 2794 Martin Stiemerling 2795 NEC Laboratories Europe 2796 Kurfuerstenanlage 36 2797 Heidelberg 69115 2798 Germany 2800 Phone: +49 6221 4342 113 2801 Fax: +49 6221 4342 155 2802 Email: martin.stiemerling@neclab.eu 2803 URI: http://ietf.stiemerling.org 2805 Sebastian Kiesel 2806 University of Stuttgart Information Center 2807 Networks and Communication Systems Department 2808 Allmandring 30 2809 Stuttgart 70550 2810 Germany 2812 Email: ietf-alto@skiesel.de 2813 URI: http://www.rus.uni-stuttgart.de/nks/ 2814 Stefano Previdi 2815 Cisco Systems, Inc. 2816 Via Del Serafico 200 2817 Rome 00191 2818 Italy 2820 Email: sprevidi@cisco.com 2822 Michael Scharf 2823 Alcatel-Lucent Bell Labs 2824 Lorenzstrasse 10 2825 Stuttgart 70435 2826 Germany 2828 Email: michael.scharf@alcatel-lucent.com