idnits 2.17.1 draft-ietf-alto-protocol-00.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 5244 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 183 ** 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 (-05) exists of draft-marocco-alto-problem-statement-04 == 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 (~~), 6 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-00.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. Network Location . . . . . . . . . . . . . . . . . . . 7 86 2.2. ALTO Service and Protocol Scope . . . . . . . . . . . . . 7 87 3. Protocol Structure . . . . . . . . . . . . . . . . . . . . . . 8 88 3.1. Server Capability . . . . . . . . . . . . . . . . . . . . 9 89 3.2. Services . . . . . . . . . . . . . . . . . . . . . . . . . 9 90 3.2.1. Map Service . . . . . . . . . . . . . . . . . . . . . 9 91 3.2.2. Map Filtering Service . . . . . . . . . . . . . . . . 10 92 3.2.3. Endpoint Property Service . . . . . . . . . . . . . . 10 93 3.2.4. Ranking Service . . . . . . . . . . . . . . . . . . . 10 94 4. Network Map . . . . . . . . . . . . . . . . . . . . . . . . . 10 95 4.1. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 96 4.2. Example Network Map . . . . . . . . . . . . . . . . . . . 11 97 5. Path Rating . . . . . . . . . . . . . . . . . . . . . . . . . 12 98 5.1. Path Cost . . . . . . . . . . . . . . . . . . . . . . . . 12 99 5.1.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . 12 100 5.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 12 101 5.2. Path Rating Query . . . . . . . . . . . . . . . . . . . . 13 102 5.2.1. Cost Map . . . . . . . . . . . . . . . . . . . . . . . 13 103 5.2.2. Ranking List . . . . . . . . . . . . . . . . . . . . . 13 104 5.2.3. Network Map and Cost Map Dependency . . . . . . . . . 13 105 6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14 106 6.1. Design Approach . . . . . . . . . . . . . . . . . . . . . 14 107 6.1.1. Use of Existing Infrastructure . . . . . . . . . . . . 14 108 6.1.2. ALTO Information Reuse and Redistribution . . . . . . 14 109 6.2. Message Format . . . . . . . . . . . . . . . . . . . . . . 15 110 6.2.1. Query Message . . . . . . . . . . . . . . . . . . . . 15 111 6.2.2. Response Message . . . . . . . . . . . . . . . . . . . 16 112 6.2.3. Query and Response Body Encoding . . . . . . . . . . . 16 113 7. Protocol Messaging . . . . . . . . . . . . . . . . . . . . . . 16 114 7.1. Client Processing . . . . . . . . . . . . . . . . . . . . 16 115 7.1.1. General Processing . . . . . . . . . . . . . . . . . . 17 116 7.1.2. General Error Conditions . . . . . . . . . . . . . . . 17 117 7.2. Server Processing . . . . . . . . . . . . . . . . . . . . 17 118 7.2.1. Successful Responses . . . . . . . . . . . . . . . . . 17 119 7.2.2. General Error Conditions . . . . . . . . . . . . . . . 17 120 7.2.3. Caching Parameters . . . . . . . . . . . . . . . . . . 17 121 7.3. ALTO Queries . . . . . . . . . . . . . . . . . . . . . . . 18 122 7.3.1. Server Capability . . . . . . . . . . . . . . . . . . 18 123 7.3.2. Map Service . . . . . . . . . . . . . . . . . . . . . 18 124 7.3.3. Map Filtering Service . . . . . . . . . . . . . . . . 19 125 7.3.4. Endpoint Property Service . . . . . . . . . . . . . . 21 126 7.3.5. Ranking Service . . . . . . . . . . . . . . . . . . . 22 127 8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 23 128 8.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 23 129 8.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 25 130 8.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 26 131 9. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 27 132 9.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 27 133 9.2. Network Address Translation Considerations . . . . . . . . 27 134 9.3. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . 28 135 9.4. Endpoint and Path Properties . . . . . . . . . . . . . . . 28 136 9.5. P2P Peer Selection . . . . . . . . . . . . . . . . . . . . 28 137 9.5.1. Client-based Peer Selection . . . . . . . . . . . . . 29 138 9.5.2. Server-based Peer Selection . . . . . . . . . . . . . 29 139 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 140 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 141 11.1. ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 142 11.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 29 143 11.3. ALTO Information . . . . . . . . . . . . . . . . . . . . . 30 144 11.4. ALTO Information Redistribution . . . . . . . . . . . . . 30 145 11.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 31 146 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 147 12.1. Normative References . . . . . . . . . . . . . . . . . . . 31 148 12.2. Informative References . . . . . . . . . . . . . . . . . . 31 149 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 33 150 Appendix B. Authors . . . . . . . . . . . . . . . . . . . . . . . 33 151 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 153 1. Introduction 155 1.1. Background and Problem Statement 157 Today, network information available to applications is mostly from 158 the view of endhosts. There is no clear mechanism to convey 159 information about the network's preferences to applications. By 160 leveraging better network-provided information, applications have 161 potential to become more network-efficient (e.g., reduce network 162 resource consumption) and achieve better application performance 163 (e.g., accelerated download rate). The ALTO Service intends to 164 provide a simple way to convey network information to applications. 166 The goal of the protocol specified in this document is to provide a 167 simple, unified protocol that meets the ALTO requirements [5], 168 providing a migration path for Internet Service Providers (ISP), 169 Content Providers, and clients that have deployed protocols with 170 similar intentions (see below). This document is a work in progress 171 and will be updated with further developments. 173 1.2. Design History and Merged Proposals 175 The protocol specified here consists of contributions from 177 o P4P [6],[7]; 179 o ALTO Info-Export [8]; 181 o Query/Response [9],[10]; 183 o ATTP [ATTP]. 185 o Proxidor [19]. 187 See Appendix A for a list of people that have contributed 188 significantly to this effort and the projects and proposals listed 189 above. 191 1.3. Solution Benefits 193 The ALTO Service offers many benefits to both end-users (consumers of 194 the service) and Internet Service Providers (providers of the 195 service). 197 1.3.1. Service Providers 199 The ALTO Service enables ISPs to influence the neighborhood selection 200 process of overlay networks to increase locality of traffic and also 201 regain the ability to efficiently engineer traffic that traverses 202 more expensive links such as backbone and transit links, thus 203 allowing a better provisioning of 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 and 235 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. Network Location 247 Network Location is a generic concept denoting a single endpoint or 248 group of endpoints. Whenever we say Network Location, we refer to 249 either a single endpoint or a group of endpoints. 251 2.2. ALTO Service and Protocol Scope 253 An ALTO Server conveys the network information from the perspective 254 of a network region. We say that the ALTO Server presents its "my- 255 Internet View" [12] of the network region. A network region in this 256 context can be an Autonomous System, an ISP, perhaps a smaller 257 region, or perhaps a set of ISPs; the details depend on the 258 deployment scenario and discovery mechanism. 260 To better understand the ALTO Service and the role of the ALTO 261 Protocol, we show in Figure 1 the overall system architecture. In 262 this architecture, an ALTO Client uses ALTO Service Discovery to 263 identify an appropriate ALTO Server; an ALTO Server prepares ALTO 264 Information; and the ALTO Client requests available ALTO Information 265 from the ALTO Server using the ALTO Protocol. 267 The ALTO Information provided by the ALTO Server can be updated 268 dynamically based on network conditions, or can be seen as a policy 269 which is updated at a larger time-scale. 271 More specifically, the ALTO Information provided by an ALTO Server 272 may be influenced (at the operator's discretion) by other systems. 273 Examples include (but are not limited to) static network 274 configuration databases, dynamic network information, routing 275 protocols, provisioning policies, and interfaces to outside parties. 276 These components are shown in the figure for completeness but outside 277 the scope of this specification. 279 +-------------------------------------------------------------------+ 280 | ISP | 281 | | 282 | +-----------+ | 283 | | Routing | | 284 | +--------------+ | Protocols | | 285 | | Provisioning | +-----------+ | 286 | | Policy | | | 287 | +--------------+\ | | 288 | \ | | 289 | \ | | 290 | +-----------+ \+---------+ +--------+ | 291 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 292 | |Network |.......| Server | -------------------- | Client | | 293 | |Information| +---------+ +--------+ | 294 | +-----------+ / / | 295 | / ALTO SD Query/Response / | 296 | / / | 297 | +----------+ +--------------+ | 298 | | External | | ALTO Service | | 299 | | Interface| | Discovery | | 300 | +----------+ +--------------+ | 301 | | | 302 | | Figure 1: Basic ALTO Architecture. | 303 | | | 304 +-------------------------------------------------------------------+ 305 | 306 +------------------+ 307 | Third Parties | 308 | | 309 | Content Providers| 310 +------------------+ 312 ALTO Architecture 314 3. Protocol Structure 316 The ALTO Protocol uses a simple extensible framework to convey 317 network information. In the general framework, the ALTO protocol 318 will convey properties on both Endpoints and paths between network 319 locations. 321 In this document, we focus on a particular endpoint property to 322 denote the location of an endpoint and a particular path property 323 called Path Rating to denote the ISP-defined cost of a path. 325 The ALTO Protocol is built on a common transport protocol, messaging 326 structure and encoding, and transaction model. The protocol is 327 subdivided into services of related functionality. ALTO-Core 328 provides the Map Service. Other services can provide additional 329 functionality. There are three such services defined in this 330 document: the Map Filtering Service, Endpoint Property Service, and 331 Ranking Service. Additional services may be defined in the future in 332 companion documents. 334 .-------------------------------------------------------------------. 335 | | 336 | .----------. .---------------. .---------------. .-------------. | 337 | | | | Map Filtering | | Endpont Prop. | | Ranking | | 338 | | | | Service | | Service | | Service | | 339 | | | `---------------' `---------------' `-------------' | 340 | | Server | .-------------------------------------------------. | 341 | |Capability| | Map Service | | 342 | | | | .-------------. .--------------. | | 343 | | | | | Network Map | | Cost Map | | | 344 | | | | `-------------' `--------------' | | 345 | `----------' `-------------------------------------------------' | 346 | | 347 `-------------------------------------------------------------------' 349 Figure 1: ALTO Protocol Structure 351 3.1. Server Capability 353 It lists the details on the information that can be provided by an 354 ALTO Server. The configuration includes, for example, details about 355 the operations and cost metrics supported by the ALTO Server. The 356 capability document can be downloaded by ALTO Clients or provisioned 357 into devices. 359 3.2. Services 361 3.2.1. Map Service 363 The Map Service provides batch information to ALTO Clients. Two maps 364 are provided in this document. The Network Map (See Section 4) 365 provides the full set of network location groupings defined by the 366 ALTO Server and the endpoints contained with each grouping. The Cost 367 Map (see Section 5.2.1) provides costs between the defined groupings. 369 These two maps can be thought of (and implemented as) as simple files 370 with appropriate encoding provided by the ALTO Server. 372 3.2.2. Map Filtering Service 374 Resource constrained ALTO Clients may benefit from query results 375 being filtered at the ALTO Server. This avoids an ALTO Client 376 spending network bandwidth collecting results and performing client- 377 side filtering. The Map Filtering Service allows ALTO Clients to 378 query for ALTO Server maps based on additional parameters. 380 3.2.3. Endpoint Property Service 382 This service allows ALTO Clients to look up properties for individual 383 endpoints. An example endpoint property is its network location (its 384 grouping defined by the ALTO Server) or connectivity type (e.g., 385 ADSL, Cable, or FioS). 387 3.2.4. Ranking Service 389 Some ALTO Clients may also benefit from querying for rankings and 390 costs based on endpoints. The Ranking Service allows an ALTO Server 391 to return either numerical costs or ordinal costs (rankings) for 392 additional network locations types such as Endpoints. 394 4. Network Map 396 In this section, we give more detail on the particular endpoint 397 property named PID. In the next section, we give more detail about 398 the particular path property named Path Rating. 400 In reality many endpoints are very close to one another in terms of 401 network connectivity, for example, endpoints on the same site of an 402 enterprise. By treating a group of endpoints together as a single 403 entity in ALTO, we can achieve much greater scalability without 404 loosing any critical information. 406 The Network Location endpoint property allows an ALTO Server to group 407 endpoints together to indicate their proximity. The resulting set of 408 groupings is called the ALTO Network Map. 410 The Network Map may also be used to communicate simple preferences. 411 For example, an ISP may prefer that endpoints associated with the 412 same PoP (Point-of-Presence) in a P2P application communicate locally 413 instead of communicating with endpoints in other PoPs. 415 Note that the definition of proximity varies depending on the 416 granularity of the ALTO algorithm. In one deployment, endpoints on 417 the same subnet may be considered close; while in another deployment, 418 endpoints connected to the same PoP may be considered close. 420 4.1. PID 422 Each group can be identified by a provider-defined Network Location 423 identifier called a PID. There can be many different ways of 424 grouping the endpoints and assigning PIDs. 426 Thus, a PID is a identifier providing an indirect and network- 427 agnostic way to specify a network aggregation. For example, a PID 428 may be defined (by the ALTO service provider) to denote a subnet, a 429 set of subnets, a metropolitan area, a PoP, an autonomous system, or 430 a set of autonomous systems. Aggregation of endpoints into PIDs can 431 indicate proximity. Also, aggregation can improve scalability. In 432 particular, network preferences (costs) may be specified between 433 PIDs, allowing cost information to be more compact and updated at a 434 smaller time scale than the network aggregations themselves. 436 4.2. Example Network Map 438 Figure 2 illustrates an example Network Map. PIDs are used to 439 identify network-agnostic aggregations. 441 .--------------------------------------------------------. 442 | ALTO Network Map | 443 | | 444 | .--------------------------------. .---------------. | 445 | | NetLoc: PID-1 | | NetLoc: PID-2 | | 446 | | .---------------------------. | | ... | | 447 | | | 128.36.0.0/16 | | `---------------` | 448 | | | .-----------------------. | | | 449 | | | | Endpoint: 128.36.9.8 | | | .---------------. | 450 | | | `-----------------------` | | | NetLoc: PID-3 | | 451 | | `---------------------------` | | ... | | 452 | | .---------------------------. | `---------------` | 453 | | | 130.132.0.0/16 | | | 454 | | | .-----------------------. | | .---------------. | 455 | | | | Endpoint: 130.132.1.2 | | | | NetLoc: PID-4 | | 456 | | | `-----------------------` | | | ... | | 457 | | `---------------------------` | `---------------` | 458 | `--------------------------------` | 459 | | 460 `--------------------------------------------------------` 462 Figure 2: Example Network Map 464 5. Path Rating 466 In this section we define a particular path property named Path 467 Rating. 469 5.1. Path Cost 471 Path Rating is based on Path Cost, which conveys the preference of an 472 ALTO Server on communication among Network Locations. Path Costs 473 have attributes: 475 o Type: identifies what the costs represent; 477 o Mode: identifies how the costs should be interpreted (numerical or 478 ordinal interpretation). 480 5.1.1. Cost Type 482 The Type attribute indicates what the cost represents. For example, 483 an ALTO Server could define costs representing air-miles, hop-counts, 484 or generic routing costs. 486 Cost types are indicated in protocol messages as alphanumeric 487 strings. An ALTO Server MUST at least define the routing cost type 488 denoted by the string 'routingcost'. 490 Note that an ISP may internally compute routing cost using any method 491 it chooses (including air-miles or hop-count). 493 If an ALTO Client requests a Cost Type that is not available, the 494 ALTO Server responds with an error as specified in Section 7.2.2.2. 496 5.1.2. Cost Mode 498 The Mode attribute indicates how costs should be interpreted. For 499 example, an ALTO Server could return costs that should be interpreted 500 as numerical values or ordinal rankings. 502 It is important to communicate such information to ALTO Clients, as 503 certain operations may not be valid on certain costs returned by an 504 ALTO Server. For example, it is possible for an ALTO Server to 505 return a set of IP addresses with costs indicating a ranking of the 506 IP addresses. Arithmetic operations, such as summation, that would 507 make sense for numerical values, do not make sense for ordinal 508 rankings. ALTO Clients may want to handle such costs differently. 510 Cost Modes are indicated in protocol messages as alphanumeric 511 strings. An ALTO Server MUST at least define the modes 'numerical' 512 and 'ordinal'. 514 If an ALTO Client requests a cost Mode that is not supported, the 515 ALTO Server MUST reply with costs having Mode either 'numerical' or 516 'ordinal'. Thus, an ALTO Server must implement at least one of 517 'numerical' or 'ordinal' Costs, but it may choose which to support. 518 ALTO Clients may choose how to handle such situations. Two 519 particular possibilities are to use the returned costs as-is (e.g., 520 treat numerical costs as ordinal rankings) or ignore the ALTO 521 information altogether. 523 5.2. Path Rating Query 525 The Path Rating Query consists of a Cost Type, a Cost Mode, a list of 526 Source Network Locations (note that a Network Location can be an 527 endpoint address or a PID), and a list of Destination Network 528 Locations. 530 Specifically, assume that a Path Rating query has a list of multiple 531 Source Network Locations, say [Src_1, Src_2, ..., Src_m], and a list 532 of multiple Destination Network Locations, say [Dst_1, Dst_2, ..., 533 Dst_n], then the ALTO Server will compute the Path Cost for each 534 communicating pair (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., 535 Src_m -> Dst_1, ..., Src_m -> Dst_n). 537 5.2.1. Cost Map 539 We refer to the Response containing the m*n entries as a Cost Map. 541 If the Cost Type is ordinal, the ranking of each communicating pair 542 is relative to the m*n entries. 544 5.2.2. Ranking List 546 If there is a single Source Network Location, we also say that the 547 response is a Ranking List. 549 5.2.3. Network Map and Cost Map Dependency 551 Note that if a Path Rating query contains any PID in the list of 552 Source Network Locations or the list of Destination Network 553 Locations, we say that the particular Path Rating is generated based 554 on a particular Network Map. Version Tags are introduced to ensure 555 that ALTO Clients are able to use consistent information even though 556 the 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. 606 For example, a full Network Map may be reused by all ALTO Clients 607 using the ALTO Server. 609 6.2. Message Format 611 The ALTO Protocol uses a RESTful design operating over HTTP. Both 612 Query and Response follow the standard format for HTTP Request and 613 Response messages [2] [3]. This section provides an overview of the 614 components of a Query message sent from an ALTO Client to an ALTO 615 Server, as well as the components of a Response message returned by 616 an ALTO Server. Note that if caching or redistribution is used, the 617 Response message may be returned from another (possibly third-party) 618 entity. Reuse and Redistrubution is further discussed in 619 Section 11.4. 621 6.2.1. Query Message 623 A Query message is generated by an ALTO Client and sent to an ALTO 624 Server. The ALTO Protocol employs the following components of the 625 HTTP request message: 627 Method: Indicates operation requested by the ALTO Client (along with 628 URI Path). 630 URI Path: Indicates the operation requested by the ALTO Client 631 (along with Method). 633 URI Query String Parameters: Indicates parameters for the requested 634 operation. Note that in the messaging specification in Section 7, 635 we abbreviate these as 'URI QS Params'. Order of query string 636 parameters is not specified. Some parameters are restricted in 637 how many times they appear. We use the notation 'min..max' to 638 denote the the minimum and maximum times they may appear, where 639 'max' may be '*' to denote unbounded. If no parameters are 640 defined for a particular ALTO request message, the query string 641 MUST be empty (and there MUST be no '?' included in the URI Path). 643 Headers: Indicates encoding of the Body. If the HTTP body of the 644 request is non-empty, the Content-Type header MUST be set to 645 "application/alto". 647 Body: Indicates additional request parameters that are not concisely 648 representable as Query String parameters. If no Body is defined 649 for a particular ALTO request message, the HTTP request body MUST 650 be empty. 652 6.2.2. Response Message 654 A Response message is generated by an ALTO Server, which corresponds 655 to a particular Query message. The ALTO Protocol employs the 656 following components of the HTTP Response message: 658 Status Code: Indicates either success or an error condition. 660 Headers: Indicates encoding of the Body and caching directives. If 661 the HTTP body of the response is non-empty, the Content-Type 662 header MUST be set to "application/alto" 664 Body: Contains data requested by the ALTO Client. 666 6.2.3. Query and Response Body Encoding 668 When the Body of a Query or Response message is not empty, it MUST 669 contain a properly-encoded message. This section will be updated to 670 include common requirements when an encoding format is decided. 672 7. Protocol Messaging 674 This section specifies client and server processing, as well as 675 messages in the ALTO Protocol. Details common to ALTO Server 676 processing of all messages is first discussed, followed by details of 677 the individual messages. 679 Note that the primary focus of the current draft is the architecture 680 and protocol operations, and only the structure of messages is 681 specified (without actual message encoding). Additionally, the 682 following details have been omitted for clarity: 684 o protocol version number 686 o transaction ID 688 o map version tags 690 o HTTP URL encoding 692 This section will be updated as revisions are made to protocol 693 details and encodings. 695 7.1. Client Processing 696 7.1.1. General Processing 698 The protocol is structured in such a way that independent of the 699 query type there are a set of general processing steps. The ALTO 700 Client selects a specific ALTO Server to communicate with and 701 establishes a TCP connection. The ALTO protocol on top of this TCP 702 connection MAY be secured through SSL/TLS to implement server and/or 703 client authentication. HTTP Basic or Digest authentication MAY 704 additionally be used. The client then creates and sends a query 705 message, which MUST be constructed as specified in Section 7.3. The 706 ALTO Client MUST additionally follow any HTTP encoding rules as well 707 as TCP transport considerations. 709 7.1.2. General Error Conditions 711 In the case the client does not receive an appropriate response from 712 the server it can choose another server to communicate or fall back 713 to perform peer selection without the use of ALTO information. 715 7.2. Server Processing 717 7.2.1. Successful Responses 719 If a Query message is successfully processed an an ALTO response is 720 generated, the HTTP status code in the response MUST be set to 200. 722 7.2.2. General Error Conditions 724 This section specifies ALTO Server behavior when it recevies a Query 725 message that cannot be processed due to a problem with processing the 726 Query message itself. 728 7.2.2.1. Invalid Query Format 730 If any component of the Query message is formatted incorrectly (i.e., 731 it does not follow the formats in Section 7.3), the ALTO Server MUST 732 return HTTP Status Code 400. 734 7.2.2.2. Unsupported Query 736 If an ALTO Server does not support the operation indicated in the 737 Query message, the ALTO Server MUST return HTTP Status Code 501. 739 7.2.3. Caching Parameters 741 If the response generated by the ALTO Server is cachable, the ALTO 742 Server MAY include relevant HTTP headers, enabling it to be cached by 743 existing HTTP Caches or the ALTO Client itself. 745 7.3. ALTO Queries 747 7.3.1. Server Capability 749 The Server Capability query allows an ALTO Client to determine the 750 available operations of a particular ALTO Server 752 This query MUST be supported. 754 7.3.1.1. Query 756 Method : 'GET' 757 URI Path : '/capability' 759 7.3.1.2. Example Response Structure 761 { 762 "instance-name": "alto.example.com", 763 "uri": "http:\/\/alto.example.com:6671", 764 "cost": [ 765 {"type":"latency", "units":"ms"}, 766 {"type":"pDistance","units":"scalar"}, 767 {"type":"bandwidth","units":"kbps"} 768 ], 769 "constraint-support": false 770 } 772 7.3.2. Map Service 774 The Map Service provides batch information to ALTO Clients in the 775 form of two maps: a Network Map and Cost Map. All queries in the Map 776 Service MUST be supported. 778 7.3.2.1. Network Map 780 The full Network Map is an instantiation of the Reverse Property 781 Lookup where the ALTO Server lists for each PID, the network 782 locations (endpoints) within the PID. 784 7.3.2.1.1. Query 786 Method : 'GET' 787 URI Path : '/prop/pid/map' 789 7.3.2.1.2. Example Response Structure 791 { 792 "PID1" : [ 793 "128.36.1.0/24", 794 "132.130.1.0/24", 795 "132.130.2.0/24" 796 ], 797 "PID2" : [ "130.132.3.0/24" ], 798 "PID3" : [ "0.0.0.0/0" ] 799 } 801 7.3.2.2. Cost Map 803 The full Cost Map is an instantiation of the Path Rating Query where 804 the ALTO Server lists for each pair of source/destination PID, the 805 Path Cost from the source to destination. 807 ALTO Server provides costs using the default Cost Type 808 ('routingcost') and default Cost Mode ('numerical'). 810 7.3.2.2.1. Query 812 Method : 'GET' 813 URI Path : '/cost/pid/map' 815 7.3.2.2.2. Example Response Structure 817 { 818 "Type": "routingcost", 819 "Mode": "numerical", 820 "Map" : { 821 "PID1": { "PID1": 1, "PID2": 5 , "PID3": 10 }, 822 "PID2": { "PID1": 5 , "PID2": 1 , "PID3": 15 }, 823 "PID3": { "PID1": 20, "PID2": 15, "PID3": 1 } 824 } 825 } 827 7.3.3. Map Filtering Service 829 The Map Filtering Service allows ALTO Clients to specify filtering 830 criteria to return a subset of the full maps available in the Map 831 Service. 833 The services defined in this section are OPTIONAL. 835 7.3.3.1. Network Map 837 ALTO Clients can query for a subset of the full network map (see 838 Section 7.3.2.1). 840 7.3.3.1.1. Query 842 Method : 'POST' 843 URI Path : '/prop/pid/filter' 845 7.3.3.1.2. Example Request Structure 847 POST /prop/pid/filter ... 849 [ "PID1", "PID2" ] 851 7.3.3.1.3. Example Response Structure 853 { 854 "PID1" : [ 855 "128.36.1.0/24", 856 "132.130.1.0/24", 857 "132.130.2.0/24" 858 ], 859 "PID2" : [ "130.132.3.0/24" ], 860 "PID3" : [ "0.0.0.0/0" ] 861 } 863 7.3.3.2. Cost Map 865 ALTO Clients can query for the Cost Map (see Section 7.3.2.2) based 866 on additional parameters. 868 7.3.3.2.1. Query 870 Method : 'POST' 871 URI Path : '/cost/pid/filter' 872 URI QS Params : 'type=[costtype]' (multiplicity: 0..1) 873 'mode=[costmode]' (multiplicity: 0..1) 874 'constraint=[constraint]' (multiplicity: 0..*) 876 The 'constraint' parameter is optional and is to be used only if the 877 ALTO service supports it. It allows a client to specify a target 878 numerical cost. The constraint contains two entities: (1) an 879 operator either 'gt' for greater than , 'lt' for less than or 'eq' 880 for equal to with 10 percent on either side, (2) a target numerical 881 cost. The numerical cost is a number that MUST be defined in the 882 units specified in the ALTO service configuration document obtained 883 from ALTO service discovery. If multiple 'constraint' parameters are 884 specified, the ALTO Server assumes they are related to each other 885 with a logical AND. 887 If the query does not specify the 'type' and 'mode' query string 888 parameters, then the server assumes the type to be 'routingcost' and 889 the mode to be 'numerical'. A Query MUST contain no more than one 890 'type' parameter, and no more than one 'mode' parameter. 892 The request body MAY specify a list of source PIDs, and a list of 893 destination PIDs. If a list is empty, it is interpreted by the ALTO 894 Server as the full set of PIDs. The ALTO Server returns costs 895 between each pair of source/destination PID. 897 7.3.3.2.2. Example Request Structure 899 POST /cost/pid/filter 901 { 902 "src": [ "PID1" ], 903 "dst": [ "PID1", "PID2", "PID3" ] 904 } 906 7.3.3.2.3. Example Response Structure 908 { 909 "Type": "routingcost", 910 "Mode": "numerical", 911 "Map" : { 912 "PID1": { "PID1" : 1, "PID2": 5 , "PID3": 10 }, 913 } 914 } 916 7.3.4. Endpoint Property Service 918 The Endpoint Property Lookup query allows an ALTO Client to query for 919 properties of Endpoints known to the ALTO Server. If the ALTO Server 920 provides the Endpoint Property Service, the ALTO Server MUST define 921 at least the 'pid' property for Endpoints. Additional supported 922 properties can be defined in the Server Capability response. 924 The services defined in this section are OPTIONAL. 926 7.3.4.1. Query 928 Method : 'POST' 929 URI Path : '/endpoint/m' 930 URI QS Params : 'prop=[propertyname]' (multiplicity: 1..*) 932 The request body includes a list of Endpoints for which the property 933 value should be returned. If the request body is empty, the ALTO 934 Server implicitly assumes that the request contains a single-element 935 list with the Endpoint address of the requesting client. 937 Also note that the 'prop' parameter may be specified multiple times 938 to query for multiple properties simultaneously. For example, the 939 query string could be 'prop=pid&prop=bandwidth'. 941 7.3.4.2. Example Request Structure 943 POST /endpoint/m?prop=pid ... 945 [ "ipv4:128.36.1.34" ] 947 7.3.4.3. Example Response Structure 949 { 950 "ipv4:128.36.1.34" : { "pid": "PID1" } 951 } 953 7.3.5. Ranking Service 955 The Ranking Service allows ALTO Clients to supply lists of endpoints 956 to an ALTO Server. The ALTO Server replies with costs (numerical or 957 ordinal) amongst the endpoints. 959 In particular, this service allows lists of Endpoint addresses to be 960 ranked (ordered) by an ALTO Server. 962 The services defined in this section are OPTIONAL. 964 7.3.5.1. Ranking Query 966 7.3.5.1.1. Query 968 Method : 'POST' 969 URI Path : '/cost/endpoint/ranking' 970 URI QS Params : 'type=[costtype]' (multiplicity: 0..1) 971 'mode=[costmode]' (multiplicity: 0..1) 972 'constraint=[constraint]' (multiplicity: 0..*) 974 The request body includes a list of source and destination endpoints 975 that should be assigned a cost by the ALTO Server. The 'type', 976 'mode', and 'constraint' parameters behave as specified in 977 Section 7.3.3.2. 979 The request body MUST specify a list of source Endpoints, and a list 980 of destination Endpoints. If the list of source Endpoints is empty 981 (or it is not included), the ALTO Server MUST treat it as if it 982 contained the Endpoint address of the requesting client. The list of 983 destination Endpoints MUST NOT be empty. The ALTO Server returns 984 costs between each pair of source/destination Endpoint. 986 7.3.5.1.2. Example Request Structure 988 POST /cost/endpoint/ranking?mode=ordinal ... 990 { 991 "src": "ipv4:128.30.24.2" 992 "dst": [ 993 "ipv4:128.30.24.89", 994 "ipv4:12.32.67.3", 995 "ipv4:130.132.33.4" 996 ] 997 } 999 7.3.5.1.3. Example Response Structure 1001 { 1002 "Type": "routingcost", 1003 "Mode": "ordinal", 1004 "Ranking" : { 1005 "ipv4:128.30.24.2": { 1006 "ipv4:128.30.24.89" : 1, 1007 "ipv4:130.132.33.4" : 2, 1008 "ipv4:12.32.67.3" : 3 1009 } 1010 } 1011 } 1013 8. Use Cases 1015 The sections below depict typical use cases. 1017 8.1. ALTO Client Embedded in P2P Tracker 1019 Many P2P currently-deployed P2P systems use a Tracker to manage 1020 swarms and perform peer selection. P2P trackers may currently use a 1021 variety of information to perform peer selection to meet application- 1022 specific goals. By acting as an ALTO Client, an P2P tracker can use 1023 ALTO information as an additional information source to enable more 1024 network-efficient traffic patterns and improve application 1025 performance. 1027 A particular requirement of many P2P trackers is that they must 1028 handle a large number of P2P clients. A P2P tracker can obtain and 1029 locally store ALTO information (the Network Map and Cost Map) from 1030 the ISPs containing the P2P clients, and benefit from the same 1031 aggregation of network locations done by ALTO Servers. 1033 .---------. (1) Get Network Map .---------------. 1034 | | <----------------------> | | 1035 | ALTO | | P2P Tracker | 1036 | Server | (2) Get Cost Map | (ALTO Client) | 1037 | | <----------------------> | | 1038 `---------' `---------------' 1039 ^ | 1040 (3) Get Peers | | (4) Selected Peer 1041 | v List 1042 .---------. .-----------. 1043 | Peer 1 | <-------------- | P2P | 1044 `---------' | Client | 1045 . (5) Connect to `-----------' 1046 . Selected Peers / 1047 .---------. / 1048 | Peer 50 | <------------------ 1049 `---------' 1051 Figure 3: ALTO Client Embedded in P2P Tracker 1053 Figure 3 shows an example use case where a P2P tracker is an ALTO 1054 Client and applies ALTO information when selecting peers for its P2P 1055 clients. The example proceeds as follows: 1057 1. The P2P Tracker requests the Network Map covering all PIDs from 1058 the ALTO Server using the Reverse Property Lookup query. The 1059 Network Map includes the IP prefixes contained in each PID, 1060 allowing the P2P tracker to locally map P2P clients into a PIDs. 1062 2. The P2P Tracker requests the Cost Map amongst all PIDs from the 1063 ALTO Server. 1065 3. A P2P Client joins the swarm, and requests a peer list from the 1066 P2P Tracker. 1068 4. The P2P Tracker returns a peer list to the P2P client. The 1069 returned peer list is computed based on the Network Map and Cost 1070 Map returned by the ALTO Server, and possibly other information 1071 sources. Note that it is possible that a tracker may use only 1072 the Network Map to implement hierarchical peer selection by 1073 preferring peers within the same PID and ISP. 1075 5. The P2P Client connects to the selected peers. 1077 Note that the P2P tracker may provide peer lists to P2P clients 1078 distributed across multiple ISPs. In such a case, the P2P tracker 1079 may communicate with multiple ALTO Servers. 1081 8.2. ALTO Client Embedded in P2P Client: Numerical Costs 1083 P2P clients may also utilize ALTO information themselves when 1084 selecting from available peers. It is important to note that not all 1085 P2P systems use a P2P tracker for peer discovery and selection. 1086 Furthermore, even when a P2P tracker is used, the P2P clients may 1087 rely on other sources, such as peer exchange and DHTs, to discover 1088 peers. 1090 When an P2P Client uses ALTO information, it typically queries only 1091 the ALTO Server servicing its own ISP. The my-Internet view provided 1092 by its ISP's ALTO Server can include preferences to all potential 1093 peers. 1095 .---------. (1) Get Network Map .---------------. 1096 | | <----------------------> | | 1097 | ALTO | | P2P Client | 1098 | Server | (2) Get Cost Map | (ALTO Client) | 1099 | | <----------------------> | | .---------. 1100 `---------' `---------------' <- | P2P | 1101 .---------. / | ^ ^ | Tracker | 1102 | Peer 1 | <-------------- | | \ `---------' 1103 `---------' | (3) Gather Peers 1104 . (4) Select Peers | | \ 1105 . and Connect / .--------. .--------. 1106 .---------. / | P2P | | DHT | 1107 | Peer 50 | <---------------- | Client | `--------' 1108 `---------' | (PEX) | 1109 `--------' 1111 Figure 4: ALTO Client Embedded in P2P Client 1113 Figure 4 shows an example use case where a P2P Client locally applies 1114 ALTO information to select peers. The use case proceeds as follows: 1116 1. The P2P Client requests the Network Map covering all PIDs from 1117 the ALTO Server servicing its own ISP. 1119 2. The P2P Client requests the Cost Map amongst all PIDs from the 1120 ALTO Server. The Cost Map by default specifies numerical costs. 1122 3. The P2P Client discovers peers from sources such as Peer Exchange 1123 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 1124 P2P Trackers. 1126 4. The P2P Client uses ALTO information as part of the algorithm for 1127 selecting new peers, and connects to the selected peers. 1129 8.3. ALTO Client Embedded in P2P Client: Ranking 1131 It is also possible for a P2P Client to offload the selection and 1132 ranking process to an ALTO Server. In this use case, the ALTO Client 1133 gathers a list of known peers in the swarm, and asks the ALTO Server 1134 to rank them. 1136 As in the use case using numerical costs, the P2P Client typically 1137 only queries the ALTO Server servicing its own ISP. 1139 .---------. .---------------. 1140 | | | | 1141 | ALTO | (2) Get Endpoint Ranking | P2P Client | 1142 | Server | <----------------------> | (ALTO Client) | 1143 | | | | .---------. 1144 `---------' `---------------' <- | P2P | 1145 .---------. / | ^ ^ | Tracker | 1146 | Peer 1 | <-------------- | | \ `---------' 1147 `---------' | (1) Gather Peers 1148 . (3) Connect to | | \ 1149 . Selected Peers / .--------. .--------. 1150 .---------. / | P2P | | DHT | 1151 | Peer 50 | <---------------- | Client | `--------' 1152 `---------' | (PEX) | 1153 `--------' 1155 Figure 5: ALTO Client Embedded in P2P Client: Ranking 1157 Figure 5 shows an example of this scenario. The use case proceeds as 1158 follows: 1160 1. The P2P Client discovers peers from sources such as Peer Exchange 1161 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 1162 P2P Trackers. 1164 2. The P2P Client queries the ALTO Server's Ranking Service, 1165 including discovered peers as the set of Destination Endpoints, 1166 and indicates the 'ordinal' Cost Mode. The response indicates 1167 the ranking of the candidate peers. 1169 3. The P2P Client connects to the peers in the order specified in 1170 the ranking. 1172 9. Discussions 1174 9.1. Discovery 1176 The particular mechanism by which an ALTO Client discovers its ALTO 1177 Server is an important component to the ALTO architecture and 1178 numerous techniques have been discussed [13] [14]. However, the 1179 discovery mechanism is out of scope for this document. 1181 Some ISPs have proposed the possibility of delegation, in which an 1182 ISP provides information for customer networks which do not wish to 1183 run Portal Servers themselves. A consideration for delegation is 1184 that customer networks may wish to explicitly configure such 1185 delegation. 1187 9.2. Network Address Translation Considerations 1189 At this day and age of NAT v4<->v4, v4<->v6 [15], and possibly 1190 v6<->v6[16], a protocol should strive to be NAT friendly and minimize 1191 carrying IP addresses in the payload, or provide a mode of operation 1192 where the source IP address provide the information necessary to the 1193 server. 1195 The protocol specified in this document provides a mode of operation 1196 where the source NL-ID is computed by the ALTO Server (via the 1197 Endpoint Property Lookup interface) from the source IP address found 1198 in the ALTO Client query packets. This is similar to how some P2P 1199 Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS 1200 Protocol" in [17]). 1202 The ALTO client SHOULD use the Session Traversal Utilities for NAT 1203 (STUN) [4] to determine a public IP address to use as a source NL-ID. 1204 If using this method, the host MUST use the "Binding Request" message 1205 and the resulting "XOR-MAPPED-ADDRESS" parameter that is returned in 1206 the response. Using STUN requires cooperation from a publicly 1207 accessible STUN server. Thus, the ALTO client also requires 1208 configuration information that identifies the STUN server, or a 1209 domain name that can be used for STUN server discovery. To be 1210 selected for this purpose, the STUN server needs to provide the 1211 public reflexive transport address of the host. 1213 9.3. Mapping IPs to ASNs 1215 It may be desired for the ALTO Protocol to provide ALTO information 1216 including ASNs. Thus, ALTO Clients may need to identify the ASN for 1217 a Resource Provider to determine the cost to that Resource Provider. 1219 Applications can already map IPs to ASNs using information from a BGP 1220 Looking Glass. To do so, they must download a file of about 1.5MB 1221 when compressed (as of October 2008, with all information not needed 1222 for IP to ASN mapping removed) and periodically (perhaps monthly) 1223 refresh it. 1225 Alternatively, Reverse Property Lookup query defined in this document 1226 could be extended to map ASNs into a set of IP prefixes. The 1227 mappings provided by the ISP would be both smaller and more 1228 authoritative. 1230 For simplicity of implementation, it's highly desirable that clients 1231 only have to implement exactly one mechanism of mapping IPs to ASNs. 1233 9.4. Endpoint and Path Properties 1235 An ALTO Server could make available many properties about Endpoints 1236 beyond their network location or grouping. For example, connection 1237 type, geographical location, and others may be useful to 1238 applications. The current draft focuses on network location and 1239 grouping, but the protocol may be extended to handle other Endpoint 1240 properties. 1242 9.5. P2P Peer Selection 1244 This section discusses possible approaches to peer selection using 1245 ALTO information (Network Location Identifiers and associated Costs) 1246 from an ALTO Server. Specifically, the application must select which 1247 peers to use based on this and other sources of information. With 1248 this in mind, the usage of ALTO Costs is intentionally flexible, 1249 because: 1251 Different applications may use the information differently. For 1252 example, an application that connects to just one address may have 1253 a different algorithm for selecting it than an application that 1254 connects to many. 1256 Though initial experiments have been conducted [18], more 1257 investigation is needed to identify other methods. 1259 In addition, the application might account for robustness, perhaps 1260 using randomized exploration to determine if it performs better 1261 without ALTO information. 1263 9.5.1. Client-based Peer Selection 1265 One possibility is for peer selection using ALTO costs to be done 1266 entirely by a P2P client. The following are some techniques have 1267 been proposed and/or used: 1269 o Prefer network locations with lower ordinal rankings (i.e., higher 1270 priority) [19] [8]. 1272 o Optimistically unchoking low-cost peers with higher probability 1273 [8]. 1275 9.5.2. Server-based Peer Selection 1277 Another possibility is for ALTO costs to be used by an Application 1278 Tracker (e.g., BitTorrent Tracker) when returning peer lists. The 1279 following are techniques that have been proposed and/or used: 1281 o Using bandwidth matching (e.g., at an Application Tracker) and 1282 choosing solution (within bound of optimal) with minimal network 1283 cost [18]. 1285 10. IANA Considerations 1287 This document request the registration of a new media type: 1288 "application/alto" 1290 11. Security Considerations 1292 11.1. ISPs 1294 ISPs must be cognizant of the network topology and provisioning 1295 information provided through ALTO Interfaces. ISPs should evaluate 1296 how much information is revealed and the associated risks. In 1297 particular, providing overly fine-grained information may make it 1298 easier for attackers to infer network topology. On the other hand, 1299 revealing overly coarse-grained information may not provide benefits 1300 to network efficiency or performance improvements to ALTO Clients. 1302 11.2. ALTO Clients 1304 Applications using the information must be cognizant of the 1305 possibility that the information is malformed or incorrect. Even 1306 when it is correct, its use might harm the performance. When an 1307 application concludes that it would get better performance 1308 disregarding the ALTO information, the decision to discontinue the 1309 use of ALTO information is likely best left to the user. 1311 ALTO Clients should also be cognizant of revealing Network Location 1312 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, 1313 as doing so may allow the ALTO Server to infer communication 1314 patterns. One possibility is for the ALTO Client to only rely on 1315 Network Map for PIDs and Cost Map amongst PIDs to avoid passing IP 1316 addresses of their peers to the ALTO Server. 1318 11.3. ALTO Information 1320 An ALTO Server may optionally use authentication and encryption to 1321 protect ALTO information. SSL/TLS can provide encryption as well as 1322 authentication of the client and server. HTTP Basic or Digest 1323 authentication can provide authentication of the client (combined 1324 with SSL/TLS, it can additionally provide encryption and 1325 authentication of the server). 1327 ISPs should be cognizant that encryption only protects ALTO 1328 information until it is decrypted by the intended ALTO Client. 1329 Digital Rights Management (DRM) techniques and legal agreements 1330 protecting ALTO information are outside of the scope of this 1331 document. 1333 11.4. ALTO Information Redistribution 1335 It is possible for applications to redistribute ALTO information to 1336 improve scalability. Even with such a distribution scheme, ALTO 1337 Clients obtaining ALTO information must be able to validate the 1338 received ALTO information to ensure that it was actually generated by 1339 the correct ALTO Server. Further, to prevent the ALTO Server from 1340 being a target of attack, the verification scheme must not require 1341 ALTO Clients to contact the ALTO Server to validate every set of 1342 information. 1344 Note that the redistribution scheme must additionally handle details 1345 such as ensuring ALTO Clients retrieve ALTO information from the 1346 correct ALTO Server. See [20] and [21] for further discussion. 1347 Details of a particular redistribution scheme are outside the scope 1348 of this document. 1350 To fulfill these requirements, ALTO Information meant to be 1351 redistributable contains a digital signature which includes a hash of 1352 the ALTO information signed by the ALTO Server's private key. The 1353 corresponding public key should either be part of the ALTO 1354 information itself, or it could be included in the server capability 1355 response. The public key SHOULD include the hostname of the ALTO 1356 Server and it SHOULD be signed by a trusted authority. 1358 11.5. Denial of Service 1360 ISPs should be cognizant of the workload at the ALTO Server generated 1361 by certain ALTO Queries, such as certain queries to the Map Filtering 1362 Service and Ranking Service. The Map Service allows ALTO Servers to 1363 pre-generate maps that can be useful to many ALTO Clients. 1365 12. References 1367 12.1. Normative References 1369 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1370 Levels", BCP 14, RFC 2119, March 1997. 1372 [2] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1373 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1375 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1376 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1377 HTTP/1.1", RFC 2616, June 1999. 1379 [4] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 1380 Traversal Utilities for (NAT) (STUN)", 1381 draft-ietf-behave-rfc3489bis-18 (work in progress), July 2008. 1383 12.2. Informative References 1385 [5] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, 1386 "Application-Layer Traffic Optimization (ALTO) Requirements", 1387 draft-kiesel-alto-reqs-01 (work in progress), November 2008. 1389 [6] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, "P4P: 1390 Provider Portal for P2P Applications", draft-p4p-framework-00 1391 (work in progress), November 2008. 1393 [7] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, "P4P 1394 Protocol Specification", draft-wang-alto-p4p-specification-00 1395 (work in progress), March 2009. 1397 [8] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 1398 Export Service", draft-shalunov-alto-infoexport-00 (work in 1399 progress), October 2008. 1401 [9] Das, S. and V. Narayanan, "A Client to Service Query Response 1402 Protocol for ALTO", draft-saumitra-alto-queryresponse-00 (work 1403 in progress), March 2009. 1405 [10] Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 1406 Dimensional Peer Selection Problem", 1407 draft-saumitra-alto-multi-ps-00 (work in progress), 1408 October 2008. 1410 [11] Seedorf, J. and E. Burger, "Application-Layer Traffic 1411 Optimization (ALTO) Problem Statement", 1412 draft-marocco-alto-problem-statement-04 (work in progress), 1413 February 2009. 1415 [12] Yang, Y., Popkin, L., Penno, R., and S. Shalunov, "An 1416 Architecture of ALTO for P2P Applications", 1417 draft-yang-alto-architecture-00 (work in progress), March 2009. 1419 [13] Garcia, G., Tomsu, M., and Y. Wang, "ALTO Discovery Protocols", 1420 draft-wang-alto-discovery-00 (work in progress), March 2009. 1422 [14] Song, H., Even, R., Pascual, V., and Y. Zhang, "Application- 1423 Layer Traffic Optimization (ALTO): Discover ALTO Servers", 1424 draft-song-alto-server-discovery-00 (work in progress), 1425 March 2009. 1427 [15] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 1428 Translation", draft-baker-behave-v4v6-framework-02 (work in 1429 progress), February 2009. 1431 [16] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address 1432 Translation (NAT66)", draft-mrw-behave-nat66-02 (work in 1433 progress), March 2009. 1435 [17] "Bittorrent Protocol Specification v1.0", 1436 http://wiki.theory.org/BitTorrentSpecification, 2009. 1438 [18] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A. 1439 Silberschatz., "P4P: Provider Portal for (P2P) Applications", 1440 In SIGCOMM 2008. 1442 [19] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 1443 Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00 1444 (work in progress), March 2009. 1446 [20] Yingjie, G., Alimi, R., and R. Even, "ALTO Information 1447 Redistribution", draft-gu-alto-redistribution-01 (work in 1448 progress), October 2009. 1450 [21] Stiemerling, M., "ALTO Information Redistribution Considered 1451 Harmful", draft-stiemerling-alto-info-redist-00 (work in 1452 progress), August 2009. 1454 Appendix A. Acknowledgments 1456 First, we would like to thank the following people whose input and 1457 involvement was indispensable in achieving this merged proposal: 1459 Obi Akonjang (DT Labs/TU Berlin), 1461 Saumitra M. Das (Qualcomm Inc.), 1463 Syon Ding (China Telecom), 1465 Doug Pasko (Verizon), 1467 Laird Popkin (Pando Networks), 1469 Satish Raghunath (Juniper Networks), 1471 Albert Tian (Ericsson/Redback), 1473 Yu-Shun Wang (Microsoft), 1475 David Zhang (PPLive), 1477 Yunfei Zhang (China Mobile). 1479 We would also like to thank the following additional people who were 1480 involved in the projects that contributed to this merged document: 1481 Alex Gerber (AT&T), Chris Griffiths (Comcast), Ramit Hora (Pando 1482 Networks), Arvind Krishnamurthy (University of Washington), Marty 1483 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 1484 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T), 1485 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 1486 Damien Saucez (UCL) Thomas Scholl (AT&T), Emilio Sepulveda 1487 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 1488 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 1489 (Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia 1490 Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University), 1491 Haiyong Xie (Yale University). 1493 Appendix B. Authors 1495 [[Comment.1: RFC Editor: Please move information in this section to 1496 the Authors' Addresses section at publication time.]] 1498 Stefano Previdi 1499 Cisco 1501 Email: sprevidi@cisco.com 1503 Stanislav Shalunov 1504 BitTorrent 1506 Email: shalunov@bittorrent.com 1508 Richard Woundy 1509 Comcast 1511 Richard_Woundy@cable.comcast.com 1513 Authors' Addresses 1515 Richard Alimi (editor) 1516 Yale University 1518 Email: richard.alimi@yale.edu 1520 Reinaldo Penno (editor) 1521 Juniper Networks 1522 1194 N Mathilda Avenue 1523 Sunnyvale, CA 1524 USA 1526 Email: rpenno@juniper.net 1528 Y. Richard Yang (editor) 1529 Yale University 1531 Email: yry@cs.yale.edu