idnits 2.17.1 draft-ietf-alto-protocol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 16, 2009) is 5216 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'ATTP' on line 182 ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '2') ** Obsolete normative reference: RFC 2616 (ref. '3') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-02) exists of draft-kiesel-alto-reqs-01 == Outdated reference: A later version (-03) exists of draft-song-alto-server-discovery-00 == Outdated reference: A later version (-03) exists of draft-gu-alto-redistribution-01 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG R. Alimi, Ed. 3 Internet-Draft Yale University 4 Intended status: Standards Track R. Penno, Ed. 5 Expires: June 19, 2010 Juniper Networks 6 Y. Yang, Ed. 7 Yale University 8 December 16, 2009 10 ALTO Protocol 11 draft-ietf-alto-protocol-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 19, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 Networking applications today already have access to a great amount 50 of Inter-Provider network topology information. For example, views 51 of the Internet routing table are easily available at looking glass 52 servers and entirely practical to be downloaded by clients. What is 53 missing is knowledge of the underlying network topology from the ISP 54 or Content Provider (henceforth referred as Provider) point of view. 55 In other words, what an Provider prefers in terms of traffic 56 optimization -- and a way to distribute it. 58 The ALTO Service provides information such as preferences of network 59 resources with the goal of modifying network resource consumption 60 patterns while maintaining or improving application performance. 61 This document describes a protocol implementing the ALTO Service. 62 While such service would primarily be provided by the network (i.e., 63 the ISP), content providers and third parties could also operate this 64 service. Applications that could use this service are those that 65 have a choice in connection endpoints. Examples of such applications 66 are peer-to-peer (P2P) and content delivery networks. 68 Requirements Language 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC 2119 [1]. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 1.1. Background and Problem Statement . . . . . . . . . . . . . 5 78 1.2. Design History and Merged Proposals . . . . . . . . . . . 5 79 1.3. Solution Benefits . . . . . . . . . . . . . . . . . . . . 5 80 1.3.1. Service Providers . . . . . . . . . . . . . . . . . . 5 81 1.3.2. Applications . . . . . . . . . . . . . . . . . . . . . 6 82 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 83 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 84 2.1.1. Endpoint Address . . . . . . . . . . . . . . . . . . . 6 85 2.1.2. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 2.1.3. Network Location . . . . . . . . . . . . . . . . . . . 7 87 2.2. ALTO Service and Protocol Scope . . . . . . . . . . . . . 7 88 3. Protocol Structure . . . . . . . . . . . . . . . . . . . . . . 8 89 3.1. Server Capability . . . . . . . . . . . . . . . . . . . . 9 90 3.2. Services . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 3.2.1. Map Service . . . . . . . . . . . . . . . . . . . . . 9 92 3.2.2. Map Filtering Service . . . . . . . . . . . . . . . . 10 93 3.2.3. Endpoint Property Service . . . . . . . . . . . . . . 10 94 3.2.4. Ranking Service . . . . . . . . . . . . . . . . . . . 10 95 4. Network Map . . . . . . . . . . . . . . . . . . . . . . . . . 10 96 4.1. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 97 4.2. Example Network Map . . . . . . . . . . . . . . . . . . . 11 98 5. Cost Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 99 5.1. Cost Attributes . . . . . . . . . . . . . . . . . . . . . 12 100 5.1.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . 12 101 5.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 12 102 5.2. Cost Map Structure . . . . . . . . . . . . . . . . . . . . 13 103 5.3. Network Map and Cost Map Dependency . . . . . . . . . . . 13 104 6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14 105 6.1. Design Approach . . . . . . . . . . . . . . . . . . . . . 14 106 6.1.1. Use of Existing Infrastructure . . . . . . . . . . . . 14 107 6.1.2. ALTO Information Reuse and Redistribution . . . . . . 14 108 6.2. Message Format . . . . . . . . . . . . . . . . . . . . . . 15 109 6.2.1. Query Message . . . . . . . . . . . . . . . . . . . . 15 110 6.2.2. Response Message . . . . . . . . . . . . . . . . . . . 15 111 6.2.3. Query and Response Body Encoding . . . . . . . . . . . 16 112 7. Protocol Messaging . . . . . . . . . . . . . . . . . . . . . . 16 113 7.1. Client Processing . . . . . . . . . . . . . . . . . . . . 16 114 7.1.1. General Processing . . . . . . . . . . . . . . . . . . 16 115 7.1.2. General Error Conditions . . . . . . . . . . . . . . . 17 116 7.2. Server Processing . . . . . . . . . . . . . . . . . . . . 17 117 7.2.1. Successful Responses . . . . . . . . . . . . . . . . . 17 118 7.2.2. General Error Conditions . . . . . . . . . . . . . . . 17 119 7.2.3. Caching Parameters . . . . . . . . . . . . . . . . . . 17 120 7.3. ALTO Queries . . . . . . . . . . . . . . . . . . . . . . . 18 121 7.3.1. Server Capability . . . . . . . . . . . . . . . . . . 18 122 7.3.2. Map Service . . . . . . . . . . . . . . . . . . . . . 18 123 7.3.3. Map Filtering Service . . . . . . . . . . . . . . . . 19 124 7.3.4. Endpoint Property Service . . . . . . . . . . . . . . 21 125 7.3.5. Ranking Service . . . . . . . . . . . . . . . . . . . 22 126 8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 23 127 8.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 23 128 8.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 25 129 8.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 26 130 9. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 27 131 9.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 27 132 9.2. Network Address Translation Considerations . . . . . . . . 27 133 9.3. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . 28 134 9.4. Endpoint and Path Properties . . . . . . . . . . . . . . . 28 135 9.5. P2P Peer Selection . . . . . . . . . . . . . . . . . . . . 28 136 9.5.1. Client-based Peer Selection . . . . . . . . . . . . . 29 137 9.5.2. Server-based Peer Selection . . . . . . . . . . . . . 29 138 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 139 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 140 11.1. ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 141 11.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 29 142 11.3. ALTO Information . . . . . . . . . . . . . . . . . . . . . 30 143 11.4. ALTO Information Redistribution . . . . . . . . . . . . . 30 144 11.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 31 145 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 146 12.1. Normative References . . . . . . . . . . . . . . . . . . . 31 147 12.2. Informative References . . . . . . . . . . . . . . . . . . 31 148 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 33 149 Appendix B. Authors . . . . . . . . . . . . . . . . . . . . . . . 33 150 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 152 1. Introduction 154 1.1. Background and Problem Statement 156 Today, network information available to applications is mostly from 157 the view of endhosts. There is no clear mechanism to convey 158 information about the network's preferences to applications. By 159 leveraging better network-provided information, applications have 160 potential to become more network-efficient (e.g., reduce network 161 resource consumption) and achieve better application performance 162 (e.g., accelerated download rate). The ALTO Service intends to 163 provide a simple way to convey network information to applications. 165 The goal of this document is to specify a simple and unified protocol 166 that meets the ALTO requirements [5] while providing a migration path 167 for Internet Service Providers (ISP), Content Providers, and clients 168 that have deployed protocols with similar intentions (see below). 169 This document is a work in progress and will be updated with further 170 developments. 172 1.2. Design History and Merged Proposals 174 The protocol specified here consists of contributions from 176 o P4P [6], [7]; 178 o ALTO Info-Export [8]; 180 o Query/Response [9], [10]; 182 o ATTP [ATTP]. 184 o Proxidor [19]. 186 See Appendix A for a list of people that have contributed 187 significantly to this effort and the projects and proposals listed 188 above. 190 1.3. Solution Benefits 192 The ALTO Service offers many benefits to both end-users (consumers of 193 the service) and Internet Service Providers (providers of the 194 service). 196 1.3.1. Service Providers 198 The ALTO Service enables ISPs to influence the peer selection process 199 in distributed applications in order to increase locality of traffic, 200 improve user-experience, amongst others. It also helps ISPs to 201 efficiently engineer traffic that traverses more expensive links such 202 as backbone and transit links, thus allowing a better provisioning of 203 the networking infrastructure. 205 1.3.2. Applications 207 Applications that use the ALTO Service can benefit in multiple ways. 208 For example, they may no longer need to infer topology information, 209 and some applications can reduce reliance on measuring path 210 performance metrics themselves. They can take advantage of the ISP's 211 knowledge to avoid bottlenecks and boost performance. 213 An example type of application is a Peer-to-Peer overlay where peer 214 selection can be improved by including ALTO information in the 215 selection process. 217 2. Architecture 219 Two key design objectives of the ALTO Protocol are simplicity and 220 extensibility. At the same time, it introduces additional techniques 221 to address potential scalability and privacy issues. Below we start 222 with an introduction to the terminology. Then we define the overall 223 architecture and how the ALTO Protocol fits into the architecture. 225 2.1. Terminology 227 We use the following terms defined in [11]: Application, Overlay 228 Network, Peer, Resource, Resource Identifier, Resource Provider, 229 Resource Consumer, Resource Directory, Transport Address, Host 230 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 231 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 232 Transit Traffic. 234 We also use the following additional terms: Endpoint Address, ASN, 235 and Network Location. 237 2.1.1. Endpoint Address 239 An endpoint address represents the communication address of an end 240 point. An endpoint address can be network-attachment based (IP 241 address) or network-attachment agnostic. Common forms of endpoint 242 addresses include IP address, MAC address, overlay ID, and phone 243 number. 245 2.1.2. ASN 247 An Autonomous System Number. 249 2.1.3. Network Location 251 Network Location is a generic concept denoting a single endpoint or 252 group of endpoints. Whenever we say Network Location, we refer to 253 either a single endpoint or a group of endpoints. 255 2.2. ALTO Service and Protocol Scope 257 An ALTO Server conveys the network information from the perspective 258 of a network region. We say that the ALTO Server presents its "my- 259 Internet View" [12] of the network region. A network region in this 260 context can be an Autonomous System, an ISP, perhaps a smaller 261 region, or perhaps a set of ISPs; the details depend on the 262 deployment scenario and discovery mechanism. 264 To better understand the ALTO Service and the role of the ALTO 265 Protocol, we show in Figure 1 the overall system architecture. In 266 this architecture, an ALTO Server prepares ALTO Information; an ALTO 267 Client uses ALTO Service Discovery to identify an appropriate ALTO 268 Server; and the ALTO Client requests available ALTO Information from 269 the ALTO Server using the ALTO Protocol. 271 The ALTO Information provided by the ALTO Server can be updated 272 dynamically based on network conditions, or can be seen as a policy 273 which is updated at a larger time-scale. 275 More specifically, the ALTO Information provided by an ALTO Server 276 may be influenced (at the operator's discretion) by other systems. 277 Examples include (but are not limited to) static network 278 configuration databases, dynamic network information, routing 279 protocols, provisioning policies, and interfaces to outside parties. 280 These components are shown in the figure for completeness but outside 281 the scope of this specification. 283 +-------------------------------------------------------------------+ 284 | ISP | 285 | | 286 | +-----------+ | 287 | | Routing | | 288 | +--------------+ | Protocols | | 289 | | Provisioning | +-----------+ | 290 | | Policy | | | 291 | +--------------+\ | | 292 | \ | | 293 | \ | | 294 | +-----------+ \+---------+ +--------+ | 295 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 296 | |Network |.......| Server | -------------------- | Client | | 297 | |Information| +---------+ +--------+ | 298 | +-----------+ / / | 299 | / ALTO SD Query/Response / | 300 | / / | 301 | +----------+ +--------------+ | 302 | | External | | ALTO Service | | 303 | | Interface| | Discovery | | 304 | +----------+ +--------------+ | 305 | | | 306 | | Figure 1: Basic ALTO Architecture. | 307 | | | 308 +-------------------------------------------------------------------+ 309 | 310 +------------------+ 311 | Third Parties | 312 | | 313 | Content Providers| 314 +------------------+ 316 ALTO Architecture 318 3. Protocol Structure 320 The ALTO Protocol uses a simple extensible framework to convey 321 network information. In the general framework, the ALTO protocol 322 will convey properties on both Endpoints and paths between network 323 locations. 325 In this document, we focus on a particular endpoint property to 326 denote the location of an endpoint, and provider-defined costs for 327 paths between pairs of network locations. 329 The ALTO Protocol is built on a common transport protocol, messaging 330 structure and encoding, and transaction model. The protocol is 331 subdivided into services of related functionality. ALTO-Core 332 provides the Map Service. Other services can provide additional 333 functionality. There are three such services defined in this 334 document: the Map Filtering Service, Endpoint Property Service, and 335 Ranking Service. Additional services may be defined in the future in 336 companion documents. 338 .-------------------------------------------------------------------. 339 | | 340 | .----------. .---------------. .---------------. .-------------. | 341 | | | | Map Filtering | | Endpont Prop. | | Ranking | | 342 | | | | Service | | Service | | Service | | 343 | | | `---------------' `---------------' `-------------' | 344 | | Server | .-------------------------------------------------. | 345 | |Capability| | Map Service | | 346 | | | | .-------------. .--------------. | | 347 | | | | | Network Map | | Cost Map | | | 348 | | | | `-------------' `--------------' | | 349 | `----------' `-------------------------------------------------' | 350 | | 351 `-------------------------------------------------------------------' 353 Figure 1: ALTO Protocol Structure 355 3.1. Server Capability 357 The Server Capability Service lists the details on the information 358 that can be provided by an ALTO Server and perhaps other ALTO Servers 359 maintained by the network provider. The configuration includes, for 360 example, details about the operations and cost metrics supported by 361 the ALTO Server. The capability document can be downloaded by ALTO 362 Clients or provisioned into devices. 364 3.2. Services 366 3.2.1. Map Service 368 The Map Service provides batch information to ALTO Clients. Two maps 369 are provided in this document. The Network Map (See Section 4) 370 provides the full set of network location groupings defined by the 371 ALTO Server and the endpoints contained with each grouping. The Cost 372 Map (see Section 5) provides costs between the defined groupings. 374 These two maps can be thought of (and implemented as) as simple files 375 with appropriate encoding provided by the ALTO Server. 377 3.2.2. Map Filtering Service 379 Resource constrained ALTO Clients may benefit from query results 380 being filtered at the ALTO Server. This avoids an ALTO Client 381 spending network bandwidth or CPU collecting results and performing 382 client-side filtering. The Map Filtering Service allows ALTO Clients 383 to query for ALTO Server maps based on additional parameters. 385 3.2.3. Endpoint Property Service 387 This service allows ALTO Clients to look up properties for individual 388 endpoints. An example endpoint property is its network location (its 389 grouping defined by the ALTO Server) or connectivity type (e.g., 390 ADSL, Cable, or FioS). 392 3.2.4. Ranking Service 394 Some ALTO Clients may also benefit from querying for rankings and 395 costs based on endpoints. The Ranking Service allows an ALTO Server 396 to return either numerical costs or ordinal costs (rankings) for 397 additional network locations types such as Endpoints. 399 4. Network Map 401 In reality, many endpoints are very close to one another in terms of 402 network connectivity, for example, endpoints on the same site of an 403 enterprise. By treating a group of endpoints together as a single 404 entity in ALTO, we can achieve much greater scalability without 405 loosing critical information. 407 The Network Location endpoint property allows an ALTO Server to group 408 endpoints together to indicate their proximity. The resulting set of 409 groupings is called the ALTO Network Map. 411 The Network Map may also be used to communicate simple preferences. 412 For example, an ISP may prefer that endpoints associated with the 413 same PoP (Point-of-Presence) in a P2P application communicate locally 414 instead of communicating with endpoints in other PoPs. 416 Note that the definition of proximity varies depending on the 417 granularity of the ALTO information configured by the provider. In 418 one deployment, endpoints on the same subnet may be considered close; 419 while in another deployment, endpoints connected to the same PoP may 420 be considered close. 422 4.1. PID 424 Each group can be identified by a provider-defined Network Location 425 identifier called a PID. There can be many different ways of 426 grouping the endpoints and assigning PIDs. 428 A PID is a identifier providing an indirect and network-agnostic way 429 to specify a network aggregation. For example, a PID may be defined 430 (by the ALTO service provider) to denote a subnet, a set of subnets, 431 a metropolitan area, a PoP, an autonomous system, or a set of 432 autonomous systems. Aggregation of endpoints into PIDs can indicate 433 proximity and can improve scalability. In particular, network 434 preferences (costs) may be specified between PIDs, allowing cost 435 information to be more compact and updated at a smaller time scale 436 than the network aggregations themselves. 438 4.2. Example Network Map 440 Figure 2 illustrates an example Network Map. PIDs are used to 441 identify network-agnostic aggregations. 443 .--------------------------------------------------------. 444 | ALTO Network Map | 445 | | 446 | .--------------------------------. .---------------. | 447 | | NetLoc: PID-1 | | NetLoc: PID-2 | | 448 | | .---------------------------. | | ... | | 449 | | | 128.36.0.0/16 | | `---------------` | 450 | | | .-----------------------. | | | 451 | | | | Endpoint: 128.36.9.8 | | | .---------------. | 452 | | | `-----------------------` | | | NetLoc: PID-3 | | 453 | | `---------------------------` | | ... | | 454 | | .---------------------------. | `---------------` | 455 | | | 130.132.0.0/16 | | | 456 | | | .-----------------------. | | .---------------. | 457 | | | | Endpoint: 130.132.1.2 | | | | NetLoc: PID-4 | | 458 | | | `-----------------------` | | | ... | | 459 | | `---------------------------` | `---------------` | 460 | `--------------------------------` | 461 | | 462 `--------------------------------------------------------` 464 Figure 2: Example Network Map 466 5. Cost Map 468 An ALTO Server indicates preferences amongst network locations in the 469 form of Path Costs. Path Costs are generic costs and can be 470 internally computed by a network provider according to its own needs. 472 An ALTO Cost Map defines Path Costs pairwise amongst sets of source 473 and destination network locations. 475 5.1. Cost Attributes 477 Path Costs have attributes: 479 o Type: identifies what the costs represent; 481 o Mode: identifies how the costs should be interpreted (numerical or 482 ordinal). 484 Certain queries for Cost Maps allow the ALTO Client to indicate the 485 desired Type and Mode. 487 5.1.1. Cost Type 489 The Type attribute indicates what the cost represents. For example, 490 an ALTO Server could define costs representing air-miles, hop-counts, 491 or generic routing costs. 493 Cost types are indicated in protocol messages as alphanumeric 494 strings. An ALTO Server MUST at least define the routing cost type 495 denoted by the string 'routingcost'. 497 Note that an ISP may internally compute routing cost using any method 498 it chooses (including air-miles or hop-count). 500 If an ALTO Client requests a Cost Type that is not available, the 501 ALTO Server responds with an error as specified in Section 7.2.2.2. 503 5.1.2. Cost Mode 505 The Mode attribute indicates how costs should be interpreted. For 506 example, an ALTO Server could return costs that should be interpreted 507 as numerical values or ordinal rankings. 509 It is important to communicate such information to ALTO Clients, as 510 certain operations may not be valid on certain costs returned by an 511 ALTO Server. For example, it is possible for an ALTO Server to 512 return a set of IP addresses with costs indicating a ranking of the 513 IP addresses. Arithmetic operations, such as summation, that would 514 make sense for numerical values, do not make sense for ordinal 515 rankings. ALTO Clients may want to handle such costs differently. 517 Cost Modes are indicated in protocol messages as alphanumeric 518 strings. An ALTO Server MUST at least define the modes 'numerical' 519 and 'ordinal'. 521 If an ALTO Client requests a Cost Mode that is not supported, the 522 ALTO Server MUST reply with costs having Mode either 'numerical' or 523 'ordinal'. Thus, an ALTO Server must implement at least one of 524 'numerical' or 'ordinal' Costs, but it may choose which to support. 525 ALTO Clients may choose how to handle such situations. Two 526 particular possibilities are to use the returned costs as-is (e.g., 527 treat numerical costs as ordinal rankings) or ignore the ALTO 528 information altogether. 530 5.2. Cost Map Structure 532 A query for a Cost Map either explicitly or implicitly includes a 533 list of Source Network Locations and a list of Destination Network 534 Locations. (Note that a Network Location can be an endpoint address 535 or a PID.) 537 Specifically, assume that a query has a list of multiple Source 538 Network Locations, say [Src_1, Src_2, ..., Src_m], and a list of 539 multiple Destination Network Locations, say [Dst_1, Dst_2, ..., 540 Dst_n]. 542 The ALTO Server will return the Path Cost for each communicating pair 543 (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., Src_m -> Dst_1, ..., 544 Src_m -> Dst_n). We refer to this structure as a Cost Map. 546 If the Cost Mode is 'ordinal', the Path Cost of each communicating 547 pair is relative to the m*n entries. 549 5.3. Network Map and Cost Map Dependency 551 If a Path Cost query contains any PID in the list of Source Network 552 Locations or the list of Destination Network Locations, we say that 553 the Path Costs are generated based on a particular Network Map (which 554 defines that PID). Version Tags are introduced to ensure that ALTO 555 Clients are able to use consistent information even though the 556 information is provided in two maps. One advantage of separating 557 ALTO information into a Network Map and a Cost Map is that the two 558 components can be updated at different time scales. For example, 559 Network Maps may be stable for a longer time while Cost Maps may be 560 updated to reflect dynamic network conditions. 562 6. Protocol Overview 564 6.1. Design Approach 566 The ALTO Protocol design uses a RESTful interface with the goal of 567 leveraging current HTTP [2] [3] implementations and infrastructure. 568 ALTO messages are denoted with HTTP Content-Type "application/alto". 569 Message encodings use a structured, text-based format. The exact 570 encoding will be documented in a future revision, as the current 571 focus is overall protocol architecture and operations. 573 These design decisions make the protocol easier to understand and 574 debug, and allows for flexible ALTO Server implementation strategies. 575 More importantly, however, this enables use of existing 576 implementations and infrastructure, and allows for simple caching and 577 redistribution of ALTO information to increase scalability. 579 6.1.1. Use of Existing Infrastructure 581 An important design consideration for the ALTO Protocol is easy 582 integration with existing applications and infrastructure. As 583 outlined above, HTTP is a natural choice. In particular, this ALTO 584 Protocol design leverages: 586 o the huge installed base of infrastructure, including HTTP caches, 588 o mature software implementations, 590 o the fact that many P2P clients already have an embedded HTTP 591 client, and 593 o authentication and encryption mechanisms in HTTP and SSL. 595 6.1.2. ALTO Information Reuse and Redistribution 597 ALTO information may be useful to a large number of applications and 598 users. Distributing ALTO information must be efficient and not 599 become a bottleneck. Therefore, the ALTO Protocol specified in this 600 document integrates with existing HTTP caching infrastructure to 601 allow reuse of ALTO information by ALTO Clients and reduce load on 602 ALTO servers. ALTO information may also be cached or redistributed 603 using application-dependent mechanisms, such as P2P DHTs or P2P file- 604 sharing. For example, a full Network Map may be reused by all ALTO 605 Clients using the ALTO Server. 607 6.2. Message Format 609 The ALTO Protocol uses a RESTful design operating over HTTP. Both 610 Query and Response follow the standard format for HTTP Request and 611 Response messages [2] [3]. This section provides an overview of the 612 components of a Query message sent from an ALTO Client to an ALTO 613 Server, as well as the components of a Response message returned by 614 an ALTO Server. Note that if caching or redistribution is used, the 615 Response message may be returned from another (possibly third-party) 616 entity. Reuse and Redistrubution is further discussed in 617 Section 11.4. 619 6.2.1. Query Message 621 A Query message is generated by an ALTO Client and sent to an ALTO 622 Server. The ALTO Protocol employs the following components of the 623 HTTP request message: 625 Method: Indicates operation requested by the ALTO Client (along with 626 URI Path). 628 URI Path: Indicates the operation requested by the ALTO Client 629 (along with Method). 631 URI Query String Parameters: Indicates parameters for the requested 632 operation. Note that in the messaging specification in Section 7, 633 we abbreviate these as 'URI QS Params'. Order of query string 634 parameters is not specified. Some parameters are restricted in 635 how many times they appear. We use the notation 'min..max' to 636 denote the the minimum and maximum times they may appear, where 637 'max' may be '*' to denote unbounded. If no parameters are 638 defined for a particular ALTO request message, the query string 639 MUST be empty (and there MUST be no '?' included in the URI Path). 641 Headers: Indicates encoding of the Body. If the HTTP body of the 642 request is non-empty, the Content-Type header MUST be set to 643 "application/alto". 645 Body: Indicates additional request parameters that are not concisely 646 representable as Query String parameters. If no Body is defined 647 for a particular ALTO request message, the HTTP request body MUST 648 be empty. 650 6.2.2. Response Message 652 A Response message is generated by an ALTO Server, which corresponds 653 to a particular Query message. The ALTO Protocol employs the 654 following components of the HTTP Response message: 656 Status Code: Indicates either success or an error condition. 658 Headers: Indicates encoding of the Body and caching directives. If 659 the HTTP body of the response is non-empty, the Content-Type 660 header MUST be set to "application/alto" 662 Body: Contains data requested by the ALTO Client. 664 6.2.3. Query and Response Body Encoding 666 When the Body of a Query or Response message is not empty, it MUST 667 contain a properly-encoded message. This section will be updated to 668 include common requirements when an encoding format is decided. 670 7. Protocol Messaging 672 This section specifies client and server processing, as well as 673 messages in the ALTO Protocol. Details common to ALTO Server 674 processing of all messages is first discussed, followed by details of 675 the individual messages. 677 Note that the primary focus of the current draft is the architecture 678 and protocol operations, and only the structure of messages is 679 specified (without actual message encoding). Additionally, the 680 following details have been omitted for clarity: 682 o protocol version number 684 o transaction ID 686 o map version tags 688 o HTTP URL encoding 690 This section will be updated as revisions are made to protocol 691 details and encodings. 693 7.1. Client Processing 695 7.1.1. General Processing 697 The protocol is structured in such a way that, independent of the 698 query type, there are a set of general processing steps. The ALTO 699 Client selects a specific ALTO Server with which to communicate, 700 establishes a TCP connection, and constructs and sends query messages 701 which MUST conform to Section 7.3. In response to query messages, an 702 ALTO Server constructs and sends response messages which also MUST 703 conform to Section 7.3. 705 An ALTO Server MAY support SSL/TLS to implement server and/or client 706 authentication. An ALTO Server also MAY support HTTP Digest 707 authentication. Cookies MUST NOT be used. ALTO Clients and ALTO 708 Servers MUST additionally follow any TCP transport and HTTP 709 processing and encoding considerations. 711 7.1.2. General Error Conditions 713 In the case that the client does not receive an appropriate response 714 from the server it can choose another server to communicate or fall 715 back to a default behavior (e.g., perform peer selection without the 716 use of ALTO information). 718 7.2. Server Processing 720 7.2.1. Successful Responses 722 If a Query message is successfully processed and an ALTO response is 723 generated, the HTTP status code in the response MUST be set to 200. 725 7.2.2. General Error Conditions 727 This section specifies ALTO Server behavior when it recevies a Query 728 message that cannot be processed due to a problem with processing the 729 Query message itself. 731 7.2.2.1. Invalid Query Format 733 If any component of the Query message is formatted incorrectly (i.e., 734 it does not follow the formats in Section 7.3), the ALTO Server MUST 735 return HTTP Status Code 400. 737 7.2.2.2. Unsupported Query 739 If an ALTO Server does not support the operation indicated in the 740 Query message, the ALTO Server MUST return HTTP Status Code 501. 742 7.2.3. Caching Parameters 744 If the response generated by the ALTO Server is cachable, the ALTO 745 Server MAY include 'Cache-Control' and 'Expires' HTTP headers, 746 enabling it to be cached by intermediary HTTP Caches or the ALTO 747 Client itself. 749 7.3. ALTO Queries 751 7.3.1. Server Capability 753 The Server Capability query allows an ALTO Client to determine the 754 available operations of a particular ALTO Server 756 This query MUST be supported. 758 7.3.1.1. Query 760 Method : 'GET' 761 URI Path : '/capability' 763 7.3.1.2. Example Response Structure 765 { 766 "instance-name": "alto.example.com", 767 "uri": "http:\/\/alto.example.com:6671", 768 "cost": [ 769 {"type":"latency", "units":"ms"}, 770 {"type":"pDistance","units":"scalar"}, 771 {"type":"bandwidth","units":"kbps"} 772 ], 773 "constraint-support": false 774 } 776 7.3.2. Map Service 778 The Map Service provides batch information to ALTO Clients in the 779 form of two maps: a Network Map and Cost Map. All queries in the Map 780 Service MUST be supported. 782 7.3.2.1. Network Map 784 The full Network Map is an instantiation of the Reverse Property 785 Lookup where the ALTO Server lists for each PID, the network 786 locations (endpoints) within the PID. 788 7.3.2.1.1. Query 790 Method : 'GET' 791 URI Path : '/prop/pid/map' 793 7.3.2.1.2. Example Response Structure 795 { 796 "PID1" : [ 797 "128.36.1.0/24", 798 "132.130.1.0/24", 799 "132.130.2.0/24" 800 ], 801 "PID2" : [ "130.132.3.0/24" ], 802 "PID3" : [ "0.0.0.0/0" ] 803 } 805 7.3.2.2. Cost Map 807 The Map Service Cost Map query is a batch operation in which the ALTO 808 Server returns the Path Cost for each pair of source/destination PID 809 defined by the ALTO Server. 811 The ALTO Server provides costs using the default Cost Type 812 ('routingcost') and default Cost Mode ('numerical'). 814 7.3.2.2.1. Query 816 Method : 'GET' 817 URI Path : '/cost/pid/map' 819 7.3.2.2.2. Example Response Structure 821 { 822 "Type": "routingcost", 823 "Mode": "numerical", 824 "Map" : { 825 "PID1": { "PID1": 1, "PID2": 5 , "PID3": 10 }, 826 "PID2": { "PID1": 5 , "PID2": 1 , "PID3": 15 }, 827 "PID3": { "PID1": 20, "PID2": 15, "PID3": 1 } 828 } 829 } 831 7.3.3. Map Filtering Service 833 The Map Filtering Service allows ALTO Clients to specify filtering 834 criteria to return a subset of the full maps available in the Map 835 Service. 837 The services defined in this section are OPTIONAL. 839 7.3.3.1. Network Map 841 ALTO Clients can query for a subset of the full network map (see 842 Section 7.3.2.1). 844 7.3.3.1.1. Query 846 Method : 'POST' 847 URI Path : '/prop/pid/filter' 849 7.3.3.1.2. Example Request Structure 851 POST /prop/pid/filter ... 853 [ "PID1", "PID2" ] 855 7.3.3.1.3. Example Response Structure 857 { 858 "PID1" : [ 859 "128.36.1.0/24", 860 "132.130.1.0/24", 861 "132.130.2.0/24" 862 ], 863 "PID2" : [ "130.132.3.0/24" ], 864 "PID3" : [ "0.0.0.0/0" ] 865 } 867 7.3.3.2. Cost Map 869 ALTO Clients can query for the Cost Map (see Section 7.3.2.2) based 870 on additional parameters. 872 7.3.3.2.1. Query 874 Method : 'POST' 875 URI Path : '/cost/pid/filter' 876 URI QS Params : 'type=[costtype]' (multiplicity: 0..1) 877 'mode=[costmode]' (multiplicity: 0..1) 878 'constraint=[constraint]' (multiplicity: 0..*) 880 The 'constraint' parameter is optional and is to be used only if the 881 ALTO service supports it. It allows a client to specify a target 882 numerical cost. The constraint contains two entities: (1) an 883 operator either 'gt' for greater than , 'lt' for less than or 'eq' 884 for equal to with 10 percent on either side, (2) a target numerical 885 cost. The numerical cost is a number that MUST be defined in the 886 units specified in the ALTO service configuration document obtained 887 from ALTO service discovery. If multiple 'constraint' parameters are 888 specified, the ALTO Server assumes they are related to each other 889 with a logical AND. 891 If the query does not specify the 'type' and 'mode' query string 892 parameters, then the server assumes the type to be 'routingcost' and 893 the mode to be 'numerical'. A Query MUST contain no more than one 894 'type' parameter, and no more than one 'mode' parameter. 896 The request body MAY specify a list of source PIDs, and a list of 897 destination PIDs. If a list is empty, it is interpreted by the ALTO 898 Server as the full set of PIDs. The ALTO Server returns costs 899 between each pair of source/destination PID. 901 7.3.3.2.2. Example Request Structure 903 POST /cost/pid/filter 905 { 906 "src": [ "PID1" ], 907 "dst": [ "PID1", "PID2", "PID3" ] 908 } 910 7.3.3.2.3. Example Response Structure 912 { 913 "Type": "routingcost", 914 "Mode": "numerical", 915 "Map" : { 916 "PID1": { "PID1" : 1, "PID2": 5 , "PID3": 10 }, 917 } 918 } 920 7.3.4. Endpoint Property Service 922 The Endpoint Property Lookup query allows an ALTO Client to query for 923 properties of Endpoints known to the ALTO Server. If the ALTO Server 924 provides the Endpoint Property Service, the ALTO Server MUST define 925 at least the 'pid' property for Endpoints. Additional supported 926 properties can be defined in the Server Capability response. 928 The services defined in this section are OPTIONAL. 930 7.3.4.1. Query 932 Method : 'POST' 933 URI Path : '/endpoint/m' 934 URI QS Params : 'prop=[propertyname]' (multiplicity: 1..*) 936 The request body includes a list of Endpoints for which the property 937 value should be returned. If the request body is empty, the ALTO 938 Server implicitly assumes that the request contains a single-element 939 list with the Endpoint address of the requesting client. 941 Also note that the 'prop' parameter may be specified multiple times 942 to query for multiple properties simultaneously. For example, the 943 query string could be 'prop=pid&prop=bandwidth'. 945 7.3.4.2. Example Request Structure 947 POST /endpoint/m?prop=pid ... 949 [ "ipv4:128.36.1.34" ] 951 7.3.4.3. Example Response Structure 953 { 954 "ipv4:128.36.1.34" : { "pid": "PID1" } 955 } 957 7.3.5. Ranking Service 959 The Ranking Service allows ALTO Clients to directly supply endpoints 960 to an ALTO Server. The ALTO Server replies with costs (numerical or 961 ordinal) amongst the endpoints. 963 In particular, this service allows lists of Endpoint addresses to be 964 ranked (ordered) by an ALTO Server. 966 The services defined in this section are OPTIONAL. 968 7.3.5.1. Ranking Query 970 7.3.5.1.1. Query 972 Method : 'POST' 973 URI Path : '/cost/endpoint/ranking' 974 URI QS Params : 'type=[costtype]' (multiplicity: 0..1) 975 'mode=[costmode]' (multiplicity: 0..1) 976 'constraint=[constraint]' (multiplicity: 0..*) 978 The request body includes a list of source and destination endpoints 979 that should be assigned a cost by the ALTO Server. The 'type', 980 'mode', and 'constraint' parameters behave as specified in 981 Section 7.3.3.2. 983 The request body MUST specify a list of source Endpoints, and a list 984 of destination Endpoints. If the list of source Endpoints is empty 985 (or it is not included), the ALTO Server MUST treat it as if it 986 contained the Endpoint address of the requesting client. The list of 987 destination Endpoints MUST NOT be empty. The ALTO Server returns 988 costs between each pair of source/destination Endpoint. 990 7.3.5.1.2. Example Request Structure 992 POST /cost/endpoint/ranking?mode=ordinal ... 994 { 995 "src": "ipv4:128.30.24.2" 996 "dst": [ 997 "ipv4:128.30.24.89", 998 "ipv4:12.32.67.3", 999 "ipv4:130.132.33.4" 1000 ] 1001 } 1003 7.3.5.1.3. Example Response Structure 1005 { 1006 "Type": "routingcost", 1007 "Mode": "ordinal", 1008 "Ranking" : { 1009 "ipv4:128.30.24.2": { 1010 "ipv4:128.30.24.89" : 1, 1011 "ipv4:130.132.33.4" : 2, 1012 "ipv4:12.32.67.3" : 3 1013 } 1014 } 1015 } 1017 8. Use Cases 1019 The sections below depict typical use cases. 1021 8.1. ALTO Client Embedded in P2P Tracker 1023 Many P2P currently-deployed P2P systems use a Tracker to manage 1024 swarms and perform peer selection. P2P trackers may currently use a 1025 variety of information to perform peer selection to meet application- 1026 specific goals. By acting as an ALTO Client, an P2P tracker can use 1027 ALTO information as an additional information source to enable more 1028 network-efficient traffic patterns and improve application 1029 performance. 1031 A particular requirement of many P2P trackers is that they must 1032 handle a large number of P2P clients. A P2P tracker can obtain and 1033 locally store ALTO information (the Network Map and Cost Map) from 1034 the ISPs containing the P2P clients, and benefit from the same 1035 aggregation of network locations done by ALTO Servers. 1037 .---------. (1) Get Network Map .---------------. 1038 | | <----------------------> | | 1039 | ALTO | | P2P Tracker | 1040 | Server | (2) Get Cost Map | (ALTO Client) | 1041 | | <----------------------> | | 1042 `---------' `---------------' 1043 ^ | 1044 (3) Get Peers | | (4) Selected Peer 1045 | v List 1046 .---------. .-----------. 1047 | Peer 1 | <-------------- | P2P | 1048 `---------' | Client | 1049 . (5) Connect to `-----------' 1050 . Selected Peers / 1051 .---------. / 1052 | Peer 50 | <------------------ 1053 `---------' 1055 Figure 3: ALTO Client Embedded in P2P Tracker 1057 Figure 3 shows an example use case where a P2P tracker is an ALTO 1058 Client and applies ALTO information when selecting peers for its P2P 1059 clients. The example proceeds as follows: 1061 1. The P2P Tracker requests the Network Map covering all PIDs from 1062 the ALTO Server using the Network Map query. The Network Map 1063 includes the IP prefixes contained in each PID, allowing the P2P 1064 tracker to locally map P2P clients into a PIDs. 1066 2. The P2P Tracker requests the Cost Map amongst all PIDs from the 1067 ALTO Server. 1069 3. A P2P Client joins the swarm, and requests a peer list from the 1070 P2P Tracker. 1072 4. The P2P Tracker returns a peer list to the P2P client. The 1073 returned peer list is computed based on the Network Map and Cost 1074 Map returned by the ALTO Server, and possibly other information 1075 sources. Note that it is possible that a tracker may use only 1076 the Network Map to implement hierarchical peer selection by 1077 preferring peers within the same PID and ISP. 1079 5. The P2P Client connects to the selected peers. 1081 Note that the P2P tracker may provide peer lists to P2P clients 1082 distributed across multiple ISPs. In such a case, the P2P tracker 1083 may communicate with multiple ALTO Servers. 1085 8.2. ALTO Client Embedded in P2P Client: Numerical Costs 1087 P2P clients may also utilize ALTO information themselves when 1088 selecting from available peers. It is important to note that not all 1089 P2P systems use a P2P tracker for peer discovery and selection. 1090 Furthermore, even when a P2P tracker is used, the P2P clients may 1091 rely on other sources, such as peer exchange and DHTs, to discover 1092 peers. 1094 When an P2P Client uses ALTO information, it typically queries only 1095 the ALTO Server servicing its own ISP. The my-Internet view provided 1096 by its ISP's ALTO Server can include preferences to all potential 1097 peers. 1099 .---------. (1) Get Network Map .---------------. 1100 | | <----------------------> | | 1101 | ALTO | | P2P Client | 1102 | Server | (2) Get Cost Map | (ALTO Client) | 1103 | | <----------------------> | | .---------. 1104 `---------' `---------------' <- | P2P | 1105 .---------. / | ^ ^ | Tracker | 1106 | Peer 1 | <-------------- | | \ `---------' 1107 `---------' | (3) Gather Peers 1108 . (4) Select Peers | | \ 1109 . and Connect / .--------. .--------. 1110 .---------. / | P2P | | DHT | 1111 | Peer 50 | <---------------- | Client | `--------' 1112 `---------' | (PEX) | 1113 `--------' 1115 Figure 4: ALTO Client Embedded in P2P Client 1117 Figure 4 shows an example use case where a P2P Client locally applies 1118 ALTO information to select peers. The use case proceeds as follows: 1120 1. The P2P Client requests the Network Map covering all PIDs from 1121 the ALTO Server servicing its own ISP. 1123 2. The P2P Client requests the Cost Map amongst all PIDs from the 1124 ALTO Server. The Cost Map by default specifies numerical costs. 1126 3. The P2P Client discovers peers from sources such as Peer Exchange 1127 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 1128 P2P Trackers. 1130 4. The P2P Client uses ALTO information as part of the algorithm for 1131 selecting new peers, and connects to the selected peers. 1133 8.3. ALTO Client Embedded in P2P Client: Ranking 1135 It is also possible for a P2P Client to offload the selection and 1136 ranking process to an ALTO Server. In this use case, the ALTO Client 1137 gathers a list of known peers in the swarm, and asks the ALTO Server 1138 to rank them. 1140 As in the use case using numerical costs, the P2P Client typically 1141 only queries the ALTO Server servicing its own ISP. 1143 .---------. .---------------. 1144 | | | | 1145 | ALTO | (2) Get Endpoint Ranking | P2P Client | 1146 | Server | <----------------------> | (ALTO Client) | 1147 | | | | .---------. 1148 `---------' `---------------' <- | P2P | 1149 .---------. / | ^ ^ | Tracker | 1150 | Peer 1 | <-------------- | | \ `---------' 1151 `---------' | (1) Gather Peers 1152 . (3) Connect to | | \ 1153 . Selected Peers / .--------. .--------. 1154 .---------. / | P2P | | DHT | 1155 | Peer 50 | <---------------- | Client | `--------' 1156 `---------' | (PEX) | 1157 `--------' 1159 Figure 5: ALTO Client Embedded in P2P Client: Ranking 1161 Figure 5 shows an example of this scenario. The use case proceeds as 1162 follows: 1164 1. The P2P Client discovers peers from sources such as Peer Exchange 1165 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 1166 P2P Trackers. 1168 2. The P2P Client queries the ALTO Server's Ranking Service, 1169 including discovered peers as the set of Destination Endpoints, 1170 and indicates the 'ordinal' Cost Mode. The response indicates 1171 the ranking of the candidate peers. 1173 3. The P2P Client connects to the peers in the order specified in 1174 the ranking. 1176 9. Discussions 1178 9.1. Discovery 1180 The particular mechanism by which an ALTO Client discovers its ALTO 1181 Server is an important component to the ALTO architecture and 1182 numerous techniques have been discussed [13] [14]. However, the 1183 discovery mechanism is out of scope for this document. 1185 Some ISPs have proposed the possibility of delegation, in which an 1186 ISP provides information for customer networks which do not wish to 1187 run Portal Servers themselves. A consideration for delegation is 1188 that customer networks may wish to explicitly configure such 1189 delegation. 1191 9.2. Network Address Translation Considerations 1193 At this day and age of NAT v4<->v4, v4<->v6 [15], and possibly 1194 v6<->v6[16], a protocol should strive to be NAT friendly and minimize 1195 carrying IP addresses in the payload, or provide a mode of operation 1196 where the source IP address provide the information necessary to the 1197 server. 1199 The protocol specified in this document provides a mode of operation 1200 where the source network location is computed by the ALTO Server (via 1201 the Endpoint Property Lookup interface) from the source IP address 1202 found in the ALTO Client query packets. This is similar to how some 1203 P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS 1204 Protocol" in [17]) operate. 1206 The ALTO client SHOULD use the Session Traversal Utilities for NAT 1207 (STUN) [4] to determine a public IP address to use as a source NL-ID. 1208 If using this method, the host MUST use the "Binding Request" message 1209 and the resulting "XOR-MAPPED-ADDRESS" parameter that is returned in 1210 the response. Using STUN requires cooperation from a publicly 1211 accessible STUN server. Thus, the ALTO client also requires 1212 configuration information that identifies the STUN server, or a 1213 domain name that can be used for STUN server discovery. To be 1214 selected for this purpose, the STUN server needs to provide the 1215 public reflexive transport address of the host. 1217 9.3. Mapping IPs to ASNs 1219 It may be desired for the ALTO Protocol to provide ALTO information 1220 including ASNs. Thus, ALTO Clients may need to identify the ASN for 1221 a Resource Provider to determine the cost to that Resource Provider. 1223 Applications can already map IPs to ASNs using information from a BGP 1224 Looking Glass. To do so, they must download a file of about 1.5MB 1225 when compressed (as of October 2008, with all information not needed 1226 for IP to ASN mapping removed) and periodically (perhaps monthly) 1227 refresh it. 1229 Alternatively, the Network Map query in the Map Filtering Service 1230 defined in this document could be extended to map ASNs into a set of 1231 IP prefixes. The mappings provided by the ISP would be both smaller 1232 and more authoritative. 1234 For simplicity of implementation, it's highly desirable that clients 1235 only have to implement exactly one mechanism of mapping IPs to ASNs. 1237 9.4. Endpoint and Path Properties 1239 An ALTO Server could make available many properties about Endpoints 1240 beyond their network location or grouping. For example, connection 1241 type, geographical location, and others may be useful to 1242 applications. The current draft focuses on network location and 1243 grouping, but the protocol may be extended to handle other Endpoint 1244 properties. 1246 9.5. P2P Peer Selection 1248 This section discusses possible approaches to peer selection using 1249 ALTO information (Network Location Identifiers and associated Costs) 1250 from an ALTO Server. Specifically, the application must select which 1251 peers to use based on this and other sources of information. With 1252 this in mind, the usage of ALTO Costs is intentionally flexible, 1253 because: 1255 Different applications may use the information differently. For 1256 example, an application that connects to just one address may have 1257 a different algorithm for selecting it than an application that 1258 connects to many. 1260 Though initial experiments have been conducted [18], more 1261 investigation is needed to identify other methods. 1263 In addition, the application might account for robustness, perhaps 1264 using randomized exploration to determine if it performs better 1265 without ALTO information. 1267 9.5.1. Client-based Peer Selection 1269 One possibility is for peer selection using ALTO costs to be done 1270 entirely by a P2P client. The following are some techniques have 1271 been proposed and/or used: 1273 o Prefer network locations with lower ordinal rankings (i.e., higher 1274 priority) [19] [8]. 1276 o Optimistically unchoking low-cost peers with higher probability 1277 [8]. 1279 9.5.2. Server-based Peer Selection 1281 Another possibility is for ALTO costs to be used by an Application 1282 Tracker (e.g., BitTorrent Tracker) when returning peer lists. The 1283 following are techniques that have been proposed and/or used: 1285 o Using bandwidth matching (e.g., at an Application Tracker) and 1286 choosing solution (within bound of optimal) with minimal network 1287 cost [18]. 1289 10. IANA Considerations 1291 This document request the registration of a new media type: 1292 "application/alto" 1294 11. Security Considerations 1296 11.1. ISPs 1298 ISPs must be cognizant of the network topology and provisioning 1299 information provided through ALTO Interfaces. ISPs should evaluate 1300 how much information is revealed and the associated risks. In 1301 particular, providing overly fine-grained information may make it 1302 easier for attackers to infer network topology. On the other hand, 1303 revealing overly coarse-grained information may not provide benefits 1304 to network efficiency or performance improvements to ALTO Clients. 1306 11.2. ALTO Clients 1308 Applications using the information must be cognizant of the 1309 possibility that the information is malformed or incorrect. Other 1310 considerations (e.g., relating to application performance) can be 1311 found in Section 6 of [11]. 1313 ALTO Clients should also be cognizant of revealing Network Location 1314 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, 1315 as doing so may allow the ALTO Server to infer communication 1316 patterns. One possibility is for the ALTO Client to only rely on 1317 Network Map for PIDs and Cost Map amongst PIDs to avoid passing IP 1318 addresses of their peers to the ALTO Server. 1320 11.3. ALTO Information 1322 An ALTO Server may optionally use authentication and encryption to 1323 protect ALTO information. SSL/TLS can provide encryption as well as 1324 authentication of the client and server. HTTP Basic or Digest 1325 authentication can provide authentication of the client (combined 1326 with SSL/TLS, it can additionally provide encryption and 1327 authentication of the server). 1329 ISPs should be cognizant that encryption only protects ALTO 1330 information until it is decrypted by the intended ALTO Client. 1331 Digital Rights Management (DRM) techniques and legal agreements 1332 protecting ALTO information are outside of the scope of this 1333 document. 1335 11.4. ALTO Information Redistribution 1337 It is possible for applications to redistribute ALTO information to 1338 improve scalability. Even with such a distribution scheme, ALTO 1339 Clients obtaining ALTO information must be able to validate the 1340 received ALTO information to ensure that it was actually generated by 1341 the correct ALTO Server. Further, to prevent the ALTO Server from 1342 being a target of attack, the verification scheme must not require 1343 ALTO Clients to contact the ALTO Server to validate every set of 1344 information. 1346 Note that the redistribution scheme must additionally handle details 1347 such as ensuring ALTO Clients retrieve ALTO information from the 1348 correct ALTO Server. See [20] and [21] for further discussion. 1349 Details of a particular redistribution scheme are outside the scope 1350 of this document. 1352 To fulfill these requirements, ALTO Information meant to be 1353 redistributable contains a digital signature which includes a hash of 1354 the ALTO information signed by the ALTO Server's private key. The 1355 corresponding public key should either be part of the ALTO 1356 information itself, or it could be included in the server capability 1357 response. The public key SHOULD include the hostname of the ALTO 1358 Server and it SHOULD be signed by a trusted authority. 1360 11.5. Denial of Service 1362 ISPs should be cognizant of the workload at the ALTO Server generated 1363 by certain ALTO Queries, such as certain queries to the Map Filtering 1364 Service and Ranking Service. Therefore ISPs should employ security 1365 measures such as firewalls to prevent queries originating from 1366 unauthorized networks. 1368 ISPs should also leverage the fact that the the Map Service allows 1369 ALTO Servers to pre-generate maps that can be useful to many ALTO 1370 Clients. 1372 12. References 1374 12.1. Normative References 1376 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1377 Levels", BCP 14, RFC 2119, March 1997. 1379 [2] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1380 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1382 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1383 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1384 HTTP/1.1", RFC 2616, June 1999. 1386 [4] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 1387 Traversal Utilities for (NAT) (STUN)", 1388 draft-ietf-behave-rfc3489bis-18 (work in progress), July 2008. 1390 12.2. Informative References 1392 [5] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, 1393 "Application-Layer Traffic Optimization (ALTO) Requirements", 1394 draft-kiesel-alto-reqs-01 (work in progress), November 2008. 1396 [6] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, "P4P: 1397 Provider Portal for P2P Applications", draft-p4p-framework-00 1398 (work in progress), November 2008. 1400 [7] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, "P4P 1401 Protocol Specification", draft-wang-alto-p4p-specification-00 1402 (work in progress), March 2009. 1404 [8] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 1405 Export Service", draft-shalunov-alto-infoexport-00 (work in 1406 progress), October 2008. 1408 [9] Das, S. and V. Narayanan, "A Client to Service Query Response 1409 Protocol for ALTO", draft-saumitra-alto-queryresponse-00 (work 1410 in progress), March 2009. 1412 [10] Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 1413 Dimensional Peer Selection Problem", 1414 draft-saumitra-alto-multi-ps-00 (work in progress), 1415 October 2008. 1417 [11] Seedorf, J. and E. Burger, "Application-Layer Traffic 1418 Optimization (ALTO) Problem Statement", RFC 5693, October 2009. 1420 [12] Yang, Y., Popkin, L., Penno, R., and S. Shalunov, "An 1421 Architecture of ALTO for P2P Applications", 1422 draft-yang-alto-architecture-00 (work in progress), March 2009. 1424 [13] Garcia, G., Tomsu, M., and Y. Wang, "ALTO Discovery Protocols", 1425 draft-wang-alto-discovery-00 (work in progress), March 2009. 1427 [14] Song, H., Even, R., Pascual, V., and Y. Zhang, "Application- 1428 Layer Traffic Optimization (ALTO): Discover ALTO Servers", 1429 draft-song-alto-server-discovery-00 (work in progress), 1430 March 2009. 1432 [15] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 1433 Translation", draft-baker-behave-v4v6-framework-02 (work in 1434 progress), February 2009. 1436 [16] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address 1437 Translation (NAT66)", draft-mrw-behave-nat66-02 (work in 1438 progress), March 2009. 1440 [17] "Bittorrent Protocol Specification v1.0", 1441 http://wiki.theory.org/BitTorrentSpecification, 2009. 1443 [18] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A. 1444 Silberschatz., "P4P: Provider Portal for (P2P) Applications", 1445 In SIGCOMM 2008. 1447 [19] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 1448 Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00 1449 (work in progress), March 2009. 1451 [20] Yingjie, G., Alimi, R., and R. Even, "ALTO Information 1452 Redistribution", draft-gu-alto-redistribution-01 (work in 1453 progress), October 2009. 1455 [21] Stiemerling, M., "ALTO Information Redistribution Considered 1456 Harmful", draft-stiemerling-alto-info-redist-00 (work in 1457 progress), August 2009. 1459 Appendix A. Acknowledgments 1461 First, we would like to thank the following people whose input and 1462 involvement was indispensable in achieving this merged proposal: 1464 Obi Akonjang (DT Labs/TU Berlin), 1466 Saumitra M. Das (Qualcomm Inc.), 1468 Syon Ding (China Telecom), 1470 Doug Pasko (Verizon), 1472 Laird Popkin (Pando Networks), 1474 Satish Raghunath (Juniper Networks), 1476 Albert Tian (Ericsson/Redback), 1478 Yu-Shun Wang (Microsoft), 1480 David Zhang (PPLive), 1482 Yunfei Zhang (China Mobile). 1484 We would also like to thank the following additional people who were 1485 involved in the projects that contributed to this merged document: 1486 Alex Gerber (AT&T), Chris Griffiths (Comcast), Ramit Hora (Pando 1487 Networks), Arvind Krishnamurthy (University of Washington), Marty 1488 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 1489 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T), 1490 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 1491 Damien Saucez (UCL) Thomas Scholl (AT&T), Emilio Sepulveda 1492 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 1493 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 1494 (Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia 1495 Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University), 1496 Haiyong Xie (Yale University). 1498 Appendix B. Authors 1500 [[Comment.1: RFC Editor: Please move information in this section to 1501 the Authors' Addresses section at publication time.]] 1502 Stefano Previdi 1503 Cisco 1505 Email: sprevidi@cisco.com 1507 Stanislav Shalunov 1508 BitTorrent 1510 Email: shalunov@bittorrent.com 1512 Richard Woundy 1513 Comcast 1515 Richard_Woundy@cable.comcast.com 1517 Authors' Addresses 1519 Richard Alimi (editor) 1520 Yale University 1522 Email: richard.alimi@yale.edu 1524 Reinaldo Penno (editor) 1525 Juniper Networks 1526 1194 N Mathilda Avenue 1527 Sunnyvale, CA 1528 USA 1530 Email: rpenno@juniper.net 1532 Y. Richard Yang (editor) 1533 Yale University 1535 Email: yry@cs.yale.edu