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