idnits 2.17.1 draft-ietf-alto-deployments-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 930 has weird spacing: '... data dat...' -- The document date (July 20, 2016) is 2829 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 (-22) exists of draft-ietf-alto-incr-update-sse-02 == Outdated reference: A later version (-08) exists of draft-ietf-dnsop-edns-client-subnet-07 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-13 == Outdated reference: A later version (-20) exists of draft-ietf-i2rs-yang-network-topo-04 == Outdated reference: A later version (-02) exists of draft-kiesel-alto-xdom-disc-01 == Outdated reference: A later version (-10) exists of draft-seedorf-cdni-request-routing-alto-08 == Outdated reference: A later version (-09) exists of draft-wu-alto-te-metrics-07 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO M. Stiemerling 3 Internet-Draft Hochschule Darmstadt 4 Intended status: Informational S. Kiesel 5 Expires: January 21, 2017 University of Stuttgart 6 M. Scharf 7 Nokia 8 H. Seidel 9 BENOCS 10 S. Previdi 11 Cisco 12 July 20, 2016 14 ALTO Deployment Considerations 15 draft-ietf-alto-deployments-16 17 Abstract 19 Many Internet applications are used to access resources such as 20 pieces of information or server processes that are available in 21 several equivalent replicas on different hosts. This includes, but 22 is not limited to, peer-to-peer file sharing applications. The goal 23 of Application-Layer Traffic Optimization (ALTO) is to provide 24 guidance to applications that have to select one or several hosts 25 from a set of candidates, which are able to provide a desired 26 resource. This memo discusses deployment related issues of ALTO. It 27 addresses different use cases of ALTO such as peer-to-peer file 28 sharing and CDNs and presents corresponding examples. The document 29 also includes recommendations for network administrators and 30 application designers planning to deploy ALTO, such recommendations 31 how to generate ALTO map information. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 21, 2017. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. General Considerations . . . . . . . . . . . . . . . . . . . . 5 69 2.1. ALTO Entities . . . . . . . . . . . . . . . . . . . . . . 5 70 2.1.1. Baseline Scenario . . . . . . . . . . . . . . . . . . 5 71 2.1.2. Placement of ALTO Entities . . . . . . . . . . . . . . 7 72 2.2. Classification of Deployment Scenarios . . . . . . . . . . 8 73 2.2.1. Roles in ALTO Deployments . . . . . . . . . . . . . . 8 74 2.2.2. Information Exposure . . . . . . . . . . . . . . . . . 11 75 2.2.3. More Advanced Deployments . . . . . . . . . . . . . . 12 76 3. Deployment Considerations by ISPs . . . . . . . . . . . . . . 15 77 3.1. Objectives for the Guidance to Applications . . . . . . . 15 78 3.1.1. General Objectives for Traffic Optimization . . . . . 15 79 3.1.2. Inter-Network Traffic Localization . . . . . . . . . . 16 80 3.1.3. Intra-Network Traffic Localization . . . . . . . . . . 17 81 3.1.4. Network Off-Loading . . . . . . . . . . . . . . . . . 18 82 3.1.5. Application Tuning . . . . . . . . . . . . . . . . . . 19 83 3.2. Provisioning of ALTO Topology Data . . . . . . . . . . . . 20 84 3.2.1. High-Level Process and Requirements . . . . . . . . . 20 85 3.2.2. Data Collection from Data Sources . . . . . . . . . . 21 86 3.2.3. Partitioning and Grouping of IP Address Ranges . . . . 24 87 3.2.4. Rating Criteria and/or Cost Calculation . . . . . . . 25 88 3.3. ALTO Focus and Scope . . . . . . . . . . . . . . . . . . . 28 89 3.3.1. Limitations of Using ALTO Beyond Design Assumptions . 29 90 3.3.2. Limitations of Map-based Services and Potential 91 Solutions . . . . . . . . . . . . . . . . . . . . . . 30 92 3.3.3. Limitations of Non-Map-based Services and 93 Potential Solutions . . . . . . . . . . . . . . . . . 32 94 3.4. Monitoring ALTO . . . . . . . . . . . . . . . . . . . . . 32 95 3.4.1. Impact and Observation on Network Operation . . . . . 32 96 3.4.2. Measurement of the Impact . . . . . . . . . . . . . . 33 97 3.4.3. System and Service Performance . . . . . . . . . . . . 34 98 3.4.4. Monitoring Infrastructures . . . . . . . . . . . . . . 35 99 3.5. Abstract Map Examples for Different Types of ISPs . . . . 36 100 3.5.1. Small ISP with Single Internet Uplink . . . . . . . . 36 101 3.5.2. ISP with Several Fixed Access Networks . . . . . . . . 39 102 3.5.3. ISP with Fixed and Mobile Network . . . . . . . . . . 40 103 3.6. Comprehensive Example for Map Calculation . . . . . . . . 42 104 3.6.1. Example Network . . . . . . . . . . . . . . . . . . . 42 105 3.6.2. Potential Input Data Processing and Storage . . . . . 44 106 3.6.3. Calculation of Network Map from the Input Data . . . . 47 107 3.6.4. Calculation of Cost Map . . . . . . . . . . . . . . . 48 108 3.7. Deployment Experiences . . . . . . . . . . . . . . . . . . 50 109 4. Using ALTO for P2P Traffic Optimization . . . . . . . . . . . 53 110 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 53 111 4.1.1. Usage Scenario . . . . . . . . . . . . . . . . . . . . 53 112 4.1.2. Applicability of ALTO . . . . . . . . . . . . . . . . 53 113 4.2. Deployment Recommendations . . . . . . . . . . . . . . . . 56 114 4.2.1. ALTO Services . . . . . . . . . . . . . . . . . . . . 56 115 4.2.2. Guidance Considerations . . . . . . . . . . . . . . . 57 116 5. Using ALTO for CDNs . . . . . . . . . . . . . . . . . . . . . 60 117 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 60 118 5.1.1. Usage Scenario . . . . . . . . . . . . . . . . . . . . 60 119 5.1.2. Applicability of ALTO . . . . . . . . . . . . . . . . 62 120 5.2. Deployment Recommendations . . . . . . . . . . . . . . . . 63 121 5.2.1. ALTO Services . . . . . . . . . . . . . . . . . . . . 63 122 5.2.2. Guidance Considerations . . . . . . . . . . . . . . . 64 123 6. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 66 124 6.1. Application Guidance in Virtual Private Networks (VPNs) . 66 125 6.2. In-Network Caching . . . . . . . . . . . . . . . . . . . . 68 126 6.3. Other Application-based Network Operations . . . . . . . . 69 127 7. Security Considerations . . . . . . . . . . . . . . . . . . . 70 128 7.1. ALTO as a Protocol Crossing Trust Boundaries . . . . . . . 70 129 7.2. Information Leakage from the ALTO Server . . . . . . . . . 71 130 7.3. ALTO Server Access . . . . . . . . . . . . . . . . . . . . 72 131 7.4. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . . 73 132 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 133 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76 134 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 77 135 10.1. Normative References . . . . . . . . . . . . . . . . . . . 77 136 10.2. Informative References . . . . . . . . . . . . . . . . . . 77 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 81 139 1. Introduction 141 Many Internet applications are used to access resources such as 142 pieces of information or server processes that are available in 143 several equivalent replicas on different hosts. This includes, but 144 is not limited to, peer-to-peer (P2P) file sharing applications and 145 Content Delivery Networks (CDNs). The goal of Application-Layer 146 Traffic Optimization (ALTO) is to provide guidance to applications 147 that have to select one or several hosts from a set of candidates, 148 which are able to provide a desired resource. The basic ideas and 149 problem space of ALTO is described in [RFC5693] and the set of 150 requirements is discussed in [RFC6708]. The ALTO protocol is 151 specified in [RFC7285]. An ALTO server discovery procedure is 152 defined in [RFC7286]. 154 This document discusses use cases and operational issues that can be 155 expected when ALTO gets deployed. This includes, but is not limited 156 to, location of the ALTO server, imposed load to the ALTO server, and 157 who initiaties the queries. This document provides guidance on which 158 ALTO services to use, and it summarizes known challenges as well as 159 deployment experiences, including potential processes to generate 160 ALTO network and cost maps. It thereby complements the management 161 considerations in the protocol specification [RFC7285], which are 162 independent of any specific use of ALTO. 164 2. General Considerations 166 2.1. ALTO Entities 168 2.1.1. Baseline Scenario 170 The ALTO protocol [RFC7285] is a client/server protocol, operating 171 between a number of ALTO clients and an ALTO server, as sketched in 172 Figure 1. Below, the baseline deployment scenario for ALTO entities 173 is first reviewed independently of the actual use case. Specific 174 examples are then discussed in the remainder of this document. 176 +----------+ 177 | ALTO | 178 | Server | 179 +----------+ 180 ^ 181 _.-----|------. 182 ,-'' | `--. 183 ,' | `. 184 ( Network | ) 185 `. | ,' 186 `--. | _.-' 187 `------|-----'' 188 v 189 +----------+ +----------+ +----------+ 190 | ALTO | | ALTO |...| ALTO | 191 | Client | | Client | | Client | 192 +----------+ +----------+ +----------+ 194 Figure 1: Baseline deployment scenario of the ALTO protocol 196 This document uses the terminology introduced in [RFC5693]. In 197 particular, the following terms are defined by [RFC5693]: 199 o ALTO Service: Several resource providers may be able to provide 200 the same resource. The ALTO service gives guidance to a resource 201 consumer and/or resource directory about which resource 202 provider(s) to select in order to optimize the client's 203 performance or quality of experience, while improving resource 204 consumption in the underlying network infrastructure. 206 o ALTO Server: A logical entity that provides interfaces to satisfy 207 the queries about a particular ALTO service. 209 o ALTO Client: The logical entity that sends ALTO queries. 210 Depending on the architecture of the application, one may embed it 211 in the resource consumer and/or in the resource directory. 213 o Resource Consumer: For P2P applications, a resource consumer is a 214 specific peer that needs to access resources. For client-server 215 or hybrid applications, a consumer is a client that needs to 216 access resources. 218 We differentiate between an ALTO Client and a Resource Consumer as 219 follows: The resource consumer is specific instance of a software 220 ("process") running on a specific host. It is a client instance of a 221 client/server application or a peer of a peer-to-peer application. 222 It is the given (constant) endpoint of the data transmissions to be 223 optimized using ALTO. The optimization is done by wisely choosing 224 the other ends of these data flows (i.e., the server(s) in a client/ 225 server application or the peers in a peer-to-peer application), using 226 guidance from ALTO and possibly other information. An ALTO client is 227 a piece of software (e.g., a software library) that implements the 228 client entity of the ALTO protocol as specified in [RFC7285]. It 229 consists of data structures that are suitable for representing ALTO 230 queries, replies, network and cost maps, etc. Furthermore, it has to 231 implement an HTTP client and a JSON encoder/decoder, or it has to 232 include other software libraries that provide these building blocks. 233 In the simplest case, this ALTO client library can be linked (or 234 otherwise incorporated) into the resource consumer, in order to 235 retrieve information from an ALTO server and thereby satisfy the 236 resource consumer's need for guidance. However, other configurations 237 are possible as well, as discussed in Section 2.1.2 and other 238 sections of this document. 240 This document uses the term "Resource Directory" as defined in 241 [RFC5693], i.e., to denote an entity that is logically separate from 242 the resource consumer and that assists the resource consumer to 243 identify a set of resource providers (e.g., a tracker in a peer-to- 244 peer application). This term and its meaning is not to be confused 245 with the "Information Resource Directory (IRD)" defined as a part of 246 the ALTO protocol [RFC7285], i.e., a list of available information 247 resources offered by a specific ALTO service and the URIs at which 248 each can be accessed. For the remainder of this document, the term 249 Resource Directory is to be interpreted as defined in [RFC5693]. 251 According to these definitions, both an ALTO server and an ALTO 252 client are logical entities. A particular ALTO service may be 253 offered by more than one ALTO server. In ALTO deployments, the 254 functionality of an ALTO server can therefore be realized by several 255 server instances, e.g., by using load balancing between different 256 physical servers. The term ALTO server should not be confused with 257 use of a single physical server. 259 2.1.2. Placement of ALTO Entities 261 The ALTO server and ALTO clients may be situated at various places in 262 a network topology. An importent differentiation is whether the ALTO 263 client is located on the host that is the endpoint of the data 264 transmissions to be optimized with ALTO (see Figure 2), or whether 265 the ALTO client is located on a resource directory, which assists 266 peers or clients in finding other peers or servers, respectively, but 267 does not directly take part in the data transmission (see Figure 3). 269 +--------------+ 270 | App | 271 +-----------+ | 272 ===>|ALTO Client| |**** 273 === +-----------+--+ * 274 === * * 275 === * * 276 +-------+ +-------+<=== +--------------+ * 277 | | | | | App | * 278 | |.....| |<======== +-----------+ | * 279 | | | | ========>|ALTO Client| | * 280 +-------+ +-------+<=== +-----------+--+ * 281 Source of ALTO == * * 282 topological Server == * * 283 information == +--------------+ * 284 == | App | * 285 == +-----------+ |**** 286 ==>|ALTO Client| | 287 +-----------+--+ 288 Application 289 Legend: 290 === ALTO protocol 291 *** Application protocol 292 ... Provisioning protocol 294 Figure 2: Overview of protocol interaction between ALTO elements 295 without a resource directory 297 Figure 2 shows the operational model for an ALTO client running at 298 endpoints. An example would be a peer-to-peer file sharing 299 application that does not use a tracker, such as edonkey. In 300 addition, ALTO clients at peers could also be used in a similar way 301 even if there is a tracker, as further discussed in Section 4.1.2. 303 +-----+ 304 **| App |**** 305 ** +-----+ * 306 ** * * 307 ** * * 308 +-------+ +-------+ +--------------+ * * 309 | | | | | | +-----+ * 310 | |.....| | +-----------+ |*****| App | * 311 | | | |<===>|ALTO Client| | +-----+ * 312 +-------+ +-------+ +-----------+--+ * * 313 Source of ALTO Resource ** * * 314 topological Server directory ** * * 315 information ** +-----+ * 316 **| App |**** 317 +-----+ 318 Application 319 Legend: 320 === ALTO protocol 321 *** Application protocol 322 ... Provisioning protocol 324 Figure 3: Overview of protocol interaction between ALTO elements with 325 a resource directory 327 In Figure 3, a use case with a resource directory is illustrated, 328 e.g., a tracker in a peer-to-peer file-sharing application such as 329 BitTorrent. Both deployment scenarios may differ in the number of 330 ALTO clients that access an ALTO service. If an ALTO client is 331 implemented in a resource directory, an ALTO server may be accessed 332 by a limited and less dynamic set of clients, whereas in the general 333 case any host could be an ALTO client. This use case is further 334 detailed in Section 4. 336 Using ALTO in CDNs may be similar to a resource directory 337 [I-D.jenkins-alto-cdn-use-cases]. The ALTO server can also be 338 queried by CDN entities to get guidance about where a particular 339 client accessing data in the CDN is located in the Internet Service 340 Provider's network, as discussed in Section 5. 342 2.2. Classification of Deployment Scenarios 344 2.2.1. Roles in ALTO Deployments 346 ALTO is a general-purpose protocol and it is intended to be used by a 347 wide range of applications. In different use cases, applications, 348 resource directories, etc. can correspond to different functionality. 349 The use cases listed in this document are not meant to be 350 comprehensive. This also implies that there are different 351 possibilities where the ALTO entities are actually located, i.e., if 352 the ALTO clients and the ALTO server are in the same Internet Service 353 Provider (ISP) domain, or if the clients and the ALTO server are 354 managed/owned/located in different domains. 356 An ALTO deployment involves four kinds of entities: 358 1. Source of topological information 360 2. ALTO server 362 3. ALTO client 364 4. Resource consumer 366 Each of these entities corresponds to a certain role, which results 367 in requirements and constraints on the interaction between the 368 entities. 370 A key design objective of the ALTO service is that each of these four 371 roles can be separated, i.e., they can be realized by different 372 organizations or disjoint system components. ALTO is inherently 373 designed for use in multi-domain environments. Most importantly, 374 ALTO is designed to enable deployments in which the ALTO server and 375 the ALTO client are not located within the same administrative 376 domain. 378 As explained in [RFC5693], from this follows that at least three 379 different kinds of entities can operate an ALTO server: 381 1. Network operators. Network Service Providers (NSPs) such as 382 Internet Service Providers (ISPs) may have detailed knowledge of 383 their network topology and policies. In this case, the source of 384 the topology information and the provider of the ALTO server may 385 be part of the same organization. 387 2. Third parties. Topology information could also be collected by 388 companies or organizations that are distinct from the network 389 operators, yet have arranged certain legal agreements with one or 390 more network operators, regarding access to their topology 391 information and/or doing measurements in their networks. 392 Examples of such entities could be Content Delivery Network (CDN) 393 operators or companies specialized on offering ALTO services on 394 behalf of ISPs. 396 3. User communities. User communities could run distributed 397 measurements for estimating the topology of the Internet. In 398 this case the topology information may not originate from ISP 399 data. 401 Regarding the interaction between ALTO server and client, ALTO 402 deployments can be differentiated according to the following aspects: 404 1. Applicable trust model: The deployment of ALTO can differ 405 depending on whether ALTO client and ALTO server are operated 406 within the same organization and/or network, or not. This 407 affects a number of constraints, because the trust model is very 408 different. For instance, as discussed later in this memo, the 409 level-of-detail of maps can depend on who the involved parties 410 actually are. 412 2. Composition of the user group: The main use case of ALTO is to 413 provide guidance to any Internet application. However, an 414 operator of an ALTO server could also decide to offer guidance 415 only to a set of well-known ALTO clients, e. g., after 416 authentication and authorization. In the peer-to-peer 417 application use case, this could imply that only selected 418 trackers are allowed to access the ALTO server. The security 419 implications of using ALTO in closed groups differ from the 420 public Internet. 422 3. Covered destinations: In general, an ALTO server has to be able 423 to provide guidance for all potential destinations. Yet, in 424 practice a given ALTO client may only be interested in a subset 425 of destinations, e.g., only in the network cost between a limited 426 set of resource providers. For instance, CDN optimization may 427 not need the full ALTO cost maps, because traffic between 428 individual residential users is not in scope. This may imply 429 that an ALTO server only has to provide the costs that matter for 430 a given user, e. g., by customized maps. 432 The following sections enumerate different classes of use cases for 433 ALTO, and they discuss deployment implications of each of them. An 434 ALTO server can in principle be operated by any organization, and 435 there is no requirement that an ALTO server is deployed and operated 436 by an ISP. Yet, since the ALTO solution is designed for ISPs, most 437 examples in this document assume that the operator of an ALTO server 438 is a network operator (e.g., an ISP or the network department in a 439 large enterprise) that offers ALTO guidance in particular to users of 440 this network. 442 It must be emphasized that any application using ALTO must also work 443 if no ALTO servers can be found or if no responses to ALTO queries 444 are received, e.g., due to connectivity problems or overload 445 situations (see also [RFC6708]). 447 2.2.2. Information Exposure 449 There are basically two different approaches how an ALTO server can 450 provide network information and guidance: 452 1. The ALTO server provides maps that contain provider-defined cost 453 values between network location groupings (e.g., sets of IP 454 prefixes). These maps can be retrieved by clients via the ALTO 455 protocol, and the actual processing of the map data is done 456 inside the client. Since the maps contain (aggregated) cost 457 information for all endpoints, the client does not have to reveal 458 any internal operational data, such as the IP addresses of 459 candidate resource providers. The ALTO protocol supports this 460 mode of operation by the Network and Cost Map Service. 462 2. The ALTO server provides a query interface that returns costs or 463 rankings for explicitly specified endpoints. This means that the 464 query of the ALTO client has to include additional information 465 (e.g., a list of IP addresses). The server then calculates and 466 returns costs or rankings for the endpoints specified in the 467 request (e.g., a sorted list of the IP addresses). In ALTO, this 468 approach can be realized by the Endpoint Cost Service and other 469 related services. 471 Both approaches have different privacy implications for the server 472 and client: 474 For the client, approach 1 has the advantage that all operational 475 information stays within the client and is not revealed to the 476 provider of the server. However, this service implies that a network 477 operator providing an ALTO server has to expose a certain amount of 478 information about its network structure (e.g., IP prefixes or 479 topology information in general). 481 For the operator of a server, approach 2 has the advantage that the 482 query responses reveal less topology information to ALTO clients. 483 However, it should be noted that collaborating ALTO clients could 484 gather more information than expected by aggregating and correlating 485 responses to multiple queries sent to the ALTO server (see Section 486 5.2.1, item (3) of [RFC6708]). Furthermore, this method requires 487 that clients send internal operational information to the server, 488 such as the IP addresses of hosts also running the application. For 489 clients, such data can be sensitive. 491 As a result, both approaches have their pros and cons, as further 492 detailed in Section 3.3. 494 2.2.3. More Advanced Deployments 496 From an ALTO client's perspective, there are different ways to use 497 ALTO: 499 1. Single service instance with single metric guidance: An ALTO 500 client only obtains guidance regarding a single metric (e.g., 501 "routingcost") from a single ALTO service, e.g., an ALTO server 502 that is offered by the network service provider of the 503 corresponding access network. Corresponding ALTO server 504 instances can be discovered e.g. by ALTO server discovery 505 [RFC7286] [I-D.kiesel-alto-xdom-disc]. Since the ALTO protocol 506 is an HTTP-based, REST-ful protocol, the operator of an ALTO may 507 use well-known techniques for serving large web sites, such as 508 load balancers, in order to serve a large number of ALTO queries. 509 The ALTO protocol also supports the use of different URIs for 510 different ALTO features and thereby the distribution of the 511 service onto several servers. 513 2. Single service instance with multiple metric guidance: An ALTO 514 client could also query an ALTO service for different kinds of 515 information, e.g., cost maps with different metrics. The ALTO 516 protocol is extensible and permits such operation. However, ALTO 517 does not define how a client shall deal with different forms of 518 guidance, and it is up to the client to interpret the received 519 information accordingly. 521 3. Multiple service instances: An ALTO client can also decide to 522 access multiple ALTO servers providing guidance, possibly from 523 different operators or organizations. Each of these services may 524 only offer partial guidance, e.g., for a certain network 525 partition. In that case, it may be difficult for an ALTO client 526 to compare the guidance from different services. Different 527 organization may use different methods to determine maps, and 528 they may also have different (possibly even contradicting or 529 competing) guidance objectives. How to discover multiple ALTO 530 servers and how to deal with conflicting guidance is an open 531 issue. 533 There are also different options regarding the synchronization of 534 guidance offered by an ALTO service: 536 1. Authoritative servers: An ALTO server instance can provide 537 guidance for all destinations for all kinds of ALTO clients. 539 2. Cascaded servers: An ALTO server may itself include an ALTO 540 client and query other ALTO servers, e.g., for certain 541 destinations. This results is a cascaded deployment of ALTO 542 servers, as further explained below. 544 3. Inter-server synchronization: Different ALTO servers may 545 communicate by other means. This approach is not further 546 discussed in this document. 548 An assumption of the ALTO design is that ISPs operate ALTO servers 549 independently, irrespectively of other ISPs. This may be true for 550 most envisioned deployments of ALTO but there may be certain 551 deployments that may have different settings. Figure 4 shows such 552 setting with a university network that is connected to two upstream 553 providers. NREN is a National Research and Education Network, which 554 provides cheap high-speed connectivity to specific destinations, 555 e.g., other universities. ISP is a commercial upstream provider from 556 which the university buys connectivity to all destinations that 557 cannot be reached via the NREN. The university, as well as ISP, are 558 operating their own ALTO server. The ALTO clients, located on the 559 peers in the university network will contact the ALTO server located 560 at the university. 562 +-----------+ 563 | ISP | 564 | ALTO |<==========================++ 565 | Server | || 566 +-----------+ || 567 ,-------. ,------. || 568 ,-' `-. ,-' `-. || 569 / Commercial \ / \ || 570 ( Upstream ) ( NREN ) || 571 \ ISP / \ / || 572 `-. ,-' `-. ,-' || 573 `---+---' `+------' || 574 | | || 575 | | || 576 |,-------------. | \/ 577 ,-+ `-+ +-----------+ 578 ,' University `. |University | 579 ( Network ) | ALTO | 580 `. / | Server | 581 `-. +--' +-----------+ 582 `+------------'| /\ /\ 583 | | || || 584 +--------+-+ +-+--------+ || || 585 | Peer1 | | PeerN |<====++ || 586 +----------+ +----------+ || 587 /\ || 588 || || 589 ++======================================++ 591 Legend: 592 === ALTO protocol 594 Figure 4: Example of a cascaded ALTO server 596 In this setting, all destinations that can be reached via the NREN 597 are preferred in the rating of the university's ALTO server. In 598 contrast, all traffic that is not routed via the NREN will be handled 599 by the commercial upstream ISP and is in general less preferred due 600 to the associated costs. Yet, there may be significant differences 601 between various destinations reached via the ISP. Therefore, the 602 ALTO server at the university may also include the guidance given by 603 the ISP ALTO server in its replies to the ALTO clients. This is an 604 example for cascaded ALTO servers. 606 3. Deployment Considerations by ISPs 608 3.1. Objectives for the Guidance to Applications 610 3.1.1. General Objectives for Traffic Optimization 612 The Internet consists of many networks. The networks are owned and 613 managed by different network operators, such as commercial Internet 614 Service Providers (ISPs), enterprise IT departments, universities, 615 and other organizations. These network operators provide network 616 connectivity, e.g., by access networks, such as cable networks, xDSL 617 networks, 3G/4G mobile networks, etc. Network operators need to 618 manage, to control and to audit the traffic. Therefore, it is 619 important to understand how to deploy an ALTO service and its 620 expected impact. 622 The general objective of ALTO is to give guidance to applications on 623 what endpoints (e.g., IP addresses or IP prefixes) are to be 624 preferred according to the operator of the ALTO server. The ALTO 625 protocol gives means to let the ALTO server operator express its 626 preference, whatever this preference is. 628 ALTO enables network operators to support application-level traffic 629 engineering by influencing application resource provider selection. 630 This traffic engineering can have different objectives: 632 1. Inter-network traffic localization: ALTO can help to reduce 633 inter-domain traffic. The networks of different network 634 operators are interconnected through peering points. From a 635 business view, the inter-network settlement is needed for 636 exchanging traffic between these networks. These peering 637 agreements can be costly. To reduce these costs, a simple 638 objective is to decrease the traffic exchange across the peering 639 points and thus keep the traffic in the own network or Autonomous 640 System (AS) as far as possible. 642 2. Intra-network traffic localization: In case of large network 643 operators, the network may be grouped into several networks, 644 domains, or Autonomous Systems (ASs). The core network includes 645 one or several backbone networks, which are connected to multiple 646 aggregation, metro, and access networks. If traffic can be 647 limited to certain areas such as access networks, this decreases 648 the usage of backbone and thus helps to save resources and costs. 650 3. Network off-loading: Compared to fixed networks, mobile networks 651 have some special characteristics, including lower link 652 bandwidth, high cost, limited radio frequency resource, and 653 limited terminal battery. In mobile networks, wireless links 654 should be used efficiently. For example, in the case of a P2P 655 service, it is likely that hosts should prefer retrieving data 656 from hosts in fixed networks, and avoid retrieving data from 657 mobile hosts. 659 4. Application tuning: ALTO is also a tool to optimize the 660 performance of applications that depend on the network and 661 perform resource provider selection decisions among network 662 endpoints. And example is the network-aware selection of Content 663 Delivery Network (CDN) caches. 665 In the following, these objectives are explained in more detail with 666 examples. 668 3.1.2. Inter-Network Traffic Localization 670 ALTO guidance can be used to keep traffic local in a network, for 671 instance in order to reduce peering costs. An ALTO server can let 672 applications prefer other hosts within the same network operator's 673 network instead of randomly connecting to other hosts that are 674 located in another operator's network. Here, a network operator 675 would always express its preference for hosts in its own network, 676 while hosts located outside its own network are to be avoided (i.e., 677 they are undesired to be considered by the applications). Figure 5 678 shows such a scenario where hosts prefer hosts in the same network 679 (e.g., Host 1 and Host 2 in ISP1 and Host 3 and Host 4 in ISP2). 681 ,-------. +-----------+ 682 ,---. ,-' `-. | Host 1 | 683 ,-' `-. / ISP 1 ########|ALTO Client| 684 / \ / # \ +-----------+ 685 / ISP X \ | # | +-----------+ 686 / \ \ ########| Host 2 | 687 ; +----------------------------|ALTO Client| 688 | | | `-. ,-' +-----------+ 689 | | | `-------' 690 | Inter- | | ,-------. +-----------+ 691 : network | ; ,-' `########| Host 3 | 692 \ traffic | / / ISP 2 # \ |ALTO Client| 693 \ | / / # \ +-----------+ 694 \ |/ | # | +-----------+ 695 `-. ,-| \ ########| Host 4 | 696 `---' +----------------------------|ALTO Client| 697 `-. ,-' +-----------+ 698 `-------' 700 Legend: 701 ### preferred "connections" 702 --- non-preferred "connections" 704 Figure 5: Inter-network traffic localization 706 Examples for corresponding ALTO maps can be found in Section 3.5. 707 Depending on the application characteristics, it may not be possible 708 or not even desirable to completely localize all traffic. 710 3.1.3. Intra-Network Traffic Localization 712 The previous section describes the results of the ALTO guidance on an 713 inter-network level. In the same way, ALTO can also be used for 714 intra-network localization. In this case, ALTO provides guidance on 715 which internal hosts are to be preferred inside a single network 716 (e.g., one AS). This application-level traffic engineering can 717 reduce the capacity requirements in the core network of an ISP. 718 Figure 6 shows such a scenario where Host 1 and Host 2 are located in 719 an access net 1 of ISP 1 and connect via a low capacity link to the 720 core of the same ISP 1. If Host 1 and Host 2 exchange their data 721 with remote hosts, they would probably congest the bottleneck link. 723 Bottleneck ,-------. +-----------+ 724 ,---. | ,-' `-. | Host 1 | 725 ,-' `-. | / ISP 1 ########|ALTO Client| 726 / \ | / (Access # \ +-----------+ 727 / ISP 1 \| | net 1) # | +-----------+ 728 / (Core V \ ########| Host 2 | 729 ; network) +--X~~~X---------------------|ALTO Client| 730 | | | `-. ,-' +-----------+ 731 | | | `-------' 732 | | | ,-------. +-----------+ 733 : | ; ,-' `########| Host 3 | 734 \ | / / ISP 1 # \ |ALTO Client| 735 \ | / / (Access # \ +-----------+ 736 \ |/ | net 2) # | +-----------+ 737 `-. ,-X \ ########| Host 4 | 738 `---' ~~~~~~~X---------------------|ALTO Client| 739 ^ `-. ,-' +-----------+ 740 | `-------' 741 Bottleneck 742 Legend: 743 ### preferred "connections" 744 --- non-preferred "connections" 746 Figure 6: Intra-network traffic localization 748 The operator can guide the hosts in such a situation to try first 749 local hosts in the same network islands, avoiding or at least 750 lowering the effect on the bottleneck link, as shown in Figure 6. 752 The objective is to avoid bottlenecks by optimized endpoint selection 753 at application level. That said, it must be understood that ALTO is 754 not a general purpose method to deal with the congestion at the 755 bottleneck. 757 3.1.4. Network Off-Loading 759 Another scenario is off-loading traffic from networks. This use of 760 ALTO can be beneficial in particular in mobile networks. A network 761 operator may have the desire to guide hosts in its mobile network to 762 use hosts outside this mobile network. One reason could be that the 763 wireless network or the mobile hosts were not designed for direct 764 peer-to-peer communications between mobile hosts, and therefore, it 765 makes sense for peers to fetch content from remote peers in other 766 parts of the Internet. 768 ,-------. +-----------+ 769 ,---. ,-' `-. | Host 1 | 770 ,-' `-. / ISP 1 +-------|ALTO Client| 771 / \ / (Mobile | \ +-----------+ 772 / ISP X \ | network) | | +-----------+ 773 / \ \ +-------| Host 2 | 774 ; #############################|ALTO Client| 775 | # | `-. ,-' +-----------+ 776 | # | `-------' 777 | # | ,-------. 778 : # ; ,-' `-. 779 \ # / / ISP 2 \ 780 \ # / / (Fixed \ 781 \ #/ | network) | +-----------+ 782 `-. ,-# \ / | Host 3 | 783 `---' #############################|ALTO Client| 784 `-. ,-' +-----------+ 785 `-------' 787 Legend: 788 ### preferred "connections" 789 --- non-preferred "connections" 791 Figure 7: ALTO traffic network de-localization 793 Figure 7 shows the result of such a guidance process where Host 2 794 prefers a connection with Host 3 instead of Host 1, as shown in 795 Figure 5. 797 A realization of this scenario may have certain limitations and may 798 not be possible in all cases. For instance, it may require the ALTO 799 server to distinguish mobile and non-mobile hosts based on their IP 800 address. This may depend on mobility solutions and may not be 801 possible or accurate. In general, ALTO is not intended as a fine- 802 grained traffic engineering solution for individual hosts. Instead, 803 it typically works on aggregates (e.g., if it is known that certain 804 IP prefixes are often assigned to mobile users). 806 3.1.5. Application Tuning 808 ALTO can also provide guidance to optimize the application-level 809 topology of networked applications, e.g., by exposing network 810 performance information. Applications can often run their own 811 measurements to determine network performance, e.g., by active delay 812 measurements or bandwidth probing, but such measurements result in 813 overhead and complexity. Accessing an ALTO server can be a simpler 814 alternative. In addition, an ALTO server may also expose network 815 information that applications cannot easily measure or reverse- 816 engineer. 818 3.2. Provisioning of ALTO Topology Data 820 3.2.1. High-Level Process and Requirements 822 A process to generate ALTO topology information typically comprises 823 several steps. The first step is to gather information, which is 824 described in the following section. The subsequent sections then 825 describe how the gathered data can be processed, and which methods 826 can be applied to generate the information exposed by ALTO, such as 827 network and cost maps. 829 Providing ALTO guidance can result in a win-win situation both for 830 network providers and users of the ALTO information. Applications 831 possibly get a better performance, while the network provider has 832 means to optimize the traffic engineering and thus its costs. Yet, 833 there can be security concerns with exposing topology data. 834 Corresponding limitations are discussed in Section 7.2. 836 ISPs may have important privacy requirements when deploying ALTO, 837 which have to be taken into account when processing ALTO topology 838 data. In particular, an ISP may not be willing to expose sensitive 839 operational details of its network. The topology abstraction of ALTO 840 enables an ISP to expose the network topology at a desired 841 granularity only, determined by security policies. 843 With the Endpoint Cost Service (ECS), the ALTO client does not have 844 to implement any specific algorithm or mechanism in order to 845 retrieve, maintain and process network topology information (of any 846 kind). The complexity of the network topology (computation, 847 maintenance and distribution) is kept in the ALTO server and ECS is 848 delivered on demand. This allows the ALTO server to enhance and 849 modify the way the topology information sources are used and 850 combined. This simplifies the enforcement of privacy policies of the 851 ISP. 853 The ALTO Network Map and Cost Map service expose an abstract view on 854 the ISP network topology. Therefore, care is needed when 855 constructing those maps in order to take privacy policies into 856 account, as further discussed in Section 3.2.3. The ALTO protocol 857 also supports further features such as endpoint properties, which 858 could also be used to expose topology guidance. The privacy 859 considerations for ALTO maps also apply to such ALTO extensions. 861 3.2.2. Data Collection from Data Sources 863 The first step in the process of generating ALTO information is to 864 gather the required information from the network. An ALTO server can 865 collect topological information from a variety of sources in the 866 network and provides a cohesive, abstract view of the network 867 topology to applications using an ALTO client. Topology data sources 868 may include routing protocols, network policies, state and 869 performance information, geo-location, etc. An ALTO server requires 870 at least some topology and/or routing information, i.e., information 871 about existing endpoints and their interconnection. With this 872 information it is in principle possible to compute paths between all 873 known endpoints. Based on such basic data, the ALTO server builds an 874 ALTO-specific network topology that represents the network as it 875 should be understood and utilized by applications (resource 876 consumers) at endpoints using ALTO services (e.g., Network/Cost Map 877 Service or ECS). A basic dataset can be extended by many other 878 information obtainable from the network. 880 The ALTO protocol does not assume a specific network technology or 881 topology. In principle, ALTO can be used with various types of 882 addresses (Endpoint Addresses). [RFC7285] defines the use of IPv4/ 883 IPv6 addresses or prefixes in ALTO, but further address types could 884 be added by extensions. In this document, only the use of IPv4/IPv6 885 addresses is considered. 887 The exposure of network topology information is controlled and 888 managed by the ALTO server. ALTO abstract network topologies can be 889 automatically generated from the physical or logical topology of the 890 network, e.g., using "live" network data. The generation would 891 typically be based on policies and rules set by the network operator. 892 The maps and the guidance can significantly differ depending on the 893 use case, the network architecture, and the trust relationship 894 between ALTO server and ALTO client, etc. Besides the security 895 requirements that consist of not delivering any confidential or 896 critical information about the infrastructure, there are efficiency 897 requirements in terms of what aspects of the network are visible and 898 required by the given use case and/or application. 900 The ALTO server operator has to ensure that the ALTO topology does 901 not reveal any details that would endanger the network integrity and 902 security. For instance, ALTO is not intended to leak raw Interior 903 Gateway Protocol (IGP) or Border gateway Protocol (BGP) databases to 904 ALTO clients. 906 +--------+ +--------+ 907 | ALTO | | ALTO | 908 | Client | | Client | 909 +--------+ +--------+ 910 /\ /\ 911 || || ALTO protocol 912 || || 913 \/ \/ 914 +---------+ 915 | ALTO | 916 | Server | 917 +---------+ 918 : : : : 919 : : : : 920 +..........+ : : +..........+ Provisioning 921 : : : : protocol 922 : : : : 923 +---------+ +---------+ +---------+ +---------+ 924 | BGP | | I2RS | | PCE | | NMS | Potential 925 | Speaker | | Client | | | | OSS | data sources 926 +---------+ +---------+ +---------+ +---------+ 927 ^ ^ ^ ^ 928 | | | | 929 Link-State I2RS TED Topology and traffic related 930 NLRI for data data data from SNMP, NETCONF, 931 IGP/BGP RESTCONF, REST, IPFIX, etc. 933 Figure 8: Potential data sources for ALTO 935 As illustrated in Figure 8, the topology data used by an ALTO server 936 can originate from different data sources: 938 o Relevant information sources are interior gateway protocols (IGPs) 939 or the Border Gateway Protocol (BGP). An ALTO server could get 940 network routing information by listening to IGPs and/or peering 941 with BGP speakers. For data collection, link-state protocols are 942 more suitable since every router propagates its information 943 throughout the whole network. Hence, it is possible to obtain 944 information about all routers and their neighbors from one single 945 router in the network. In contrast, distance-vector protocols are 946 less suitable since routing information is only shared among 947 neighbors. To obtain the whole topology with distance-vector 948 routing protocols it is necessary to retrieve routing information 949 from every router in the network. 951 o The document [RFC7752] describes a mechanism by which link-state 952 and traffic engineering information can be collected from networks 953 and shared with external components using the BGP routing 954 protocol. This is achieved using a new BGP Network Layer 955 Reachability Information (NLRI) encoding format. The mechanism is 956 applicable to physical and virtual IGP links and can also include 957 Traffic Engineering (TE) data. For instance, prefix data can be 958 carried and originated in BGP, while TE data is originated and 959 carried in an IGP. The mechanism described is subject to policy 960 control. 962 o The Interface to the Routing System (I2RS) is a solution for state 963 transfer in and out of the Internet's routing system 964 [I-D.ietf-i2rs-architecture]. An ALTO server could use an I2RS 965 client to observe routing-related information. With the rise of 966 Software-Defined Networking (SDN) and a decoupling of network data 967 and control plane, topology information could also be fetched from 968 an SDN controller. If I2RS is used, [RFC7922] provides 969 traceability for these interactions. This scenario is not further 970 discussed in the remainder of this document. 972 o Another potential source of topology information could be a Path 973 Computation Element (PCE) [RFC4655]. Topology and traffic related 974 information can be retrieved from the the Traffic Engineering 975 Database (TED) and Label Switched Path Database (LSP-DB). This 976 scenario is not further discussed in the remainder of this 977 document. 979 o An ALTO server can also leverage a Network Management System (NMS) 980 or an Operations Support System (OSS) as data sources. NMS or OSS 981 solutions are used to control, operate, and manage a network, 982 e.g., using the Simple Network Management Protocol (SNMP) or 983 NETCONF. As explained for instance in [RFC7491], the NMS and OSS 984 can be consumers of network events reported and can act on these 985 reports as well as displaying them to users and raising alarms. 986 In addition, NMS and OSS systems may have access to routing 987 information and network inventory data (e.g., links, nodes, or 988 link properties not visible to routing protocols, such as Shared 989 Risk Link Groups). Furthermore, Operations, Administration, and 990 Maintenance (OAM) information can be leveraged, including traffic 991 utilization obtained from IPFIX, event notifications (e.g., via 992 syslog), liveness detection (e.g., bidirectional forwarding 993 detection, BFD). NMS or OSS systems also may have functions to 994 correlate and orchestrate information originating from other data 995 sources. For instance, it could be required to correlate IP 996 prefixes with routers (Provider, Provider Edge, Customer Edge, 997 etc.), IGP areas, VLAN IDs, or policies. 999 In the context of the provisioning protocol, topology information 1000 could be modeled in a YANG data model 1001 [I-D.ietf-i2rs-yang-network-topo]. 1003 The data sources mentioned so far are only a subset of potential 1004 topology sources and protocols. Depending on the network type, (e.g. 1005 mobile, satellite network) different hardware and protocols are in 1006 operation to form and maintain the network. 1008 In general it is challenging to gather detailed information about the 1009 whole Internet, since the network consists of multiple domains and in 1010 many cases it is not possible to collect information across network 1011 borders. Hence, potential information sources may be limited to a 1012 certain domain. 1014 3.2.3. Partitioning and Grouping of IP Address Ranges 1016 ALTO introduces provider-defined network location identifiers called 1017 Provider-defined Identifiers (PIDs) to aggregate network endpoints in 1018 the Map Services. Endpoints within one PID may be treated as single 1019 entity, assuming proximity based on network topology or other 1020 similarity. A key use case of PIDs is to specify network preferences 1021 (costs) between PIDs instead of individual endpoints. It is up to 1022 the operator of the ALTO server how to group endpoints and how to 1023 assign PIDs. For example, a PID may denote a subnet, a set of 1024 subnets, a metropolitan area, a POP, an autonomous system, or a set 1025 of autonomous systems. 1027 This document only considers deployment scenarios in which PIDs 1028 expand to a set of IP address ranges (CIDR). A PID is characterized 1029 by a string identifier and its associated set of endpoint addresses 1030 [RFC7285]. If an ALTO server offers the Map Service, corresponding 1031 identifiers have to be configured. 1033 An automated ALTO implementation may use dynamic algorithms to 1034 aggregate network topology. However, it is often desirable to have a 1035 mechanism through which the network operator can control the level 1036 and details of network aggregation based on a set of requirements and 1037 constraints. This will typically be governed by policies that 1038 enforce a certain level of abstraction and prevent leakage of 1039 sensitive operational data. 1041 For instance, an ALTO server may leverage BGP information that is 1042 available in a networks service provider network layer and compute 1043 the group of prefix. An example are BGP communities, which are used 1044 in MPLS/IP networks as a common mechanism to aggregate and group 1045 prefixes. A BGP community is an attribute used to tag a prefix to 1046 group prefixes based on mostly any criteria (as an example, most ISP 1047 networks originate BGP prefixes with communities identifying the 1048 Point of Presence (PoP) where the prefix has been originated). These 1049 BGP communities could be used to map IP address ranges to PIDs. By 1050 an additional policy, the ALTO server operator may decide an 1051 arbitrary cost defined between groups. Alternatively, there are 1052 algorithms that allow the dynamic computation of costs between 1053 groups. The ALTO protocol itself is independent of such algorithms 1054 and policies. 1056 3.2.4. Rating Criteria and/or Cost Calculation 1058 An ALTO server indicates preferences amongst network locations in the 1059 form of abstract costs. These costs are generic costs and can be 1060 internally computed by the operator of the ALTO server according to 1061 its own policy. For a given ALTO network map, an ALTO cost map 1062 defines directional costs pairwise amongst the set of source and 1063 destination network locations defined by the PIDs. 1065 The ALTO protocol permits the use of different cost types. An ALTO 1066 cost type is defined by the combination of a cost metric and a cost 1067 mode. The cost metric identifies what the costs represent. The cost 1068 mode identifies how the costs should be interpreted, i.e., whether 1069 returned costs should be interpreted as numerical values or ordinal 1070 rankings. The ALTO protocol also allows the definition of additional 1071 constraints defining which elements of a cost map shall be returned. 1073 The ALTO protocol specification [RFC7285] defines the "routingcost" 1074 cost metric as the basic set of rating criteria, which has to be 1075 supported by all implementations. This cost metric conveys a generic 1076 measure for the cost of routing traffic from a source to a 1077 destination. A lower value indicates a higher preference for traffic 1078 to be sent from a source to a destination. How that metric is 1079 calculated is up to the ALTO server. 1081 It is possible to calculate the "routingcost" cost metric based on 1082 actual routing protocol information. Typically, Interior Gateway 1083 Protocols (IGP) provide details about endpoints and links within a 1084 given network, while the Bordger Gateway Protocol (BGPs) is used to 1085 provide details about links to endpoints in other networks. Besides 1086 topology and routing information, networks have a multitude of other 1087 attributes about their state, condition, and operation. That 1088 comprises but is not limited to attributes like link utilization, 1089 bandwidth and delay, ingress/egress points of data flows from/towards 1090 endpoints outside of the network up to the location of nodes and 1091 endpoints. 1093 In order to enable use of extended information, there is a protocol 1094 extension procedure to add new ALTO cost types. The following list 1095 gives an overview on further rating criteria that have been proposed 1096 or which are in use by ALTO-related prototype implementations. This 1097 list is not intended as normative text. Instead, its only purpose is 1098 to document and discuss rating criteria that have been proposed so 1099 far. Whether such rating criteria are useful and whether the 1100 corresponding information would actually be made available by ISPs 1101 can also depend on the use case of ALTO. A definition of further 1102 metrics can be found for instance in [I-D.wu-alto-te-metrics]. 1104 Distance-related rating criteria: 1106 o Relative topological distance: The term relative means that a 1107 larger numerical value means greater distance, but it is up to the 1108 ALTO service how to compute the values, and the ALTO client will 1109 not be informed about the nature of the computation. One way to 1110 determine relative topological distance may be counting AS hops, 1111 but when querying this parameter, the ALTO client must not assume 1112 that the numbers actually are AS hops. In addition to the AS 1113 path, a relative cost value could also be calculated taking into 1114 account other routing protocol parameters, such as BGP local 1115 preference or multi-exit discriminator (MED) attributes. 1117 o Absolute topological distance, expressed in the number of 1118 traversed autonomous systems (AS). 1120 o Absolute topological distance, expressed in the number of router 1121 hops (i.e., how much the TTL value of an IP packet will be 1122 decreased during transit). 1124 o Absolute physical distance, based on knowledge of the approximate 1125 geo-location (e.g., continent, country) of an IP address. 1127 Performance-related rating criteria: 1129 o The minimum achievable throughput between the resource consumer 1130 and the candidate resource provider, which is considered useful by 1131 the application (only in ALTO queries). 1133 o An arbitrary upper bound for the throughput from/to the candidate 1134 resource provider (only in ALTO responses). This may be, but is 1135 not necessarily the provisioned access bandwidth of the candidate 1136 resource provider. 1138 o The maximum round-trip time (RTT) between resource consumer and 1139 the candidate resource provider, which is acceptable for the 1140 application for useful communication with the candidate resource 1141 provider (only in ALTO queries). 1143 o An arbitrary lower bound for the RTT between resource consumer and 1144 the candidate resource provider (only in ALTO responses). This 1145 may be, for example, based on measurements of the propagation 1146 delay in a completely unloaded network. 1148 Charging-related rating criteria: 1150 o Metrics representing an abstract cost, e.g., determined by 1151 policies that distinguish "cheap" from "expensive" IP subnet 1152 ranges without detailing the cost function. The abstract metric 1153 "routingcost" according to [RFC7285] is an example for a metric 1154 for which the cost function does not have to be disclosed. 1156 o Traffic volume caps, in case the Internet access of the resource 1157 consumer is not charged with a "flat rate". For each candidate 1158 resource location, the ALTO service could indicate the amount of 1159 data or the bitrate that may be transferred from/to this resource 1160 location until a given point in time, and how much of this amount 1161 has already been consumed. Furthermore, an ALTO server may have 1162 to indicate how excess traffic would be handled (e.g., blocked, 1163 throttled, or charged separately at an indicated price), e.g., by 1164 a new endpoint property. This is outside the scope of this 1165 document. Also, it is left for further study how several 1166 applications would interact if only some of them use this 1167 criterion. Also left for further study is the use of such a 1168 criterion in resource directories that issue ALTO queries on 1169 behalf of other endpoints. 1171 All the above listed rating criteria are subject to the remarks 1172 below: 1174 The ALTO client must be aware that with high probability the actual 1175 performance values will differ from whatever an ALTO server exposes. 1176 In particular, an ALTO client must not consider a throughput 1177 parameter as a permission to send data at the indicated rate without 1178 using congestion control mechanisms. 1180 The discrepancies are due to various reasons, including, but not 1181 limited to the following facts: 1183 o The ALTO service is not an admission control system. 1185 o The ALTO service may not know the instantaneous congestion status 1186 of the network. 1188 o The ALTO service may not know all link bandwidths, i.e., where the 1189 bottleneck really is, and there may be shared bottlenecks. 1191 o The ALTO service may not have all information about the actual 1192 routing. 1194 o The ALTO service may not know whether the candidate endpoint 1195 itself is overloaded. 1197 o The ALTO service may not know whether the candidate endpoint 1198 throttles the bandwidth it devotes for the considered application. 1200 o The ALTO service may not know whether the candidate endpoint will 1201 throttle the data it sends to the client (e.g., because of some 1202 fairness algorithm, such as tit-for-tat). 1204 Because of these inaccuracies and the lack of complete, instantaneous 1205 state information, which are inherent to the ALTO service, the 1206 application must use other mechanisms (such as passive measurements 1207 on actual data transmissions) to assess the currently achievable 1208 throughput, and it must use appropriate congestion control mechanisms 1209 in order to avoid a congestion collapse. Nevertheless, the rating 1210 criteria may provide a useful shortcut for quickly excluding 1211 candidate resource providers from such probing, if it is known in 1212 advance that connectivity is in any case worse than what is 1213 considered the minimum useful value by the respective application. 1215 Rating criteria that should not be defined for and used by the ALTO 1216 service include: 1218 o Performance metrics that are closely related to the instantaneous 1219 congestion status. The definition of alternate approaches for 1220 congestion control is explicitly out of the scope of ALTO. 1221 Instead, other appropriate means, such as using TCP based 1222 transport, have to be used to avoid congestion. In other words, 1223 ALTO is a service to provide network and policy information, with 1224 update intervals that are possibly several orders of magnitude 1225 slower than congestion control loops (e.g., in TCP) can react on 1226 changes in network congestion state. This clear separation of 1227 responsibilities avoids traffic oscillations and can help for 1228 network stability and cost optimization. 1230 o Performance metrics that raise privacy concerns. For instance, it 1231 has been questioned whether an ALTO service should publicly expose 1232 the provisioned access bandwidth of cable / DSL customers, as this 1233 could enable identification of "premium customers" of an ISP. 1235 3.3. ALTO Focus and Scope 1237 The purpose of this section is ensure that administrators and users 1238 of ALTO services are aware of the objectives of the ALTO protocol 1239 design. Using ALTO beyond this scope may limit its efficiency. 1240 Likewise, Map-based and Endpoint-based ALTO Services may face certain 1241 issues during deployment. This section explains these limitations 1242 and also outlines potential solutions. 1244 3.3.1. Limitations of Using ALTO Beyond Design Assumptions 1246 ALTO is designed as a protocol between clients integrated in 1247 applications and servers that provide network information and 1248 guidance (e.g., basic network location structure and preferences of 1249 network paths). The objective is to modify network resource 1250 consumption patterns at application level while maintaining or 1251 improving application performance. This design focus results in a 1252 number of characteristics of ALTO: 1254 o Endpoint focus: In typical ALTO use cases, neither the consumer of 1255 the topology information (i.e., the ALTO client) nor the 1256 considered resources (e.g., files at endpoints) are part of the 1257 network. The ALTO server presents an abstract network topology 1258 containing only information relevant to an application overlay for 1259 better-than-random resource provider selection among its 1260 endpoints. The ALTO protocol specification [RFC7285] is not 1261 designed to expose network internals such as routing tables or 1262 configuration data that are not relevant for application-level 1263 resource provider selection decisions in network endpoints. 1265 o Abstraction: The ALTO services such as the Network/Cost Map 1266 Service or the ECS provide an abstract view of the network only. 1267 The operator of the ALTO server has full control over the 1268 granularity (e.g., by defining policies how to aggregate subnets 1269 into PIDs) and the level-of-detail of the abstract network 1270 representation (e.g., by deciding what cost types to support). 1272 o Multiple administrative domains: The ALTO protocol is designed for 1273 use cases where the ALTO server and client can be located in 1274 different organizations or trust domains. ALTO assumes a loose 1275 coupling between server and client. In addition, ALTO does not 1276 assume that an ALTO client has any a priori knowledge about the 1277 ALTO server and its supported features. An ALTO server can be 1278 discovered automatically. 1280 o Read-only: ALTO is a query/response protocol to retrieve guidance 1281 information. Neither network/cost map queries nor queries to the 1282 endpoint cost service are designed to affect state in the network. 1284 If ALTO shall be deployed for use cases beyond the scope defined by 1285 these assumptions, the protocol design may result in limitations. 1287 For instance, in an Application-Based Network Operation (ABNO) 1288 environment the application could issue explicit service request to 1289 the network [RFC7491]. In this case, the application would require 1290 detailed knowledge about the internal network topology and the actual 1291 state. A network configuration would also require a corresponding 1292 security solution for authentication and authorization. ALTO is not 1293 designed for operations to control, operate, and manage a network. 1295 Such deployments could be addressed by network management solutions, 1296 e.g., based on SNMP [RFC3411] or NETCONF [RFC6241] and YANG [RFC6020] 1297 that are typically designed to manipulate configuration state. 1298 Reference [RFC7491] contains a more detailed discussion of interfaces 1299 between components such as Element Management System (EMS), Network 1300 Management System (NMS), Operations Support System (OSS), Traffic 1301 Engineering Database (TED), Label Switched Path Database (LSP-DB), 1302 Path Computation Element (PCE), and other Operations, Administration, 1303 and Maintenance (OAM) components. 1305 3.3.2. Limitations of Map-based Services and Potential Solutions 1307 The specification of the Map Service in the ALTO protocol [RFC7285] 1308 is based on the concept of network maps. A network map partitions 1309 the network into Provider-defined Identifiers (PIDs) that group one 1310 or more endpoints (e.g., subnetworks) to a single aggregate. The 1311 "costs" between the various PIDs are stored in a cost map. Map-based 1312 approaches such as the ALTO network and cost map service lower the 1313 signaling load on the server as maps have to be retrieved only if 1314 they change. 1316 One main assumption for map-based approaches is that the information 1317 provided in these maps is static for a long period of time. This 1318 assumption is fine as long as the network operator does not change 1319 any parameter, e.g., routing within the network and to the upstream 1320 peers, IP address assignment stays stable (and thus the mapping to 1321 the partitions). However, there are several cases where this 1322 assumption is not valid: 1324 1. ISPs reallocate IP subnets from time to time. 1326 2. ISPs reallocate IP subnets on short notice. 1328 3. IP prefix blocks may be assigned to a router that serves a 1329 variety of access networks. 1331 4. Network costs between IP prefixes may change depending on the 1332 ISP's routing and traffic engineering. 1334 These effects can be explained as follows: 1336 Case 1: ISPs may reallocate IP subnets within their infrastructure 1337 from time to time, partly to ensure the efficient usage of IPv4 1338 addresses (a scarce resource), and partly to enable efficient route 1339 tables within their network routers. The frequency of these 1340 "renumbering events" depend on the growth in number of subscribers 1341 and the availability of address space within the ISP. As a result, a 1342 subscriber's household device could retain an IP address for as short 1343 as a few minutes, or for months at a time or even longer. 1345 It has been suggested that ISPs providing ALTO services could sub- 1346 divide their subscribers' devices into different IP subnets (or 1347 certain IP address ranges) based on the purchased service tier, as 1348 well as based on the location in the network topology. The problem 1349 is that this sub-allocation of IP subnets tends to decrease the 1350 efficiency of IP address allocation, in particular for IPv4. A 1351 growing ISP that needs to maintain high efficiency of IP address 1352 utilization may be reluctant to jeopardize their future acquisition 1353 of IP address space. 1355 However, this is not an issue for map-based approaches if changes are 1356 applied in the order of days. 1358 Case 2: ISPs can use techniques that allow the reallocation of IP 1359 prefixes on very short notice, i.e., within minutes. An IP prefix 1360 that has no IP address assignment to a host anymore can be 1361 reallocated to areas where there is currently a high demand for IP 1362 addresses. 1364 Case 3: In residential access networks (e.g., DSL, cable), IP 1365 prefixes are assigned to broadband gateways, which are the first IP- 1366 hop in the access-network between the Customer Premises Equipment 1367 (CPE) and the Internet. The access-network between CPE and broadband 1368 gateway (called aggregation network) can have varying characteristics 1369 (and thus associated costs), but still using the same IP prefix. For 1370 instance one IP address IP1 out of a given CIDR prefix can be 1371 assigned to a VDSL access line (e.g., 2 MBit/s uplink) while another 1372 IP address IP2 within the same given CIDR prefix is assigned to a 1373 slow ADSL line (e.g., 128 kbit/s uplink). These IP addresses may be 1374 assigned on a first come first served basis, i.e., a single IP 1375 address out of the same CIDR prefix can change its associated costs 1376 quite fast. This may not be an issue with respect to the used 1377 upstream provider (thus the cross ISP traffic) but depending on the 1378 capacity of the aggregation-network this may raise to an issue. 1380 Case 4: The routing and traffic engineering inside an ISP network, as 1381 well as the peering with other autonomous systems, can change 1382 dynamically and affect the information exposed by an ALTO server. As 1383 a result, cost maps and possibly also network maps can change. 1385 One solution to deal with map changes is to use incremental ALTO 1386 updates [I-D.ietf-alto-incr-update-sse]. 1388 3.3.3. Limitations of Non-Map-based Services and Potential Solutions 1390 The specification of the ALTO protocol [RFC7285] also includes the 1391 Endpoint Cost Service (ECS) mechanism. ALTO clients can ask the ALTO 1392 server for guidance for specific IP addresses, thereby avoiding the 1393 need of processing maps. This can mitigate some of the problems 1394 mentioned in the previous section. 1396 However frequent requests, particularly with long lists of IP 1397 addresses, may overload the ALTO server. The server has to rank each 1398 received IP address, which causes load at the server. This may be 1399 amplified when not only a single ALTO client is asking for guidance, 1400 but a large number of them. The results of the ECS are also more 1401 difficult to cache than ALTO maps. Therefore, the ALTO client may 1402 have to await the server response before starting a communication, 1403 which results in an additional delay. 1405 Caching of IP addresses at the ALTO client or the usage of the H12 1406 approach [I-D.kiesel-alto-h12] in conjunction with caching may lower 1407 the query load on the ALTO server. 1409 When ALTO server receives an ECS request, it may not have the most 1410 appropriate topology information in order to accurately determine the 1411 ranking. [RFC7285] generally assumes that a server can always offer 1412 some guidance. In such a case the ALTO server could adopt one of the 1413 following strategies: 1415 o Reply with available information (best effort). 1417 o Query another ALTO server presumed to have better topology 1418 information and return that response (cascaded servers). 1420 o Redirect the request to another ALTO server presumed to have 1421 better topology information (redirection). 1423 The protocol mechanisms and decision processes that would be used to 1424 determine if redirection is necessary and which mode to use is out of 1425 the scope of this document, since protocol extensions could be 1426 required. 1428 3.4. Monitoring ALTO 1430 3.4.1. Impact and Observation on Network Operation 1432 ALTO presents a new opportunity for managing network traffic by 1433 providing additional information to clients. In particular, the 1434 deployment of an ALTO server may shift network traffic patterns, and 1435 the potential impact to network operation can be large. An ISP 1436 providing ALTO may want to assess the benefits of ALTO as part of the 1437 management and operations (cf. [RFC7285]). For instance, the ISP 1438 might be interested in understanding whether the provided ALTO maps 1439 are effective, and in order to decide whether an adjustment of the 1440 ALTO configuration would be useful. Such insight can be obtained 1441 from a monitoring infrastructure. An ISP offering ALTO could 1442 consider the impact on (or integration with) traffic engineering and 1443 the deployment of a monitoring service to observe the effects of ALTO 1444 operations. The measurement of impacts can be challenging because 1445 ALTO-enabled applications may not provide related information back to 1446 the ALTO service provider. 1448 To construct an effective monitoring infrastructure, the ALTO service 1449 provider should decide how to monitor the performance of ALTO and 1450 identify and deploy data sources to collect data to compute the 1451 performance metrics. In certain trusted deployment environments, it 1452 may be possible to collect information directly from ALTO clients. 1453 It may also be possible to vary or selectively disable ALTO guidance 1454 for a portion of ALTO clients either by time, geographical region, or 1455 some other criteria to compare the network traffic characteristics 1456 with and without ALTO. Monitoring an ALTO service could also be 1457 realized by third parties. In this case, insight into ALTO data may 1458 require a trust relationship between the monitoring system operator 1459 and the network service provider offering an ALTO service. 1461 The required monitoring depends on the network infrastructure and the 1462 use of ALTO, and an exhaustive description is outside the scope of 1463 this document. 1465 3.4.2. Measurement of the Impact 1467 ALTO realizes an interface between the network and applications. 1468 This implies that an effective monitoring infrastructure may have to 1469 deal with both network and application performance metrics. This 1470 document does not comprehensively list all performance metrics that 1471 could be relevant, nor does it formally specify metrics. 1473 The impact of ALTO can be classified regarding a number of different 1474 criteria: 1476 o Total amount and distribution of traffic: ALTO enables ISPs to 1477 influence and localize traffic of applications that use the ALTO 1478 service. An ISP may therefore be interested in analyzing the 1479 impact on the traffic, i.e., whether network traffic patterns are 1480 shifted. For instance, if ALTO shall be used to reduce the inter- 1481 domain P2P traffic, it makes sense to evaluate the total amount of 1482 inter-domain traffic of an ISP. Then, one possibility is to study 1483 how the introduction of ALTO reduces the total inter-domain 1484 traffic (inbound and/our outbound). If the ISPs intention is to 1485 localize the traffic inside his network, the network-internal 1486 traffic distribution will be of interest. Effectiveness of 1487 localization can be quantified in different ways, e.g., by the 1488 load on core routers and backbone links, or by considering more 1489 advanced effects, such as the average number of hops that traffic 1490 traverses inside a domain. 1492 o Application performance: The objective of ALTO is improve 1493 application performance. ALTO can be used by very different types 1494 applications, with different communication characteristics and 1495 requirements. For instance, if ALTO guidance achieves traffic 1496 localization, one would expect that applications achieve a higher 1497 throughput and/or smaller delays to retrieve data. If 1498 application-specific performance characteristics (e.g., video or 1499 audio quality) can be monitored, such metrics related to user 1500 experience could also help to analyze the benefit of an ALTO 1501 deployment. If available, selected statistics from the TCP/IP 1502 stack in hosts could be leveraged, too. 1504 Of potential interest can also be the share of applications or 1505 customers that actually use an offered ALTO service, i.e., the 1506 adoption of the service. 1508 Monitoring statistics can be aggregated, averaged, and normalized in 1509 different ways. This document does not mandate specific ways how to 1510 calculate metrics. 1512 3.4.3. System and Service Performance 1514 A number of interesting parameters can be measured at the ALTO 1515 server. [RFC7285] suggests certain ALTO-specific metrics to be 1516 monitored: 1518 o Requests and responses for each service listed in a Information 1519 Directory (total counts and size in bytes). 1521 o CPU and memory utilization 1523 o ALTO map updates 1525 o Number of PIDs 1527 o ALTO map sizes (in-memory size, encoded size, number of entries) 1529 This data characterizes the workload, the system performance as well 1530 as the map data. Obviously, such data will depend on the 1531 implementation and the actual deployment of the ALTO service. 1533 Logging is also recommended in [RFC7285]. 1535 3.4.4. Monitoring Infrastructures 1537 Understanding the impact of ALTO may require interaction between 1538 different systems, operating at different layers. Some information 1539 discussed in the preceding sections is only visible to an ISP, while 1540 application-level performance can hardly be measured inside the 1541 network. It is possible that not all information of potential 1542 interest can directly be measured, either because no corresponding 1543 monitoring infrastructure or measurement method exists, or because it 1544 is not easily accessible. 1546 One way to quantify the benefit of deploying ALTO is to measure 1547 before and after enabling the ALTO service. In addition to passive 1548 monitoring, some data could also be obtained by active measurements, 1549 but due to the resulting overhead, the latter should be used with 1550 care. Yet, in all monitoring activities an ALTO service provider has 1551 to take into account that ALTO clients are not bound to ALTO server 1552 guidance as ALTO is only one source of information, and any 1553 measurement result may thus be biased. 1555 Potential sources for monitoring the use of ALTO include: 1557 o Network monitoring and performance management systems: Many ISPs 1558 deploy systems to monitor the network traffic, which may have 1559 insight into traffic volumes, network topology, bandwidth 1560 information inside the management area. Data can be obtained by 1561 SNMP, NETCONF, IP Flow Information Export (IPFIX), syslog, etc. 1562 On-demand OAM tests (such as Ping or BDF) could also be used. 1564 o Applications/clients: Relevant data could be obtained by 1565 instrumentation of applications. 1567 o ALTO server: If available, log files or other statistics data 1568 could be analyzed. 1570 o Other application entities: In several use cases, there are other 1571 application entities that could provide data as well. For 1572 instance, there may be centralized log servers that collect data. 1574 In many ALTO use cases some data sources are located within an ISP 1575 network while some other data is gathered at application level. 1576 Correlation of data could require a collaboration agreement between 1577 the ISP and an application owner, including agreements of data 1578 interchange formats, methods of delivery, etc. In practice, such a 1579 collaboration may not be possible in all use cases of ALTO, because 1580 the monitoring data can be sensitive, and because the interacting 1581 entities may have different priorities. Details of how to build an 1582 over-arching monitoring system for evaluating the benefits of ALTO 1583 are outside the scope of this memo. 1585 3.5. Abstract Map Examples for Different Types of ISPs 1587 3.5.1. Small ISP with Single Internet Uplink 1589 The ALTO protocol does not mandate how to determine costs between 1590 endpoints and/or determine map data. In complex usage scenarios this 1591 can be a non-trivial problem. In order to show the basic principle, 1592 this and the following sections explain for different deployment 1593 scenarios how ALTO maps could be structured. 1595 For a small ISP, the inter-domain traffic optimizing problem is how 1596 to decrease the traffic exchanged with other ISPs, because of high 1597 settlement costs. By using the ALTO service to optimize traffic, a 1598 small ISP can define two "optimization areas": one is its own 1599 network; the other one consists of all other network destinations. 1600 The cost map can be defined as follows: the cost of a link between 1601 clients of the inner ISP's network is lower than between clients of 1602 the outer ISP's network and clients of inner ISP's network. As a 1603 result, a host with an ALTO client inside the network of this ISP 1604 will prefer retrieving data from hosts connected to the same ISP. 1606 An example is given in Figure 9. It is assumed that ISP A is a small 1607 ISP only having one access network. As operator of the ALTO service, 1608 ISP A can define its network to be one optimization area, named as 1609 PID1, and define other networks to be the other optimization area, 1610 named as PID2. C1 is denoted as the cost inside the network of ISP 1611 A. C2 is denoted as the cost from PID2 to PID1, and C3 from PID1 to 1612 PID2. For the sake of simplicity, in the following C2=C3 is assumed. 1613 In order to keep traffic local inside ISP A, it makes sense to define 1614 C1| | 1623 | | C3 (=C2) \\\\ //// 1624 \\ // \-----------/ 1625 \\ // 1626 \\\\ //// 1627 ----------- 1629 Figure 9: Example ALTO deployment for a small ISP 1631 A simplified extract of the corresponding ALTO network and cost maps 1632 is listed in Figure 10 and Figure 11, assuming that the network of 1633 ISP A has the IPv4 address ranges 192.0.2.0/24 and 198.51.100.0/25, 1634 as well as the IPv6 address range 2001:db8:100::/48. In this 1635 example, the cost values C1 and C2 can be set to any number C1|PID 2 |<--->+PID 3 | | 1749 | |C1 | |C2 | |C3 | | +----------------+ 1750 | +---+--+ +------+ +--+---+ | | | 1751 | ^ ^ | C8 | Other Networks | 1752 | | | |<--------+ PID 5 | 1753 | +------------------------+ | | | 1754 | C6 | | | 1755 +------------------------------------+ +----------------+ 1757 Figure 12: ALTO deployment in large ISPs with layered fixed network 1758 structures 1760 3.5.3. ISP with Fixed and Mobile Network 1762 An ISP with both mobile network and fixed network may focus on 1763 optimizing the mobile traffic by keeping traffic in the fixed network 1764 as much as possible, because wireless bandwidth is a scarce resource 1765 and traffic is costly in mobile network. In such a case, the main 1766 requirement of traffic optimization could be decreasing the usage of 1767 radio resources in the mobile network. An ALTO service can be 1768 deployed to meet these needs. 1770 Figure 13 shows an example: ISP A operates one mobile network, which 1771 is connected to a backbone network. The ISP also runs two fixed 1772 access networks AN A and AN B, which are also connected to the 1773 backbone network. In this network structure, the mobile network can 1774 be defined as one optimization area, and PID 1 can be assigned to it. 1775 Access networks AN A and B can also be defined as optimization areas, 1776 and PID 2 and PID 3 can be assigned, respectively. The cost values 1777 are then defined as shown in Figure 13. 1779 To decrease the usage of wireless link, the relationship of these 1780 costs can be defined as follows: 1782 From view of mobile network: C4 < C1 and C4 = C8. This means that 1783 clients in mobile network requiring data resources from other clients 1784 will prefer clients in AN A or B to clients in the mobile network. 1785 This policy can decrease the usage of wireless link and power 1786 consumption in terminals. 1788 From view of AN A: C2 < C6, C5 = maximum cost. This means that 1789 clients in other optimization area will avoid retrieving data from 1790 the mobile network. 1792 From view of AN B: Analog to the view of AN A, C3 < C8 and C9 = 1793 maximum cost. 1795 +-----------------------------------------------------------------+ 1796 | | 1797 | ISP A +-------------+ | 1798 | +--------+ ALTO +---------+ | 1799 | | | Service | | | 1800 | | +------+------+ | | 1801 | | | | | 1802 | | | | | 1803 | | | | | 1804 | +-------+-------+ | C6 +--------+------+ | 1805 | | AN A |<--------------| AN B | | 1806 | | PID 2 | C7 | | PID 3 | | 1807 | | C2 |-------------->| C3 | | 1808 | +---------------+ | +---------------+ | 1809 | ^ | | | ^ | 1810 | | | | | | | 1811 | | | C4 | C8 | | | 1812 | C5 | | | | | C9 | 1813 | | | +--------+---------+ | | | 1814 | | +-->| Mobile Network |<---+ | | 1815 | | | PID 1 | | | 1816 | +------- | C1 |----------+ | 1817 | +------------------+ | 1818 +-----------------------------------------------------------------+ 1820 Figure 13: ALTO deployment in ISPs with mobile network 1822 These examples show that for ALTO in particular the relationships 1823 between different costs matter; the operator of the server has 1824 several degrees of freedom how to set the absolute values. 1826 3.6. Comprehensive Example for Map Calculation 1828 In addition to the previous, abstract examples, this section presents 1829 a more detailed scenario with a realistic IGP and BGP routing 1830 protocol configuration. This example was first described in 1831 [I-D.seidel-alto-map-calculation]. 1833 3.6.1. Example Network 1835 Figure 14 depicts a network which is used to explain the steps 1836 carried out in the course of this example. The network consists of 1837 nine routers (R1 to R9). Two of them are border routers (R1 + R8) 1838 connected to neighbored networks (AS 2 to AS 4). Furthermore, AS 4 1839 is not directly connected to the local network, but has AS 3 as 1840 transit network. The links between the routers are point-to-point 1841 connections. These connections also form the core network with the 1842 2001:db8:1:0::/56 prefix. This prefix is large enough to provide 1843 addresses for all router interconnections. In addition to the core 1844 network, the local network also has five client networks attached to 1845 five different routers (R2, R5, R6, R7 and R9). Each client network 1846 has a /56 prefix with 2001:db8:1:x00:: (x = [1..5]) as network 1847 address. 1849 +-------------------+ +-----+ +-----+ +-------------------+ 1850 |2001:db8:1:200::/56+----+ R6 | | R7 +----+2001:db8:1:300::/56| 1851 +-------------------+ +--+--+ +--+--+ +-------------------+ 1852 | | 1853 +---------------+ | | 1854 | AS 2 | | | 1855 |2001:db8:2::/48| | 10 | 10 1856 +------------+--+ | | 1857 | | | 1858 | | | 1859 +--+--+ 15 +--+--+ +--+--+ +-------------------+ 1860 | R1 +--------+ R3 +----+ R5 |----+2001:db8:1:400::/56| 1861 +--+--+ +--+--+ 5 +--+--+ +-------------------+ 1862 | \ / | | 1863 | \ / 15 | | 1864 | \ / | | +---------------+ 1865 | \/ | | | AS 4 | 1866 | 20 /\ | 5 | 10 |2001:db8:4::/48| 1867 | / \ | | +-------+-------+ 1868 | / \ 20 | | | 1869 | / \ | | | 1870 +--+--+ +--+--+ +--+--+ +-------+-------+ 1871 | R2 | | R4 | | R8 +--------+ AS 3 | 1872 +--+--+ +--+--+ +--+--+ |2001:db8:3::/48| 1873 | | | +---------------+ 1874 | | | 10 1875 | | 20 | 1876 +------------+------+ | +--+--+ +-------------------+ 1877 |2001:db8:1:100::/56| +-------+ R9 +----+2001:db8:1:500::/56| 1878 +-------------------+ +-----+ +-------------------+ 1880 Figure 14: Example network 1882 The example network utilizes two different routing protocols, one for 1883 IGP and another for EGP routing. The used IGP is a link-state 1884 protocol such as IS-IS. The applied link weights are annotated in 1885 the graph and additionally shown in Figure 15. All links are 1886 bidirectional and their weights are symmetric. To obtain the 1887 topology and routing information from the network, the topology data 1888 source must be connected directly to one of the routers (R1...R9). 1889 Furthermore, the topology data source must be enabled to communicate 1890 with the router and vice versa. 1892 The Border Gateway Protocol (BGP) is used in this scenario to route 1893 between autonomous systems (AS). External BGP is running on the two 1894 border routers R1 and R8. Furthermore, internal BGP is used to 1895 propagate external as well as internal prefixes within the network 1896 boundaries; it is running on every router with an attached client 1897 network (R2, R5, R6, R7 and R9). Since no route reflector is present 1898 it is necessary to fetch routes from each BGP router separately. 1900 R1 R2 R3 R4 R5 R6 R7 R8 R9 1901 R1 0 15 15 20 - - - - - 1902 R2 15 0 20 - - - - - - 1903 R3 15 20 0 5 5 10 - - - 1904 R4 20 - 5 0 5 - - - 20 1905 R5 - - 5 5 0 - 10 10 - 1906 R6 - - 10 - - 0 - - - 1907 R7 - - - - 10 - 0 - - 1908 R8 - - - - 10 - - 0 10 1909 R9 - - - 20 - - - 10 0 1911 Figure 15: Example network link weights 1913 For monitoring purposes it is possible to enable e.g. SNMP or 1914 NETCONF on the routers within the network. This way an ALTO server 1915 may obtain several additional information about the state of the 1916 network. For example, utilization, latency, and bandwidth 1917 information could be retrieved periodically from the network 1918 components to get and keep an up-to-date view on the network 1919 situation. 1921 In the following, it is assumed that the listed attributes are 1922 collected from the network: 1924 o IS-IS: topology, link weights 1926 o BGP: prefixes, AS numbers, AS distances, or other BGP metrics 1928 o SNMP: latency, utilization, bandwidth 1930 3.6.2. Potential Input Data Processing and Storage 1932 Due to the variety of data source available in a network it may be 1933 necessary to aggregate the information and define a suitable data 1934 model that can hold the information efficiently and easily 1935 accessible. One potential model is an annotated directed graph that 1936 represents the topology. The attributes can be annotated at the 1937 corresponding positions in the graph. In the following it is shown 1938 how such a topology graph could describe the example topology. 1940 In the topology graph, a node represents a router in the network, 1941 while the edges stand for the links that connect the routers. Both 1942 routers and links have a set of attributes that store information 1943 gathered from the network. 1945 Each router could be associated with a basic set of information, such 1946 as: 1948 o ID: Unique ID within the network to identify the router. 1950 o Neighbor IDs: List of directly connected routers. 1952 o Endpoints: List of connected endpoints. The endpoints may also 1953 have further attributes themselves depending on the network and 1954 address type. Such potential attributes are costs for reaching 1955 the endpoint from the router, AS numbers, or AS distances. 1957 In addition to the basic set many more attributes may be assigned to 1958 router nodes. This mainly depends on the utilized data sources. 1959 Examples for such additional attributes are geographic location, host 1960 name and/or interface types, just to name a few. 1962 The example network shown in Figure 14 represents such an internal 1963 network graph where the routers R1 to R9 represent the nodes and the 1964 connections between them are the links. For instance, R2 has one 1965 directly attached IPv6 endpoint that belongs to its own AS, as shown 1966 in Figure 16. 1968 ID: 2 1970 Neighbor IDs: 1,3 (R1, R3) 1972 Endpoints: 1974 Endpoint: 2001:db8:1:100::/56 1976 Weight: 10 (e.g., the default IGP metric value) 1978 ASNumber: 1 (our own AS) 1980 ASDistance: 0 1982 Host Name: R2 1984 Figure 16: Example router R2 1986 Router R8 has two attached IPv6 endpoints, as explained in Figure 17. 1987 The first one belongs to a directly neighbored AS with AS number 3. 1988 The AS distance from our network to AS3 is 1. The second endpoint 1989 belongs to an AS (AS4) that is no direct neighbor but directly 1990 connected to AS3. To reach endpoints in AS4 it is necessary to cross 1991 AS3, which increases the AS distance by one. 1993 ID: 8 1995 Neighbor IDs: 5,9 (R5, R9) 1997 Endpoints: 1999 Endpoint: 2001:db8:3::/48 2001 Weight: 100 2003 ASNumber: 3 2005 ASDistance: 1 2007 Endpoint: 2001:db8:4::/48 2009 Weight: 200 2011 ASNumber: 4 2013 ASDistance: 2 2015 Host Name: R8 2017 Figure 17: Example router R8 2019 A potential set of attributes for a link is described in the 2020 following list: 2022 o Source ID: ID of the source router of the link. 2024 o Destination ID: ID of the destination router of the link. 2026 o Weight: The cost to cross the link, e.g., defined by the used IGP. 2028 Additional attributes that provide technical details and state 2029 information can be assigned to links as well. The availability of 2030 such additional attributes depends on the utilized data sources. 2031 Such attributes can be characteristics like maximum bandwidth, 2032 utilization, or latency on the link as well as the link type. 2034 In the example, the link attributes are equal for all links and only 2035 their values differ. It is assumed that the attributes utilization, 2036 bandwidth, and latency are collected e.g. via SNMP or NETCONF. In 2037 the topology of Figure 14 the links between R1 and R2 would then have 2038 the following link attributes explained in Figure 18: 2040 R1->R2: 2042 Source ID: 1 2044 Destination ID: 2 2046 Weight: 15 2048 Bandwidth: 10Gbit/s 2050 Utilization: 0.1 2052 Latency: 2ms 2054 R2->R1: 2056 Source ID: 2 2058 Destination ID: 1 2060 Weight: 15 2062 Bandwidth: 10Gbit/s 2064 Utilization: 0.55 2066 Latency: 5ms 2068 Figure 18: Link attributes 2070 It has to be emphasized that values for utilization and latency can 2071 be very volatile. 2073 3.6.3. Calculation of Network Map from the Input Data 2075 The goal of the ALTO map calculation process is to get from the graph 2076 representation of the network to a coarser-grained and abstract 2077 matrix representation. The first step is to generate the network 2078 map. Only after the network map has been generated it is possible to 2079 compute the cost map, since it relies on the network map. 2081 To generate an ALTO network map a grouping function is required. A 2082 grouping function processes information from the network graph to 2083 group endpoints into PIDs. The way of grouping is manifold and 2084 algorithms can utilize any information provided by the network graph 2085 to perform the grouping. The functions may omit certain endpoints in 2086 order to simplify the map or in order to hide details about the 2087 network that are not intended to be published in the resulting ALTO 2088 network map. 2090 For IP endpoints, which are either an IP (version 4 or version 6) 2091 address or prefix, [RFC7285] requires the use of longest-prefix 2092 matching algorithm to map IPs to PIDs. This requirement results in 2093 the constraint that every IP must be mapped to a PID and that the 2094 same prefix or address is not mapped to more than one PID. To meet 2095 the first constraint every calculated map must provide a default PID 2096 that contains the prefixes 0.0.0.0/0 for IPv4 and ::/0 for IPv6. 2097 Both prefixes cover their entire address space and if no other PID 2098 matches an IP endpoint the default PID will. The second constraint 2099 must be met by the grouping function that assigns endpoints to PIDs. 2100 In case of collision the grouping function must decide to which PID 2101 an endpoint is assigned. These or other constraints may apply to 2102 other endpoint types depending on the used matching algorithm. 2104 A simple example for such grouping is to compose PIDs by host names. 2105 For instance, each router's host name is selected as the name for a 2106 PID and the attached endpoints are the member endpoints of the 2107 corresponding PID. Additionally, backbone prefixes should not appear 2108 in the map so they are filtered out. The following table in 2109 Figure 19 shows the resulting ALTO network map, using the network in 2110 Figure 14 as example: 2112 PID | Endpoints 2113 ---------+----------------------------------- 2114 R1 | 2001:db8:2::/48 2115 R2 | 2001:db8:1:100::/56 2116 R5 | 2001:db8:1:400::/56 2117 R6 | 2001:db8:1:200::/56 2118 R7 | 2001:db8:1:300::/56 2119 R8 | 2001:db8:3::/48, 2001:db8:4::/48 2120 R9 | 2001:db8:1:500::/56 2121 default | 0.0.0.0/0, ::/0 2123 Figure 19: Example ALTO network map 2125 Since router R3 and R4 have no endpoints assigned they are not 2126 represented in the network map. Furthermore, as previously 2127 mentioned, the "default" PID was added to represent all endpoints 2128 that are not part of the example network. 2130 3.6.4. Calculation of Cost Map 2132 After successfully creating the network map, the typical next step is 2133 to calculate the costs between the generated PIDs, which form the 2134 cost map. Those costs are calculated by cost functions. A cost 2135 function may calculate unidirectional values, which means it is 2136 necessary to compute the costs from every PID to every PID. In 2137 general, it is possible to use all available information in the 2138 network graph to compute the costs. In case a PID contains more than 2139 one IP address or prefix, the cost function may first calculate a set 2140 of cost values for each source/destination IP pair. In that case, a 2141 tie-breaker function is required to decide the resulting cost value 2142 as [RFC7285] allows one cost value only between 2 PIDs. Such tie- 2143 breaker can be a simple function such as minimum, maximum, or average 2144 value. 2146 No matter what metric the cost function is using, the path from 2147 source to destination is usually defined by the path with minimum 2148 weight. When the link weight is represented by an additive metric, 2149 the path weight is the sum of link weights of all traversed links. 2150 The path may be determined for instance with the Bellman-Ford or 2151 Dijkstra algorithm. The latter progressively builds the shortest 2152 path in terms of cumulated link lengths. In our example, the link 2153 lengths are link weights with values illustrated in Figure 15. 2154 Hence, the cost function generally extracts the optimal path with 2155 respect to a chosen metric, such as the IGP link weight. It is also 2156 possible that more than one path with the same minimum weight exist, 2157 which means it is not entirely clear which path is going to be 2158 selected by the network. Hence, a tie-breaker similar to the one 2159 used to resolve costs for PIDs with multiple endpoints is necessary. 2161 An important note is that [RFC7285] does not require cost maps to 2162 provide costs for every PID pair, so if no path cost can be 2163 calculated for a certain pair, the corresponding field in the cost 2164 map is left out. Administrators may also not want to provide cost 2165 values for some PID pairs due to various reasons. Such pairs may be 2166 defined before the cost calculation is performed. 2168 Based on the network map example shown in the previous section it is 2169 possible to calculate the cost maps. Figure 20 provides an example 2170 where the selected metric for the cost map is the minimum number of 2171 hops necessary to get from the endpoints in the source PID to 2172 endpoints in the destination PID. Our chosen tie-breaker selects the 2173 minimum hop count when more than one value is returned by the cost 2174 function. 2176 PID | default | R1 | R2 | R5 | R6 | R7 | R8 | R9 | 2177 --------+---------+-----+-----+-----+-----+-----+-----+-----| 2178 default | x | x | x | x | x | x | x | x | 2179 R1 | x | 0 | 2 | 3 | 3 | 4 | 4 | 3 | 2180 R2 | x | 2 | 0 | 3 | 3 | 4 | 4 | 4 | 2181 R5 | x | 3 | 3 | 0 | 3 | 2 | 2 | 3 | 2182 R6 | x | 3 | 3 | 3 | 0 | 4 | 4 | 4 | 2183 R7 | x | 4 | 4 | 2 | 4 | 0 | 3 | 4 | 2184 R8 | x | 4 | 4 | 2 | 4 | 3 | 0 | 2 | 2185 R9 | x | 3 | 4 | 3 | 4 | 4 | 2 | 0 | 2187 Figure 20: Example ALTO hopcount cost map 2189 It should be mentioned that R1->R9 has several paths with equal path 2190 weights. The paths R1->R3->R5->R8->R9, R1->R3->R4->R9 and R1->R4->R9 2191 all have a path weight of 40. Due to the minimum hopcount value tie- 2192 breaker, 3 hops is chosen as value for the path R1->R4->R9. 2193 Furthermore, since the "default" PID is, in a sense, a virtual PID 2194 with no endpoints that are part of the example network, no cost 2195 values are calculated for other PIDs from or towards it. 2197 3.7. Deployment Experiences 2199 There are multiple interoperable implementations of the ALTO 2200 protocol. Some experiences in implementating and using ALTO for 2201 large-scale networks have been documented in 2202 [I-D.seidel-alto-map-calculation] and are here summarized: 2204 o Data collection: Retrieving topology information typically 2205 requires implementing several protocols other than ALTO for data 2206 collection. For such other protocols, ALTO deployments faced 2207 protocol behaviors that were different to what would be expected 2208 from the specification of the corresponding protocol. This 2209 includes behavior caused by older versions of the protocol 2210 specification, a lax interpretation on the remote side or simply 2211 incompatibility with the corresponding standard. This sort of 2212 problems in collecting data can make an ALTO deployment more 2213 complicated, even if it is unrelated to ALTO protocol itself. 2215 o Data processing: Processing network information can be very 2216 complex and quite resource-demanding. Gathering information from 2217 an autonomous system connected to Internet may imply that a server 2218 must store and process hundreds of thousands of prefixes, several 2219 hundreds of megabytes of IPFIX/Netflow information per minute, and 2220 information from hundreds of routers and attributes of thousands 2221 of links. A lot of disk memory, RAM, and CPU cycles as well as 2222 efficient algorithms are required to process the information. 2223 Operators of an ALTO server have to be aware that significant 2224 compute resources are not only required for the ALTO server, but 2225 also for the corresponding data collection. 2227 o Network map calculation: Large IP based networks consist of 2228 hundreds of thousands of prefixes, which have to be mapped to PIDs 2229 in the process of network map calculation. As a result, network 2230 maps get very large (up to tens of megabytes). However, depending 2231 on the design of the network and the chosen grouping function the 2232 calculated network maps contains redundancy that can be removed. 2233 There are at least two ways to reduce the size by removing 2234 redundancy. First, adjacent IP prefixes can be merged. When a 2235 PID has two adjacent prefix entries it can merge them together to 2236 one larger prefix. It is mandatory that both prefixes are in the 2237 same PID. However, it cannot be ruled out that the large prefix 2238 is assigned to another PID. This must be checked and it is up to 2239 the grouping function whether it merges the prefixes and removes 2240 the larger prefix from the other PID or not. A simple example, 2241 when a PID comprises the prefixes 2001:db8:0:0::/64 and 2001:db8: 2242 0:1::/64 it can easily merge them to 2001:db8:0:0::/63. Second, a 2243 prefix and its next-longer-prefix match may be in the same PID. 2244 In this case, the smaller prefix can simply be removed since it is 2245 redundant for obvious reasons. A simple example, a PID comprises 2246 the prefixes 2001:db8:0:0::/62 and 2001:db8:0:1::/64 and the /62 2247 is the next-longer prefix match of the /64, the /64 prefix can 2248 simply be removed. In contrast, if another PID contains the 2001: 2249 db8:0:0::/63 prefix, the entry 2001:db8:0:1::/64 cannot be removed 2250 since the next-longer prefix is not in the same PID anymore. 2251 Operators of an ALTO server thus have to analyze whether their 2252 address assignment schemes allows such tuning. 2254 o Cost map calculation: One known implementation challenge with cost 2255 map calculations is the vast amount of CPU cycles that may be 2256 required to calculate the costs in large networks. This is 2257 particular problematic if costs are calculated between the 2258 endpoints of each source-destination PID pair. Very often several 2259 to many endpoints of a PID are attached to the same node, so the 2260 same path cost is calculated several times. This is clearly 2261 inefficient. A remedy could be more sophisticated algorithms, 2262 such as looking up the routers the endpoints of each PID are 2263 connected to in our network graph and calculated cost map based on 2264 the costs between the routers. When deploying and configuring 2265 ALTO servers, administrators should consider the impact of huge 2266 cost maps and possibly ensure that map sizes do not get too large. 2268 In addition, further deployment experiences have been documented. 2269 One real example is described in greater detail in reference 2270 [I-D.lee-alto-chinatelecom-trial]. 2272 Also, experiments have been conducted with ALTO-like deployments in 2273 Internet Service Provider (ISP) networks. For instance, NTT 2274 performed tests with their HINT server implementation and dummy nodes 2275 to gain insight on how an ALTO-like service can influence peer-to- 2276 peer systems [RFC6875]. The results of an early experiment conducted 2277 in the Comcast network are documented in [RFC5632]. 2279 4. Using ALTO for P2P Traffic Optimization 2281 4.1. Overview 2283 4.1.1. Usage Scenario 2285 Originally, peer-to-peer (P2P) applications were the main driver for 2286 the development of ALTO. In this use case it is assumed that one 2287 party (usually the operator of a "managed" IP network domain) will 2288 disclose information about the network through ALTO. The application 2289 overlay will query this information and optimize its behavior in 2290 order to improve performance or Quality of Experience in the 2291 application while reducing the utilization of the underlying network 2292 infrastructure. The resulting win-win situation is assumed to be the 2293 incentive for both parties to provide or consume the ALTO 2294 information, respectively. 2296 P2P systems can be built with or without use of a centralized 2297 resource directory ("tracker"). The scope of this section is the 2298 interaction of P2P applications with the ALTO service. In this 2299 scenario, the resource consumer ("peer") asks the resource directory 2300 for a list of candidates that can provide the desired resource. 2301 There are different options for how ALTO can be deployed in such use 2302 cases with a centralized resource directory. 2304 For efficiency reasons (i.e., message size), only a subset of all 2305 resource providers known to the resource directory will be returned 2306 to the resource consumer. Some or all of these resource providers, 2307 plus further resource providers learned by other means such as direct 2308 communication between peers, will be contacted by the resource 2309 consumer for accessing the resource. The purpose of ALTO is giving 2310 guidance on this peer selection, which should yield better-than- 2311 random results. The tracker response as well as the ALTO guidance 2312 are most beneficial in the initial phase after the resource consumer 2313 has decided to access a resource, as long as only few resource 2314 providers are known. Later, when the resource consumer has already 2315 exchanged some data with other peers and measured the transmission 2316 speed, the relative importance of ALTO may dwindle. 2318 4.1.2. Applicability of ALTO 2320 A tracker-based P2P application can leverage ALTO in different ways. 2321 In the following, the different alternatives and their pros and cons 2322 are discussed. 2324 ,-------. +-----------+ 2325 ,---. ,-' ========>| Peer 1 |******** 2326 ,-' `-. / ISP 1 V \ |ALTO Client| * 2327 / \ / +-------------+ \ +-----------+ * 2328 / ISP X \ | + ALTO Server | | +-----------+ * 2329 / \ \ +-------------+<====>| Peer 2 | * 2330 ; +---------+ : \ / |ALTO Client|****** * 2331 | | Global | | `-. ,-' +-----------+ * * 2332 | | Tracker | | `-------' * * 2333 | +---------+ | ,-------. +-----------+ * * 2334 : * ; ,-' ========>| Peer 3 | * * 2335 \ * / / ISP 2 V \ |ALTO Client|**** * * 2336 \ * / / +-------------+ \ +-----------+ * * * 2337 \ * / | | ALTO Server | | +-----------+ * * * 2338 `-. * ,-' \ +-------------+<====>| Peer 4 |** * * * 2339 `-*-' \ / |ALTO Client| * * * * 2340 * `-. ,-' +-----------+ * * * * 2341 * `-------' * * * * 2342 * * * * * 2343 ******************************************************* 2344 Legend: 2345 === ALTO protocol 2346 *** Application protocol 2348 Figure 21: Global tracker and local ALTO servers 2350 Figure 21 depicts a tracker-based P2P system with several peers. The 2351 peers (i.e., resource consumers) embed an ALTO client to improve the 2352 resource provider selection. The tracker (i.e., resource directory) 2353 itself may be hosted and operated by another entity. A tracker 2354 external to the ISPs of the peers may be a typical use case. For 2355 instance, a tracker like Pirate Bay can serve BitTorrent peers world- 2356 wide. The figure only shows one tracker instance, but deployments 2357 with several trackers could be possible, too. 2359 The scenario depicted in Figure 21 lets the peers directly 2360 communicate with their ISP's ALTO server (i.e., ALTO client embedded 2361 in the peers), thus giving the peers the most control on which 2362 information they query for, as they can integrate information 2363 received from one tracker or several trackers and through direct 2364 peer-to-peer knowledge exchange. For instance, the latter approach 2365 is called peer exchange (PEX) in BitTorrent. In this deployment 2366 scenarios, the peers have to discover a suitable ALTO server (e.g., 2367 offered by their ISP, as described in [RFC7286]). 2369 There are also tracker-less P2P system architectures that do not rely 2370 on centralized resource directories, e.g., unstructured P2P networks. 2371 Regarding the use of ALTO, their deployment would be similar to 2372 Figure 21, since the ALTO client would be embedded in the peers as 2373 well. This option is not further considered in this memo. 2375 ,-------. 2376 ,---. ,-' `-. +-----------+ 2377 ,-' `-. / ISP 1 \ | Peer 1 |******** 2378 / \ / +-------------+ \ | | * 2379 / ISP X \ ++====>| ALTO Server | )+-----------+ * 2380 / \ || \ +-------------+ / +-----------+ * 2381 ; +-----------+ : || \ / | Peer 2 | * 2382 | | Tracker |<====++ `-. ,-' | |****** * 2383 | |ALTO Client| | `-------' +-----------+ * * 2384 | +-----------+<====++ ,-------. * * 2385 : * ; || ,-' `-. +-----------+ * * 2386 \ * / || / ISP 2 \ | Peer 3 | * * 2387 \ * / || / +-------------+ \ | |**** * * 2388 \ * / ++====>| ALTO Server | )+-----------+ * * * 2389 `-. * ,-' \ +-------------+ / +-----------+ * * * 2390 `-*-' \ / | Peer 4 |** * * * 2391 * `-. ,-' | | * * * * 2392 * `-------' +-----------+ * * * * 2393 * * * * * 2394 * * * * * 2395 ********************************************************* 2396 Legend: 2397 === ALTO protocol 2398 *** Application protocol 2400 Figure 22: Global tracker accessing ALTO server at various ISPs 2402 An alternative deployment scenario for a tracker-based system is 2403 depicted in Figure 22. Here, the tracker embeds the ALTO client. 2404 When the tracker receives a request from a querying peer, it first 2405 discovers the ALTO server responsible for the querying peer. This 2406 discovery can be done by using various ALTO server discovery 2407 mechanisms [RFC7286] [I-D.kiesel-alto-xdom-disc]. The ALTO client 2408 subsequently sends to the querying peer only those peers that are 2409 preferred by the ALTO server responsible for the querying peer. The 2410 peers do not query the ALTO servers themselves. This gives the peers 2411 a better initial selection of candidates, but does not consider peers 2412 learned through direct peer-to-peer knowledge exchange. 2414 ISP 1 ,-------. +-----------+ 2415 ,---. +-------------+******| Peer 1 | 2416 ,-' `-. /| Tracker |\ | | 2417 / \ / +-------------+**** +-----------+ 2418 / ISP X \ | === | * +-----------+ 2419 / \ \ +-------------+ / * | Peer 2 | 2420 ; +---------+ : \| AlTO Server |/ ***| | 2421 | | Global | | +-------------+ +-----------+ 2422 | | Tracker | | `-------' 2423 | +---------+ | +-----------+ 2424 : * ; ,-------. | Peer 3 | 2425 \ * / +-------------+ ****| | 2426 \ * / /| Tracker |*** +-----------+ 2427 \ * / / +-------------+ \ +-----------+ 2428 `-. * ,-' | === | | Peer 4 |** 2429 `-*-' \ +-------------+ / | | * 2430 * \| ALTO Server |/ +-----------+ * 2431 * +-------------+ * 2432 * ISP 2 `-------' * 2433 ************************************************* 2434 Legend: 2435 === ALTO protocol 2436 *** Application protocol 2438 Figure 23: Local trackers and local ALTO servers (P4P approach) 2440 There are some attempts to let ISPs deploy their own trackers, as 2441 shown in Figure 23. In this case, the client cannot get guidance 2442 from the ALTO server other than by talking to the ISP's tracker, 2443 which in turn communicates with the ALTO server using the ALTO 2444 protocol. It should be noted that the peers are still allowed to 2445 contact other trackers operated by entities other than the peer's 2446 ISP, but in this case they cannot benefit from ALTO guidance. 2448 4.2. Deployment Recommendations 2450 4.2.1. ALTO Services 2452 The ALTO protocol specification [RFC7285] details how an ALTO client 2453 can query an ALTO server for guiding information and receive the 2454 corresponding replies. In case of peer-to-peer networks, two 2455 different ALTO services can be used: The Cost Map Service is often 2456 preferred as solution by peer-to-peer software implementors and 2457 users, since it avoids disclosing peer IP addresses to a centralized 2458 entity. Alternatively, network operators may have a preference for 2459 the Endpoint Cost Service (ECS), since it does not require exposure 2460 of the network topology. 2462 For actual use of ALTO in P2P applications, both software vendors and 2463 network operators have to agree which ALTO services to use. The ALTO 2464 protocol is flexible and supports both services. Note that for other 2465 use cases of ALTO, in particular in more controlled environments, 2466 both the Cost Map Service as well as Endpoint Cost Service might be 2467 feasible and it is more an engineering trade-off whether to use a 2468 map-based or query-based ALTO service. 2470 4.2.2. Guidance Considerations 2472 As explained in Section 4.1.2, for a tracker-based P2P application 2473 there are two fundamentally different possibilities where to place 2474 the ALTO client: 2476 1. ALTO client in the resource consumer ("peer") 2478 2. ALTO client in the resource directory ("tracker") 2480 Both approaches have advantages and drawbacks that have to be 2481 considered. If the ALTO client is in the resource consumer 2482 (Figure 21), a potentially very large number of clients has to be 2483 deployed. Instead, when using an ALTO client in the resource 2484 directory (Figure 22 and Figure 23), ostensibly peers do not have to 2485 directly query the ALTO server. In this case, an ALTO server could 2486 even not permit access to peers. 2488 However, it seems to be beneficial for all participants to let the 2489 peers directly query the ALTO server. Considering the plethora of 2490 different applications that could use ALTO, e.g. multiple tracker or 2491 non-tracker based P2P systems or other applications searching for 2492 relays, this renders the ALTO service more useful. The peers are 2493 also the single point having all operational knowledge to decide 2494 whether to use the ALTO guidance and how to use the ALTO guidance. 2495 For a given peer one can also expect that an ALTO server of the 2496 corresponding ISP provides useful guidance and can be discovered. 2498 Yet, ALTO clients in the resource consumer also have drawbacks 2499 compared to use in the resource directory. In the following, both 2500 scenarios are compared more in detail in order to explain the impact 2501 on ALTO guidance and the need for third-party ALTO queries. 2503 In the first scenario (see Figure 24), the peer (resource consumer) 2504 queries the tracker (resource directory) for the desired resource 2505 (F1). The resource directory returns a list of potential resource 2506 providers without considering ALTO (F2). It is then the duty of the 2507 resource consumer to invoke ALTO (F3/F4), in order to solicit 2508 guidance regarding this list. 2510 Peer w. ALTO cli. Tracker ALTO Server 2511 --------+-------- --------+-------- --------+-------- 2512 | F1 Tracker query | | 2513 |======================>| | 2514 | F2 Tracker reply | | 2515 |<======================| | 2516 | F3 ALTO protocol query | 2517 |---------------------------------------------->| 2518 | F4 ALTO protocol reply | 2519 |<----------------------------------------------| 2520 | | | 2522 ==== Application protocol (i.e., tracker-based P2P app protocol) 2523 ---- ALTO protocol 2525 Figure 24: Basic message sequence chart for resource consumer- 2526 initiated ALTO query 2528 In the second scenario (see Figure 25), the resource directory has an 2529 embedded ALTO client, which we will refer to as Resource Directory 2530 ALTO Client (RDAC) in this document. After receiving a query for a 2531 given resource (F1) the resource directory invokes the RDAC to 2532 evaluate all resource providers it knows (F2/F3). Then it returns a, 2533 possibly shortened, list containing the "best" resource providers to 2534 the resource consumer (F4). 2536 Peer Tracker w. RDAC ALTO Server 2537 --------+-------- --------+-------- --------+-------- 2538 | F1 Tracker query | | 2539 |======================>| | 2540 | | F2 ALTO cli. p. query | 2541 | |---------------------->| 2542 | | F3 ALTO cli. p. reply | 2543 | |<----------------------| 2544 | F4 Tracker reply | | 2545 |<======================| | 2546 | | | 2548 ==== Application protocol (i.e., tracker-based P2P app protocol) 2549 ---- ALTO protocol 2551 Figure 25: Basic message sequence chart for third-party ALTO query 2553 Note: The message sequences depicted in Figure 24 and Figure 25 may 2554 occur both in the target-aware and the target-independent query mode 2555 (cf. [RFC6708]). In the target-independent query mode no message 2556 exchange with the ALTO server might be needed after the tracker 2557 query, because the candidate resource providers could be evaluated 2558 using a locally cached "map", which has been retrieved from the ALTO 2559 server some time ago. 2561 The first approach has the following problem: While the resource 2562 directory might know thousands of peers taking part in a swarm, the 2563 list returned to the resource consumer is usually shortened for 2564 efficiency reasons. Therefore, the "best" (in the sense of ALTO) 2565 potential resource providers might not be contained in that list 2566 anymore, even before ALTO can consider them. 2568 Much better traffic optimization could be achieved if the tracker 2569 would evaluate all known peers using ALTO. This list would then 2570 include a significantly higher fraction of "good" peers. If the 2571 tracker returned "good" peers only, there might be a risk that the 2572 swarm might disconnect and split into several disjunct partitions. 2573 However, finding the right mix of ALTO-biased and random peer 2574 selection is out of the scope of this document. 2576 Therefore, from an overall optimization perspective, the second 2577 scenario with the ALTO client embedded in the resource directory is 2578 advantageous, because it is ensured that the addresses of the "best" 2579 resource providers are actually delivered to the resource consumer. 2580 An architectural implication of this insight is that the ALTO server 2581 discovery procedures must support third-party discovery. That is, as 2582 the tracker issues ALTO queries on behalf of the peer which contacted 2583 the tracker, the tracker must be able to discover an ALTO server that 2584 can give guidance suitable for that respective peer (see 2585 [I-D.kiesel-alto-xdom-disc]). 2587 In principle, a combined approach could also be possible. For 2588 instance, a tracker could use a coarse-grained "global" ALTO server 2589 to find the peers in the general vicinity of the requesting peer, 2590 while peers could use "local" ALTO servers for a more fine-grained 2591 guidance. Yet, there is no known deployment experience for such a 2592 combined approach. 2594 5. Using ALTO for CDNs 2596 5.1. Overview 2598 5.1.1. Usage Scenario 2600 This section briefly introduces the usage of ALTO for Content 2601 Delivery Networks (CDNs), as explained in 2602 [I-D.jenkins-alto-cdn-use-cases]. CDNs are used in the delivery of 2603 some Internet services (e.g., delivery of websites, software updates 2604 and video delivery) from a location closer to the location of the 2605 user. A CDN typically consists of a network of servers often 2606 attached to Internet Service Provider (ISP) networks. The point of 2607 attachment is often as close to content consumers and peering points 2608 as economically or operationally feasible in order to decrease 2609 traffic load on the ISP backbone and to provide better user 2610 experience measured by reduced latency and higher throughput. 2612 CDNs use several techniques to redirect a client to a server 2613 (surrogate). A request routing function within a CDN is responsible 2614 for receiving content requests from user agents, obtaining and 2615 maintaining necessary information about a set of candidate 2616 surrogates, and for selecting and redirecting the user agent to the 2617 appropriate surrogate. One common way is relying on the DNS system, 2618 but there are many other ways, see [RFC3568]. 2620 +--------------------+ 2621 | CDN Request Router | 2622 | with ALTO Client | 2623 +--------------------+ 2624 /\ 2625 || ALTO protocol 2626 || 2627 \/ 2628 +---------+ 2629 | ALTO | 2630 | Server | 2631 +---------+ 2632 : 2633 : Provisioning protocol 2634 : 2635 ,-----------. 2636 ,-' Source of `-. 2637 ( topological ) 2638 `-. information ,-' 2639 `-----------' 2640 Figure 26: Use of ALTO information for CDN request routing 2642 In order to derive the optimal benefit from a CDN it is preferable to 2643 deliver content from the servers (caches) that are "closest" to the 2644 end user requesting the content. "closest" may be as simple as 2645 geographical or IP topology distance, but it may also consider other 2646 combinations of metrics and CDN or Internet Service Provider (ISP) 2647 policies. As illustrated in Figure 26, ALTO could provide this 2648 information. 2650 User Agent Request Router Surrogate 2651 | | | 2652 | F1 Initial Request | | 2653 +---------------------------->| | 2654 | +--+ | 2655 | | | F2 Surrogate Selection | 2656 | |<-+ (using ALTO) | 2657 | F3 Redirection Response | | 2658 |<----------------------------+ | 2659 | | | 2660 | F4 Content Request | | 2661 +-------------------------------------------------------->| 2662 | | | 2663 | | F5 Content | 2664 |<--------------------------------------------------------+ 2665 | | | 2667 Figure 27: Example of CDN surrogate selection 2669 Figure 27 illustrates the interaction between a user agent, a request 2670 router, and a surrogate for the delivery of content in a single CDN. 2671 As explained in [I-D.jenkins-alto-cdn-use-cases], the user agent 2672 makes an initial request to the CDN (F1). This may be an 2673 application-level request (e.g., HTTP) or a DNS request. In the 2674 second step (F2), the request router selects an appropriate surrogate 2675 (or set of surrogates) based on the user agent's (or its proxy's) IP 2676 address, the request router's knowledge of the network topology 2677 (which can be obtained by ALTO) and reachability cost between CDN 2678 caches and end users, and any additional CDN policies. Then (F3), 2679 the request router responds to the initial request with an 2680 appropriate response containing a redirection to the selected cache, 2681 for example by returning an appropriate DNS A/AAAA record, a HTTP 302 2682 redirect, etc. The user agent uses this information to connect 2683 directly to the surrogate and request the desired content (F4), which 2684 is then delivered (F5). 2686 5.1.2. Applicability of ALTO 2688 The most simple use case for ALTO in a CDN context is to improve the 2689 selection of a CDN surrogate or origin. In this case, the CDN makes 2690 use of an ALTO server to choose a better CDN surrogate or origin than 2691 would otherwise be the case. Although it is possible to obtain raw 2692 network map and cost information in other ways, for example passively 2693 listening to the ISP's routing protocols or use of active probing, 2694 the use of an ALTO service to expose that information may provide 2695 additional control to the ISP over how their network map/cost is 2696 exposed. Additionally it may enable the ISP to maintain a functional 2697 separation between their routing plane and network map computation 2698 functions. This may be attractive for a number of reasons, for 2699 example: 2701 o The ALTO service could provide a filtered view of the network 2702 and/or cost map that relates to CDN locations and their proximity 2703 to end users, for example to allow the ISP to control the level of 2704 topology detail they are willing to share with the CDN. 2706 o The ALTO service could apply additional policies to the network 2707 map and cost information to provide a CDN-specific view of the 2708 network map/cost, for example to allow the ISP to encourage the 2709 CDN to use network links that would not ordinarily be preferred by 2710 a Shortest Path First routing calculation. 2712 o The routing plane may be operated and controlled by a different 2713 operational entity (even within a single ISP) than the CDN. 2714 Therefore, the CDN may not be able to passively listen to routing 2715 protocols, nor may it have access to other network topology data 2716 (e.g., inventory databases). 2718 When CDN servers are deployed outside of an ISP's network or in a 2719 small number of central locations within an ISP's network, a 2720 simplified view of the ISP's topology or an approximation of 2721 proximity is typically sufficient to enable the CDN to serve end 2722 users from the optimal server/location. As CDN servers are deployed 2723 deeper within ISP networks it becomes necessary for the CDN to have 2724 more detailed knowledge of the underlying network topology and costs 2725 between network locations in order to enable the CDN to serve end 2726 users from the optimal servers for the ISP. 2728 The request router in a CDN will typically also take into account 2729 criteria and constraints that are not related to network topology, 2730 such as the current load of CDN surrogates, content owner policies, 2731 end user subscriptions, etc. This document only discusses use of 2732 ALTO for network information. 2734 A general issue for CDNs is that the CDN logic has to match the 2735 client's IP address with the closest CDN surrogate, both for DNS or 2736 HTTP redirect based approaches (see, for instance, 2737 [I-D.penno-alto-cdn]). This matching is not trivial, for instance, 2738 in DNS based approaches, where the IP address of the DNS original 2739 requester is unknown (see [I-D.ietf-dnsop-edns-client-subnet] for a 2740 discussion of this and a solution approach). 2742 In addition to use by a single CDN, ALTO can also be used in 2743 scenarios that interconnect several CDNs. This use case is detailed 2744 in [I-D.seedorf-cdni-request-routing-alto]. 2746 5.2. Deployment Recommendations 2748 5.2.1. ALTO Services 2750 In its simplest form an ALTO server would provide an ISP with the 2751 capability to offer a service to a CDN that provides network map and 2752 cost information. The CDN can use that data to enhance its surrogate 2753 and/or origin selection. If an ISP offers an ALTO network and cost 2754 map service to expose a cost mapping/ranking between end user IP 2755 subnets (within that ISP's network) and CDN surrogate IP subnets/ 2756 locations, periodic updates of the maps may be needed. As introduced 2757 in Section 3.3), it is common for broadband subscribers to obtain 2758 their IP addresses dynamically and in many deployments the IP subnets 2759 allocated to a particular network region can change relatively 2760 frequently, even if the network topology itself is reasonably static. 2762 An alternative would be to use the ALTO Endpoint Cost Service (ECS): 2763 When an end user requests a given content, the CDN request router 2764 issues an ECS request with the endpoint address (IPv4/IPv6) of the 2765 end user (content requester) and the set of endpoint addresses of the 2766 surrogate (content targets). The ALTO server receives the request 2767 and ranks the addresses based on their distance from the content 2768 requester. Once the request router obtained from the ALTO server the 2769 ranked list of locations (for the specific user), it can incorporate 2770 this information into its selection mechanisms in order to point the 2771 user to the most appropriate surrogate. 2773 Since CDNs operate in a controlled environment, the ALTO network/cost 2774 map service and ECS have a similar level of security and 2775 confidentiality of network-internal information. However, the 2776 network/cost map service and ECS differ in the way the ALTO service 2777 is delivered and address a different set of requirements in terms of 2778 topology information and network operations. 2780 If a CDN already has means to model connectivity policies, the map- 2781 based approaches could possibly be integrated into that. If the ECS 2782 service is preferred, a request router that uses ECS could cache the 2783 results of ECS queries for later usage in order to address the 2784 scalability limitations of ECS and to reduce the number of 2785 transactions between CDN and ALTO server. The ALTO server may 2786 indicate in the reply message how long the content of the message is 2787 to be considered reliable and insert a lifetime value that will be 2788 used by the CDN in order to cache (and then flush or refresh) the 2789 entry. 2791 5.2.2. Guidance Considerations 2793 In the following it is discussed how a CDN could make use of ALTO 2794 services. 2796 In one deployment scenario, ALTO could expose ISP end user 2797 reachability to a CDN. The request router needs to have information 2798 about which end user IP subnets are reachable via which networks or 2799 network locations. The network map services offered by ALTO could be 2800 used to expose this topology information while avoiding routing plane 2801 peering between the ISP and the CDN. For example, if CDN surrogates 2802 are deployed within the access or aggregation network, the ISP is 2803 likely to want to utilize the surrogates deployed in the same access/ 2804 aggregation region in preference to surrogates deployed elsewhere, in 2805 order to alleviate the cost and/or improve the user experience. 2807 In addition, CDN surrogates could also use ALTO guidance, e.g., if 2808 there is more than one upstream source of content or several origins. 2809 In this case, ALTO could help a surrogate with the decision about 2810 which upstream source to use. This specific variant of using ALTO is 2811 not further detailed in this document. 2813 If content can be provided by several CDNs, there may be a need to 2814 interconnect these CDNs. In this case, ALTO can be uses as an 2815 interface [I-D.seedorf-cdni-request-routing-alto], in particular for 2816 footprint and capabilities advertisement. 2818 Other and more advanced scenarios of deploying ALTO are also listed 2819 in [I-D.jenkins-alto-cdn-use-cases] and [I-D.penno-alto-cdn]. 2821 The granularity of ALTO information required depends on the specific 2822 deployment of the CDN. For example, an "over-the-top" CDN whose 2823 surrogates are deployed only within the Internet backbone may only 2824 require knowledge of which end user IP subnets are reachable via 2825 which ISPs' networks, whereas a CDN deployed within a particular 2826 ISP's network requires a finer granularity of knowledge. 2828 An ALTO server ranks addresses based on topology information it 2829 acquires from the network. By default, according to [RFC7285], 2830 distance in ALTO represents an abstract "routingcost" that can be 2831 computed for instance from routing protocol information. But an ALTO 2832 server may also take into consideration other criteria or other 2833 information sources for policy, state, and performance information 2834 (e.g., geo-location), as explained in Section 3.2.2. 2836 The different methods and algorithms through which the ALTO server 2837 computes topology information and rankings is out of the scope of 2838 this document. If rankings are based on routing protocol 2839 information, it is obvious that network events may impact the ranking 2840 computation. Due to internal redundancy and resilience mechanisms 2841 inside current networks, most of the network events happening in the 2842 infrastructure will be handled internally in the network, and they 2843 should have limited impact on a CDN. However, catastrophic events 2844 such as main trunks failures or backbone partitioning will have to be 2845 taken into account by the ALTO server to redirect traffic away from 2846 the impacted area. 2848 An ALTO server implementation may want to keep state about ALTO 2849 clients so to inform and signal to these clients when a major network 2850 event happened, e.g., by a notification mechanism. In a CDN/ALTO 2851 interworking architecture with few CDN components interacting with 2852 the ALTO server there are less scalability issues in maintaining 2853 state about clients in the ALTO server, compared to ALTO guidance to 2854 any Internet user. 2856 6. Other Use Cases 2858 This section briefly surveys and references other use cases that have 2859 been tested or suggested for ALTO deployments. 2861 6.1. Application Guidance in Virtual Private Networks (VPNs) 2863 Virtual Private Network (VPN) technology is widely used in public and 2864 private networks to create groups of users that are separated from 2865 other users of the network and allows these users to communicate 2866 among themselves as if they were on a private network. Network 2867 Service Providers (NSPs) offer different types of VPNs. [RFC4026] 2868 distinguishes between Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) 2869 using different sub-types. In the following, the term "VPN" is used 2870 to refer to provider supplied virtual private networking. 2872 From the perspective of an application at an endpoint, a VPN may not 2873 be very different to any other IP connectivity solution, but there 2874 are a number of specific applications that could benefit from ALTO 2875 topology exposure and guidance in VPNs. As in the general Internet, 2876 one advantage is that applications do not have to perform excessive 2877 measurements on their own. For instance, potential use cases for 2878 ALTO application guidance in VPN environments are: 2880 o Enterprise application optimization: Enterprise customers often 2881 run distributed applications that exchange large amounts of data, 2882 e.g., for synchronization of replicated data bases. Network 2883 topology information could be useful for placement of replicas as 2884 well as for the scheduling of transfers. 2886 o Private cloud computing solution: An enterprise customer could run 2887 its own data centers at the four sites. The cloud management 2888 system could want to understand the network costs between 2889 different sites for intelligent routing and placement decisions of 2890 Virtual Machines (VMs) among the VPN sites. 2892 o Cloud-bursting: One or more VPN endpoints could be located in a 2893 public cloud. If an enterprise customer needs additional 2894 resources, they could be provided by a public cloud, which is 2895 accessed through the VPN. Network topology awareness would help 2896 to decide in which data center of the public cloud those resources 2897 should be allocated. 2899 These examples focus on enterprises, which are typical users of VPNs. 2900 VPN customers typically have no insight into the network topology 2901 that transports the VPN. Similar to other ALTO use cases, better- 2902 than-random application-level decisions would be enabled by an ALTO 2903 server offered by the NSP, as illustrated in Figure 28. 2905 +---------------+ 2906 | Customer's | 2907 | management | 2908 | application |. 2909 | (ALTO client) | . 2910 +---------------+ . VPN provisioning 2911 /\ . (out-of-scope) 2912 || ALTO . 2913 \/ . 2914 +---------------------+ +----------------+ 2915 | ALTO server | | VPN portal/OSS | 2916 | provided by NSP | | (out-of-scope) | 2917 +---------------------+ +----------------+ 2918 : VPN network 2919 : and cost maps 2920 : 2921 /---------:---------\ Network service provider 2922 | : | 2923 +-------+ _______________________ +-------+ 2924 | App a | ()_____. .________. .____() | App d | 2925 +-------+ | | | | | | +-------+ 2926 \---| |--------| |--/ 2927 | | | | 2928 |^| |^| Customer VPN 2929 V V 2930 +-------+ +-------+ 2931 | App b | | App c | 2932 +-------+ +-------+ 2934 Figure 28: Using ALTO in VPNs 2936 A common characteristic of these use cases is that applications will 2937 not necessarily run in the public Internet, and that the relationship 2938 between the provider and customer of the VPN is rather well-defined. 2939 Since VPNs often run in a managed environment, an ALTO server may 2940 have access to topology information (e.g., traffic engineering data) 2941 that would not be available for the public Internet, and it may 2942 expose it to the customer of the VPN only. 2944 Also, a VPN will not necessarily be static. The customer could 2945 possibly modify the VPN and add new VPN sites by a Web portal, 2946 network management systems, or other Operation Support Systems (OSS) 2947 solutions. Prior to adding a new VPN site, an application will not 2948 have connectivity to that site, i.e., an ALTO server could offer 2949 access to information that an application cannot measure on its own 2950 (e.g., expected delay to a new VPN site). 2952 The VPN use cases, requirements, and solutions are further detailed 2953 in [I-D.scharf-alto-vpn-service]. 2955 6.2. In-Network Caching 2957 Deployment of intra-domain P2P caches has been proposed for 2958 cooperation between the network operator and the P2P service 2959 providers, e.g., to reduce the bandwidth consumption in access 2960 networks [I-D.deng-alto-p2pcache]. 2962 +--------------+ +------+ 2963 | ISP 1 network+----------------+Peer 1| 2964 +-----+--------+ +------+ 2965 | 2966 +--------+------------------------------------------------------+ 2967 | | ISP 2 network | 2968 | +---------+ | 2969 | |L1 Cache | | 2970 | +-----+---+ | 2971 | +--------------------+----------------------+ | 2972 | | | | | 2973 | +------+------+ +------+-------+ +------+-------+ | 2974 | | AN1 | | AN2 | | AN3 | | 2975 | | +---------+ | | +----------+ | | | | 2976 | | |L2 Cache | | | |L2 Cache | | | | | 2977 | | +---------+ | | +----------+ | | | | 2978 | +------+------+ +------+-------+ +------+-------+ | 2979 | | | | 2980 | +--------------------+ | | 2981 | | | | | 2982 | +------+------+ +------+-------+ +------+-------+ | 2983 | | SUB-AN11 | | SUB-AN12 | | SUB-AN31 | | 2984 | | +---------+ | | | | | | 2985 | | |L3 Cache | | | | | | | 2986 | | +---------+ | | | | | | 2987 | +------+------+ +------+-------+ +------+-------+ | 2988 | | | | | 2989 +--------+--------------------+----------------------+----------+ 2990 | | | 2991 +---+---+ +---+---+ | 2992 | | | | | 2993 +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ 2994 |Peer2| |Peer3| |Peer4| |Peer5| |Peer6| 2995 +-----+ +-----+ +-----+ +-----+ +-----+ 2997 Figure 29: General architecture of intra-ISP caches 2999 Figure 29 depicts the overall architecture of potential P2P cache 3000 deployments inside an ISP 2 with various access network types. As 3001 shown in the figure, P2P caches may be deployed at various levels, 3002 including the interworking gateway linking with other ISPs, internal 3003 access network gateways linking with different types of accessing 3004 networks (e.g. WLAN, cellular and wired), and even within an 3005 accessing network at the entries of individual WLAN sub-networks. 3006 Moreover, depending on the network context and the operator's policy, 3007 each cache can be a Forwarding Cache or a Bidirectional Cache 3008 [I-D.deng-alto-p2pcache]. 3010 In such a cache architecture, the locations of caches could be used 3011 as dividers of different PIDs to guide intra-ISP network abstraction 3012 and mark costs among them according to the location and type of 3013 relevant caches. 3015 Further details and deployment considerations can be found in 3016 [I-D.deng-alto-p2pcache]. 3018 6.3. Other Application-based Network Operations 3020 An ALTO server can be part of an overall framework for Application- 3021 Based Network Operations (ABNO) [RFC7491] that brings together 3022 different technologies for gathering information about the resources 3023 available in a network, for consideration of topologies and how those 3024 topologies map to underlying network resources, for requesting path 3025 computation, and for provisioning or reserving network resources. 3026 Such an architecture may include additional components such as a Path 3027 Computation Element (PCE) for on-demand and application-specific 3028 reservation of network connectivity, reliability, and resources (such 3029 as bandwidth). Some use cases how to leverage ALTO for joint network 3030 and application-layer optimization are explained in [RFC7491]. 3032 7. Security Considerations 3034 Security concerns were extensively discussed from the very beginning 3035 of the development of the ALTO protocol, and they have been 3036 considered in detail in the ALTO requirements document [RFC6708] as 3037 well as in the ALTO protocol specification document [RFC7285]. The 3038 two main security concerns are related to the unwanted disclosure of 3039 information through ALTO and the negative impact of specially 3040 crafted, wrong ("faked") guidance presented to an ALTO client. In 3041 addition to this, the usual concerns related to the operation of any 3042 networked application apply. 3044 This section focuses on the peer-to-peer use case, which is - from a 3045 security perspective - probably the most difficult ALTO use case that 3046 has been considered. Special attention is given to the two main 3047 security concerns. 3049 7.1. ALTO as a Protocol Crossing Trust Boundaries 3051 The optimization of peer-to-peer applications was the first use case 3052 and the impetus for the development of the ALTO protocol, in 3053 particular file sharing applications such as BitTorrent [RFC5594]. 3055 As explained in Section 4.1.1, for the publisher of the ALTO 3056 information (i.e., the ALTO server operator) it may not be apparent 3057 who is in charge of the P2P application overlay. Some P2P 3058 applications do not have any central control entity and the whole 3059 overlay consists only of the peers, which are under control of the 3060 individual users. Other P2P applications may have some control 3061 entities such as super peers or trackers, but these may be located in 3062 foreign countries and under the control of unknown organizations. As 3063 outlined in Section 4.2.2, in some scenarios it may be very 3064 beneficial to forward ALTO information to such trackers, super peers, 3065 etc. located in remote networks. This situation is aggravated by the 3066 vast number of different P2P applications which are evolving quickly 3067 and often without any coordination with the network operators. 3069 In summary it can be said that in many instances of the P2P use case, 3070 the ALTO protocol bridges the border between the "managed" IP network 3071 infrastructure under strict administrative control and one or more 3072 "unmanaged" application overlays, i.e., overlays for which it is hard 3073 to tell who is in charge of them. This differs from more controlled 3074 environments (e.g., in the CDN use case), in which bilateral 3075 agreements between the producer and consumer of guidance are 3076 possible. 3078 7.2. Information Leakage from the ALTO Server 3080 An ALTO server will be provisioned with information about the ISP's 3081 network and possibly also with information about neighboring ISPs. 3082 This information (e.g., network topology, business relations, etc.) 3083 is often considered to be confidential to the ISP and can include 3084 very sensitive information. ALTO does not require any particular 3085 level of details of information disclosure, and hence the provider 3086 should evaluate how much information is revealed and the associated 3087 risks. 3089 Furthermore, if the ALTO information is very fine grained, it may 3090 also be considered sensitive with respect to user privacy. For 3091 example, consider a hypothetical endpoint property "provisioned 3092 access link bandwidth" or "access technology (ADSL, VDSL, FTTH, 3093 etc.)" and an ALTO service that publishes this property for 3094 individual IP addresses. This information could not only be used for 3095 traffic optimization but, for example, also for targeted advertising 3096 to residential users with exceptionally good (or bad) connectivity, 3097 such as special banner ads. For an advertisement system it would be 3098 more complex to obtain such information otherwise, e.g., by bandwidth 3099 probing. 3101 Different scenarios related to the unwanted disclosure of an ALTO 3102 server's information have been itemized and categorized in RFC 6708, 3103 Section 5.2.1., cases (1)-(3) [RFC6708]. 3105 In some use cases it is not possible to use access control (see 3106 Section 7.3) to limit the distribution of ALTO knowledge to a small 3107 set of trusted clients. In these scenarios it seems tempting not to 3108 use network maps and cost maps at all, and instead completely rely on 3109 endpoint cost service and endpoint ranking in the ALTO server. While 3110 this practice may indeed reduce the amount of information that is 3111 disclosed to an individual ALTO client, some issues should be 3112 considered: First, when using the map based approach, it is trivial 3113 to analyze the maximum amount of information that could be disclosed 3114 to a client: the full maps. In contrast, when providing endpoint 3115 cost service only, the ALTO server operator could be prone to a false 3116 feeling of security, while clients use repeated queries and/or 3117 collaboration to gather more information than they are expected to 3118 get (see Section 5.2.1., case (3) in [RFC6708]). Second, the 3119 endpoint cost service reveals more information about the user or 3120 application behavior to the ALTO server, e.g., which other hosts are 3121 considered as peers for the exchange of a significant amount of data 3122 (see Section 5.2.1., cases (4)-(6) in [RFC6708]). 3124 Consequently, users may be more reluctant to use the ALTO service at 3125 all if it is based on the endpoint cost service instead of providing 3126 network and cost maps. Given that some popular P2P applications are 3127 sometimes used for purposes such as distribution of files without the 3128 explicit permission from the copyright owner, it may also be in the 3129 interest of the ALTO server operator that an ALTO server cannot infer 3130 the behavior of the application to be optimized. One possible 3131 conclusion could be to publish network and cost maps through ALTO 3132 that are so coarse-grained that they do not violate the network 3133 operator's or the user's interests. 3135 In other use cases in more controlled environments (e.g., in the CDN 3136 use case) bilateral agreements, access control (see Section 7.3), and 3137 encryption could be used to reduce the risk of information leakage. 3139 7.3. ALTO Server Access 3141 Depending on the use case of ALTO, it may be desired to apply access 3142 restrictions to an ALTO server, i.e., by requiring client 3143 authentication. According to [RFC7285], ALTO requires that HTTP 3144 Digest Authentication is supported, in order to achieve client 3145 authentication and possibly to limit the number of parties with whom 3146 ALTO information is directly shared. TLS Client Authentication may 3147 also be supported. 3149 In general, well-known security management techniques and best 3150 current practices [RFC4778] for operational ISP infrastructure also 3151 apply to an ALTO service, including functions to protect the system 3152 from unauthorized access, key management, reporting security-relevant 3153 events, and authorizing user access and privileges. 3155 For peer-to-peer applications, a potential deployment scenario is 3156 that an ALTO server is solely accessible by peers from the ISP 3157 network (as shown in Figure 21). For instance, the source IP address 3158 can be used to grant only access from that ISP network to the server. 3159 This will "limit" the number of peers able to attack the server to 3160 the user's of the ISP (however, including compromised computers that 3161 are part of a botnet). 3163 If the ALTO server has to be accessible by parties not located in the 3164 ISP's network (see Figure 22), e.g., by a third-party tracker or by a 3165 CDN system outside the ISP's network, the access restrictions have to 3166 be looser. In the extreme case, i.e., no access restrictions, each 3167 and every host in the Internet can access the ALTO server. This 3168 might no be the intention of the ISP, as the server is not only 3169 subject to more possible attacks, but also the server load could 3170 increase, since possibly more ALTO clients have to be served. 3172 There are also use cases where the access to the ALTO server has to 3173 be much more strictly controlled, i. e., where an authentication and 3174 authorization of the ALTO client to the server may be needed. For 3175 instance, in case of CDN optimization the provider of an ALTO service 3176 as well as potential users are possibly well-known. Only CDN 3177 entities may need ALTO access; access to the ALTO servers by 3178 residential users may neither be necessary nor be desired. 3180 Access control can also help to prevent Denial-of-Service attacks by 3181 arbitrary hosts from the Internet. Denial-of-Service (DoS) can both 3182 affect an ALTO server and an ALTO client. A server can get 3183 overloaded if too many requests hit the server, or if the query load 3184 of the server surpasses the maximum computing capacity. An ALTO 3185 client can get overloaded if the responses from the sever are, either 3186 intentionally or due to an implementation mistake, too large to be 3187 handled by that particular client. 3189 7.4. Faking ALTO Guidance 3191 The ALTO services enables an ALTO service provider to influence the 3192 behavior of network applications. An attacker who is able to 3193 generate false replies, or e.g. an attacker who can intercept the 3194 ALTO server discovery procedure, can provide faked ALTO guidance. 3196 Here is a list of examples how the ALTO guidance could be faked and 3197 what possible consequences may arise: 3199 Sorting: An attacker could change the sorting order of the ALTO 3200 guidance (given that the order is of importance, otherwise the 3201 ranking mechanism is of interest), i.e., declaring peers located 3202 outside the ISP as peers to be preferred. This will not pose a 3203 big risk to the network or peers, as it would mimic the "regular" 3204 peer operation without traffic localization, apart from the 3205 communication/processing overhead for ALTO. However, it could 3206 mean that ALTO is reaching the opposite goal of shuffling more 3207 data across ISP boundaries, incurring more costs for the ISP. In 3208 another example, fake guidance could give unrealistically low 3209 costs to devices in an ISP's mobile network, thus encouraging 3210 other devices to contact them, thereby degrading the ISP's mobile 3211 network and causing customer dissatisfaction. 3213 Preference of a single peer: A single IP address (thus a peer) could 3214 be marked as to be preferred all over other peers. This peer can 3215 be located within the local ISP or also in other parts of the 3216 Internet (e.g., a web server). This could lead to the case that 3217 quite a number of peers to trying to contact this IP address, 3218 possibly causing a Denial-of-Service (DoS) attack. 3220 The ALTO protocol protects the authenticity and integrity of ALTO 3221 information while in transit by leveraging the authenticity and 3222 integrity protection mechanisms in TLS (see Section 8.3.5 of 3223 [RFC7285]). It has not yet been investigated how wrong ALTO guidance 3224 given by an autheticated ALTO server can impact the operation of the 3225 network and the applications. 3227 8. IANA Considerations 3229 This document makes no specific request to IANA. 3231 9. Acknowledgments 3233 This memo is the result of contributions made by several people: 3235 o Xianghue Sun, Lee Kai, and Richard Yang contributed text on ISP 3236 deployment requirements and monitoring. 3238 o Stefano Previdi contributed parts of the Section 5 on "Using ALTO 3239 for CDNs". 3241 o Rich Woundy contributed text to Section 3.3. 3243 o Lingli Deng, Wei Chen, Qiuchao Yi, and Yan Zhang contributed 3244 Section 6.2. 3246 Thomas-Rolf Banniza, Vinayak Hegde, Qin Wu, Wendy Roome, and Sabine 3247 Randriamasy provided very useful comments and reviewed the document. 3249 10. References 3251 10.1. Normative References 3253 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 3254 Optimization (ALTO) Problem Statement", RFC 5693, 3255 October 2009. 3257 [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 3258 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 3259 Requirements", RFC 6708, September 2012. 3261 [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 3262 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 3263 Traffic Optimization (ALTO) Protocol", RFC 7285, 3264 September 2014. 3266 [RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 3267 H. Song, "Application-Layer Traffic Optimization (ALTO) 3268 Server Discovery", RFC 7286, November 2014. 3270 10.2. Informative References 3272 [I-D.deng-alto-p2pcache] 3273 Lingli, D., Chen, W., Yi, Q., and Y. Zhang, 3274 "Considerations for ALTO with network-deployed P2P 3275 caches", draft-deng-alto-p2pcache-03 (work in progress), 3276 February 2014. 3278 [I-D.ietf-alto-incr-update-sse] 3279 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 3280 Server-Sent Events (SSE)", 3281 draft-ietf-alto-incr-update-sse-02 (work in progress), 3282 April 2016. 3284 [I-D.ietf-dnsop-edns-client-subnet] 3285 Contavalli, C., Gaast, W., tale, t., and W. Kumari, 3286 "Client Subnet in DNS Queries", 3287 draft-ietf-dnsop-edns-client-subnet-07 (work in progress), 3288 March 2016. 3290 [I-D.ietf-i2rs-architecture] 3291 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 3292 Nadeau, "An Architecture for the Interface to the Routing 3293 System", draft-ietf-i2rs-architecture-13 (work in 3294 progress), February 2016. 3296 [I-D.ietf-i2rs-yang-network-topo] 3297 Clemm, A., Medved, J., Varga, R., Tkacik, T., Bahadur, N., 3298 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 3299 Topologies", draft-ietf-i2rs-yang-network-topo-04 (work in 3300 progress), July 2016. 3302 [I-D.jenkins-alto-cdn-use-cases] 3303 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 3304 S. Previdi, "Use Cases for ALTO within CDNs", 3305 draft-jenkins-alto-cdn-use-cases-03 (work in progress), 3306 June 2012. 3308 [I-D.kiesel-alto-h12] 3309 Kiesel, S. and M. Stiemerling, "ALTO H12", 3310 draft-kiesel-alto-h12-02 (work in progress), March 2010. 3312 [I-D.kiesel-alto-xdom-disc] 3313 Kiesel, S. and M. Stiemerling, "Application Layer Traffic 3314 Optimization (ALTO) Cross-Domain Server Discovery", 3315 draft-kiesel-alto-xdom-disc-01 (work in progress), 3316 July 2015. 3318 [I-D.lee-alto-chinatelecom-trial] 3319 Li, K. and G. Jian, "ALTO and DECADE service trial within 3320 China Telecom", draft-lee-alto-chinatelecom-trial-04 (work 3321 in progress), March 2012. 3323 [I-D.penno-alto-cdn] 3324 Penno, R., Medved, J., Alimi, R., Yang, R., and S. 3325 Previdi, "ALTO and Content Delivery Networks", 3326 draft-penno-alto-cdn-03 (work in progress), March 2011. 3328 [I-D.scharf-alto-vpn-service] 3329 Scharf, M., Gurbani, V., Soprovich, G., and V. Hilt, "The 3330 Virtual Private Network (VPN) Service in ALTO: Use Cases, 3331 Requirements and Extensions", 3332 draft-scharf-alto-vpn-service-02 (work in progress), 3333 February 2014. 3335 [I-D.seedorf-cdni-request-routing-alto] 3336 Seedorf, J., Yang, Y., and J. Peterson, "CDNI Footprint 3337 and Capabilities Advertisement using ALTO", 3338 draft-seedorf-cdni-request-routing-alto-08 (work in 3339 progress), March 2015. 3341 [I-D.seidel-alto-map-calculation] 3342 Seidel, H., "ALTO map calculation from live network data", 3343 draft-seidel-alto-map-calculation-00 (work in progress), 3344 October 2015. 3346 [I-D.wu-alto-te-metrics] 3347 Wu, Q., Yang, Y., Lee, Y., Dhody, D., and S. Randriamasy, 3348 "ALTO Traffic Engineering Cost Metrics", 3349 draft-wu-alto-te-metrics-07 (work in progress), 3350 March 2016. 3352 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 3353 Architecture for Describing Simple Network Management 3354 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 3355 December 2002. 3357 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 3358 Content Network (CN) Request-Routing Mechanisms", 3359 RFC 3568, July 2003. 3361 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 3362 Private Network (VPN) Terminology", RFC 4026, March 2005. 3364 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 3365 Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/ 3366 RFC4655, August 2006, 3367 . 3369 [RFC4778] Kaeo, M., "Operational Security Current Practices in 3370 Internet Service Provider Environments", RFC 4778, 3371 January 2007. 3373 [RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop 3374 on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", 3375 RFC 5594, July 2009. 3377 [RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and 3378 Y. Yang, "Comcast's ISP Experiences in a Proactive Network 3379 Provider Participation for P2P (P4P) Technical Trial", 3380 RFC 5632, September 2009. 3382 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 3383 Network Configuration Protocol (NETCONF)", RFC 6020, 3384 October 2010. 3386 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 3387 Bierman, "Network Configuration Protocol (NETCONF)", 3388 RFC 6241, June 2011. 3390 [RFC6875] Kamei, S., Momose, T., Inoue, T., and T. Nishitani, "The 3391 P2P Network Experiment Council's Activities and 3392 Experiments with Application-Layer Traffic Optimization 3393 (ALTO) in Japan", RFC 6875, DOI 10.17487/RFC6875, 3394 February 2013, . 3396 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 3397 Application-Based Network Operations", RFC 7491, 3398 DOI 10.17487/RFC7491, March 2015, 3399 . 3401 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 3402 S. Ray, "North-Bound Distribution of Link-State and 3403 Traffic Engineering (TE) Information Using BGP", RFC 7752, 3404 DOI 10.17487/RFC7752, March 2016, 3405 . 3407 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 3408 the Routing System (I2RS) Traceability: Framework and 3409 Information Model", RFC 7922, DOI 10.17487/RFC7922, 3410 June 2016, . 3412 Authors' Addresses 3414 Martin Stiemerling 3415 Hochschule Darmstadt 3417 Email: mls.ietf@gmail.com 3418 URI: http://ietf.stiemerling.org 3420 Sebastian Kiesel 3421 University of Stuttgart Information Center 3422 Networks and Communication Systems Department 3423 Allmandring 30 3424 Stuttgart 70550 3425 Germany 3427 Email: ietf-alto@skiesel.de 3429 Michael Scharf 3430 Nokia 3431 Lorenzstrasse 10 3432 Stuttgart 70435 3433 Germany 3435 Email: michael.scharf@nokia.com 3437 Hans Seidel 3438 BENOCS GmbH 3440 Email: hseidel@benocs.com 3442 Stefano Previdi 3443 Cisco Systems, Inc. 3444 Via Del Serafico 200 3445 Rome 00191 3446 Italy 3448 Email: sprevidi@cisco.com