idnits 2.17.1 draft-ietf-alto-deployments-09.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 195 has weird spacing: '...logical ser...' == Line 220 has weird spacing: '...logical ser...' -- The document date (February 11, 2014) is 3728 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 (-03) exists of draft-deng-alto-p2pcache-02 == Outdated reference: A later version (-16) exists of draft-farrkingel-pce-abno-architecture-06 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-25 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-01 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-04 == Outdated reference: A later version (-02) exists of draft-scharf-alto-vpn-service-01 == Outdated reference: A later version (-10) exists of draft-seedorf-cdni-request-routing-alto-05 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO M. Stiemerling, Ed. 3 Internet-Draft NEC Europe Ltd. 4 Intended status: Informational S. Kiesel, Ed. 5 Expires: August 15, 2014 University of Stuttgart 6 S. Previdi 7 Cisco 8 M. Scharf 9 Alcatel-Lucent Bell Labs 10 February 11, 2014 12 ALTO Deployment Considerations 13 draft-ietf-alto-deployments-09 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, security considerations, recommendations for 27 network administrators, and also guidance for application designers 28 using 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 August 15, 2014. 47 Copyright Notice 49 Copyright (c) 2014 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 . . . . . . . . . . . . . 4 69 2.2. Classification of Deployment Scenarios . . . . . . . . . 6 70 2.2.1. Deployment Degrees of Freedom . . . . . . . . . . . . 6 71 2.2.2. Information Exposure . . . . . . . . . . . . . . . . 7 72 2.2.3. More Advanced Deployments . . . . . . . . . . . . . . 8 73 3. Deployment Considerations by ISPs . . . . . . . . . . . . . . 9 74 3.1. Objectives for the Guidance to Applications . . . . . . . 9 75 3.1.1. General Objectives for Traffic Optimization . . . . . 10 76 3.1.2. Inter-Network Traffic Localization . . . . . . . . . 11 77 3.1.3. Intra-Network Traffic Localization . . . . . . . . . 12 78 3.1.4. Network Off-Loading . . . . . . . . . . . . . . . . . 13 79 3.1.5. Application Tuning . . . . . . . . . . . . . . . . . 14 80 3.2. Provisioning of ALTO Maps . . . . . . . . . . . . . . . . 14 81 3.2.1. Data Sources . . . . . . . . . . . . . . . . . . . . 15 82 3.2.2. Privacy Requirements . . . . . . . . . . . . . . . . 17 83 3.2.3. Map Partitioning and Grouping . . . . . . . . . . . . 18 84 3.2.4. Rating Criteria and/or Cost Calculation . . . . . . . 18 85 3.3. Known Limitations of ALTO . . . . . . . . . . . . . . . . 21 86 3.3.1. Limitations of Map-based Approaches . . . . . . . . . 21 87 3.3.2. Limitiations of Non-Map-based Approaches . . . . . . 23 88 3.4. Monitoring the Performance of ALTO . . . . . . . . . . . 23 89 3.4.1. Supervising the Benefits of ALTO . . . . . . . . . . 23 90 3.4.2. How to Monitor ALTO Performance . . . . . . . . . . . 23 91 3.4.3. Monitoring Infrastructure . . . . . . . . . . . . . . 25 92 3.5. Map Examples for Different Types of ISPs . . . . . . . . 26 93 3.5.1. Small ISP with Single Internet Uplink . . . . . . . . 26 94 3.5.2. ISP with Several Fixed Access Networks . . . . . . . 28 95 3.5.3. ISP with Fixed and Mobile Network . . . . . . . . . . 29 96 3.6. Deployment Experiences . . . . . . . . . . . . . . . . . 30 97 4. Using ALTO for P2P Traffic Optimization . . . . . . . . . . . 31 98 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 31 99 4.1.1. Usage Scenario . . . . . . . . . . . . . . . . . . . 31 100 4.1.2. Applicability of ALTO . . . . . . . . . . . . . . . . 31 101 4.2. Deployment Recommendations . . . . . . . . . . . . . . . 34 102 4.2.1. ALTO Services . . . . . . . . . . . . . . . . . . . . 35 103 4.2.2. Guidance Considerations . . . . . . . . . . . . . . . 35 104 5. Using ALTO for CDNs . . . . . . . . . . . . . . . . . . . . . 37 105 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 37 106 5.1.1. Usage Scenario . . . . . . . . . . . . . . . . . . . 37 107 5.1.2. Applicability of ALTO . . . . . . . . . . . . . . . . 39 108 5.2. Deployment Recommendations . . . . . . . . . . . . . . . 40 109 5.2.1. ALTO Services . . . . . . . . . . . . . . . . . . . . 40 110 5.2.2. Guidance Considerations . . . . . . . . . . . . . . . 41 111 6. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 43 112 6.1. Virtual Private Networks (VPNs) . . . . . . . . . . . . . 43 113 6.2. In-Network Caching . . . . . . . . . . . . . . . . . . . 45 114 6.3. Other Use Cases . . . . . . . . . . . . . . . . . . . . . 46 115 7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 116 7.1. Information Leakage from the ALTO Server . . . . . . . . 46 117 7.2. ALTO Server Access . . . . . . . . . . . . . . . . . . . 47 118 7.3. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . 47 119 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 120 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 48 121 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 122 10.1. Normative References . . . . . . . . . . . . . . . . . . 48 123 10.2. Informative References . . . . . . . . . . . . . . . . . 48 124 Appendix A. Contributing Authors and Acknowledgments . . . . . . 50 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 127 1. Introduction 129 Many Internet applications are used to access resources such as 130 pieces of information or server processes that are available in 131 several equivalent replicas on different hosts. This includes, but 132 is not limited to, peer-to-peer (P2P) file sharing applications and 133 Content Delivery Networks (CDNs). The goal of Application-Layer 134 Traffic Optimization (ALTO) is to provide guidance to applications 135 that have to select one or several hosts from a set of candidates, 136 which are able to provide a desired resource. The basic ideas and 137 problem space of ALTO is described in [RFC5693] and the set of 138 requirements is discussed in [RFC6708]. 140 However, there are no considerations about what operational issues 141 are to be expected once ALTO will be deployed. This includes, but is 142 not limited to, location of the ALTO server, imposed load to the ALTO 143 server, or from whom the queries are performed. 145 Comments and discussions about this memo should be directed to the 146 ALTO working group: alto@ietf.org. 148 2. General Considerations 150 2.1. ALTO Entities 152 2.1.1. Baseline Scenario 154 The ALTO protocol [I-D.ietf-alto-protocol] is a client/server 155 protocol, operating between a number of ALTO clients and an ALTO 156 server, as sketched in Figure 1. 158 +----------+ 159 | ALTO | 160 | Server | 161 +----------+ 162 ^ 163 _.-----|------. 164 ,-'' | `--. 165 ,' | `. 166 ( Network | ) 167 `. | ,' 168 `--. | _.-' 169 `------|-----'' 170 v 171 +----------+ +----------+ +----------+ 172 | ALTO | | ALTO |...| ALTO | 173 | Client | | Client | | Client | 174 +----------+ +----------+ +----------+ 176 Figure 1: Baseline Deployment Scenario of the ALTO Protocol 178 2.1.2. Placement of ALTO Entities 180 The ALTO server and ALTO clients can be situated at various entities 181 in a network deployment. The first differentiation is whether the 182 ALTO client is located on the actual host that runs the application, 183 as shown in Figure 2, or if the ALTO client is located on a resource 184 directory, as shown in Figure 3. 186 +-----+ 187 =====| |** 188 ==== +-----+ * 189 ==== * * 190 ==== * * 191 +-----+ +------+===== +-----+ * 192 | |.....| |======================| | * 193 +-----+ +------+===== +-----+ * 194 Source of ALTO ==== * * 195 topological service ==== * * 196 information ==== +-----+ * 197 =====| |** 198 +-----+ 199 Legend: 200 === ALTO client protocol 201 *** Application protocol 202 ... Provisioning protocol 204 Figure 2: Overview of protocol interaction between ALTO elements 205 without a resource directory 207 Figure 2 shows the operational model for applications that do not use 208 a resouce directory. An example would be a peer-to-peer file sharing 209 application that does not use a tracker, such as edonkey. 211 +-----+ 212 **| |** 213 ** +-----+ * 214 ** * * 215 ** * * 216 +-----+ +------+ +-----+** +-----+ * 217 | |.....| |=====| |**********| | * 218 +-----+ +------+ +-----+** +-----+ * 219 Source of ALTO Resource ** * * 220 topological service directory ** * * 221 information ** +-----+ * 222 **| |** 223 +-----+ 225 Legend: 226 === ALTO client protocol 227 *** Application protocol 228 ... Provisioning protocol 230 Figure 3: Overview of protocol interaction between ALTO elements with 231 a resource directory 233 In Figure 3, a use case with a resource directory is illustrated, 234 e.g., a tracker in peer-to-peer filesharing. Both deployment 235 scenarios may differ in the number of ALTO clients that access an 236 ALTO service: If ALTO clients are implemented in a resource 237 directory, ALTO servers may be accessed by a limited and less dynamic 238 set of clients, whereas in the general case any host could be an ALTO 239 client. This use case is further detailed in Section 4. 241 Using ALTO in CDNs may be similar to a resource directory 242 [I-D.jenkins-alto-cdn-use-cases]. The ALTO server can also be 243 queried by CDN entities to get a guidance about where the a 244 particular client accessing data in the CDN is exactly located in the 245 ISP's network, as discussed in Section 5. 247 2.2. Classification of Deployment Scenarios 249 2.2.1. Deployment Degrees of Freedom 251 ALTO is a general-purpose solution and it is intended to be used by a 252 wide range of applications. This implies that there are different 253 possibilities where the ALTO entities are actually located, i.e., if 254 the ALTO clients and the ALTO server are in the same ISP's domain, or 255 if the clients and the ALTO server are managed/owned/located in 256 different domains. 258 ALTO deployments can be differentiated e.g. according to the 259 following aspects: 261 1. Applicable trust model: The deployment of ALTO can differ 262 depending on whether ALTO client and ALTO server are operated 263 within the same organization and/or network, or not. This 264 affects a lot of constraints, because the trust model is very 265 different. For instance, as discussed later in this memo, the 266 level-of-detail of maps can depend on who the involved parties 267 actually are. 269 2. Size of user group: The main use case of ALTO is to provide 270 guidance to any Internet application. However, an operator of an 271 ALTO server could also decide to only offer guidance to a set of 272 well-known ALTO clients, e. g., after authentication and 273 authorization. In the peer-to-peer application use case, this 274 could imply that only selected trackers are allowed to access the 275 ALTO server. The security implications of using ALTO in closed 276 groups differ from the public Internet. 278 3. Covered destinations: In general, an ALTO server has to be able 279 to provide guidance for all potential destinations. Yet, in 280 practice a given ALTO client may only be interested in a subset 281 of destinations, e.g., only in the network cost between a limited 282 set of resource providers. For instance, CDN optimization may 283 not need the full ALTO cost maps, because traffic between 284 individual residential users is not in scope. This may imply 285 that an ALTO server only has to provide the costs that matter for 286 a given user, e. g., by customized maps. 288 The following sections enumerate different classes of use cases for 289 ALTO, and they discuss the deployment implications of each of them. 291 However, it must be emphasized that any application using ALTO must 292 also work if no ALTO servers can be found or if no responses to ALTO 293 queries are received, e.g., due to connectivity problems or overload 294 situations (see also [RFC6708]). 296 2.2.2. Information Exposure 298 An ALTO server stores information about preferences (e.g., a list of 299 preferred autonomous systems, IP ranges, etc.) and ALTO clients can 300 retrieve these preferences. There are basically two different 301 approaches on where the preferences are actually processed: 303 1. The ALTO server has a list of preferences and clients can 304 retrieve this list via the ALTO protocol. This preference list 305 can partially be updated by the server. The actual processing of 306 the data is done on the client and thus there is no data of the 307 client's operation revealed to the ALTO server . 309 2. The ALTO server has a list of preferences or preferences 310 calculated during runtime and the ALTO client is sending 311 information of its operation (e.g., a list of IP addresses) to 312 the server. The server is using this operational information to 313 determine its preferences and returns these preferences (e.g., a 314 sorted list of the IP addresses) back to the ALTO client. 316 Approach 1 has the advantage (seen from the client) that all 317 operational information stays within the client and is not revealed 318 to the provider of the server. On the other hand, approach 1 319 requires that the provider of the ALTO server, i.e., the network 320 operator, reveals information about its network structure (e.g., AS 321 numbers, IP ranges, topology information in general) to the ALTO 322 client. The ALTO protocol supports this scheme by the Network and 323 Cost Map Service. 325 Approach 2 has the advantage (seen from the operator) that all 326 operational information stays with the ALTO server and is not 327 revealed to the ALTO client. On the other hand, approach 2 requires 328 that the clients send their operational information to the server. 329 This approach is realized by the ALTO Endpoint Cost Service (ECS). 331 Both approaches have their pros and cons, as detailed in Section 3.3. 333 2.2.3. More Advanced Deployments 335 From an ALTO client's perspective, there are two fundamental ways to 336 use ALTO: 338 1. Single server: An ALTO client only obtains guidance from a single 339 ALTO server instance, e.g., an ALTO server that is offered by the 340 network service provider of the corresponding access network. 341 This ALTO server can be discovered e.g. by ALTO server discovery 342 [I-D.ietf-alto-server-discovery] [I-D.kist-alto-3pdisc]. 344 2. Multiple servers: An ALTO client is aware of more than one ALTO 345 server. This scenario is mostly identical to the former one if 346 all those servers provide the same guidance (e.g., load 347 balancing). Yet, an ALTO client can also decide to access 348 multiple servers providing different guidance, possibly from 349 different operators. In that case, it may be difficult for an 350 ALTO client to compare the guidance from different servers. How 351 to discover multiple servers is an open issue. 353 There are also different options regarding the guidance offered by an 354 ALTO server: 356 1. Authorative servers: An ALTO server instance can provide guidance 357 for all destinations for all kinds of ALTO clients. 359 2. Cascaded servers: An ALTO server may itself include an ALTO 360 client and query other ALTO servers, e.g., for certain 361 destinations. This results is a cascaded deployment of ALTO 362 servers, as further explained below. 364 3. Inter-server synchronization: Different ALTO servers my 365 communicate by other means. This approach is not further 366 discussed in this document. 368 An assumption of the ALTO solution is that ISP operate ALTO servers 369 independently, irrespectively of other ISPs. This may true for most 370 envisioned deployments of ALTO but there are certain deployments that 371 may have different settings. Figure 4 shows such setting with a 372 university network that is connected to two upstream providers. ISP2 373 is the national research network and ISP1 is a commercial upstream 374 provider to this university network. The university, as well as 375 ISP1, are operating their own ALTO server. The ALTO clients, located 376 on the peers will contact the ALTO server located at the university. 378 +-----------+ 379 | ISP1 | 380 | ALTO | 381 | Server | 382 +----------=+ 383 ,-------= ,------. 384 ,-' =`-. ,-' `-. 385 / Upstream= \ / Upstream \ 386 ( ISP1 = ) ( ISP2 ) 387 \ = / \ / 388 `-. =,-' `-. ,-' 389 `---+---= `+------' 390 | = | 391 | ======================= 392 |,-------------. | = 393 ,-+ `-+ +-----------+ 394 ,' University `. |University | 395 ( Network ) | ALTO | 396 `. =======================| Server | 397 `-= +-' +-----------+ 398 =`+------------'| 399 = | | 400 +--------+-+ +-+--------+ 401 | Peer1 | | PeerN | 402 +----------+ +----------+ 404 Figure 4: Cascaded ALTO Server 406 In this setting all "destinations" useful for the peers within ISP2 407 are free-of-charge for the peers located in the university network 408 (i.e., they are preferred in the rating of the ALTO server). 409 However, all traffic that is not towards ISP2 will be handled by the 410 ISP1 upstream provider. Therefore, the ALTO server at the university 411 has also to include the guidance given by the ISP1 ALTO server in its 412 replies to the ALTO clients. This is an example for cascaded ALTO 413 servers. 415 3. Deployment Considerations by ISPs 417 3.1. Objectives for the Guidance to Applications 418 3.1.1. General Objectives for Traffic Optimization 420 The Internet is a large network consisting of many networks 421 worldwide. These networks are built by network operators or Internet 422 Service Providers (named ISP in this memo), and these networks 423 provide network connectivity to access networks, such as cable 424 networks, xDSL networks, 3G/4G mobile networks, etc. Some of these 425 networks are also built by universities or big organizations. These 426 network providers need to manage, to control and to audit the 427 traffic. Thus, it's important for ISPs to understand the requirement 428 of optimizing traffic, and how to deploy ALTO service in these 429 manageability and controllability networks. 431 The objective of ALTO is to give guidance to applications on what IP 432 addresses or IP prefixes are to be preferred according to the 433 operator of the ALTO server. The ALTO protocol gives means to let 434 the ALTO server operator express its preference, whatever this 435 preference is. 437 ALTO enables ISPs to perform traffic engineering by influencing 438 application resource selections. This traffic engineering can have 439 different objectives: 441 1. Inter-network traffic localization: ALTO can help to reduce 442 inter-domain traffic. The networks of ISPs are connected through 443 peering points. From a business view, the inter-network 444 settlement is needed for exchanging traffic between these 445 networks. These peering agreements can be costly. To reduce 446 these costs, a simple objective is to decrease the traffic 447 exchange across the peering points and thus keep the traffic in 448 the own network or Autonomous System (AS) as far as possible. 450 2. Intra-network traffic localization: In case of large ISPs, the 451 network may be grouped into several networks, domains, or 452 Autonomous Systems (ASs). The core network includes one or 453 several backbone networks, which are connected to multiple 454 aggregation, metro, and access networks. If traffic can be 455 limited to access networks, this decreases the usage of backbone 456 and thus helps to save resources and costs. 458 3. Network off-loading: Compared to fixed networks, mobile networks 459 have some special characteristics, including smaller link 460 bandwidth, high cost, limited radio frequency resource, and 461 limited terminal battery. In mobile networks, the usage of 462 wireless link should be decreased as far as possible and be used 463 efficiently. For example, in the case of a P2P service, the 464 hosts in fixed networks should avoid retrieving data from hosts 465 in the mobile networks, and hosts in mobile networks should 466 prefer the data retrieval from hosts in fixed networks. 468 4. Application tuning: ALTO is also a powerful tool to optimize the 469 performance of applications that depend on the network and 470 perform resource selection decisions. 472 In the following, these objectives are explained in more detail with 473 deployment examples. 475 3.1.2. Inter-Network Traffic Localization 477 ALTO guidance can be used to keep traffic local in a network. An 478 ALTO server can let applications prefer other hosts within the same 479 network operator's network instead of randomly connecting to other 480 hosts that are located in another operator's network. Here, a 481 network operator would always express its preference for hosts in its 482 own network, while hosts located outside its own network are to be 483 avoided (i.e., they are undesired to be considered by the 484 applications). Figure 5 shows such a scenario where hosts prefer 485 hosts in the same network (e.g., Host 1 and Host 2 in ISP1 and Host 3 486 and Host 4 in ISP2). 488 ,-------. +-----------+ 489 ,---. ,-' `-. | Host 1 | 490 ,-' `-. / ISP 1 ########|ALTO Client| 491 / \ / # \ +-----------+ 492 / ISP X \ | # | +-----------+ 493 / \ \ ########| Host 2 | 494 ; +----------------------------|ALTO Client| 495 | | | `-. ,-' +-----------+ 496 | | | `-------' 497 | | | ,-------. +-----------+ 498 : | ; ,-' `########| Host 3 | 499 \ | / / ISP 2 # \ |ALTO Client| 500 \ | / / # \ +-----------+ 501 \ +---------+ # | +-----------+ 502 `-. ,-' \ | ########| Host 4 | 503 `---' \ +------------------|ALTO Client| 504 `-. ,-' +-----------+ 505 `-------' 507 Legend: 508 ### preferred "connections" 509 --- non-preferred "connections" 511 Figure 5: ALTO Traffic Network Localization 513 TBD: Describes limits of this approach (e.g., traffic localization 514 guidance is of less use if the peers cannot upload); describe how 515 maps would look like. 517 3.1.3. Intra-Network Traffic Localization 519 The above sections described the results of the ALTO guidance on an 520 inter-network level. However, ALTO can also be used for intra- 521 network localization. In this case, ALTO provides guidance which 522 internal hosts are to be preferred inside a single network or, e.g., 523 one AS. Figure 6 shows such a scenario where Host 1 and Host 2 are 524 located in Net 2 of ISP1 and connect via a low capacity link to the 525 core (Net 1) of the same ISP1. If Host 1 and Host 2 exchange their 526 data with remote hosts, they would probably congest the bottleneck 527 link. 529 ,-------. +-----------+ 530 ,---. ,-' `-. | Host 1 | 531 ,-' `-. / ISP 1 #########|ALTO Client| 532 / \ / Net 2 # \ +-----------+ 533 / ISP 1 \ | ######### | +-----------+ 534 / Net 1 \ \ # / | Host 2 | 535 ; ###; \ # ##########|ALTO Client| 536 | X~~~~~~~~~~~~X#######,-' +-----------+ 537 | ### | ^ `-------' 538 | | | 539 : ; | 540 \ / Bottleneck 541 \ / 542 \ / 543 `-. ,-' 544 `---' 545 Legend: 546 ### peer "connections" 547 ~~~ bottleneck link 549 Figure 6: Without Intra-Network ALTO Traffic Localization 551 The operator can guide the hosts in such a situation to try first 552 local hosts in the same network islands, avoiding or at least 553 lowering the effect on the bottleneck link, as shown in Figure 7. 555 ,-------. +-----------+ 556 ,---. ,-' `-. | Peer 1 | 557 ,-' `-. / ISP 1 #########|ALTO Client| 558 / \ / Net 2 # \ +-----------+ 559 / ISP 1 \ | # | +-----------+ 560 / Net 1 \ \ #########| Peer 2 | 561 ; ; \ ##########|ALTO Client| 562 | #~~~~~~~~~~~########,-' +-----------+ 563 | ### | ^ `-------' 564 | | | 565 : ; | 566 \ / Bottleneck 567 \ / 568 \ / 569 `-. ,-' 570 `---' 571 Legend: 572 ### peer "connections" 573 ~~~ bottleneck link 575 Figure 7: With Intra-Network ALTO Traffic Localization 577 3.1.4. Network Off-Loading 579 Another scenario is off-loading traffic from networks. This use of 580 ALTO can be beneficial in particular in mobile broadband networks. 581 The network operator may have the desire to guide hosts in its own 582 network to use hosts in remote networks. One reason can be that the 583 wireless network is not made for the load cause by, e.g., peer-to- 584 peer applications, and the operator has the need that peers fetch 585 their data from remote peers in other parts of the Internet. 587 ,-------. +-----------+ 588 ,---. ,-' `-. | Host 1 | 589 ,-' `-. / ISP 1 +-------|ALTO Client| 590 / \ / | \ +-----------+ 591 / ISP X \ | | | +-----------+ 592 / \ \ +-------| Host 2 | 593 ; #-###########################|ALTO Client| 594 | # | `-. ,-' +-----------+ 595 | # | `-------' 596 | # | ,-------. +-----------+ 597 : # ; ,-' `+-------| Host 3 | 598 \ # / / ISP 2 | \ |ALTO Client| 599 \ # / / | \ +-----------+ 600 \ ########### | | +-----------+ 601 `-. ,-' \ # +-------| Host 4 | 602 `---' \ ###################|ALTO Client| 603 `-. ,-' +-----------+ 604 `-------' 606 Legend: 607 === preferred "connections" 608 --- non-preferred "connections" 610 Figure 8: ALTO Traffic Network De-Localization 612 Figure 8 shows the result of such a guidance process where Host 2 613 prefers a connection with Host 4 instead of Host 1, as shown in 614 Figure 5. 616 TBD: Limits of this approach in general and with respect to p2p. 617 describe how maps would look like. 619 3.1.5. Application Tuning 621 ALTO can also provide guidance to optimize the application-level 622 topology of networked applications, e.g., by exposing network 623 performance information. Applications can often run own measurements 624 to determine network performance, e.g., by active delay measurements 625 or bandwidth probing, but such measurements result in overhead and 626 complexity. Accessing an ALTO server can be a simpler alternative. 627 In addition, an ALTO server may also expose network information that 628 applications cannot easily measure or reverse-engineer. 630 3.2. Provisioning of ALTO Maps 631 3.2.1. Data Sources 633 An ALTO server collects topological information from a variety of 634 sources in the network and provides a cohesive, abstracted view of 635 the network topology to applications using an ALTO client. The ALTO 636 server builds an ALTO-specific network topology that represents the 637 network as it should be understood and utilized by the application. 639 ALTO abstract network topologies can be auto-generated from the 640 physical or logical topology of the underlying network. The 641 generation would typically be based on policies and rules set by the 642 network operator. The maps and the guidance can significantly differ 643 depending on the use case, the network architecture, and the trust 644 relationship between ALTO server and ALTO client, etc. Besides the 645 security requirements that consist of not delivering any confidential 646 or critical information about the infrastructure, there are 647 efficiency requirements in terms of what aspects of the network are 648 visible and required by the given use case and/or application. 650 The ALTO server builds topology (for either Map and ECS services) 651 based on multiple sources that may include routing protocols, network 652 policies, state and performance information, geo-location, etc. The 653 network topology information is controlled and managed by the ALTO 654 server. In all cases, the ALTO topology will not contain any details 655 that would endanger the network integrity and security. For 656 instance, ALTO is not intended to leak raw IGP/BGP databases to ALTO 657 clients. 659 +--------+ +--------+ 660 | Client | | Client | 661 +--------+ +--------+ 662 ^ ^ 663 | | ALTO protocol 664 +---------+ 665 | ALTO | 666 | Server | 667 +---------+ 668 ^ ^ ^ Potential 669 | | | data sources 670 +--------+ | +--------+ 671 | | | 672 +---------+ +---------+ +---------+ 673 | BGP | | I2RS | | NMS | 674 | Speaker | | Client | | OSS | 675 +---------+ +---------+ +---------+ 676 ^ ^ ^ 677 | | | 678 Link-State I2RS SNMP/NETCONF, 679 NLRI for data traffic statistics, 680 IGP/BGP IPFIX, etc. 682 Figure 9: Data sources for ALTO 684 As illustrated in Figure 9, the topology data used by an ALTO server 685 can originate from different data sources: 687 o The document [I-D.ietf-idr-ls-distribution] describes a mechanism 688 by which links state and traffic engineering information can be 689 collected from networks and shared with external components using 690 the BGP routing protocol. This is achieved using a new BGP 691 Network Layer Reachability Information (NLRI) encoding format. 692 The mechanism is applicable to physical and virtual IGP links and 693 can also include Traffic Engineering (TE) data. For instance, 694 prefix data can be carried and originated in BGP, while TE data is 695 originated and carried in an IGP. The mechanism described is 696 subject to policy control. Note an ALTO Server can use other 697 mechanisms to get network data, for example, peering with multiple 698 IGP and BGP Speakers. 700 o The Interface to the Routing System (I2RS) is a solution for state 701 transfer in and out of the Internet's routing system 702 [I-D.ietf-i2rs-architecture]. An ALTO server could use an I2RS 703 client to observe routing-related information. 705 o An ALTO server can also leverage Network Management Station (NMS) 706 or an Operations Support System (OSS) as data sources. A NMS or 707 OSS solutions are used to control, operate, and manage a network, 708 e.g., using the Simple Network Management Protocol (SNMP) or 709 NETCONF. As explained for instance in 710 [I-D.farrkingel-pce-abno-architecture], the NMS and OSS can be 711 consumers of network events reported and can act on these reports 712 as well as displaying them to users and raising alarms. The NMS 713 and OSS can also access the Traffic Engineering Database (TED) and 714 Label Switched Path Database (LSP-DB) to show the users the 715 current state of the network. In addition, NMS and OSS systems 716 may have access to IGP/BGP routing information, network inventory 717 data (e.g., links, nodes, or link properties not visible to 718 routing protocols, such as Shared Risk Link Groups), statistics 719 collection system that provides traffic information, such as 720 traffic demands or link utilizations obtained from IP Flow 721 Information Export (IPFIX), as well as other information (e.g., 722 syslog). NMS or OSS systems also may have functions to correlate 723 and orchestrate information originating from other data sources. 724 For instance, it could be required to correlate IP prefixes with 725 routers (Provider, Provider Edge, Custumer Edge, etc.), IGP areas, 726 VLAN IDs, or policies. 728 3.2.2. Privacy Requirements 730 Providing ALTO guidance results in a win-win situation both for 731 network providers and users of the ALTO information. Applications 732 possibly get a better performance, while the the network provider has 733 means to optimize the traffic engineering and thus its costs. 735 Still, ISPs may have other important requirements when deploying 736 ALTO: In particular, an ISP may not be willing to expose sensitive 737 operational details of its network. The topology abstraction of ALTO 738 enables an ISP to expose the network topology at a desired 739 granularity only. 741 With the ALTO Endpoint Cost Service, the ALTO client does not to have 742 to implement any specific algorithm or mechanism in order to 743 retrieve, maintain and process network topology information (of any 744 kind). The complexity of the network topology (computation, 745 maintenance and distribution) is kept in the ALTO server and ECS is 746 delivered on demand. This allows the ALTO server to enhance and 747 modify the way the topology information sources are used and 748 combined. This simplifies the enforcement of privacy policies of the 749 ISP. 751 The ALTO Network Map and Cost Map service expose an abstracted view 752 on the ISP network topology. Therefore, in this case care is needed 753 when constructing those maps, as further discussed in Section 3.2.3. 755 3.2.3. Map Partitioning and Grouping 757 Host group descriptors are used in the ALTO client protocol to 758 describe the location of a host in the network topology. These 759 identifiers are called Partition ID (PID) and e.g. expand to a set of 760 IP address ranges (CIDR). 762 An automated ALTO implementation may use dynamic algorithms to 763 aggregate network topology. However, it is often desirable to have a 764 mechanism through which the network operator can control the level 765 and details of network aggregation based on a set of requirements and 766 constraints. This will typically be governed by policies that 767 enforce a certain level of abstraction and prevent leakage of 768 sensitive operational data. 770 For instance, an ALTO server may leverage BGP information that is 771 available in a networks service provider network layer and compute 772 the group of prefix. An example are BGP Communities, which are used 773 in MPLS/IP networks as a common mechanism to aggregate and group 774 prefixes. A BGP Community is an attribute used to tag a prefix to 775 group prefixes based on mostly any criteria (as an example, most ISP 776 networks originate BGP prefixes with communities identifying the 777 Point of Presence (PoP) where the prefix has been originated). These 778 BGP communities could be used to map IP address ranges to PIDs. By 779 an additional policy, the ALTO server operator may decide an 780 arbitrary cost defined between groups. Alternatively, there are 781 algorithms that allows a dynamic computation of cost between groups. 783 3.2.4. Rating Criteria and/or Cost Calculation 785 Rating criteria are used in the ALTO client protocol to express 786 topology- or connectivity-related properties, which are evaluated in 787 order to generate the ALTO guidance. The ALTO client protocol 788 specification defines a basic set of rating criteria, which have to 789 be supported by all implementations, and an extension procedure for 790 adding new criteria. 792 The following list gives an overview on further rating criteria that 793 have been proposed or which are in use by ALTO-related prototype 794 implementations. This list is not intended as normative text. 795 Instead, the only purpose of the following list is to document the 796 rating criteria that have been proposed so far. It can also depend 797 on the use case of ALTO whether such rating criteria are useful, and 798 whether the corresponding information would indeed be made available 799 by ISPs. 801 Distance-related rating criteria: 803 o Relative topological distance: The term relative means that a 804 larger numerical value means greater distance, but it is up to the 805 ALTO service how to compute the values, and the ALTO client will 806 not be informed about the nature of the information. One way of 807 generating this kind of information may be counting AS hops, but 808 when querying this parameter, the ALTO client must not assume that 809 the numbers actually are AS hops. 811 o Absolute topological distance, expressed in the number of 812 traversed autonomous systems (AS). 814 o Absolute topological distance, expressed in the number of router 815 hops (i.e., how much the TTL value of an IP packet will be 816 decreased during transit). 818 o Absolute physical distance, based on knowledge of the approximate 819 geolocation (e.g., continent, country) of an IP address. 821 Performance-related rating criteria: 823 o The minimum achievable throughput between the resource consumer 824 and the candidate resource provider, which is considered useful by 825 the application (only in ALTO queries). 827 o An arbitrary upper bound for the throughput from/to the candidate 828 resource provider (only in ALTO responses). This may be, but is 829 not necessarily the provisioned access bandwidth of the candidate 830 resource provider. 832 o The maximum round-trip time (RTT) between resource consumer and 833 the candidate resource provider, which is acceptable for the 834 application for useful communication with the candidate resource 835 provider (only in ALTO queries). 837 o An arbitrary lower bound for the RTT between resource consumer and 838 the candidate resource provider (only in ALTO responses). This 839 may be, for example, based on measurements of the propagation 840 delay in a completely unloaded network. 842 Charging-related rating criteria: 844 o Traffic volume caps, in case the Internet access of the resource 845 consumer is not charged by "flat rate". For each candidate 846 resource provider, the ALTO service could indicate the amount of 847 data that may be transferred from/to this resource provider until 848 a given point in time, and how much of this amount has already 849 been consumed. Furthermore, it would have to be indicated how 850 excess traffic would be handled (e.g., blocked, throttled, or 851 charged separately at an indicated price). The interaction of 852 several applications running on a host, out of which some use this 853 criterion while others don't, as well as the evaluation of this 854 criterion in resource directories, which issue ALTO queries on 855 behalf of other peers, are for further study. 857 These rating criteria are subject to the remarks below: 859 The ALTO client must be aware, that with high probability, the actual 860 performance values differ significantly from these upper and lower 861 bounds. In particular, an ALTO client must not consider the "upper 862 bound for throughput" parameter as a permission to send data at the 863 indicated rate without using congestion control mechanisms. 865 The discrepancies are due to various reasons, including, but not 866 limited to the facts that 868 o the ALTO service is not an admission control system 870 o the ALTO service may not know the instantaneous congestion status 871 of the network 873 o the ALTO service may not know all link bandwidths, i.e., where the 874 bottleneck really is, and there may be shared bottlenecks 876 o the ALTO service may not have all information about the actual 877 routing 879 o the ALTO service may not know whether the candidate peer itself is 880 overloaded 882 o the ALTO service may not know whether the candidate peer throttles 883 the bandwidth it devotes for the considered application 885 o the ALTO service may not know whether the candidate peer will 886 throttle the data it sends to us (e.g., because of some fairness 887 algorithm, such as tit-for-tat). 889 Because of these inaccuracies and the lack of complete, instantaneous 890 state information, which are inherent to the ALTO service, the 891 application must use other mechanisms (such as passive measurements 892 on actual data transmissions) to assess the currently achievable 893 throughput, and it must use appropriate congestion control mechanisms 894 in order to avoid a congestion collapse. Nevertheless, these rating 895 criteria may provide a useful shortcut for quickly excluding 896 candidate resource providers from such probing, if it is known in 897 advance that connectivity is in any case worse than what is 898 considered the minimum useful value by the respective application. 900 Rating criteria that should not be defined for and used by the ALTO 901 service include: 903 o Performance metrics that are closely related to the instantaneous 904 congestion status. The definition of alternate approaches for 905 congestion control is explicitly out of the scope of ALTO. 906 Instead, other appropriate means, such as using TCP based 907 transport, have to be used to avoid congestion. 909 o Performance metrics that raise privacy concerns. For instance, it 910 has been questioned whether an ALTO service could publicly expose 911 the provisioned access bandwidth, e.g. of cable / DSL customers, 912 because this could enables identification of "premium" customers. 914 3.3. Known Limitations of ALTO 916 This section describes some known limitations of ALTO in general or 917 specific mechanisms in ALTO. 919 3.3.1. Limitations of Map-based Approaches 921 The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses 922 so-called network maps. The network map approach uses host group 923 descriptors that group one or multiple subnetworks (i.e., IP 924 prefixes) to a single aggregate. A set of IP prefixes is called 925 partition and the associated Host Group Descriptor is called 926 Partition ID (PID). The "costs" between the various partition IDs is 927 stored in a second map, the cost map. Map-based approaches lower the 928 signaling load on the server as maps have to be retrieved only if 929 they change. 931 One main assumption for map-based approaches is that the information 932 provided in these maps is static for a longer period of time. This 933 assumption is fine as long as the network operator does not change 934 any parameter, e.g., routing within the network and to the upstream 935 peers, IP address assignment stays stable (and thus the mapping to 936 the partitions). However, there are several cases where this 937 assumption is not valid: 939 1. ISPs reallocate IP subnets from time to time; 941 2. ISPs reallocate IP subnets on short notice; 943 3. IP prefix blocks may be assigned to a router that serves a 944 variety of access networks; 946 4. Network costs between IP prefixes may change depending on the 947 ISP's routing and traffic engineering. 949 Explanation: 951 For 1): ISPs reallocate IPv4 subnets within their infrastructure from 952 time to time, partly to ensure the efficient usage of IPv4 addresses 953 (a scarce resource), and partly to enable efficient route tables 954 within their network routers. The frequency of these "renumbering 955 events" depend on the growth in number of subscribers and the 956 availability of address space within the ISP. As a result, a 957 subscriber's household device could retain an IPv4 address for as 958 short as a few minutes, or for months at a time or even longer. 960 It has been suggested that ISPs providing ALTO services could sub- 961 divide their subscribers' devices into different IPv4 subnets (or 962 certain IPv4 address ranges) based on the purchased service tier, as 963 well as based on the location in the network topology. The problem 964 is that this sub-allocation of IPv4 subnets tends to decrease the 965 efficiency of IPv4 address allocation. A growing ISP that needs to 966 maintain high efficiency of IPv4 address utilization may be reluctant 967 to jeopardize their future acquisition of IPv4 address space. 969 However, this is not an issue for map-based approaches if changes are 970 applied in the order of days. 972 For 2): ISPs can use techniques that allow the reallocation of IP 973 prefixes on very short notice, i.e., within minutes. An IP prefix 974 that has no IP address assignment to a host anymore can be 975 reallocated to areas where there is currently a high demand for IP 976 addresses. 978 For 3): In residential access networks (e.g., DSL, cable), IP 979 prefixes are assigned to broadband gateways, which are the first IP- 980 hop in the access-network between the Customer Premises Equipment 981 (CPE) and the Internet. The access-network between CPE and broadband 982 gateway (called aggregation network) can have varying characteristics 983 (and thus associated costs), but still using the same IP prefix. For 984 instance one IP addresses IP11 out of a IP prefix IP1 can be assigned 985 to a VDSL (e.g., 2 MBit/s uplink) access line while the subsequent IP 986 address IP12 is assigned to a slow ADSL line (e.g., 128 kbit/s 987 uplink). These IP addresses are assigned on a first come first 988 served basis, i.e., the a single IP address out of the same IP prefix 989 can change its associated costs quite fast. This may not be an issue 990 with respect to the used upstream provider (thus the cross ISP 991 traffic) but depending on the capacity of the aggregation-network 992 this may raise to an issue. 994 For 4): The routing and traffic engineering inside an ISP network, as 995 well as the peering with other autonomous systems, can change 996 dynamically and affect the information exposed by an ALTO server. As 997 a result, cost map and possibly also network maps can change. 999 3.3.2. Limitiations of Non-Map-based Approaches 1001 The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses, 1002 amongst others mechanism, a mechanism called Endpoint Cost Service 1003 (ECS). ALTO clients can ask guidance for specific IP addresses to 1004 the ALTO server. However, asking for IP addresses, asking with long 1005 lists of IP addresses, and asking quite frequently may overload the 1006 ALTO server. The server has to rank each received IP address, which 1007 causes load at the server. This may be amplified by the fact that 1008 not only a single ALTO client is asking for guidance, but a larger 1009 number of them. The results of the ECS are also more difficult to 1010 cache than ALTO maps. 1012 Caching of IP addresses at the ALTO client or the usage of the H12 1013 approach [I-D.kiesel-alto-h12] in conjunction with caching may lower 1014 the query load on the ALTO server. 1016 3.4. Monitoring the Performance of ALTO 1018 3.4.1. Supervising the Benefits of ALTO 1020 An ISP providing ALTO may want to assess the benefits of ALTO as part 1021 of the management and operations (cf. [I-D.ietf-alto-protocol]). For 1022 instance, the ISP might be interested in understanding whether the 1023 provided ALTO maps are effective, and in order to decide whether an 1024 adjustment of the ALTO configuration would be useful. Such insight 1025 can be obtained from a monitoring infrastructure. An NSP offering 1026 ALTO could consider the impact on (or integration with) traffic 1027 engineering and the deployment of a monitoring service to observe the 1028 effects of ALTO operations. To construct an effective monitoring 1029 infrastructure, the ISP should decise how to monitor the performance 1030 of ALTO and identify and deploy data sources to collect data to 1031 compute the performance metrics. The required monitoring depends on 1032 the network infrastructure and the use of ALTO, and an exhaustive 1033 description is outside the scope of this document. 1035 3.4.2. How to Monitor ALTO Performance 1037 ALTO realizes an interface between the network and applications. 1038 This implies that an effective monitoring infrastructure may have to 1039 deal with both network and application performance metrics. This 1040 document does not comprehensively list all performance metrics that 1041 could be relevant, nor does it formally specify metrics. 1043 The performance impact of ALTO can be classified in a number of 1044 different categories: 1046 o Total amount and distribution of traffic: ALTO enables ISPs to 1047 influence and localize traffic of applications that use the ALTO 1048 service. An ISP may therefore be interested in analyzing the 1049 impact on the traffic, i.e., whether network traffic patterns are 1050 shifted. For instance, if ALTO shall be used to reduce the inter- 1051 domain P2P traffic, it makes sense to evaluate the total amount of 1052 inter-domain traffic of an ISP. Then, one possibility is to study 1053 how the introduction of ALTO reduces the total interdomain traffic 1054 (inbound and/our outbound). If the ISPs intention is to localize 1055 the traffic inside his network, the network-internal traffic 1056 distribution will be of interest. Effectiveness of localization 1057 can be quantified in different ways, e.g., by the load on core 1058 routers and backbone links, or by considering more advanced 1059 effects, such as the average number of hops that traffic traverses 1060 inside a domain. 1062 o Application performance: The objective of ALTO is improve 1063 application performance. ALTO can be used by very different types 1064 applications, with different communication characteristics and 1065 requirements. For instance, if ALTO guidance achieves traffic 1066 localization, one would expect that applications achieve a higher 1067 throughput and/or smaller delays to retrieve data. Application- 1068 specific performance characteristics (e.g., video or audio 1069 quality) can be useful as well. In addition, selected statistics 1070 from the TCP/IP stack in hosts can be useful, e.g., the number of 1071 retransmitted TCP segments. 1073 o ALTO system performance: As mentioned in [I-D.ietf-alto-protocol], 1074 there are a number of interesting parameters that can be measured 1075 at an ALTO server, including the Requests and responses for each 1076 service listed in a Information Directory (total counts and size 1077 in bytes) or the CPU and memory utilization. Also, the 1078 characteristics of the ALTO maps can be monitored as well, e.g., 1079 regarding the frequency of ALTO map updates, the number of PIDs, 1080 or the ALTO map sizes (in-memory size, encoded size, number of 1081 entries). 1083 o ALTO service utilization: Of potential interet can be the share of 1084 applications or customers that actually use an offered ALTO 1085 service, i.e., the degree of adoption. 1087 Monitoring statistics can be aggregated, averaged, and normalized in 1088 different ways. This document does not mandate specific ways how to 1089 calculate metrics. 1091 One way to quantify the benefit of deploying ALTO is to measure 1092 before and after enabling the ALTO service. In addition to passive 1093 monitoring, some data could also be obtained by active measurements, 1094 but due to the resulting overhead, the latter should be used with 1095 care. Yet, in all monitoring activities an ALTO service provider has 1096 to take into account that ALTO Clients are not bound to ALTO Server 1097 guidance as ALTO is only one source of information, and any 1098 measurement result may thus be biased. 1100 3.4.3. Monitoring Infrastructure 1102 Understanding the impact of ALTO may require interaction between 1103 different systems, operating at different layers. Some information 1104 discussed in the preceding section is only visible to an ISP, while 1105 application-level performance can hardly be measured inside the 1106 network. It is possible that not all information of potential 1107 interest can directly be measured, either because no corresponding 1108 monitoring infrastructure or measurement method exists, or because it 1109 is not easily accessible. 1111 Potential sources for monitoring the use of ALTO include: 1113 o Network Operations, Administration, and Maintenance (OAM) systems: 1114 Many ISPs deploy OAM systems to monitor the network traffic, which 1115 may have insight into traffic volumes, network topology, and 1116 bandwidth information inside the management area. Data can be 1117 obtained by SNMP, Netflow, IP Flow Information Export (IPFIX), 1118 syslog, etc. 1120 o Applications/clients: Relevant data could be obtained by 1121 instrumentation of applications. 1123 o ALTO server: If available, log files or other statistics data 1124 could be analyzed. 1126 o Other application entities: In several use cases, there are other 1127 application entities that could provide data as well. For 1128 instance, there may be centralized log servers that collect data. 1130 In many ALTO use cases some data sources are located within an ISP 1131 while some other data is gathered at application level. Correlation 1132 of data would require a collaboration agreement between the ISP and 1133 an application owner, including aggrements of data interchange 1134 formats, methods of delivery, etc. In practice, such a collaboration 1135 may not be possible in all use cases of ALTO, because the monitoring 1136 data can be sensitive, and because the interacting entities may have 1137 different priorities. Details of how to build an over-arching 1138 monitoring system for evaluating the benefits of ALTO are outside the 1139 scope of this memo. 1141 3.5. Map Examples for Different Types of ISPs 1143 3.5.1. Small ISP with Single Internet Uplink 1145 For a small ISP, the inter-domain traffic optimizing problem is how 1146 to decrease the traffic exchanged with other ISPs, because of high 1147 settlement costs. By using the ALTO service to optimize traffic, a 1148 small ISP can define two "optimization areas": one is its own 1149 network; the other one consists of all other network destinations. 1150 The cost map can be defined as follows: the cost of link between 1151 clients of inner ISP's networks is lower than between clients of 1152 outer ISP's networks and clients of inner ISP's network. As a 1153 result, a host with ALTO client inside the network of this ISP will 1154 prefer retrieving data from hosts connected to the same ISP. 1156 An example is given in Figure 10. It is assumed that ISP A is a 1157 small ISP only having one access network. As operator of the ALTO 1158 service, ISP A can define its network to be one optimization area, 1159 named as PID1, and define other networks to be the other optimization 1160 area, named as PID2. C1 is denoted as the cost inside the network of 1161 ISP A. C2 is denoted as the cost from PID2 to PID1, and C3 from PID1 1162 to PID2. For the sake of simplifity, in the following C2=C3 is 1163 assumed. In order to keep traffic local inside ISP A, it makes sense 1164 to define: C1|PID 2 |<--->+PID 3 | | 1294 | |C1 | |C2 | |C3 | | +----------------+ 1295 | +---+--+ +------+ +-+----+ | | | 1296 | | | | C8 | Other Networks | 1297 | +----------------------+ |<--------+ PID 5 | 1298 | C6 | | | 1299 | | | | 1300 +------------------------------------+ +----------------+ 1302 Figure 13: ALTO deployment in large ISPs with layered fixed network 1303 structures 1305 3.5.3. ISP with Fixed and Mobile Network 1307 An ISP with both mobile network and fixed network my focus on 1308 optimizing the mobile traffic by keeping traffic in the fixed network 1309 as far as possible, because wireless bandwidth is a scarce resource 1310 and traffic is costly in mobile network. In such a case, the main 1311 requirement of traffic optimization could be decreasing the usage of 1312 radio resources in the mobile network. An ALTO service can be 1313 deployed to meet these needs. 1315 Figure 14 shows an example: ISP A operates one mobile network, which 1316 is connected to a backbone network. The ISP also runs two fixed 1317 access networks AN A and AN B, which are also connected to the 1318 backbone network. In this network structure, the mobile network can 1319 be defined as one optimization area, and PID 1 can be assigned to it. 1320 Access networks AN A and B can also be defined as optimization areas, 1321 and PID 2 and PID 3 can be assigned, respectively. The cost values 1322 are then defined as shown in Figure 14. 1324 To decrease the usage of wireless link, the relationship of these 1325 costs can be defined as follows: 1327 From view of mobile network: C4 < C1. This means that clients in 1328 mobile network requiring data resource from other clients will prefer 1329 clients in AN A to clients in the mobile network. This policy can 1330 decrease the usage of wireless link and power consumption in 1331 terminals. 1333 From view of AN A: C2 < C6, C5 = maximum cost. This means that 1334 clients in other optimization area will avoid retrieving data from 1335 the mobile network. 1337 +-----------------------------------------------------------------+ 1338 | | 1339 | ISP A +-------------+ | 1340 | +--------+ ALTO +---------+ | 1341 | | | Service | | | 1342 | | +------+------+ | | 1343 | | | | | 1344 | | | | | 1345 | | | | | 1346 | +-------+-------+ | C6 +--------+------+ | 1347 | | AN A |<--------------| AN B | | 1348 | | PID 2 | C7 | | PID 3 | | 1349 | | C2 |-------------->| C3 | | 1350 | +---------------+ | +---------------+ | 1351 | ^ | | | ^ | 1352 | | | | | | | 1353 | | |C4 | | | | 1354 | C5 | | | | | | 1355 | | | +--------+---------+ | | | 1356 | | +-->| Mobile Network |<---+ | | 1357 | | | PID 1 | | | 1358 | +------- | C1 |----------+ | 1359 | +------------------+ | 1360 +-----------------------------------------------------------------+ 1362 Figure 14: ALTO deployment in ISPs with mobile network 1364 3.6. Deployment Experiences 1366 The examples in the previous section are simple and do not consider 1367 specific requirements inside access networks, such as different link 1368 types. Deploying an ALTO service in real network will have to 1369 require further network conditions and requirements. One real 1370 example is described in greater detail in reference 1371 [I-D.lee-alto-chinatelecom-trial]. 1373 Also, experiments have been conducted with ALTO-like deployments in 1374 Internet Service Provider (ISP) networks. For instance, NTT 1375 performed tests with their HINT server implementation and dummy nodes 1376 to gain insight on how an ALTO-like service influence peer-to-peer 1377 systems [I-D.kamei-p2p-experiments-japan]. The results of an early 1378 experiment conducted in the Comcast network are documented in 1379 [RFC5632]. 1381 4. Using ALTO for P2P Traffic Optimization 1383 4.1. Overview 1385 4.1.1. Usage Scenario 1387 Peer-to-peer applications can be build without and with use of a 1388 centralized resource directory ("tracker"). The scope of this 1389 section is the interaction of P2P applications with the ALTO service, 1390 focusing on the use case with a centralized resource directory. In 1391 this scenario, the resource consumer ("peer") asks the resource 1392 directory for a list of candidate resource providers, which can 1393 provide the desired resource. 1395 For efficiency reasons (i.e., message size), usually only a subset of 1396 all resource providers known to the resource directory will be 1397 returned to the resource consumer. Some or all of these resource 1398 providers, plus further resource providers learned by other means 1399 such as direct communication between peers, will be contacted by the 1400 resource consumer for accessing the resource. The purpose of ALTO is 1401 giving guidance on this peer selection, which is supposed to yield 1402 better-than-random results. The tracker response as well as the ALTO 1403 guidance are most beneficial in the initial phase after the resource 1404 consumer has decided to access a resource, as long as only few 1405 resource providers are known. Later, when the resource consumer has 1406 already exchanged some data with other peers and measured the 1407 transmission speed, the relative importance of ALTO may dwindle. 1409 4.1.2. Applicability of ALTO 1411 A tracker-based P2P application can leverage ALTO in different ways. 1412 In the following, the different alternatives and their pros and cons 1413 are discussed. 1415 ,-------. 1416 ,---. ,-' `-. +-----------+ 1417 ,-' `-. / ISP 1 \ | Peer 1 |***** 1418 / \ / +-------------+ \ | | * 1419 / ISP X \ +=====>| ALTO Server | )+-----------+ * 1420 / \ = \ +-------------+ / +-----------+ * 1421 ; +-----------+ : = \ / | Peer 2 | * 1422 | | Tracker |<====+ `-. ,-' | |***** 1423 | |ALTO Client|<====+ `-------' +-----------+ ** 1424 | +-----------+ | = ,-------. ** 1425 : * ; = ,-' `-. +-----------+ ** 1426 \ * / = / ISP 2 \ | Peer 3 | ** 1427 \ * / = / +-------------+ \ | |***** 1428 \ * / +=====>| ALTO Server | )+-----------+ *** 1429 `-. * ,-' \ +-------------+ / +-----------+ *** 1430 `-*-' \ / | Peer 4 |***** 1431 * `-. ,-' | | **** 1432 * `-------' +-----------+ **** 1433 * **** 1434 * **** 1435 ***********************************************<****** 1436 Legend: 1437 === ALTO client protocol 1438 *** Application protocol 1440 Figure 15: Global tracker accessing ALTO server at various ISPs 1442 Figure 15 depicts a tracker-based system in which the tracker embeds 1443 the ALTO client. The tracker itself is hosted and operated by an 1444 entity different than the ISP hosting and operating the ALTO server. 1445 A tracker outside the network of the ISP is the typical use case. 1446 For instance, a tracker like Pirate Bay can serve Bittorrent peers 1447 world-wide. Initially, the tracker has to look-up the ALTO server in 1448 charge for each peer where it receives a ALTO query for. Therefore, 1449 the ALTO server has to discover the handling ALTO server, as 1450 described in [I-D.ietf-alto-server-discovery]. However, the peers do 1451 not have any way to query the server themselves. This setting allows 1452 giving the peers a better selection of candidate peers for their 1453 operation at an initial time, but does not consider peers learned 1454 through direct peer-to-peer knowledge exchange. This is called peer 1455 exchange (PEX) in bittorent, for instance. 1457 ,-------. +-----------+ 1458 ,---. ,-' `-. +==>| Peer 1 |***** 1459 ,-' `-. / ISP 1 \ = |ALTO Client| * 1460 / \ / +-------------+<=+ +-----------+ * 1461 / ISP X \ | + ALTO Server |<=+ +-----------+ * 1462 / \ \ +-------------+ /= | Peer 2 | * 1463 ; +---------+ : \ / +==>|ALTO Client|***** 1464 | | Global | | `-. ,-' +-----------+ ** 1465 | | Tracker | | `-------' ** 1466 | +---------+ | ,-------. +-----------+ ** 1467 : * ; ,-' `-. +==>| Peer 3 | ** 1468 \ * / / ISP 2 \ = |ALTO Client|***** 1469 \ * / / +-------------+<=+ +-----------+ *** 1470 \ * / | | ALTO Server |<=+ +-----------+ *** 1471 `-. * ,-' \ +-------------+ /= | Peer 4 |***** 1472 `-*-' \ / +==>|ALTO Client| **** 1473 * `-. ,-' +-----------+ **** 1474 * `-------' **** 1475 * **** 1476 ***********************************************<**** 1477 Legend: 1478 === ALTO client protocol 1479 *** Application protocol 1481 Figure 16: Global Tracker - Local ALTO Servers 1483 The scenario in Figure 16 lets the peers directly communicate with 1484 their ISP's ALTO server (i.e., ALTO client embedded in the peers), 1485 giving thus the peers the most control on which information they 1486 query for, as they can integrate information received from trackers 1487 and through direct peer-to-peer knowledge exchange. 1489 ,-------. +-----------+ 1490 ,---. ,-' ISP 1 `-. ***>| Peer 1 | 1491 ,-' `-. /+-------------+\ * | | 1492 / \ / + Tracker |<** +-----------+ 1493 / ISP X \ | +-----===-----+<** +-----------+ 1494 / \ \ +-----===-----+ /* | Peer 2 | 1495 ; +---------+ : \+ ALTO Server |/ ***>| | 1496 | | Global | | +-------------+ +-----------+ 1497 | | Tracker | | `-------' 1498 | +---------+ | +-----------+ 1499 : ^ ; ,-------. | Peer 3 | 1500 \ * / ,-' ISP 2 `-. ***>| | 1501 \ * / /+-------------+\ * +-----------+ 1502 \ * / / + Tracker |<** +-----------+ 1503 `-. *,-' | +-----===-----+ | | Peer 4 |<* 1504 `---* \ +-----===-----+ / | | * 1505 * \+ ALTO Server |/ +-----------+ * 1506 * +-------------+ * 1507 * `-------' * 1508 *********************************************** 1509 Legend: 1510 === ALTO client protocol 1511 *** Application protocol 1513 Figure 17: P4P approach with local tracker and local ALTO server 1515 There are some attempts to let ISP's to deploy their own trackers, as 1516 shown in Figure 17. In this case, the client has no chance to get 1517 guidance from the ALTO server, other than talking to the ISP's 1518 tracker. However, the peers would have still chance the contact 1519 other trackers, deployed by entities other than the peer's ISP. 1521 Figure 17 and Figure 15 ostensibly take peers the possibility to 1522 directly query the ALTO server, if the communication with the ALTO 1523 server is not permitted for any reason. However, considering the 1524 plethora of different applications of ALTO, e.g., multiple tracker 1525 and non-tracker based P2P systems and or applications searching for 1526 relays, it seems to be beneficial for all participants to let the 1527 peers directly query the ALTO server. The peers are also the single 1528 point having all operational knowledge to decide whether to use the 1529 ALTO guidance and how to use the ALTO guidance. This is a preference 1530 for the scenario depicted in Figure Figure 16. 1532 4.2. Deployment Recommendations 1533 4.2.1. ALTO Services 1535 In case of peer-to-peer networks, two different ALTO services can be 1536 used: The Cost Map Service is often prefered as solution by peer-to- 1537 peer software implementors and users, since it avoids disclosuring 1538 peer IP addresses to a centralized entity. Different to that, 1539 network operators may have a preference for the Endpoint Cost 1540 Service, since it does not require exposure of the network topology. 1542 For actual use of ALTO in P2P applications, both software vendors and 1543 network operators have to agree which ALTO services to use. The ALTO 1544 protocol is flexible and supports both services. Note that for other 1545 use cases of ALTO, in particular in more controlled environments, 1546 both the Cost Map Service as well as ECS might be feasible and it is 1547 more an engineering tradeoff whether to use a map-based or query- 1548 based ALTO service. 1550 4.2.2. Guidance Considerations 1552 The ALTO protocol specification [I-D.ietf-alto-protocol] details how 1553 an ALTO client can query an ALTO server for guiding information and 1554 receive the corresponding replies. However, in the considered 1555 scenario of a tracker-based P2P application, there are two 1556 fundamentally different possibilities where to place the ALTO client: 1558 1. ALTO client in the resource consumer ("peer") 1560 2. ALTO client in the resource directory ("tracker") 1562 In the following, both scenarios are compared in order to explain the 1563 need for third-party ALTO queries. 1565 In the first scenario (see Figure 18), the resource consumer queries 1566 the resource directory for the desired resource (F1). The resource 1567 directory returns a list of potential resource providers without 1568 considering ALTO (F2). It is then the duty of the resource consumer 1569 to invoke ALTO (F3/F4), in order to solicit guidance regarding this 1570 list. 1572 Peer w. ALTO cli. Tracker ALTO Server 1573 --------+-------- --------+-------- --------+-------- 1574 | F1 Tracker query | | 1575 |======================>| | 1576 | F2 Tracker reply | | 1577 |<======================| | 1578 | F3 ALTO client protocol query | 1579 |---------------------------------------------->| 1580 | F4 ALTO client protocol reply | 1581 |<----------------------------------------------| 1582 | | | 1584 ==== Application protocol (i.e., tracker-based P2P app protocol) 1585 ---- ALTO client protocol 1587 Figure 18: Basic message sequence chart for resource consumer- 1588 initiated ALTO query 1590 In the second scenario (see Figure 19), the resource directory has an 1591 embedded ALTO client, which we will refer to as RDAC in this 1592 document. After receiving a query for a given resource (F1) the 1593 resource directory invokes the RDAC to evaluate all resource 1594 providers it knows (F2/F3). Then it returns a, possibly shortened, 1595 list containing the "best" resource providers to the resource 1596 consumer (F4). 1598 Peer Tracker w. RDAC ALTO Server 1599 --------+-------- --------+-------- --------+-------- 1600 | F1 Tracker query | | 1601 |======================>| | 1602 | | F2 ALTO cli. p. query | 1603 | |---------------------->| 1604 | | F3 ALTO cli. p. reply | 1605 | |<----------------------| 1606 | F4 Tracker reply | | 1607 |<======================| | 1608 | | | 1610 ==== Application protocol (i.e., tracker-based P2P app protocol) 1611 ---- ALTO client protocol 1613 Figure 19: Basic message sequence chart for third-party ALTO query 1615 Note: the message sequences depicted in Figure 18 and Figure 19 may 1616 occur both in the target-aware and the target-independent query mode 1617 (c.f. [RFC6708]). In the target-independent query mode no message 1618 exchange with the ALTO server might be needed after the tracker 1619 query, because the candidate resource providers could be evaluated 1620 using a locally cached "map", which has been retrieved from the ALTO 1621 server some time ago. 1623 The first approach has the following problem: While the resource 1624 directory might know thousands of peers taking part in a swarm, the 1625 list returned to the resource consumer is usually shortened for 1626 efficiency reasons. Therefore, the "best" (in the sense of ALTO) 1627 potential resource providers might not be contained in that list 1628 anymore, even before ALTO can consider them. 1630 Much better traffic optimization could be achieved if the tracker 1631 would evaluate all known peers using ALTO. This list would then 1632 include a significantly higher fraction of "good" peers. (Note, that 1633 if the tracker returned "good" peers only, there might be a risk that 1634 the swarm might disconnect and split into several disjunct 1635 partitions. However, finding the right mix of ALTO-biased and random 1636 peer selection is out of the scope of this document.) 1638 Therefore, from an overall optimization perspective, the second 1639 scenario with the ALTO client embedded in the resource directory is 1640 advantageous, because it is ensured that the addresses of the "best" 1641 resource providers are actually delivered to the resource consumer. 1642 An architectural implication of this insight is that the ALTO server 1643 discovery procedures must support third-party discovery. That is, as 1644 the tracker issues ALTO queries on behalf of the peer which contacted 1645 the tracker, the tracker must be able to discover an ALTO server that 1646 can give guidance suitable for that respective peer (see 1647 [I-D.kist-alto-3pdisc]). 1649 5. Using ALTO for CDNs 1651 5.1. Overview 1653 5.1.1. Usage Scenario 1655 This section discuss the usage of ALTO for Content Delivery Networks 1656 (CDNs) [I-D.jenkins-alto-cdn-use-cases]. CDNs are used in the 1657 delivery of some Internet services (e.g. delivery of websites, 1658 software updates and video delivery) from a location closer to the 1659 location of the user. A CDN typically consists of a network of 1660 servers often attached to Network Service Provider (NSP) networks. 1661 The point of attachment is often as close to content consumers and 1662 peering points as economically or operationally feasible in order to 1663 decrease traffic load on the NSP backbone and to provide better user 1664 experience measured by reduced latency and higher throughput. 1666 CDNs use several techniques to redirect a client to a server 1667 (surrogate). A request routing function within a CDN is responsible 1668 for receiving content requests from user agents, obtaining and 1669 maintaining necessary information about a set of candidate 1670 surrogates, and for selecting and redirecting the user agent to the 1671 appropriate surrogate. One common way is relying on the DNS system, 1672 but there are many other ways, see [RFC3568]. 1674 In order to derive the optimal benefit from a CDN it is preferable to 1675 deliver content from the servers (caches) that are "closest" to the 1676 end user requesting the content. "closest" may be as simple as 1677 geographical or IP topology distance, but it may also consider other 1678 combinations of metrics and CDN or Network Service Provider (NSP) 1679 policies. 1681 User Agent Request Router Surrogate 1682 | | | 1683 | F1 Initial Request | | 1684 +---------------------------->| | 1685 | +--+ | 1686 | | | F2 Surrogate Selection | 1687 | |<-+ (using ALTO) | 1688 | F3 Redirection Response | | 1689 |<----------------------------+ | 1690 | | | 1691 | F4 Content Request | | 1692 +-------------------------------------------------------->| 1693 | | | 1694 | | F5 Content | 1695 |<--------------------------------------------------------+ 1696 | | | 1698 Figure 20: Example of CDN surrogate selection 1700 Figure 20 illustrates the interaction between a user agent, a request 1701 router, and a surrogate for the delivery of content in a single CDN. 1702 As also explained in [I-D.jenkins-alto-cdn-use-cases], the user agent 1703 makes an initial request to the CDN (F1). This may be an 1704 application-level request (e.g. HTTP, RTMP, etc.) or a DNS request. 1705 In the second step (F2), the request router selects an appropriate 1706 surrogate (or set of Surrogates) based on the user agent's (or its 1707 proxy's) IP address, the request router's knowledge of the network 1708 topology (which can be obtained by ALTO) and reachability cost 1709 between CDN caches and end users, and any additional CDN policies. 1710 Then, the request router responds to the initial request with an 1711 appropriate response containing a redirection to the selected cache, 1712 for example by returning an appropriate DNS A/AAAA record, a HTTP 302 1713 redirect, etc. (F3). The user agent uses this information to 1714 connect directly to the surrogate and request the desired content 1715 (F4), which is then delivered (F5). 1717 In addition to use by a single CDN, ALTO can also be used in 1718 scenarios that interconnect several CDNs. This use case is detailed 1719 in [I-D.seedorf-cdni-request-routing-alto]. 1721 5.1.2. Applicability of ALTO 1723 The most simple use case for ALTO in a CDN context is to improve the 1724 selection of a CDN surrogate or origin. In this case, the CDN makes 1725 use of an ALTO server to choose a better CDN surrogate or origin than 1726 would otherwise be the case. Although it is possible to obtain raw 1727 network map and cost information in other ways, for example passively 1728 listening to the NSP's routing protocols or use of active probing, 1729 the use of an ALTO service to expose that information may provide 1730 additional control to the NSP over how their network map/cost is 1731 exposed. Additionally it may enable the NSP to maintain a functional 1732 separation between their routing plane and network map computation 1733 functions. This may be attractive for a number of reasons, for 1734 example: 1736 o The ALTO service could provide a filtered view of the network and/ 1737 or cost map that relates to CDN locations and their proximity to 1738 end users, for example to allow the NSP to control the level of 1739 topology detail they are willing to share with the CDN. 1741 o The ALTO service could apply additional policies to the network 1742 map and cost information to provide a CDN-specific view of the 1743 network map/cost, for example to allow the NSP to encourage the 1744 CDN to use network links that would not ordinarily be preferred by 1745 a Shortest Path First routing calculation. 1747 o The routing plane may be operated and controlled by a different 1748 operational entity (even within a single NSP) to the CDN. 1749 Therefore, the CDN may not be able to passively listen to routing 1750 protocols, nor may it have access to other network topology data 1751 (e.g., inventory databases). 1753 When CDN servers are deployed outside of an NSP's network or in a 1754 small number of central locations within an NSP's network a 1755 simplified view of the NSP's topology or an approximation of 1756 proximity is typically sufficient to enable the CDN to serve end 1757 users from the optimal server/location. As CDN servers are deployed 1758 deeper within NSP networks it becomes necessary for the CDN to have 1759 more detailed knowledge of the underlying network topology and costs 1760 between network locations in order to enable the CDN to serve end 1761 users from the most optimal servers for the NSP. 1763 The request router in a CDN will typicallly also take into account 1764 criteria and constraints that are not related to network topology, 1765 such as the current load of CDN surrogates, content owner policies, 1766 end user subscriptions, etc. This document only discusses use of 1767 ALTO for network information. 1769 A general issue for CDNs is that the CDN logic has to match the 1770 client's IP address with the closest CDN surrogate, both for DNS or 1771 HTTP redirect based approaches (see, for instance, 1772 [I-D.penno-alto-cdn]). This matching is not trivial, for instance, 1773 in DNS based approaches, where the IP address of the DNS original 1774 requester is unknown (see [I-D.vandergaast-edns-client-ip] for a 1775 discussion of this and a solution approach). 1777 5.2. Deployment Recommendations 1779 5.2.1. ALTO Services 1781 In its simplest form an ALTO server would provide an NSP with the 1782 capability to offer a service to a CDN that provides network map and 1783 cost information. The CDN can use that data to enhance its surrogate 1784 and/or origin selection. An alternative would be the Endpoint Cost 1785 Service (ECS). 1787 If an NSP offers an ALTO network and cost map service to expose a 1788 cost mapping/ranking between end user IP subnets (within that NSP's 1789 network) and CDN surrogate IP subnets/locations, periodic updates of 1790 the maps may be needed. It is common for broadband subscribers to 1791 obtain their IP addresses dynamically and in many deployments the IP 1792 subnets allocated to a particular network region can change 1793 relatively frequently, even if the network topology itself is 1794 reasonably static. 1796 An alternative would be to use the ALTO Endpoint Cost Service (ECS): 1797 When an end user request a given content, the CDN request router 1798 issues an ECS request with the endpoint address (IPv4/IPv6) of the 1799 end user (content requester) and the set of endpoint addresses of the 1800 surrogate (content targets). The ALTO server receives the request 1801 and ranks the list of content targets addresses based on their 1802 distance from the content requester. Once the request router 1803 obtained from the ALTO Server the ranked list of locations (for the 1804 specific user), it can incorporate this information into its 1805 selection mechanisms in order to point the user to the most 1806 appropriate surrogate. 1808 When ALTO server receives an ECS request, it may not have the most 1809 appropriate topology information in order to accurately determine the 1810 ranking. In such a case the ALTO server may want to adopt the 1811 following strategies: 1813 o Reply with available information (best effort). 1815 o Redirect the request to another ALTO server presumed to have 1816 better topology information (redirection). 1818 o Doing both (best effort and redirection). In this case, the reply 1819 message contains both the rankings and the indication of another 1820 ALTO server where more accurate rankings may be delivered. 1822 The decision process that is used to determine if redirection is 1823 necessary and which mode to use is out of the scope of this document. 1825 Since CDNs operate in a controlled environment, the ALTO network/cost 1826 map service and ECS have a similar level of security and 1827 confidentiality of network-internal information. However, the 1828 network/cost map service and ECS differ in the way the ALTO service 1829 is delivered and address a different set of requirements in terms of 1830 topology information and network operations. 1832 In order to address the scalability limitations of ECS and to reduce 1833 the number of transactions between CDN and ALTO server, a request 1834 router that uses ECS could cache the results of ECS queries for later 1835 usage. The ALTO server may indicate in the reply message how long 1836 the content of the message is to be considered reliable and insert a 1837 lifetime value that will be used by the CDN in order to cache (and 1838 then flush or refresh) the entry. 1840 5.2.2. Guidance Considerations 1842 In the following, some deployment scenarios for ALTO are outlined, as 1843 examples to demonstrate how a CDN could make use of ALTO services. 1845 In one deployment scenarion, ALTO could expose NSP end user 1846 reachability to a CDN. The request router needs to have information 1847 on which end user IP subnets are reachable via which networks or 1848 network locations. The network map services offered by ALTO could be 1849 used to expose this topology information while avoiding routing plane 1850 peering between the NSP and the CDN. For example, if CDN surrogates 1851 are deployed within the access or aggregation network, the NSP is 1852 likely to want to utilise the surrogates deployed in the same access/ 1853 aggregation region in preference to surrogates deployed elsewhere, in 1854 order to alleviate the cost and/or improve the user experience. 1856 In addition, CDN surrogates could use ALTO guidance as well, e.g., if 1857 there is more than one upstream source of content or several origins. 1858 ALTO could help a surrogate with the decision which upstream source 1859 to use. 1861 If content can be provided by several CDNs, there may be a need to 1862 interconnect these CDNs. In this case, ALTO can be uses as interface 1863 [I-D.seedorf-cdni-request-routing-alto], in particular for footprint 1864 and capabilities advertisement interface. As explained in 1865 [I-D.seedorf-cdni-request-routing-alto], this specific variant of 1866 using ALTO requires protocol extensions and is therefore not further 1867 detailed in this document. 1869 Other and more advanced scenarios of deploying ALTO are also listed 1870 in [I-D.jenkins-alto-cdn-use-cases] and [I-D.penno-alto-cdn]. 1872 The granularity of ALTO information required depends on the specific 1873 deployment of the CDN. For example, an over-the-top CDN whose 1874 surrogates are deployed only within the Internet "backbone" may only 1875 require knowledge of which end user IP subnets are reachable via 1876 which NSPs' networks, whereas a CDN deployed within a particular 1877 NSP's network requires a finer granularity of knowledge. 1879 ALTO server ranks addresses based on topology information it acquires 1880 from the network. By default, according to [I-D.ietf-alto-protocol], 1881 distance in ALTO represents the routing cost as computed by the 1882 routing layer (e.g., OSPF, ISIS, BGP), but it may also take into 1883 consideration other routing criteria such as MPLS-VPN (MP-BGP) and 1884 MPLS-TE (RSVP), policy and state and performance information in 1885 addition to other information sources (policy, geo-location, state, 1886 and performance), as explained in Section 3.2.1. 1888 The different methods and algorithms through which the ALTO server 1889 computes topology information and rankings is out of the scope of 1890 this document. However, and in the case the rankings are based on 1891 routing (IP/MPLS) topology, it is obvious that network events may 1892 impact the ranking computation. Due to internal redundancy and 1893 resilience mechanisms inside current networks, most of the network 1894 events happening in the infrastructure will have limited impact on a 1895 CDN. However, catastrophic events such as main trunks failures or 1896 backbone partition will have to take into account by the ALTO server 1897 so to redirect traffic away from the failure impacted area. An ALTO 1898 server implementation may want to keep state about ALTO clients so to 1899 inform and signal to these clients when a major network event 1900 happened so to clear the ALTO cache in the client. In a CDN/ALTO 1901 interworking architecture where there's a few CDN component 1902 interacting with the ALTO server there are no scalability issues in 1903 maintaining state about clients in the ALTO server. 1905 6. Other Use Cases 1907 This section briefly surveys and references other use cases that have 1908 been suggested for ALTO. 1910 6.1. Virtual Private Networks (VPNs) 1912 Virtual Private Network (VPN) technology is widely used in public and 1913 private networks to create groups of users that are separated from 1914 other users of the network and allows these users to communicate 1915 among them as if they were on a private network. Network Service 1916 Providers (NSPs) offer different types of VPNs. [RFC4026] 1917 distinguishes between Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) 1918 using different sub-types. In the following, the term "VPN" is used 1919 to refer to provider supplied virtual private networking. 1921 ALTO topology exposure is also very useful for providing application 1922 guidance in VPNs, so that applications do not have to perform 1923 excessive measurements on their own. For instance, potential use 1924 cases for ALTO optimization over VPNs are: 1926 o Enterprise application optimization: Enterprise customers often 1927 run distributed applications that exchange large amounts of data, 1928 e.g., for synchronization of replicated data bases. Both for 1929 placement of replicas as well as for the scheduling of transfers 1930 insight into network topology information could be useful. 1932 o Private cloud computing solution: An enterprise customer could run 1933 own data centers at the four sites. The cloud management system 1934 could want to understand the network costs between different sites 1935 for intelligent routing and placement decisions of Virtual 1936 Machines (VMs) among the VPN sites. 1938 o Cloud-bursting: One or more VPN endpoints could be located in a 1939 public cloud. If an enterprise customer needs additional 1940 resources, they could be provided by a public cloud, which is 1941 accessed through the VPN. Network topology awareness would help 1942 to decide in which data center of the public cloud those resources 1943 should be allocated. 1945 These examples focus on enterprise customers of NSPs, which are 1946 typical users of provider-supplied VPNs. Such VPN customers 1947 typically have no insight into the network topology that transports 1948 the VPN. If better-than-random decisions would be enabled by an ALTO 1949 server offered by the NSP, as illustrated in Figure Figure 21. 1951 +---------------+ 1952 | Customer's | 1953 | management | 1954 | application |. 1955 | (ALTO client) | . 1956 +---------------+ . VPN provisioning 1957 ^ . (out-of-scope) 1958 | ALTO . 1959 V . 1960 +---------------------+ +----------------+ 1961 | ALTO server | | VPN portal/OSS | 1962 | provided by NSP | | (out-of-scope) | 1963 +---------------------+ +----------------+ 1964 ^ VPN network 1965 * and cost maps 1966 * 1967 /---------*---------\ Network service provider 1968 | * | 1969 +-------+ _______________________ +-------+ 1970 | App a | ()_____. .________. .____() | App d | 1971 +-------+ | | | | | | +-------+ 1972 \---| |--------| |--/ 1973 | | | | 1974 |^| |^| Customer VPN 1975 V V 1976 +-------+ +-------+ 1977 | App b | | App c | 1978 +-------+ +-------+ 1980 Figure 21: Using ALTO in VPNs 1982 A common characteristic of these use cases is that applications will 1983 not necessarily run in the public Internet, and that the relationship 1984 between the provider and customer of the VPN is rather well-defined. 1985 Since VPNs run often in a managed environment, an ALTO server may 1986 have access to topology information (e.g., traffic engineering data) 1987 that would not be available for the public Internet, and it may 1988 expose it to the customer of the VPN only. 1990 Also, A VPN will not necessarily be static. The customer could 1991 possibly modify the VPN and add new VPN sites by a Web portal or 1992 other Operation Support Systems (OSS) solutions. Prior to adding a 1993 new VPN site, an application will not be have connectivity to that 1994 site, i.e., an ALTO server could offer access to information that an 1995 application cannot measure on its own (e.g., expected delay to a new 1996 VPN site). 1998 The VPN use cases, requirements, and solutions are further detailed 1999 in [I-D.scharf-alto-vpn-service]. 2001 6.2. In-Network Caching 2003 Deployment of intra-domain P2P caches has been proposed for a 2004 cooperations between the network operator and the P2P service 2005 providers, e.g., to reduce the bandwith consumption in access 2006 networks [I-D.deng-alto-p2pcache]. 2008 +--------------+ +------+ 2009 | ISP 1 network+----------------+Peer 1| 2010 +-----+--------+ +------+ 2011 | 2012 +--------+------------------------------------------------------+ 2013 | | ISP 2 network | 2014 | +---------+ | 2015 | |L1 Cache | | 2016 | +-----+---+ | 2017 | +--------------------+----------------------+ | 2018 | | | | | 2019 | +------+------+ +------+-------+ +------+-------+ | 2020 | | AN1 | | AN2 | | AN3 | | 2021 | | +---------+ | | +----------+ | | | | 2022 | | |L2 Cache | | | |L2 Cache | | | | | 2023 | | +---------+ | | +----------+ | | | | 2024 | +------+------+ +------+-------+ +------+-------+ | 2025 | | | | 2026 | +--------------------+ | | 2027 | | | | | 2028 | +------+------+ +------+-------+ +------+-------+ | 2029 | | SUB-AN11 | | SUB-AN12 | | SUB-AN31 | | 2030 | | +---------+ | | | | | | 2031 | | |L3 Cache | | | | | | | 2032 | | +---------+ | | | | | | 2033 | +------+------+ +------+-------+ +------+-------+ | 2034 | | | | | 2035 +--------+--------------------+----------------------+----------+ 2036 | | | 2037 +---+---+ +---+---+ | 2038 | | | | | 2039 +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ 2040 |Peer2| |Peer3| |Peer4| |Peer5| |Peer6| 2041 +-----+ +-----+ +-----+ +-----+ +-----+ 2043 Figure 22: General architecture of intra-ISP caches 2045 Figure 22 depics the overall architecture of a potential P2P cache 2046 deployments inside an ISP 2 with various access network types. As 2047 shown in the figure, P2P caches may be deployed at various levels, 2048 including the interworking gateway linking with other ISPs, internal 2049 access network gateways linking with different types of accessing 2050 networks (e.g. WLAN, cellular and wired), and even within an 2051 accessing network at the entries of individual WLAN sub-networks. 2052 Moreover, depending on the network context and the operator's policy, 2053 each cache can be a Forwarding Cache or a Bidirectional Cache 2054 [I-D.deng-alto-p2pcache]. 2056 In such a cache architecture, the locations of caches could be used 2057 as dividers of different PIDs to guide intra-ISP network abstraction 2058 and mark costs among them according to the location and type of 2059 relevant caches. 2061 Further details and deployment considerations can be found in 2062 [I-D.deng-alto-p2pcache]. 2064 6.3. Other Use Cases 2066 TODO 2068 7. Security Considerations 2070 The ALTO protocol itself as well as the ALTO client and server raise 2071 new security issues beyond the ones mentioned in 2072 [I-D.ietf-alto-protocol] and issues related to message transport over 2073 the Internet. For instance, Denial of Service (DoS) is of interest 2074 for the ALTO server and also for the ALTO client. A server can get 2075 overloaded if too many TCP requests hit the server, or if the query 2076 load of the server surpasses the maximum computing capacity. An ALTO 2077 client can get overloaded if the responses from the sever are, either 2078 intentionally or due to an implementation mistake, too large to be 2079 handled by that particular client. 2081 This section is solely giving a first shot on security issues related 2082 to ALTO deployments. 2084 7.1. Information Leakage from the ALTO Server 2086 The ALTO server will be provisioned with information about the owning 2087 ISP's network and very likely also with information about neighboring 2088 ISPs. This information (e.g., network topology, business relations, 2089 etc.) is considered to be confidential to the ISP and must not be 2090 revealed. 2092 The ALTO server will naturally reveal parts of that information in 2093 small doses to peers, as the guidance given will depend on the above 2094 mentioned information. This is seen beneficial for both parties, 2095 i.e., the ISP's and the peer's. However, there is the chance that one 2096 or multiple peers are querying an ALTO server with the goal to gather 2097 information about network topology or any other data considered 2098 confidential or at least sensitive. It is unclear whether this is a 2099 real technical security risk or whether this is more a perceived 2100 security risk. 2102 7.2. ALTO Server Access 2104 Depending on the use case of ALTO, several access restrictions to an 2105 ALTO server may or may not apply. 2107 For peer-to-peer applications, a potential deployment scenario is 2108 that an ALTO server is solely accessible by peers from the ISP 2109 network (as shown in Figure 16). For instance, the source IP address 2110 can be used to grant only access from that ISP network to the server. 2111 This will "limit" the number of peers able to attack the server to 2112 the user's of the ISP (however, including botnet computers). 2114 If the ALTO server has to be accessible by parties not located in the 2115 ISP's network (see Figure Figure 15), e.g., by a third-party tracker 2116 or by a CDN system outside the ISP's network, the access restrictions 2117 have to be looser. In the extreme case, i.e., no access 2118 restrictions, each and every host in the Internet can access the ALTO 2119 server. This might no be the intention of the ISP, as the server is 2120 not only subject to more possible attacks, but also on the load 2121 imposed to the server, i.e., possibly more ALTO clients to serve and 2122 thus more work load. 2124 There are also use cases where the access to the ALTO server has to 2125 be much more strictly controlled, i. e., where an authentication and 2126 authorization of the ALTO client to the server may be needed. For 2127 instance, in case of CDN optimization the provider of an ALTO service 2128 as well as potential users are possibly well-known. Only CDN 2129 entities may need ALTO access; access to the ALTO servers by 2130 residential users may neither be necessary nor be desired. 2132 7.3. Faking ALTO Guidance 2134 It has not yet been investigated how a faked or wrong ALTO guidance 2135 by an ALTO server can impact the operation of the network and also 2136 the peers. 2138 Here is a list of examples how the ALTO guidance could be faked and 2139 what possible consequences may arise: 2141 Sorting An attacker could change to sorting order of the ALTO 2142 guidance (given that the order is of importance, otherwise the 2143 ranking mechanism is of interest), i.e., declaring peers located 2144 outside the ISP as peers to be preferred. This will not pose a 2145 big risk to the network or peers, as it would mimic the "regular" 2146 peer operation without traffic localization, apart from the 2147 communication/processing overhead for ALTO. However, it could 2148 mean that ALTO is reaching the opposite goal of shuffling more 2149 data across ISP boundaries, incurring more costs for the ISP. 2151 Preference of a single peer A single IP address (thus a peer) could 2152 be marked as to be preferred all over other peers. This peer can 2153 be located within the local ISP or also in other parts of the 2154 Internet (e.g., a web server). This could lead to the case that 2155 quite a number of peers to trying to contact this IP address, 2156 possibly causing a Denial of Service (DoS) attack. 2158 8. IANA Considerations 2160 This document makes no specific request to IANA. 2162 9. Conclusion 2164 This document discusses how the ALTO protocol can be deployed in 2165 different use cases and provides corresponding guidance and 2166 recommendations to network administrators and application developers. 2168 10. References 2170 10.1. Normative References 2172 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 2173 Content Network (CN) Request-Routing Mechanisms", RFC 2174 3568, July 2003. 2176 10.2. Informative References 2178 [I-D.deng-alto-p2pcache] 2179 Lingli, D., Chen, W., Yi, Q., and Y. Zhang, 2180 "Considerations for ALTO with network-deployed P2P 2181 caches", draft-deng-alto-p2pcache-02 (work in progress), 2182 July 2013. 2184 [I-D.farrkingel-pce-abno-architecture] 2185 King, D. and A. Farrel, "A PCE-based Architecture for 2186 Application-based Network Operations", draft-farrkingel- 2187 pce-abno-architecture-06 (work in progress), October 2013. 2189 [I-D.ietf-alto-protocol] 2190 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 2191 ietf-alto-protocol-25 (work in progress), January 2014. 2193 [I-D.ietf-alto-server-discovery] 2194 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 2195 S. Yongchao, "ALTO Server Discovery", draft-ietf-alto- 2196 server-discovery-10 (work in progress), September 2013. 2198 [I-D.ietf-i2rs-architecture] 2199 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 2200 Nadeau, "An Architecture for the Interface to the Routing 2201 System", draft-ietf-i2rs-architecture-01 (work in 2202 progress), February 2014. 2204 [I-D.ietf-idr-ls-distribution] 2205 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 2206 Ray, "North-Bound Distribution of Link-State and TE 2207 Information using BGP", draft-ietf-idr-ls-distribution-04 2208 (work in progress), November 2013. 2210 [I-D.jenkins-alto-cdn-use-cases] 2211 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 2212 S. Previdi, "Use Cases for ALTO within CDNs", draft- 2213 jenkins-alto-cdn-use-cases-03 (work in progress), June 2214 2012. 2216 [I-D.kamei-p2p-experiments-japan] 2217 Kamei, S., Momose, T., Inoue, T., and T. Nishitani, "ALTO- 2218 Like Activities and Experiments in P2P Network Experiment 2219 Council", draft-kamei-p2p-experiments-japan-09 (work in 2220 progress), October 2012. 2222 [I-D.kiesel-alto-h12] 2223 Kiesel, S. and M. Stiemerling, "ALTO H12", draft-kiesel- 2224 alto-h12-02 (work in progress), March 2010. 2226 [I-D.kist-alto-3pdisc] 2227 Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party 2228 ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05 2229 (work in progress), January 2014. 2231 [I-D.lee-alto-chinatelecom-trial] 2232 Li, K. and G. Jian, "ALTO and DECADE service trial within 2233 China Telecom", draft-lee-alto-chinatelecom-trial-04 (work 2234 in progress), March 2012. 2236 [I-D.penno-alto-cdn] 2237 Penno, R., Medved, J., Alimi, R., Yang, R., and S. 2238 Previdi, "ALTO and Content Delivery Networks", draft- 2239 penno-alto-cdn-03 (work in progress), March 2011. 2241 [I-D.scharf-alto-vpn-service] 2242 Scharf, M., Gurbani, V., Soprovich, G., and V. Hilt, "The 2243 Virtual Private Network (VPN) Service in ALTO: Use Cases, 2244 Requirements and Extensions", draft-scharf-alto-vpn- 2245 service-01 (work in progress), July 2013. 2247 [I-D.seedorf-cdni-request-routing-alto] 2248 Seedorf, J. and Y. Yang, "CDNI Footprint and Capabilities 2249 Advertisement using ALTO", draft-seedorf-cdni-request- 2250 routing-alto-05 (work in progress), October 2013. 2252 [I-D.vandergaast-edns-client-ip] 2253 Contavalli, C., Gaast, W., Leach, S., and D. Rodden, 2254 "Client IP information in DNS requests", draft- 2255 vandergaast-edns-client-ip-01 (work in progress), May 2256 2010. 2258 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 2259 Private Network (VPN) Terminology", RFC 4026, March 2005. 2261 [RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and 2262 Y. Yang, "Comcast's ISP Experiences in a Proactive Network 2263 Provider Participation for P2P (P4P) Technical Trial", RFC 2264 5632, September 2009. 2266 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 2267 Optimization (ALTO) Problem Statement", RFC 5693, October 2268 2009. 2270 [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 2271 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 2272 Requirements", RFC 6708, September 2012. 2274 Appendix A. Contributing Authors and Acknowledgments 2276 This memo is the result of contributions made by several people, such 2277 as: 2279 o Xianghue Sun, Lee Kai, and Richard Yang contributed text on ISP 2280 deployment requirements and monitoring. 2282 o Stefano Previdi contributed parts of the Section 5 on "Using ALTO 2283 for CDNs". 2285 o Rich Woundy contributed text to Section 3.3. 2287 o Lingli Deng, Wei Chen, Qiuchao Yi, Yan Zhang contributed 2288 Section 6.2. 2290 The authors would like to thank Thomas-Rolf Banniza, Vinayak Hegde, 2291 and Qin Wu for useful comments and reviews of the document. 2293 Martin Stiemerling is partially supported by the CHANGE project ( 2294 http://www.change-project.eu), a research project supported by the 2295 European Commission under its 7th Framework Program (contract no. 2296 257422). The views and conclusions contained herein are those of the 2297 authors and should not be interpreted as necessarily representing the 2298 official policies or endorsements, either expressed or implied, of 2299 the CHANGE project or the European Commission. 2301 Authors' Addresses 2303 Martin Stiemerling (editor) 2304 NEC Laboratories Europe 2305 Kurfuerstenanlage 36 2306 Heidelberg 69115 2307 Germany 2309 Phone: +49 6221 4342 113 2310 Fax: +49 6221 4342 155 2311 Email: martin.stiemerling@neclab.eu 2312 URI: http://ietf.stiemerling.org 2314 Sebastian Kiesel (editor) 2315 University of Stuttgart, Computing Center 2316 Allmandring 30 2317 Stuttgart 70550 2318 Germany 2320 Email: ietf-alto@skiesel.de 2322 Stefano Previdi 2323 Cisco Systems, Inc. 2324 Via Del Serafico 200 2325 Rome 00191 2326 Italy 2328 Email: sprevidi@cisco.com 2329 Michael Scharf 2330 Alcatel-Lucent Bell Labs 2331 Lorenzstrasse 10 2332 Stuttgart 70435 2333 Germany 2335 Email: michael.scharf@alcatel-lucent.com