idnits 2.17.1 draft-ietf-alto-protocol-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (March 4, 2010) is 5138 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 192 -- Looks like a reference, but probably isn't: 'TODO' on line 1506 ** 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) ** Obsolete normative reference: RFC 4627 (ref. '4') (Obsoleted by RFC 7158, RFC 7159) == 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 == Outdated reference: A later version (-06) exists of draft-stiemerling-alto-deployments-01 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 3 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: September 5, 2010 Juniper Networks 6 Y. Yang, Ed. 7 Yale University 8 March 4, 2010 10 ALTO Protocol 11 draft-ietf-alto-protocol-02.txt 13 Abstract 15 Networking applications today already have access to a great amount 16 of Inter-Provider network topology information. For example, views 17 of the Internet routing table are easily available at looking glass 18 servers and entirely practical to be downloaded by clients. What is 19 missing is knowledge of the underlying network topology from the ISP 20 or Content Provider (henceforth referred as Provider) point of view. 21 In other words, what a Provider prefers in terms of traffic 22 optimization -- and a way to distribute it. 24 The ALTO Service provides information such as preferences of network 25 resources with the goal of modifying network resource consumption 26 patterns while maintaining or improving application performance. 27 This document describes a protocol implementing the ALTO Service. 28 While such service would primarily be provided by the network (i.e., 29 the ISP), content providers and third parties could also operate this 30 service. Applications that could use this service are those that 31 have a choice in connection endpoints. Examples of such applications 32 are peer-to-peer (P2P) and content delivery networks. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [1]. 40 Status of this Memo 42 This Internet-Draft is submitted to IETF in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF), its areas, and its working groups. Note that 47 other groups may also distribute working documents as Internet- 48 Drafts. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 The list of current Internet-Drafts can be accessed at 56 http://www.ietf.org/ietf/1id-abstracts.txt. 58 The list of Internet-Draft Shadow Directories can be accessed at 59 http://www.ietf.org/shadow.html. 61 This Internet-Draft will expire on September 5, 2010. 63 Copyright Notice 65 Copyright (c) 2010 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 1.1. Background and Problem Statement . . . . . . . . . . . . . 5 82 1.2. Design History and Merged Proposals . . . . . . . . . . . 5 83 1.3. Solution Benefits . . . . . . . . . . . . . . . . . . . . 5 84 1.3.1. Service Providers . . . . . . . . . . . . . . . . . . 5 85 1.3.2. Applications . . . . . . . . . . . . . . . . . . . . . 6 86 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 87 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 88 2.1.1. Endpoint Address . . . . . . . . . . . . . . . . . . . 6 89 2.1.2. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 7 90 2.1.3. Network Location . . . . . . . . . . . . . . . . . . . 7 91 2.2. ALTO Service and Protocol Scope . . . . . . . . . . . . . 7 92 3. Protocol Structure . . . . . . . . . . . . . . . . . . . . . . 8 93 3.1. Server Capability . . . . . . . . . . . . . . . . . . . . 9 94 3.2. Services . . . . . . . . . . . . . . . . . . . . . . . . . 9 95 3.2.1. Map Service . . . . . . . . . . . . . . . . . . . . . 9 96 3.2.2. Map Filtering Service . . . . . . . . . . . . . . . . 10 97 3.2.3. Endpoint Property Service . . . . . . . . . . . . . . 10 98 3.2.4. Endpoint Cost Service . . . . . . . . . . . . . . . . 10 99 4. Network Map . . . . . . . . . . . . . . . . . . . . . . . . . 10 100 4.1. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 101 4.2. Example Network Map . . . . . . . . . . . . . . . . . . . 11 102 5. Cost Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 103 5.1. Cost Attributes . . . . . . . . . . . . . . . . . . . . . 12 104 5.1.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . 12 105 5.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 12 106 5.2. Cost Map Structure . . . . . . . . . . . . . . . . . . . . 13 107 5.3. Network Map and Cost Map Dependency . . . . . . . . . . . 13 108 6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14 109 6.1. Design Approach . . . . . . . . . . . . . . . . . . . . . 14 110 6.1.1. Use of Existing Infrastructure . . . . . . . . . . . . 14 111 6.1.2. ALTO Information Reuse and Redistribution . . . . . . 14 112 7. Protocol Messaging . . . . . . . . . . . . . . . . . . . . . . 15 113 7.1. Message Format . . . . . . . . . . . . . . . . . . . . . . 15 114 7.1.1. Protocol Versioning Approach . . . . . . . . . . . . . 15 115 7.1.2. Request Message . . . . . . . . . . . . . . . . . . . 16 116 7.1.3. Response Message . . . . . . . . . . . . . . . . . . . 17 117 7.2. General Processing . . . . . . . . . . . . . . . . . . . . 19 118 7.2.1. Server Responses . . . . . . . . . . . . . . . . . . . 19 119 7.2.2. Client Behavior . . . . . . . . . . . . . . . . . . . 19 120 7.3. HTTP Usage . . . . . . . . . . . . . . . . . . . . . . . . 20 121 7.3.1. Authentication and Encryption . . . . . . . . . . . . 20 122 7.3.2. Cookies . . . . . . . . . . . . . . . . . . . . . . . 20 123 7.3.3. Caching Parameters . . . . . . . . . . . . . . . . . . 20 124 7.4. ALTO Requests . . . . . . . . . . . . . . . . . . . . . . 20 125 7.4.1. Server Capability . . . . . . . . . . . . . . . . . . 21 126 7.4.2. Map Service . . . . . . . . . . . . . . . . . . . . . 23 127 7.4.3. Map Filtering Service . . . . . . . . . . . . . . . . 27 128 7.4.4. Endpoint Property Service . . . . . . . . . . . . . . 30 129 7.4.5. Endpoint Cost Service . . . . . . . . . . . . . . . . 33 130 7.5. Redistributable Responses . . . . . . . . . . . . . . . . 35 131 7.5.1. Server and Request Parameters . . . . . . . . . . . . 36 132 7.5.2. Expiration Time . . . . . . . . . . . . . . . . . . . 36 133 7.5.3. Signature . . . . . . . . . . . . . . . . . . . . . . 37 134 8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 38 135 8.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 38 136 8.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 40 137 8.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 41 138 9. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 41 139 9.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 42 140 9.2. Network Address Translation Considerations . . . . . . . . 42 141 9.3. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . 42 142 9.4. Endpoint and Path Properties . . . . . . . . . . . . . . . 43 143 9.5. P2P Peer Selection . . . . . . . . . . . . . . . . . . . . 43 144 9.5.1. Client-based Peer Selection . . . . . . . . . . . . . 43 145 9.5.2. Server-based Peer Selection . . . . . . . . . . . . . 44 146 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 147 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44 148 11.1. Privacy Considerations for ISPs . . . . . . . . . . . . . 44 149 11.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 44 150 11.3. Authentication, Integrity Protection, and Encryption . . . 45 151 11.4. ALTO Information Redistribution . . . . . . . . . . . . . 45 152 11.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 46 153 11.6. ALTO Server Access Control . . . . . . . . . . . . . . . . 47 154 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 155 12.1. Normative References . . . . . . . . . . . . . . . . . . . 47 156 12.2. Informative References . . . . . . . . . . . . . . . . . . 48 157 Appendix A. ALTO Protocol Grammar . . . . . . . . . . . . . . . . 49 158 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 49 159 Appendix C. Authors . . . . . . . . . . . . . . . . . . . . . . . 50 160 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 162 1. Introduction 164 1.1. Background and Problem Statement 166 Today, network information available to applications is mostly from 167 the view of endhosts. There is no clear mechanism to convey 168 information about the network's preferences to applications. By 169 leveraging better network-provided information, applications have 170 potential to become more network-efficient (e.g., reduce network 171 resource consumption) and achieve better application performance 172 (e.g., accelerated download rate). The ALTO Service intends to 173 provide a simple way to convey network information to applications. 175 The goal of this document is to specify a simple and unified protocol 176 that meets the ALTO requirements [7] while providing a migration path 177 for Internet Service Providers (ISP), Content Providers, and clients 178 that have deployed protocols with similar intentions (see below). 179 This document is a work in progress and will be updated with further 180 developments. 182 1.2. Design History and Merged Proposals 184 The protocol specified here consists of contributions from 186 o P4P [8], [9]; 188 o ALTO Info-Export [10]; 190 o Query/Response [11], [12]; 192 o ATTP [ATTP]. 194 o Proxidor [19]. 196 See Appendix B for a list of people that have contributed 197 significantly to this effort and the projects and proposals listed 198 above. 200 1.3. Solution Benefits 202 The ALTO Service offers many benefits to both end-users (consumers of 203 the service) and Internet Service Providers (providers of the 204 service). 206 1.3.1. Service Providers 208 The ALTO Service enables ISPs to influence the peer selection process 209 in distributed applications in order to increase locality of traffic, 210 improve user-experience, amongst others. It also helps ISPs to 211 efficiently engineer traffic that traverses more expensive links such 212 as transit and backup links, thus allowing a better provisioning of 213 the networking infrastructure. 215 1.3.2. Applications 217 Applications that use the ALTO Service can benefit in multiple ways. 218 For example, they may no longer need to infer topology information, 219 and some applications can reduce reliance on measuring path 220 performance metrics themselves. They can take advantage of the ISP's 221 knowledge to avoid bottlenecks and boost performance. 223 An example type of application is a Peer-to-Peer overlay where peer 224 selection can be improved by including ALTO information in the 225 selection process. 227 2. Architecture 229 Two key design objectives of the ALTO Protocol are simplicity and 230 extensibility. At the same time, it introduces additional techniques 231 to address potential scalability and privacy issues. Below we start 232 with an introduction to the terminology. Then we define the overall 233 architecture and how the ALTO Protocol fits into the architecture. 235 2.1. Terminology 237 We use the following terms defined in [13]: Application, Overlay 238 Network, Peer, Resource, Resource Identifier, Resource Provider, 239 Resource Consumer, Resource Directory, Transport Address, Host 240 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 241 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 242 Transit Traffic. 244 We also use the following additional terms: Endpoint Address, ASN, 245 and Network Location. 247 2.1.1. Endpoint Address 249 An endpoint address represents the communication address of an end 250 point. An endpoint address can be network-attachment based (IP 251 address) or network-attachment agnostic. Common forms of endpoint 252 addresses include IP address, MAC address, overlay ID, and phone 253 number. 255 2.1.2. ASN 257 An Autonomous System Number. 259 2.1.3. Network Location 261 Network Location is a generic concept denoting a single endpoint or 262 group of endpoints. Whenever we say Network Location, we refer to 263 either a single endpoint or a group of endpoints. 265 2.2. ALTO Service and Protocol Scope 267 An ALTO Server conveys the network information from the perspective 268 of a network region. We say that the ALTO Server presents its "my- 269 Internet View" [14] of the network region. A network region in this 270 context can be an Autonomous System, an ISP, perhaps a smaller 271 region, or perhaps a set of ISPs; the details depend on the 272 deployment scenario and discovery mechanism. 274 To better understand the ALTO Service and the role of the ALTO 275 Protocol, we show in Figure 1 the overall system architecture. In 276 this architecture, an ALTO Server prepares ALTO Information; an ALTO 277 Client uses ALTO Service Discovery to identify an appropriate ALTO 278 Server; and the ALTO Client requests available ALTO Information from 279 the ALTO Server using the ALTO Protocol. 281 The ALTO Information provided by the ALTO Server can be updated 282 dynamically based on network conditions, or can be seen as a policy 283 which is updated at a larger time-scale. 285 More specifically, the ALTO Information provided by an ALTO Server 286 may be influenced (at the operator's discretion) by other systems. 287 Examples include (but are not limited to) static network 288 configuration databases, dynamic network information, routing 289 protocols, provisioning policies, and interfaces to outside parties. 290 These components are shown in the figure for completeness but outside 291 the scope of this specification. 293 +-------------------------------------------------------------------+ 294 | ISP | 295 | | 296 | +-----------+ | 297 | | Routing | | 298 | +--------------+ | Protocols | | 299 | | Provisioning | +-----------+ | 300 | | Policy | | | 301 | +--------------+\ | | 302 | \ | | 303 | \ | | 304 | +-----------+ \+---------+ +--------+ | 305 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 306 | |Network |.......| Server | -------------------- | Client | | 307 | |Information| +---------+ +--------+ | 308 | +-----------+ / / | 309 | / ALTO SD Query/Response / | 310 | / / | 311 | +----------+ +--------------+ | 312 | | External | | ALTO Service | | 313 | | Interface| | Discovery | | 314 | +----------+ +--------------+ | 315 | | | 316 | | Figure 1: Basic ALTO Architecture. | 317 | | | 318 +-------------------------------------------------------------------+ 319 | 320 +------------------+ 321 | Third Parties | 322 | | 323 | Content Providers| 324 +------------------+ 326 ALTO Architecture 328 3. Protocol Structure 330 The ALTO Protocol uses a simple extensible framework to convey 331 network information. In the general framework, the ALTO protocol 332 will convey properties on both Endpoints and paths between network 333 locations. 335 In this document, we focus on a particular endpoint property to 336 denote the location of an endpoint, and provider-defined costs for 337 paths between pairs of network locations. 339 The ALTO Protocol is built on a common transport protocol, messaging 340 structure and encoding, and transaction model. The protocol is 341 subdivided into services of related functionality. ALTO-Core 342 provides the Map Service. Other services can provide additional 343 functionality. There are three such services defined in this 344 document: the Map Filtering Service, Endpoint Property Service, and 345 Endpoint Cost Service. Additional services may be defined in the 346 future in companion documents. Note that functionality offered in 347 different services are not totally non-overlapping (e.g., the Map 348 Service and Map Filtering Service). 350 .--------------------------------------------------------. 351 | | 352 | .----------. .-----------. .----------. .----------. | 353 | | | | Map | | Endpoint | | Endpoint | | 354 | | | | Filtering | | Property | | Cost | | 355 | | | | Service | | Service | | Service | | 356 | | | `-----------' `----------' `----------' | 357 | | Server | .-------------------------------------. | 358 | |Capability| | Map Service | | 359 | | | | .-------------. .--------------. | | 360 | | | | | Network Map | | Cost Map | | | 361 | | | | `-------------' `--------------' | | 362 | `----------' `-------------------------------------' | 363 | | 364 `--------------------------------------------------------' 366 Figure 1: ALTO Protocol Structure 368 3.1. Server Capability 370 The Server Capability Service lists the details on the information 371 that can be provided by an ALTO Server and perhaps other ALTO Servers 372 maintained by the network provider. The configuration includes, for 373 example, details about the operations and cost metrics supported by 374 the ALTO Server. The capability document can be downloaded by ALTO 375 Clients or provisioned into devices. 377 3.2. Services 379 3.2.1. Map Service 381 The Map Service provides batch information to ALTO Clients. Two maps 382 are provided in this document. The Network Map (See Section 4) 383 provides the full set of network location groupings defined by the 384 ALTO Server and the endpoints contained with each grouping. The Cost 385 Map (see Section 5) provides costs between the defined groupings. 387 These two maps can be thought of (and implemented as) as simple files 388 with appropriate encoding provided by the ALTO Server. 390 3.2.2. Map Filtering Service 392 Resource constrained ALTO Clients may benefit from query results 393 being filtered at the ALTO Server. This avoids an ALTO Client 394 spending network bandwidth or CPU collecting results and performing 395 client-side filtering. The Map Filtering Service allows ALTO Clients 396 to query for ALTO Server maps based on additional parameters. 398 3.2.3. Endpoint Property Service 400 This service allows ALTO Clients to look up properties for individual 401 endpoints. An example endpoint property is its network location (its 402 grouping defined by the ALTO Server) or connectivity type (e.g., 403 ADSL, Cable, or FioS). 405 3.2.4. Endpoint Cost Service 407 Some ALTO Clients may also benefit from querying for costs and 408 rankings based on endpoints. The Endpoint Cost Service allows an 409 ALTO Server to return either numerical costs or ordinal costs 410 (rankings) directly amongst Endpoints. 412 4. Network Map 414 In reality, many endpoints are very close to one another in terms of 415 network connectivity, for example, endpoints on the same site of an 416 enterprise. By treating a group of endpoints together as a single 417 entity in ALTO, we can achieve much greater scalability without 418 loosing critical information. 420 The Network Location endpoint property allows an ALTO Server to group 421 endpoints together to indicate their proximity. The resulting set of 422 groupings is called the ALTO Network Map. 424 The Network Map may also be used to communicate simple preferences. 425 For example, an ISP may prefer that endpoints associated with the 426 same PoP (Point-of-Presence) in a P2P application communicate locally 427 instead of communicating with endpoints in other PoPs. 429 Note that the definition of proximity varies depending on the 430 granularity of the ALTO information configured by the provider. In 431 one deployment, endpoints on the same subnet may be considered close; 432 while in another deployment, endpoints connected to the same PoP may 433 be considered close. 435 4.1. PID 437 Each group of Endpoints is identified by a provider-defined Network 438 Location identifier called a PID. There can be many different ways 439 of grouping the endpoints and assigning PIDs. 441 A PID is an identifier providing an indirect and network-agnostic way 442 to specify a network aggregation. For example, a PID may be defined 443 (by the ALTO service provider) to denote a subnet, a set of subnets, 444 a metropolitan area, a PoP, an autonomous system, or a set of 445 autonomous systems. Aggregation of endpoints into PIDs can indicate 446 proximity and can improve scalability. In particular, network 447 preferences (costs) may be specified between PIDs, allowing cost 448 information to be more compact and updated at a smaller time scale 449 than the network aggregations themselves. 451 4.2. Example Network Map 453 Figure 2 illustrates an example Network Map. PIDs are used to 454 identify network-agnostic aggregations. 456 .--------------------------------------------------------. 457 | ALTO Network Map | 458 | | 459 | .--------------------------------. .---------------. | 460 | | NetLoc: PID-1 | | NetLoc: PID-2 | | 461 | | .---------------------------. | | ... | | 462 | | | 128.36.0.0/16 | | `---------------` | 463 | | | .-----------------------. | | | 464 | | | | Endpoint: 128.36.9.8 | | | .---------------. | 465 | | | `-----------------------` | | | NetLoc: PID-3 | | 466 | | `---------------------------` | | ... | | 467 | | .---------------------------. | `---------------` | 468 | | | 130.132.0.0/16 | | | 469 | | | .-----------------------. | | .---------------. | 470 | | | | Endpoint: 130.132.1.2 | | | | NetLoc: PID-4 | | 471 | | | `-----------------------` | | | ... | | 472 | | `---------------------------` | `---------------` | 473 | `--------------------------------` | 474 | | 475 `--------------------------------------------------------` 477 Figure 2: Example Network Map 479 5. Cost Map 481 An ALTO Server indicates preferences amongst network locations in the 482 form of Path Costs. Path Costs are generic costs and can be 483 internally computed by a network provider according to its own needs. 485 An ALTO Cost Map defines Path Costs pairwise amongst sets of source 486 and destination network locations. 488 5.1. Cost Attributes 490 Path Costs have attributes: 492 o Type: identifies what the costs represent; 494 o Mode: identifies how the costs should be interpreted (numerical or 495 ordinal). 497 Certain queries for Cost Maps allow the ALTO Client to indicate the 498 desired Type and Mode. 500 5.1.1. Cost Type 502 The Type attribute indicates what the cost represents. For example, 503 an ALTO Server could define costs representing air-miles, hop-counts, 504 or generic routing costs. 506 Cost types are indicated in protocol messages as alphanumeric 507 strings. An ALTO Server MUST at least define the routing cost type 508 denoted by the string 'routingcost'. 510 Note that an ISP may internally compute routing cost using any method 511 it chooses (including air-miles or hop-count). 513 If an ALTO Client requests a Cost Type that is not available, the 514 ALTO Server responds with an error as specified in Section 7.2.1.3. 516 5.1.2. Cost Mode 518 The Mode attribute indicates how costs should be interpreted. For 519 example, an ALTO Server could return costs that should be interpreted 520 as numerical values or ordinal rankings. 522 It is important to communicate such information to ALTO Clients, as 523 certain operations may not be valid on certain costs returned by an 524 ALTO Server. For example, it is possible for an ALTO Server to 525 return a set of IP addresses with costs indicating a ranking of the 526 IP addresses. Arithmetic operations, such as summation, that would 527 make sense for numerical values, do not make sense for ordinal 528 rankings. ALTO Clients may want to handle such costs differently. 530 Cost Modes are indicated in protocol messages as alphanumeric 531 strings. An ALTO Server MUST at least define the modes 'numerical' 532 and 'ordinal'. 534 If an ALTO Client requests a Cost Mode that is not supported, the 535 ALTO Server MUST reply with costs having Mode either 'numerical' or 536 'ordinal'. Thus, an ALTO Server must implement at least one of 537 'numerical' or 'ordinal' Costs, but it may choose which to support. 538 ALTO Clients may choose how to handle such situations. Two 539 particular possibilities are to use the returned costs as-is (e.g., 540 treat numerical costs as ordinal rankings) or ignore the ALTO 541 information altogether. 543 5.2. Cost Map Structure 545 A query for a Cost Map either explicitly or implicitly includes a 546 list of Source Network Locations and a list of Destination Network 547 Locations. (Note that a Network Location can be an endpoint address 548 or a PID.) 550 Specifically, assume that a query has a list of multiple Source 551 Network Locations, say [Src_1, Src_2, ..., Src_m], and a list of 552 multiple Destination Network Locations, say [Dst_1, Dst_2, ..., 553 Dst_n]. 555 The ALTO Server will return the Path Cost for each communicating pair 556 (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., Src_m -> Dst_1, ..., 557 Src_m -> Dst_n). We refer to this structure as a Cost Map. 559 If the Cost Mode is 'ordinal', the Path Cost of each communicating 560 pair is relative to the m*n entries. 562 5.3. Network Map and Cost Map Dependency 564 If a Cost Map contains any PID in the list of Source Network 565 Locations or the list of Destination Network Locations, we say that 566 the Path Costs are generated based on a particular Network Map (which 567 defines that PID). Version Tags are introduced to ensure that ALTO 568 Clients are able to use consistent information even though the 569 information is provided in two maps. 571 A Version Tag is an opaque string associated with a Network Map 572 maintained by the ALTO Server. When the Network Map changes, the 573 Version Tag SHOULD also be changed. Possibilities for generating a 574 Version Tag included the last-modified timestamp for the Network Map, 575 or a hash of its contents. 577 A Network Map distributed by the ALTO Server includes its Version 578 Tag. A Cost Map referring to PIDs also includes the Version Tag of 579 the Network Map on which it is based. 581 One advantage of separating ALTO information into a Network Map and a 582 Cost Map is that the two components can be updated at different time 583 scales. For example, Network Maps may be stable for a longer time 584 while Cost Maps may be updated to reflect dynamic network conditions. 586 6. Protocol Overview 588 6.1. Design Approach 590 The ALTO Protocol design uses a RESTful interface with the goal of 591 leveraging current HTTP [2] [3] implementations and infrastructure. 592 ALTO messages are denoted with HTTP Content-Type "application/alto" 593 and use JSON [4] encoding. 595 These design decisions make the protocol easier to understand and 596 debug, and allows for flexible ALTO Server implementation strategies. 597 More importantly, however, this enables use of existing 598 implementations and infrastructure, and allows for simple caching and 599 redistribution of ALTO information to increase scalability. 601 6.1.1. Use of Existing Infrastructure 603 An important design consideration for the ALTO Protocol is easy 604 integration with existing applications and infrastructure. As 605 outlined above, HTTP is a natural choice. In particular, this ALTO 606 Protocol design leverages: 608 o the huge installed base of infrastructure, including HTTP caches, 610 o mature software implementations, 612 o the fact that many P2P clients already have an embedded HTTP 613 client, and 615 o authentication and encryption mechanisms in HTTP and SSL/TLS. 617 6.1.2. ALTO Information Reuse and Redistribution 619 ALTO information may be useful to a large number of applications and 620 users. Distributing ALTO information must be efficient and not 621 become a bottleneck. Therefore, the ALTO Protocol specified in this 622 document integrates with existing HTTP caching infrastructure to 623 allow reuse of ALTO information by ALTO Clients and reduce load on 624 ALTO servers. ALTO information may also be cached or redistributed 625 using application-dependent mechanisms, such as P2P DHTs or P2P file- 626 sharing. For example, a full Network Map may be reused by all ALTO 627 Clients using the ALTO Server. 629 Note that if caching or redistribution is used, the Response message 630 may be returned from another (possibly third-party) entity. Reuse 631 and Redistrubution is further discussed in Section 11.4. 633 7. Protocol Messaging 635 This section specifies client and server processing, as well as 636 messages in the ALTO Protocol. Details common to ALTO Server 637 processing of all messages is first discussed, followed by details of 638 the individual messages. 640 7.1. Message Format 642 Request and Response follow the standard format for HTTP Request and 643 Response messages [2] [3]. 645 The following subsections provide an overview of how ALTO Requests 646 and Responses are encoded in HTTP and design rationale. Details 647 common to all ALTO Request and Response message are also specified 648 here. 650 7.1.1. Protocol Versioning Approach 652 The ALTO Protocol uses a simple and clean approach to versioning that 653 permits evolution between versions even if ALTO information is being 654 served as static, pre-generated files. 656 In particular, it is assumed that a single host responding to ALTO 657 Requests implements a single protocol version. Note that virtual 658 hosting can be used if multiple protocol versions need to be 659 supported by a single physical server. 661 A common query (Server Capability, detailed in Section 7.4.1) to be 662 present in all ALTO protocol versions allows an ALTO Client to 663 discover additional ALTO Servers and the ALTO Protocol version number 664 of each. 666 This approach keeps the ALTO Server implementation free from parsing 667 and directing each request based on version number. Although ALTO 668 Requests are free from protocol version numbers, the protocol version 669 number is echoed in each ALTO Response to keep responses self- 670 contained to, for example, ease reading persisted or redistributed 671 ALTO responses. 673 This document specifies the ALTO Protocol version 1. 675 7.1.2. Request Message 677 An ALTO Request is a standard HTTP Request generated by an ALTO 678 Client, with certain components defined by the ALTO Protocol. 680 The basic syntax of an ALTO Request is: 682 / HTTP/1.1 683 Host: 685 For example: 687 GET /capability HTTP/1.1 688 Host: alto.example.com:6671 690 7.1.2.1. Standard HTTP Headers 692 The Host header MUST follow the standard rules for the HTTP 1.1 Host 693 Header. 695 The Content-Length header MUST follow the standard rules defined in 696 HTTP 1.1. 698 The Content-Type HTTP Header MUST have value "application/alto" if 699 the Body is non-empty. 701 7.1.2.2. Method and Resource 703 Next, both the HTTP Method and remainder of the URI-Path (denoted as 704 Resource) indicate the operation requested by the ALTO Client. In 705 this example, the ALTO Client is requesting basic capability 706 information from the ALTO Server. 708 7.1.2.3. Input Parameters 710 Certain operations defined by the ALTO Protocol (e.g., in the Map 711 Filtering Service) allow the ALTO Client to supply additional input 712 parameters. Such input parameters are encoded in a URI-Query-String 713 where possible and appropriate. However, due to practical 714 limitations (e.g. underlying HTTP implementations may have 715 limitations on the total length of a URI and the Query-String is 716 better-suited for simple unstructured parameters and lists), some 717 operations in the ALTO Protocol use input parameters encoded in the 718 HTTP Request Body. 720 7.1.3. Response Message 722 A Response message is a standard HTTP Response generated by an ALTO 723 Server with certain components defined by the ALTO Protocol. 725 The basic syntax of an ALTO Response is: 727 HTTP/1.1 728 Content-Length: 729 Content-Type: 731 { 732 "meta" : , 733 : 734 } 736 where the HTTP Response Body is a JSON Object with a particular 737 structure (defined below). 739 For example (corresponding to the Request example in Section 7.1.2 740 with ellipses indicating information omitted for illustration 741 clarity): 743 HTTP/1.1 200 OK 744 Content-Length: 1000 745 Content-Type: application/alto 747 { 748 "meta" : { 749 "version": 1 750 ... 751 }, 752 "capability" : { 753 ... 754 } 755 } 757 7.1.3.1. Standard HTTP Headers 759 The Content-Length header MUST follow the standard rules defined in 760 HTTP 1.1. 762 The Content-Type HTTP Header MUST have value "application/alto" if 763 the Body is non-empty. 765 7.1.3.2. Status Code and Message 767 The HTTP Status Code MUST indicate success or an appropriate error 768 condition using standard HTTP Status Codes. The HTTP Status Message 769 MUST follow the standard rules in HTTP 1.1. 771 Since the ALTO Protocol is designed as a straightforward use of HTTP 772 to retrieve ALTO information from a server, only HTTP Status codes 773 are needed. [[Comment.1: This can be changed if a need for different 774 application-layer status codes arises.]] 776 7.1.3.3. HTTP Body 778 The Response body MUST encode a single top-level JSON object. This 779 JSON object has distinct sections for 781 o Encoding meta information in an extensible way, and 783 o Encoding the requested ALTO Information. 785 7.1.3.3.1. Meta Information 787 The top-level JSON object MUST at least have a member named "meta" 788 with a JSON Object of type for encoding meta 789 information about the Response. 791 MUST contain at least a member with name "version" and 792 integer value specifying the ALTO Protocol version. 794 Section 7.5 is an example usage of additional meta information that 795 can accompany ALTO information. 797 7.1.3.3.2. ALTO Information 799 If the Response is successful (i.e., HTTP status code is 2xx), then 800 the top-level JSON object MUST contain a second member detailing the 801 requested ALTO information. The name and value of this member are 802 Response-specific and are detailed later in this section for each 803 particular ALTO Response. 805 7.1.3.4. Signature 807 An ALTO Server may additionally supply a signature asserting that it 808 generated a particular response. In order to allow the signature to 809 be computed over the entire response message, the signature itself is 810 specified in an HTTP Header or Trailer (see Section 7.5.3). 812 7.2. General Processing 814 The protocol is structured in such a way that, independent of the 815 query type, there are a set of general processing steps. The ALTO 816 Client selects a specific ALTO Server with which to communicate, 817 establishes a TCP connection, and constructs and sends ALTO Request 818 messages which MUST conform to Section 7.4. In response to Request 819 messages, an ALTO Server constructs and sends ALTO Response messages 820 which also MUST conform to Section 7.4. 822 7.2.1. Server Responses 824 7.2.1.1. Successful Request 826 If a Request message is successfully processed and the requested ALTO 827 information returned by the ALTO Server, the HTTP status code in the 828 Response MUST be set to a valid 2xx HTTP status code. 830 7.2.1.2. Invalid Request Format 832 If any component of the Request message is formatted incorrectly 833 (i.e., it does not follow Section 7.4), the ALTO Server MUST return 834 HTTP Status Code 400. 836 7.2.1.3. Unsupported Request 838 If an ALTO Server does not support the operation indicated in the 839 Request message, the ALTO Server MUST return HTTP Status Code 501. 841 7.2.2. Client Behavior 843 7.2.2.1. Successful Response 845 This specification does not indicate any required actions taken by 846 ALTO Clients upon receiving a successful response from an ALTO 847 Server. Although ALTO Clients are suggested to interpret the 848 received ALTO Information and adapt application behavior, ALTO 849 Clients may also choose to ignore the received information. 851 7.2.2.2. Error Conditions 853 If an ALTO Client does not receive a successful response from the 854 ALTO Server, it can either choose another server or fall back to a 855 default behavior (e.g., perform peer selection without the use of 856 ALTO information). 858 7.3. HTTP Usage 860 7.3.1. Authentication and Encryption 862 An ALTO Server MAY support SSL/TLS to implement server and/or client 863 authentication, as well as encryption. 865 An ALTO Server MAY support HTTP Digest authentication. 867 7.3.2. Cookies 869 Cookies MUST NOT be used. 871 7.3.3. Caching Parameters 873 If the Response generated by the ALTO Server is cachable, the ALTO 874 Server MAY include 'Cache-Control' and 'Expires' HTTP headers. 876 If a Response generated by the ALTO Server is not cachable, the ALTO 877 Server MUST specify the "Cache-Control: no-cache" HTTP Header. 879 7.4. ALTO Requests 881 This section documents the individual operations supported in the 882 ALTO Protocol. See Section 7.1.2 and Section 7.1.3 for 883 specifications of HTTP Request/Response components common to all 884 operations in the ALTO Protocol. 886 Table 1 provides an summary of the HTTP Method and URI-Paths used for 887 ALTO Requests: 889 +-------------------+-------------+----------------------------+ 890 | Service | Operation | HTTP Method and URI-Path | 891 +-------------------+-------------+----------------------------+ 892 | Server Capability | Lookup | GET /capability | 893 | | | | 894 | Map | Network Map | GET /map/core/pid/net | 895 | Map | Cost Map | GET /map/core/cost | 896 | | | | 897 | Map Filtering | Network Map | POST /map/filter/pid/net | 898 | Map Filtering | Cost Map | POST /map/filter/pid/cost | 899 | | | | 900 | Endpoint Prop. | Lookup | GET /endpoint/prop/ | 901 | | | POST /endpoint/prop/lookup | 902 | | | | 903 | Endpoint Cost | Lookup | POST /endpoint/cost/lookup | 904 +-------------------+-------------+----------------------------+ 905 Table 1: Overview of ALTO Requests 907 7.4.1. Server Capability 909 The Server Capability request allows an ALTO Client to determine the 910 functionality supported by a particular ALTO Server and references to 911 additional ALTO Servers provided by the ALTO Service Provider. 913 This operation MUST be supported by the ALTO Server. 915 7.4.1.1. Request Syntax 917 GET /capability HTTP/1.1 918 Host: 920 7.4.1.2. Response Syntax 922 HTTP/1.1 200 923 Content-Length: 924 Content-Type: application/alto 926 { 927 "meta" : , 928 "capability" : { 929 "server-list" : [ 930 { 931 "uri" : , 932 "version" : , 933 "services" : , 934 "cost-types" : , 935 "cost-constraints" : 936 }, 937 ... 938 ], 939 "self" : { 940 "certificate" : 941 } 942 } 943 } 945 for this Response is the JSON String "capability" and 946 is a JSON Object with REQUIRED members: 948 o server-list: JSON Array of available ALTO Servers, and the ALTO 949 Protocol version and basic capabilities provided by each server. 951 o self: JSON Object encoding additional details about the ALTO 952 Server itself. 954 Each element of the "server-list" is a JSON object with the following 955 REQUIRED members: 957 o uri: Denotes the base HTTP URI for the ALTO Server. For example, 958 "http://alto-v1.example.com:6671" 960 o version: Denotes the protocol version implemented by the ALTO 961 Server. 963 o services: Lists the services supported by the ALTO Server. The 964 service names defined in this document are are "map", "map- 965 filtering", "endpoint-property", and "endpoint-cost". 967 and OPTIONAL members: 969 o cost-types: Array of CostTypeObj JSON Objects where each 970 CostTypeObj MUST have a "type" member with a JSONString value 971 denoting the name of the cost type and a "units" member with a 972 JSONString value denoting the units in which the ALTO Server 973 returns this cost type. 975 o const-constraints: Indicates if the ALTO Server supports cost 976 constraints. The value 'false' is implied if this member is not 977 present. 979 The "self" JSON Object has the following OPTIONAL members: 981 o certificate: PEM-encoded X.509 certificate used by the ALTO Server 982 to sign distributed information (see Section 7.5). 984 7.4.1.3. Example 986 GET /capability HTTP/1.1 987 Host: alto.example.com:6671 988 HTTP/1.1 200 OK 989 Content-Length: [TODO] 990 Content-Type: application/alto 992 { 993 "meta" : { 994 "version" : 1 995 }, 996 "capability" : { 997 "server-list" : [ 998 { 999 "uri": "http://alto.example.com:6671", 1000 "version" : 1, 1001 "services" : [ "map", "map-filtering" ], 1002 "cost-types": [ 1003 { "type":"latency", "units":"ms" }, 1004 { "type":"pDistance", "units":"scalar" }, 1005 { "type":"bandwidth", "units":"kbps" } 1006 ], 1007 "cost-constraints": false 1008 } 1009 ] 1010 } 1011 } 1013 7.4.2. Map Service 1015 The Map Service provides batch information to ALTO Clients in the 1016 form of two maps: a Network Map and Cost Map. All Requests in the Map 1017 Service MUST be supported. 1019 An ALTO Server MUST support the Map Service and MUST implement all 1020 operations defined in this section. 1022 7.4.2.1. Network Map 1024 The full Network Map lists for each PID, the network locations 1025 (endpoints) within the PID. 1027 7.4.2.1.1. Request Syntax 1029 GET /map/core/pid/net HTTP/1.1 1030 Host: 1032 7.4.2.1.2. Response Syntax 1034 HTTP/1.1 200 1035 Content-Length: 1036 Content-Type: application/alto 1038 { 1039 "meta" : , 1040 "network-map": { 1041 "map-vtag" : , 1042 "map" : { 1043 : , 1044 ..., 1045 : 1046 } 1047 } 1048 } 1050 for this Response is the JSON String "network-map" and 1051 is a JSON Object with REQUIRED members: 1053 o map-vtag: The Version Tag of the Network Map (Section 5.3) 1055 o map: a JSON Object with each member representing a PID and its 1056 associated set of IP Prefixes. A member's name denotes the PID's 1057 name as JSON String, and the member's value is a JSON Array of 1058 JSON Strings, with each string representing the IP Prefix in CIDR 1059 notation. 1061 7.4.2.1.3. Example 1063 GET /map/core/pid/net HTTP/1.1 1064 Host: alto.example.com:6671 1065 HTTP/1.1 200 OK 1066 Content-Length: [TODO] 1067 Content-Type: application/alto 1069 { 1070 "meta" : { 1071 "version" : 1 1072 }, 1073 "network-map" : { 1074 "map-vtag" : "1266506139", 1075 "map" : { 1076 "PID1" : [ 1077 "128.36.1.0/24", 1078 "132.130.1.0/24", 1079 "132.130.2.0/24" 1080 ], 1081 "PID2" : [ 1082 "130.132.3.0/24" 1083 ], 1084 "PID3" : [ 1085 "0.0.0.0/0" 1086 ] 1087 } 1088 } 1089 } 1091 7.4.2.2. Cost Map 1093 The Map Service Cost Map query is a batch operation in which the ALTO 1094 Server returns the Path Cost for each pair of source/destination PID 1095 defined by the ALTO Server. 1097 The ALTO Server provides costs using the default Cost Type 1098 ('routingcost') and default Cost Mode ('numerical'). 1100 7.4.2.2.1. Request Syntax 1102 GET /map/core/pid/cost HTTP/1.1 1103 Host: 1105 7.4.2.2.2. Response Syntax 1107 HTTP/1.1 200 1108 Content-Length: 1109 Content-Type: application/alto 1111 { 1112 "meta" : , 1113 "cost-map": { 1114 "map-vtag" : , 1115 "cost-type" : , 1116 "cost-mode" : , 1117 "map" : { 1118 : { 1119 : , 1120 ... 1121 : 1122 }, 1123 ..., 1124 : { 1125 : , 1126 ... 1127 : 1128 } 1129 } 1130 } 1131 } 1133 for this Response is the JSON String "cost-map" and 1134 is a JSON Object with REQUIRED members: 1136 o map-vtag: The Version Tag of the Network Map used to generate the 1137 Cost Map (Section 5.3) 1139 o cost-type: Cost Type used in the map (Section 5.1.1) 1141 o cost-mode: Cost Mode used in the map (Section 5.1.2) 1143 o map: a JSON Object with each member representing a vector of costs 1144 from a Source PID to a set of Destination PIDs (Section 5.2). A 1145 member's name denotes the Source PID's name, and a member's value 1146 is itself a JSON Object with members representing the cost to each 1147 destination PID. 1149 7.4.2.2.3. Example 1151 GET /map/core/pid/cost HTTP/1.1 1152 Host: alto.example.com:6671 1154 HTTP/1.1 200 OK 1155 Content-Length: [TODO] 1156 Content-Type: application/alto 1158 { 1159 "meta" : { 1160 "version" : 1 1161 }, 1162 "cost-map" : { 1163 "map-vtag" : "1266506139", 1164 "cost-type" : "routingcost", 1165 "cost-mode" : "numerical", 1166 "map" : { 1167 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 1168 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 1169 "PID3": { "PID1": 20, "PID2": 15, "PID3": 1 } 1170 } 1171 } 1172 } 1174 7.4.3. Map Filtering Service 1176 The Map Filtering Service allows ALTO Clients to specify filtering 1177 criteria to return a subset of the full maps available in the Map 1178 Service. 1180 An ALTO Server MAY support the Map Filtering Service. If an ALTO 1181 Server supports the Map Filtering Service, all operations defined in 1182 this section MUST be implemented. 1184 7.4.3.1. Network Map 1186 ALTO Clients can query for a subset of the full network map (see 1187 Section 7.4.2.1). 1189 7.4.3.1.1. Request Syntax 1191 POST /map/filter/pid/net HTTP/1.1 1192 Host: 1193 Content-Length: 1195 1197 The Body of the request is a JSON Array of the PIDs (each is a JSON 1198 String) to be included in the resulting Network Map. 1200 7.4.3.1.2. Response Syntax 1202 The Response syntax is identical to that of the Map Service's Network 1203 Map Response (Section 7.4.2.1.2). 1205 The ALTO Server MUST only include PIDs in the Response that were 1206 specified in the Request. If the Request contains a PID name that is 1207 not currently defined by the ALTO Server, the ALTO Server MUST behave 1208 as if the PID did not appear in the request. 1210 7.4.3.1.3. Example 1212 POST /map/filter/pid/net HTTP/1.1 1213 Host: alto.example.com:6671 1214 Content-Length: 1216 [ "PID1", "PID2" ] 1218 HTTP/1.1 200 OK 1219 Content-Length: [TODO] 1220 Content-Type: application/alto 1222 { 1223 "meta" : { 1224 "version" : 1 1225 }, 1226 "network-map" : { 1227 "map-vtag" : "1266506139", 1228 "map" : { 1229 "PID1" : [ 1230 "128.36.1.0/24", 1231 "132.130.1.0/24", 1232 "132.130.2.0/24" 1233 ], 1234 "PID2" : [ 1235 "130.132.3.0/24" 1236 ] 1237 } 1238 } 1239 } 1241 7.4.3.2. Cost Map 1243 ALTO Clients can query for the Cost Map (see Section 7.4.2.2) based 1244 on additional parameters. 1246 7.4.3.2.1. Request Syntax 1248 POST /map/filter/pid/cost? HTTP/1.1 1249 Host: 1251 { 1252 "src" : , 1253 "dst" : 1254 } 1256 where the Query String may contain the following parameters: 1258 o type: The requested Cost Type (Section 5.1.1). If not specified, 1259 the default value is "routingcost". This parameter MUST NOT be 1260 specified multiple times. 1262 o mode: The requested Cost mode (Section 5.1.2). If not specified, 1263 the default value is "numerical". This parameter MUST NOT be 1264 specified multiple times. 1266 o constraint: Defines a constraint on which elements of the Cost Map 1267 are returned. This parameter MUST NOT be used if the Server 1268 Capability Response (Section 7.4.1) indicates that constraint 1269 support is not available. A constraint contains two entities 1270 separated by whitespace (before URL encoding): (1) an operator 1271 either 'gt' for greater than , 'lt' for less than or 'eq' for 1272 equal to with 10 percent on either side, (2) a target numerical 1273 cost. The numerical cost is a number that MUST be defined in the 1274 units specified in the Server Capability Response. If multiple 1275 'constraint' parameters are specified, the ALTO Server assumes 1276 they are related to each other with a logical AND. If no 1277 'constraint' parameters are specified, then the ALTO Server 1278 returns the full Cost Map. 1280 The Request body MAY specify a list of Source PIDs, and a list of 1281 Destination PIDs. The lists are included as members of a single JSON 1282 Object, with values being an array of PIDs (each PID being a JSON 1283 String). If a list is empty, it is interpreted by the ALTO Server as 1284 the full set of currently-defined PIDs. The ALTO Server returns 1285 costs between each pair of source/destination PID. If the Request 1286 body is empty, both lists are interpreted to be empty. 1288 7.4.3.2.2. Response Syntax 1290 The Response syntax is identical to that of the Map Service's Cost 1291 Map Response (Section 7.4.2.2.2). 1293 If the Request contains a PID name that is not currently defined by 1294 the ALTO Server, the ALTO Server MUST behave as if the PID did not 1295 appear in the request. 1297 7.4.3.2.3. Example 1299 POST /map/filter/pid/cost?type=hopcount HTTP/1.1 1300 Host: alto.example.com:6671 1302 { 1303 "src" : [ "PID1" ], 1304 "dst" : [ "PID1", "PID2", "PID3" ] 1305 } 1307 HTTP/1.1 200 OK 1308 Content-Length: [TODO] 1309 Content-Type: application/alto 1311 { 1312 "meta" : { 1313 "version" : 1 1314 }, 1315 "cost-map" : { 1316 "map-vtag" : "1266506139", 1317 "cost-type" : "hopcount", 1318 "cost-mode" : "numerical", 1319 "map" : { 1320 "PID1": { "PID1": 0, "PID2": 1, "PID3": 2 } 1321 } 1322 } 1323 } 1325 7.4.4. Endpoint Property Service 1327 The Endpoint Property Lookup query allows an ALTO Client to lookup 1328 properties of Endpoints known to the ALTO Server. If the ALTO Server 1329 provides the Endpoint Property Service, the ALTO Server MUST define 1330 at least the 'pid' property for Endpoints. [TODO: Additional 1331 supported properties can be defined in the Server Capability 1332 response.] 1334 An ALTO Server MAY support the Endpoint Property Service. If an ALTO 1335 Server supports the Endpoint Property Service, all operations defined 1336 in this section MUST be implemented. 1338 7.4.4.1. Endpoint Property Lookup 1340 7.4.4.1.1. Request Syntax 1342 POST /endpoint/prop/lookup? HTTP/1.1 1343 Host: 1344 Content-Length: 1346 1348 where the Query String may contain the following parameters: 1350 o prop: The requested property type. This parameter MUST be 1351 specified at least once, and MAY be specified multiple times 1352 (e.g., to query for multiple different properties at once). 1354 and >Endpoint> is an IPv4 address or IPv6 address. 1356 An alternate syntax is supported for the case when properties are 1357 requested for a single endpoint: 1359 GET /endpoint/prop/? HTTP/1.1 1360 Host: 1362 where the Query String and >Endpoint> are the same as in the first 1363 form. 1365 7.4.4.1.2. Response Syntax 1367 HTTP/1.1 200 1368 Content-Length: 1369 Content-Type: application/alto 1371 { 1372 "meta" : , 1373 "endpoint-properties": { 1374 : { 1375 : , 1376 ... 1377 : 1378 }, 1379 ..., 1380 : { 1381 : , 1382 ... 1383 : 1384 } 1385 } 1386 } 1388 for this Response is the JSON String "endpoint-properties" 1389 and is a JSON Object with one member for each >Endpoint> 1390 included in the Request. Each such member includes one name/value 1391 pair for each requested property, where both the name and value are 1392 JSON Strings. If the ALTO Server does not define a requested 1393 property for an particular endpoint, then it MUST omit it from the 1394 Response for only that endpoint. 1396 7.4.4.1.3. Example 1398 POST /endpoint/prop/lookup?prop=pid HTTP/1.1 1399 Host: alto.example.com:6671 1400 Content-Length: [TODO] 1402 [ "128.36.1.34", "132.130.4.53" ] 1404 HTTP/1.1 200 OK 1405 Content-Length: [TODO] 1406 Content-Type: application/alto 1408 { 1409 "meta" : , 1410 "endpoint-properties": { 1411 "128.36.1.34" : { "pid": "PID1" }, 1412 "132.130.4.53" : { "pid": "PID2" } 1413 } 1414 } 1416 7.4.5. Endpoint Cost Service 1418 The Endpoint Cost Service allows ALTO Clients to directly supply 1419 endpoints to an ALTO Server. The ALTO Server replies with costs 1420 (numerical or ordinal) amongst the endpoints. 1422 In particular, this service allows lists of Endpoint addresses to be 1423 ranked (ordered) by an ALTO Server. 1425 An ALTO Server MAY support the Endpoint Cost Service. If an ALTO 1426 Server supports the Endpoint Cost Service, all operations defined in 1427 this section MUST be implemented. 1429 7.4.5.1. Endpoint Cost Lookup 1431 7.4.5.1.1. Request Syntax 1433 POST /endpoint/cost/lookup? HTTP/1.1 1434 Host: 1435 Content-Length: 1437 { 1438 "src" : , 1439 "dst" : 1440 } 1442 The request body includes a list of source and destination endpoints 1443 that should be assigned a cost by the ALTO Server. The allowed Query 1444 String parameters are defined identically to Section 7.4.3.2. 1446 The request body MUST specify a list of source Endpoints, and a list 1447 of destination Endpoints, using a similar structure to 1448 Section 7.4.3.2. If the list of source Endpoints is empty (or it is 1449 not included), the ALTO Server MUST treat it as if it contained the 1450 Endpoint address of the requesting client. The list of destination 1451 Endpoints MUST NOT be empty. The ALTO Server returns costs between 1452 each pair of source/destination Endpoint. 1454 7.4.5.1.2. Response Syntax 1456 HTTP/1.1 200 1457 Content-Length: 1458 Content-Type: application/alto 1460 { 1461 "meta" : , 1462 "endpoint-cost-map" : { 1463 "cost-type" : , 1464 "cost-mode" : , 1465 "map" : { 1466 : { 1467 : , 1468 ... 1469 : 1470 }, 1471 ..., 1472 : { 1473 : , 1474 ... 1475 : 1476 } 1477 } 1478 } 1479 } 1481 for this Response is the JSON String "endpoint-cost-map" 1482 and is a JSON Object with REQUIRED members: 1484 o cost-type: Cost Type used in the map (Section 5.1.1) 1486 o cost-mode: Cost Mode used in the map (Section 5.1.2) 1488 o map: a JSON Object with each member representing a vector of costs 1489 from a Source Endpoint to a set of Destination Endpoints 1490 (Section 5.2). A member's name denotes the Source Endpoint's 1491 name, and a member's value is itself a JSON Object with members 1492 representing the cost to each destination Endpoint. 1494 7.4.5.1.3. Example 1496 POST /endpoint/cost/m?mode=ordinal HTTP/1.1 1497 Host: alto.example.com:6671 1498 Content-Length: [TODO] 1500 { 1501 "src": [ "128.30.24.2" ], 1502 "dst": [ "128.30.24.89", "12.32.67.3", "130.132.33.4" ] 1503 } 1505 HTTP/1.1 200 OK 1506 Content-Length: [TODO] 1507 Content-Type: application/alto 1509 { 1510 "meta" : { 1511 "version" : 1 1512 }, 1513 "endpoint-cost-map" : { 1514 "cost-type" : "routingcost", 1515 "cost-mode" : "ordinal", 1516 "map" : { 1517 "128.30.24.2": { 1518 "128.30.24.89" : 1, 1519 "130.132.33.4" : 2, 1520 "12.32.67.3" : 3 1521 } 1522 } 1523 } 1524 } 1526 7.5. Redistributable Responses 1528 An ALTO Server MAY indicate that a response is suitable for 1529 redistribution by including a "redistribution" JSON object in the 1530 of an ALTO Response message: 1532 { 1533 "meta" : { 1534 ... 1535 "redistribution" : { 1536 "server" : , 1537 "request-uri" : , 1538 "request-body" : , 1539 "expires" : 1540 } 1541 }, 1542 ... 1543 } 1545 If an ALTO Server indicates the that the response is redistributable, 1546 the Response message MUST satisfy all requirements in this section. 1548 7.5.1. Server and Request Parameters 1550 The ALTO Server generating the response indicates its own address and 1551 any input parameters used to generate the response. This allows ALTO 1552 Clients to which the information is distributed to understand the 1553 context of the query and interpret the results. This information is 1554 encoded in members of the redistribution JSON Object. 1556 The 'server' member is REQUIRED and MUST have a value equal to the 1557 ALTO Server's hostname and port, in a format identical to the HTTP 1558 1.1 Host header. 1560 The 'request-uri' member is REQUIRED and MUST specify the HTTP 1561 Request-URI that was passed in the HTTP Request. 1563 If the HTTP Request body was non-empty, the 'request-body' member 1564 MUST specify full JSON value passed in the HTTP Request (note that 1565 whitespace may differ, as long as the JSON Value is identical). If 1566 the HTTP Request was empty, then the 'request-body' MUST NOT be 1567 included. 1569 Note that information about ALTO Client performing the Request and 1570 any HTTP Headers passed in the request are not included. If any such 1571 information or headers influence the response generated by the ALTO 1572 Server, the response SHOULD NOT be indicated as redistributable. 1574 7.5.2. Expiration Time 1576 ALTO Responses marked as redistributable SHOULD indicate a time after 1577 which the information is considered stale and should be refreshed 1578 from the ALTO Server (or possibly another ALTO Client). 1580 The 'expires' element is RECOMMENDED and, if present, MUST specify a 1581 time in UTC formatted according to [5]. 1583 If an expiration time is present, the ALTO Server SHOULD ensure that 1584 it is reasonably consistent with the expiration time that would be 1585 computed by HTTP header fields. If the expiration time in the 1586 'expires' element is earlier, some ALTO Clients may refresh data from 1587 the ALTO Server earlier than expected. If the expiration time 1588 included in the response body is later, some ALTO Clients may refresh 1589 the data later than expected. 1591 7.5.3. Signature 1593 ALTO Responses marked as redistributable MUST include a signature 1594 used to assert that the ALTO Server Provider generated the ALTO 1595 Information. 1597 Verification of the signature requires the ALTO Client to retrieve 1598 the ALTO Server's public key. There are multiple possibilities to 1599 retrieve it: 1601 o SSL/TLS connection with the ALTO Server: The public key algorithm 1602 and public key may be retrieved from the ALTO Server's X.509 1603 Certificate used on an HTTPS connection between the ALTO Server 1604 and ALTO Client. 1606 o Included in ALTO Server's Server Capability Response: If the ALTO 1607 Client requests from the ALTO Server over a non SSL/TLS 1608 connection, an X.509 certificate (including the public key and 1609 public key algorithm) can be included in the Server Capability 1610 Response. 1612 To reduce requirements on the underlying transport (i.e., requiring 1613 SSL/TLS), the ALTO Protocol uses the latter option. Thus, if an ALTO 1614 Server marks any Response as redistributable, the Server Capability 1615 Response MUST include a PEM-encoded X.509 certificate. This 1616 specification does not mandate any requirements on the X.509 1617 certificate (other than consistency between its public key and the 1618 signature in redistributable ALTO Responses), but ALTO Clients SHOULD 1619 verify that the certificate satisfies any local policies (e.g., 1620 Issuer, expiration date, etc). 1622 The ALTO Server may include the Hash Algorithm, Signature Algorithm, 1623 and Signature in either HTTP Headers or Trailers. Headers may be 1624 useful if Responses are pre-generated, while Trailers may be useful 1625 if Responses are dynamically generated (e.g., to avoid buffering 1626 large responses in memory while the hash value is computed). 1628 The following HTTP Headers (the ALTO Server MAY specify them as HTTP 1629 Trailers) are used to encode the Signature parameters: 1631 X-ALTO-HashAlgorithm: 1632 X-ALTO-SignatureAlgorithm: 1633 X-ALTO-SignatureDigest: 1635 where and are an integer values 1636 from the IANA TLS HashAlgorithm and SignatureAlgorithm registries, 1637 and is the corresponding PEM-encoded signature. 1639 ALTO Clients SHOULD pass the ALTO Server Certificate, Signature, and 1640 Signature Algorithm along with the body of the ALTO Response. The 1641 mechanism for redistributing such information is not specified by the 1642 ALTO Protocol, but one possibility is to add additional messages or 1643 fields to the application's native protocol. 1645 8. Use Cases 1647 The sections below depict typical use cases. 1649 8.1. ALTO Client Embedded in P2P Tracker 1651 Many P2P currently-deployed P2P systems use a Tracker to manage 1652 swarms and perform peer selection. P2P trackers may currently use a 1653 variety of information to perform peer selection to meet application- 1654 specific goals. By acting as an ALTO Client, an P2P tracker can use 1655 ALTO information as an additional information source to enable more 1656 network-efficient traffic patterns and improve application 1657 performance. 1659 A particular requirement of many P2P trackers is that they must 1660 handle a large number of P2P clients. A P2P tracker can obtain and 1661 locally store ALTO information (the Network Map and Cost Map) from 1662 the ISPs containing the P2P clients, and benefit from the same 1663 aggregation of network locations done by ALTO Servers. 1665 .---------. (1) Get Network Map .---------------. 1666 | | <----------------------> | | 1667 | ALTO | | P2P Tracker | 1668 | Server | (2) Get Cost Map | (ALTO Client) | 1669 | | <----------------------> | | 1670 `---------' `---------------' 1671 ^ | 1672 (3) Get Peers | | (4) Selected Peer 1673 | v List 1674 .---------. .-----------. 1675 | Peer 1 | <-------------- | P2P | 1676 `---------' | Client | 1677 . (5) Connect to `-----------' 1678 . Selected Peers / 1679 .---------. / 1680 | Peer 50 | <------------------ 1681 `---------' 1683 Figure 3: ALTO Client Embedded in P2P Tracker 1685 Figure 3 shows an example use case where a P2P tracker is an ALTO 1686 Client and applies ALTO information when selecting peers for its P2P 1687 clients. The example proceeds as follows: 1689 1. The P2P Tracker requests the Network Map covering all PIDs from 1690 the ALTO Server using the Network Map query. The Network Map 1691 includes the IP prefixes contained in each PID, allowing the P2P 1692 tracker to locally map P2P clients into a PIDs. 1694 2. The P2P Tracker requests the Cost Map amongst all PIDs from the 1695 ALTO Server. 1697 3. A P2P Client joins the swarm, and requests a peer list from the 1698 P2P Tracker. 1700 4. The P2P Tracker returns a peer list to the P2P client. The 1701 returned peer list is computed based on the Network Map and Cost 1702 Map returned by the ALTO Server, and possibly other information 1703 sources. Note that it is possible that a tracker may use only 1704 the Network Map to implement hierarchical peer selection by 1705 preferring peers within the same PID and ISP. 1707 5. The P2P Client connects to the selected peers. 1709 Note that the P2P tracker may provide peer lists to P2P clients 1710 distributed across multiple ISPs. In such a case, the P2P tracker 1711 may communicate with multiple ALTO Servers. 1713 8.2. ALTO Client Embedded in P2P Client: Numerical Costs 1715 P2P clients may also utilize ALTO information themselves when 1716 selecting from available peers. It is important to note that not all 1717 P2P systems use a P2P tracker for peer discovery and selection. 1718 Furthermore, even when a P2P tracker is used, the P2P clients may 1719 rely on other sources, such as peer exchange and DHTs, to discover 1720 peers. 1722 When an P2P Client uses ALTO information, it typically queries only 1723 the ALTO Server servicing its own ISP. The my-Internet view provided 1724 by its ISP's ALTO Server can include preferences to all potential 1725 peers. 1727 .---------. (1) Get Network Map .---------------. 1728 | | <----------------------> | | 1729 | ALTO | | P2P Client | 1730 | Server | (2) Get Cost Map | (ALTO Client) | 1731 | | <----------------------> | | .---------. 1732 `---------' `---------------' <- | P2P | 1733 .---------. / | ^ ^ | Tracker | 1734 | Peer 1 | <-------------- | | \ `---------' 1735 `---------' | (3) Gather Peers 1736 . (4) Select Peers | | \ 1737 . and Connect / .--------. .--------. 1738 .---------. / | P2P | | DHT | 1739 | Peer 50 | <---------------- | Client | `--------' 1740 `---------' | (PEX) | 1741 `--------' 1743 Figure 4: ALTO Client Embedded in P2P Client 1745 Figure 4 shows an example use case where a P2P Client locally applies 1746 ALTO information to select peers. The use case proceeds as follows: 1748 1. The P2P Client requests the Network Map covering all PIDs from 1749 the ALTO Server servicing its own ISP. 1751 2. The P2P Client requests the Cost Map amongst all PIDs from the 1752 ALTO Server. The Cost Map by default specifies numerical costs. 1754 3. The P2P Client discovers peers from sources such as Peer Exchange 1755 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 1756 P2P Trackers. 1758 4. The P2P Client uses ALTO information as part of the algorithm for 1759 selecting new peers, and connects to the selected peers. 1761 8.3. ALTO Client Embedded in P2P Client: Ranking 1763 It is also possible for a P2P Client to offload the selection and 1764 ranking process to an ALTO Server. In this use case, the ALTO Client 1765 gathers a list of known peers in the swarm, and asks the ALTO Server 1766 to rank them. 1768 As in the use case using numerical costs, the P2P Client typically 1769 only queries the ALTO Server servicing its own ISP. 1771 .---------. .---------------. 1772 | | | | 1773 | ALTO | (2) Get Endpoint Ranking | P2P Client | 1774 | Server | <----------------------> | (ALTO Client) | 1775 | | | | .---------. 1776 `---------' `---------------' <- | P2P | 1777 .---------. / | ^ ^ | Tracker | 1778 | Peer 1 | <-------------- | | \ `---------' 1779 `---------' | (1) Gather Peers 1780 . (3) Connect to | | \ 1781 . Selected Peers / .--------. .--------. 1782 .---------. / | P2P | | DHT | 1783 | Peer 50 | <---------------- | Client | `--------' 1784 `---------' | (PEX) | 1785 `--------' 1787 Figure 5: ALTO Client Embedded in P2P Client: Ranking 1789 Figure 5 shows an example of this scenario. The use case proceeds as 1790 follows: 1792 1. The P2P Client discovers peers from sources such as Peer Exchange 1793 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 1794 P2P Trackers. 1796 2. The P2P Client queries the ALTO Server's Ranking Service, 1797 including discovered peers as the set of Destination Endpoints, 1798 and indicates the 'ordinal' Cost Mode. The response indicates 1799 the ranking of the candidate peers. 1801 3. The P2P Client connects to the peers in the order specified in 1802 the ranking. 1804 9. Discussions 1805 9.1. Discovery 1807 The particular mechanism by which an ALTO Client discovers its ALTO 1808 Server is an important component to the ALTO architecture and 1809 numerous techniques have been discussed [15] [16]. However, the 1810 discovery mechanism is out of scope for this document. 1812 Some ISPs have proposed the possibility of delegation, in which an 1813 ISP provides information for customer networks which do not wish to 1814 run Portal Servers themselves. A consideration for delegation is 1815 that customer networks may wish to explicitly configure such 1816 delegation. 1818 9.2. Network Address Translation Considerations 1820 At this day and age of NAT v4<->v4, v4<->v6 [17], and possibly 1821 v6<->v6[18], a protocol should strive to be NAT friendly and minimize 1822 carrying IP addresses in the payload, or provide a mode of operation 1823 where the source IP address provide the information necessary to the 1824 server. 1826 The protocol specified in this document provides a mode of operation 1827 where the source network location is computed by the ALTO Server (via 1828 the Endpoint Property Lookup interface) from the source IP address 1829 found in the ALTO Client query packets. This is similar to how some 1830 P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS 1831 Protocol" in [19]) operate. 1833 The ALTO client SHOULD use the Session Traversal Utilities for NAT 1834 (STUN) [6] to determine a public IP address to use as a source NL-ID. 1835 If using this method, the host MUST use the "Binding Request" message 1836 and the resulting "XOR-MAPPED-ADDRESS" parameter that is returned in 1837 the response. Using STUN requires cooperation from a publicly 1838 accessible STUN server. Thus, the ALTO client also requires 1839 configuration information that identifies the STUN server, or a 1840 domain name that can be used for STUN server discovery. To be 1841 selected for this purpose, the STUN server needs to provide the 1842 public reflexive transport address of the host. 1844 9.3. Mapping IPs to ASNs 1846 It may be desired for the ALTO Protocol to provide ALTO information 1847 including ASNs. Thus, ALTO Clients may need to identify the ASN for 1848 a Resource Provider to determine the cost to that Resource Provider. 1850 Applications can already map IPs to ASNs using information from a BGP 1851 Looking Glass. To do so, they must download a file of about 1.5MB 1852 when compressed (as of October 2008, with all information not needed 1853 for IP to ASN mapping removed) and periodically (perhaps monthly) 1854 refresh it. 1856 Alternatively, the Network Map query in the Map Filtering Service 1857 defined in this document could be extended to map ASNs into a set of 1858 IP prefixes. The mappings provided by the ISP would be both smaller 1859 and more authoritative. 1861 For simplicity of implementation, it's highly desirable that clients 1862 only have to implement exactly one mechanism of mapping IPs to ASNs. 1864 9.4. Endpoint and Path Properties 1866 An ALTO Server could make available many properties about Endpoints 1867 beyond their network location or grouping. For example, connection 1868 type, geographical location, and others may be useful to 1869 applications. The current draft focuses on network location and 1870 grouping, but the protocol may be extended to handle other Endpoint 1871 properties. 1873 9.5. P2P Peer Selection 1875 This section discusses possible approaches to peer selection using 1876 ALTO information (Network Location Identifiers and associated Costs) 1877 from an ALTO Server. Specifically, the application must select which 1878 peers to use based on this and other sources of information. With 1879 this in mind, the usage of ALTO Costs is intentionally flexible, 1880 because: 1882 Different applications may use the information differently. For 1883 example, an application that connects to just one address may have 1884 a different algorithm for selecting it than an application that 1885 connects to many. 1887 Though initial experiments have been conducted [20], more 1888 investigation is needed to identify other methods. 1890 In addition, the application might account for robustness, perhaps 1891 using randomized exploration to determine if it performs better 1892 without ALTO information. 1894 9.5.1. Client-based Peer Selection 1896 One possibility is for peer selection using ALTO costs to be done 1897 entirely by a P2P client. The following are some techniques have 1898 been proposed and/or used: 1900 o Prefer network locations with lower ordinal rankings (i.e., higher 1901 priority) [21] [10]. 1903 o Optimistically unchoking low-cost peers with higher probability 1904 [10]. 1906 9.5.2. Server-based Peer Selection 1908 Another possibility is for ALTO costs to be used by an Application 1909 Tracker (e.g., BitTorrent Tracker) when returning peer lists. The 1910 following are techniques that have been proposed and/or used: 1912 o Using bandwidth matching (e.g., at an Application Tracker) and 1913 choosing solution (within bound of optimal) with minimal network 1914 cost [20]. 1916 10. IANA Considerations 1918 This document request the registration of a new media type: 1919 "application/alto" 1921 11. Security Considerations 1923 11.1. Privacy Considerations for ISPs 1925 ISPs must be cognizant of the network topology and provisioning 1926 information provided through ALTO Interfaces. ISPs should evaluate 1927 how much information is revealed and the associated risks. On the 1928 one hand, providing overly fine-grained information may make it 1929 easier for attackers to infer network topology. In particular, 1930 attackers may try to infer details regarding ISPs' operational 1931 policies, inter-ISP business relationships, etc. by intenionally 1932 posting a multitude of selective queries to an ALTO server (and 1933 carefully analyzing the responses). Such sophisticated attacks may 1934 reveal more information than an ISP hosting an ALTO server intends to 1935 disclose. On the other hand, revealing overly coarse-grained 1936 information may not provide benefits to network efficiency or 1937 performance improvements to ALTO Clients. 1939 11.2. ALTO Clients 1941 Applications using the information must be cognizant of the 1942 possibility that the information is malformed or incorrect. Even if 1943 an ALTO Server has been properly authenticated by the ALTO Client, 1944 the information provided may be malicious because the ALTO Server and 1945 its credentials have been compromised (e.g., through malware). Other 1946 considerations (e.g., relating to application performance) can be 1947 found in Section 6 of [13]. 1949 ALTO Clients should also be cognizant of revealing Network Location 1950 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, 1951 as doing so may allow the ALTO Server to infer communication 1952 patterns. One possibility is for the ALTO Client to only rely on 1953 Network Map for PIDs and Cost Map amongst PIDs to avoid passing IP 1954 addresses of their peers to the ALTO Server. 1956 In addition, ALTO clients should be cautious not to unintentionally 1957 or indirectly disclose the resource identifier (of which they try to 1958 improve the retrieval through ALTO-guidance), e.g., the name/ 1959 identifier of a certain video stream in P2P live streaming, to the 1960 ALTO server. Note that the ALTO Protocol specified in this document 1961 does not explicitly reveal any resource identifier to the ALTO 1962 Server. However, for instance, depending on the popularity or other 1963 specifics (such as language) of the resource, an ALTO server could 1964 potentially deduce information about the desired resource from 1965 information such as the Network Locations the client sends as part of 1966 its request to the server. 1968 11.3. Authentication, Integrity Protection, and Encryption 1970 SSL/TLS can provide encryption of transmitted messages as well as 1971 authentication of the ALTO Client and Server. HTTP Basic or Digest 1972 authentication can provide authentication of the client (combined 1973 with SSL/TLS, it can additionally provide encryption and 1974 authentication of the server). 1976 An ALTO Server may optionally use authentication (and potentially 1977 encryption) to protect ALTO information it provides. This can be 1978 achieved by digitally signing a hash of the ALTO information itself 1979 and attaching the signature to the ALTO information. There may be 1980 special use cases where encryption of ALTO information is desirable. 1981 In most cases, however, information sent out by an ALTO Server is 1982 most likely to be regarded as non-confidential information. 1984 ISPs should be cognizant that encryption only protects ALTO 1985 information until it is decrypted by the intended ALTO Client. 1986 Digital Rights Management (DRM) techniques and legal agreements 1987 protecting ALTO information are outside of the scope of this 1988 document. 1990 11.4. ALTO Information Redistribution 1992 It is possible for applications to redistribute ALTO information to 1993 improve scalability. Even with such a distribution scheme, ALTO 1994 Clients obtaining ALTO information must be able to validate the 1995 received ALTO information to ensure that it was actually generated by 1996 the correct ALTO Server. Further, to prevent the ALTO Server from 1997 being a target of attack, the verification scheme must not require 1998 ALTO Clients to contact the ALTO Server to validate every set of 1999 information. Note that in any case, contacting the originating ALTO 2000 server for information validation would undermine the intended effect 2001 of redistribution and is therefore not desirable. 2003 Note that the redistribution scheme must additionally handle details 2004 such as ensuring ALTO Clients retrieve ALTO information from the 2005 correct ALTO Server. See [22] and [23] for further discussion. 2006 Details of a particular redistribution scheme are outside the scope 2007 of this document. 2009 To fulfill these requirements, ALTO Information meant to be 2010 redistributable contains a digital signature which includes a hash of 2011 the ALTO information signed by the ALTO Server with its private key. 2012 The corresponding public key should either be part of the ALTO 2013 information itself, or it could be included in the server capability 2014 response. The public key SHOULD include the hostname of the ALTO 2015 Server and it SHOULD be signed by a trusted authority (i.e., in a 2016 certificate). This an ALTO client retrieving redistributed ALTO 2017 information to verify the correctness of the ALTO Server's signature, 2018 given that it trusts the authority which signed the ALTO Server's 2019 certificate. Note that in some cases this requires that the 2020 retrieving ALTO Client must be able to derive a transitive 2021 certificate chain (including a Root-CA) to the trusted authority 2022 which signed the ALTO Server's certificate. This requirement may not 2023 be possible to fulfill between every ALTO Client / ALTO Server 2024 combination on the Internet due to the lack of a world-wide public 2025 key infrastructure. 2027 11.5. Denial of Service 2029 ISPs should be cognizant of the workload at the ALTO Server generated 2030 by certain ALTO Queries, such as certain queries to the Map Filtering 2031 Service and Ranking Service. In particular, queries which can be 2032 generated with low effort but result in expensive workloads at the 2033 ALTO Server could be exploited for Denial-of-Service attacks. For 2034 instance, a simple ALTO query with n Source Network Locations and m 2035 Destination Network Locations can be generated fairly easily but 2036 results in the computation of n*m Path Costs between pairs by the 2037 ALTO Server (see Section 5.2). One way to limit Denial-of-Service 2038 attacks is to employ access control to the ALTO server. Another 2039 possible mechanism for an ALTO Server to protect itself against a 2040 multitude of computationally expensive bogus requests is to demand 2041 that each ALTO Client to solve a computational puzzle first before 2042 allocating resources for answering a request (see, e.g., [24]). The 2043 current specification the current specification does not use such 2044 computational puzzles, and discussion regarding tradeoffs of such an 2045 approach would be needed before including such a technique in the 2046 ALTO Protocol. 2048 ISPs should also leverage the fact that the the Map Service allows 2049 ALTO Servers to pre-generate maps that can be useful to many ALTO 2050 Clients. 2052 11.6. ALTO Server Access Control 2054 In order to limit access to an ALTO server (e.g., for an ISP to only 2055 allow its users to access its ALTO server, or to prevent Denial-of- 2056 Service attacks by arbitrary hosts from the Internet), an ALTO server 2057 may employ access control policies. Depending on the use-case and 2058 scenario, an ALTO server may restrict access to its services more 2059 strictly or rather openly (see [25] for a more detailed discussion on 2060 this issue). 2062 12. References 2064 12.1. Normative References 2066 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2067 Levels", BCP 14, RFC 2119, March 1997. 2069 [2] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 2070 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 2072 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 2073 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 2074 HTTP/1.1", RFC 2616, June 1999. 2076 [4] Crockford, D., "The application/json Media Type for JavaScript 2077 Object Notation (JSON)", RFC 4627, July 2006. 2079 [5] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: 2080 Timestamps", RFC 3339, July 2002. 2082 [6] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 2083 Traversal Utilities for (NAT) (STUN)", 2084 draft-ietf-behave-rfc3489bis-18 (work in progress), July 2008. 2086 12.2. Informative References 2088 [7] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, 2089 "Application-Layer Traffic Optimization (ALTO) Requirements", 2090 draft-kiesel-alto-reqs-01 (work in progress), November 2008. 2092 [8] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, "P4P: 2093 Provider Portal for P2P Applications", draft-p4p-framework-00 2094 (work in progress), November 2008. 2096 [9] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, "P4P 2097 Protocol Specification", draft-wang-alto-p4p-specification-00 2098 (work in progress), March 2009. 2100 [10] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 2101 Export Service", draft-shalunov-alto-infoexport-00 (work in 2102 progress), October 2008. 2104 [11] Das, S. and V. Narayanan, "A Client to Service Query Response 2105 Protocol for ALTO", draft-saumitra-alto-queryresponse-00 (work 2106 in progress), March 2009. 2108 [12] Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 2109 Dimensional Peer Selection Problem", 2110 draft-saumitra-alto-multi-ps-00 (work in progress), 2111 October 2008. 2113 [13] Seedorf, J. and E. Burger, "Application-Layer Traffic 2114 Optimization (ALTO) Problem Statement", RFC 5693, October 2009. 2116 [14] Yang, Y., Popkin, L., Penno, R., and S. Shalunov, "An 2117 Architecture of ALTO for P2P Applications", 2118 draft-yang-alto-architecture-00 (work in progress), March 2009. 2120 [15] Garcia, G., Tomsu, M., and Y. Wang, "ALTO Discovery Protocols", 2121 draft-wang-alto-discovery-00 (work in progress), March 2009. 2123 [16] Song, H., Even, R., Pascual, V., and Y. Zhang, "Application- 2124 Layer Traffic Optimization (ALTO): Discover ALTO Servers", 2125 draft-song-alto-server-discovery-00 (work in progress), 2126 March 2009. 2128 [17] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 2129 Translation", draft-baker-behave-v4v6-framework-02 (work in 2130 progress), February 2009. 2132 [18] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address 2133 Translation (NAT66)", draft-mrw-behave-nat66-02 (work in 2134 progress), March 2009. 2136 [19] "Bittorrent Protocol Specification v1.0", 2137 http://wiki.theory.org/BitTorrentSpecification, 2009. 2139 [20] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A. 2140 Silberschatz., "P4P: Provider Portal for (P2P) Applications", 2141 In SIGCOMM 2008. 2143 [21] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 2144 Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00 2145 (work in progress), March 2009. 2147 [22] Yingjie, G., Alimi, R., and R. Even, "ALTO Information 2148 Redistribution", draft-gu-alto-redistribution-01 (work in 2149 progress), October 2009. 2151 [23] Stiemerling, M., "ALTO Information Redistribution Considered 2152 Harmful", draft-stiemerling-alto-info-redist-00 (work in 2153 progress), August 2009. 2155 [24] Jennings, C., "Computational Puzzles for SPAM Reduction in 2156 SIP", draft-jennings-sip-hashcash-06 (work in progress), 2157 July 2007. 2159 [25] Stiemerling, M. and S. Kiesel, "ALTO Deployment 2160 Considerations", draft-stiemerling-alto-deployments-01 (work in 2161 progress), March 2010. 2163 Appendix A. ALTO Protocol Grammar 2165 All of the mechanisms specified in this document are described in 2166 both prose and an augmented Backus-Naur Form (BNF) defined in RFC 2167 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that 2168 are used by this specification, and not repeated here. Implementers 2169 need to be familiar with the notation and content of RFC 2234 in 2170 order to understand this specification. Certain basic rules are in 2171 uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle 2172 brackets are used within definitions to clarify the use of rule 2173 names. 2175 TODO 2177 Appendix B. Acknowledgments 2179 Thank you to Jan Seedorf for contributions to the Security 2180 Considerations section. 2182 We would like to thank the following people whose input and 2183 involvement was indispensable in achieving this merged proposal: 2185 Obi Akonjang (DT Labs/TU Berlin), 2187 Saumitra M. Das (Qualcomm Inc.), 2189 Syon Ding (China Telecom), 2191 Doug Pasko (Verizon), 2193 Laird Popkin (Pando Networks), 2195 Satish Raghunath (Juniper Networks), 2197 Albert Tian (Ericsson/Redback), 2199 Yu-Shun Wang (Microsoft), 2201 David Zhang (PPLive), 2203 Yunfei Zhang (China Mobile). 2205 We would also like to thank the following additional people who were 2206 involved in the projects that contributed to this merged document: 2207 Alex Gerber (AT&T), Chris Griffiths (Comcast), Ramit Hora (Pando 2208 Networks), Arvind Krishnamurthy (University of Washington), Marty 2209 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 2210 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T), 2211 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 2212 Damien Saucez (UCL) Thomas Scholl (AT&T), Emilio Sepulveda 2213 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 2214 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 2215 (Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia 2216 Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University), 2217 Haiyong Xie (Yale University). 2219 Appendix C. Authors 2221 [[Comment.2: RFC Editor: Please move information in this section to 2222 the Authors' Addresses section at publication time.]] 2224 Stefano Previdi 2225 Cisco 2226 Email: sprevidi@cisco.com 2228 Stanislav Shalunov 2229 BitTorrent 2231 Email: shalunov@bittorrent.com 2233 Richard Woundy 2234 Comcast 2236 Richard_Woundy@cable.comcast.com 2238 Authors' Addresses 2240 Richard Alimi (editor) 2241 Yale University 2243 Email: richard.alimi@yale.edu 2245 Reinaldo Penno (editor) 2246 Juniper Networks 2247 1194 N Mathilda Avenue 2248 Sunnyvale, CA 2249 USA 2251 Email: rpenno@juniper.net 2253 Y. Richard Yang (editor) 2254 Yale University 2256 Email: yry@cs.yale.edu