idnits 2.17.1 draft-ietf-alto-protocol-03.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 811 has weird spacing: '...etaData meta...' == Line 812 has weird spacing: '...NString typ...' == Line 830 has weird spacing: '...istInfo redis...' == Line 985 has weird spacing: '...NString type...' == Line 986 has weird spacing: '...NString unit...' == (9 more instances...) -- The document date (March 8, 2010) is 5163 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 193 -- Looks like a reference, but probably isn't: 'RspDataType' on line 813 -- Looks like a reference, but probably isn't: 'OPTIONAL' on line 998 -- Looks like a reference, but probably isn't: 'TODO' on line 1569 ** 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-02 == Outdated reference: A later version (-06) exists of draft-stiemerling-alto-deployments-02 Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 6 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 9, 2010 Juniper Networks 6 Y. Yang, Ed. 7 Yale University 8 March 8, 2010 10 ALTO Protocol 11 draft-ietf-alto-protocol-03.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 9, 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 . . . . . . . . . . . . . . . . . . . . . . 13 105 5.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 13 106 5.2. Cost Map Structure . . . . . . . . . . . . . . . . . . . . 14 107 5.3. Network Map and Cost Map Dependency . . . . . . . . . . . 14 108 6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14 109 6.1. Design Approach . . . . . . . . . . . . . . . . . . . . . 14 110 6.1.1. Use of Existing Infrastructure . . . . . . . . . . . . 15 111 6.1.2. ALTO Information Reuse and Redistribution . . . . . . 15 112 7. Protocol Messaging . . . . . . . . . . . . . . . . . . . . . . 15 113 7.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 16 114 7.2. Message Format . . . . . . . . . . . . . . . . . . . . . . 16 115 7.2.1. Protocol Versioning Approach . . . . . . . . . . . . . 16 116 7.2.2. Request Message . . . . . . . . . . . . . . . . . . . 17 117 7.2.3. Response Message . . . . . . . . . . . . . . . . . . . 18 118 7.3. General Processing . . . . . . . . . . . . . . . . . . . . 20 119 7.3.1. Server Responses . . . . . . . . . . . . . . . . . . . 20 120 7.3.2. Client Behavior . . . . . . . . . . . . . . . . . . . 20 121 7.4. HTTP Usage . . . . . . . . . . . . . . . . . . . . . . . . 21 122 7.4.1. Authentication and Encryption . . . . . . . . . . . . 21 123 7.4.2. Cookies . . . . . . . . . . . . . . . . . . . . . . . 21 124 7.4.3. Caching Parameters . . . . . . . . . . . . . . . . . . 21 125 7.5. ALTO Requests . . . . . . . . . . . . . . . . . . . . . . 21 126 7.5.1. Server Capability . . . . . . . . . . . . . . . . . . 22 127 7.5.2. Map Service . . . . . . . . . . . . . . . . . . . . . 25 128 7.5.3. Map Filtering Service . . . . . . . . . . . . . . . . 28 129 7.5.4. Endpoint Property Service . . . . . . . . . . . . . . 32 130 7.5.5. Endpoint Cost Service . . . . . . . . . . . . . . . . 34 131 7.6. Redistributable Responses . . . . . . . . . . . . . . . . 36 132 7.6.1. Server and Request Parameters . . . . . . . . . . . . 37 133 7.6.2. Expiration Time . . . . . . . . . . . . . . . . . . . 37 134 7.6.3. Signature . . . . . . . . . . . . . . . . . . . . . . 38 135 8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 39 136 8.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 39 137 8.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 40 138 8.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 41 139 9. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 42 140 9.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 42 141 9.2. Network Address Translation Considerations . . . . . . . . 43 142 9.3. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . 43 143 9.4. Endpoint and Path Properties . . . . . . . . . . . . . . . 44 144 9.5. P2P Peer Selection . . . . . . . . . . . . . . . . . . . . 44 145 9.5.1. Client-based Peer Selection . . . . . . . . . . . . . 44 146 9.5.2. Server-based Peer Selection . . . . . . . . . . . . . 44 147 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 148 11. Security Considerations . . . . . . . . . . . . . . . . . . . 45 149 11.1. Privacy Considerations for ISPs . . . . . . . . . . . . . 45 150 11.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 45 151 11.3. Authentication, Integrity Protection, and Encryption . . . 46 152 11.4. ALTO Information Redistribution . . . . . . . . . . . . . 46 153 11.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 47 154 11.6. ALTO Server Access Control . . . . . . . . . . . . . . . . 48 155 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 156 12.1. Normative References . . . . . . . . . . . . . . . . . . . 48 157 12.2. Informative References . . . . . . . . . . . . . . . . . . 48 158 Appendix A. ALTO Protocol Grammar . . . . . . . . . . . . . . . . 50 159 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 50 160 Appendix C. Authors . . . . . . . . . . . . . . . . . . . . . . . 51 161 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 163 1. Introduction 165 1.1. Background and Problem Statement 167 Today, network information available to applications is mostly from 168 the view of endhosts. There is no clear mechanism to convey 169 information about the network's preferences to applications. By 170 leveraging better network-provided information, applications have the 171 potential to become more network-efficient (e.g., reduce network 172 resource consumption) and achieve better application performance 173 (e.g., accelerated download rate). The ALTO Service intends to 174 provide a simple way to convey network information to applications. 176 The goal of this document is to specify a simple and unified protocol 177 that meets the ALTO requirements [7] while providing a migration path 178 for Internet Service Providers (ISP), Content Providers, and clients 179 that have deployed protocols with similar intentions (see below). 180 This document is a work in progress and will be updated with further 181 developments. 183 1.2. Design History and Merged Proposals 185 The protocol specified here consists of contributions from 187 o P4P [8], [9]; 189 o ALTO Info-Export [10]; 191 o Query/Response [11], [12]; 193 o ATTP [ATTP]. 195 o Proxidor [19]. 197 See Appendix B for a list of people that have contributed 198 significantly to this effort and the projects and proposals listed 199 above. 201 1.3. Solution Benefits 203 The ALTO Service offers many benefits to both end-users (consumers of 204 the service) and Internet Service Providers (providers of the 205 service). 207 1.3.1. Service Providers 209 The ALTO Service enables ISPs to influence the peer selection process 210 in distributed applications in order to increase locality of traffic, 211 improve user-experience, amongst others. It also helps ISPs to 212 efficiently engineer traffic that traverses more expensive links such 213 as transit and backup links, thus allowing a better provisioning of 214 the networking infrastructure. 216 1.3.2. Applications 218 Applications that use the ALTO Service can benefit in multiple ways. 219 For example, they may no longer need to infer topology information, 220 and some applications can reduce reliance on measuring path 221 performance metrics themselves. They can take advantage of the ISP's 222 knowledge to avoid bottlenecks and boost performance. 224 An example type of application is a Peer-to-Peer overlay where peer 225 selection can be improved by including ALTO information in the 226 selection process. 228 2. Architecture 230 Two key design objectives of the ALTO Protocol are simplicity and 231 extensibility. At the same time, it introduces additional techniques 232 to address potential scalability and privacy issues. Below we start 233 with an introduction to the terminology. Then we define the overall 234 architecture and how the ALTO Protocol fits into the architecture. 236 2.1. Terminology 238 We use the following terms defined in [13]: Application, Overlay 239 Network, Peer, Resource, Resource Identifier, Resource Provider, 240 Resource Consumer, Resource Directory, Transport Address, Host 241 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 242 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 243 Transit Traffic. 245 We also use the following additional terms: Endpoint Address, ASN, 246 and Network Location. 248 2.1.1. Endpoint Address 250 An endpoint address represents the communication address of an end 251 point. An endpoint address can be network-attachment based (IP 252 address) or network-attachment agnostic. Common forms of endpoint 253 addresses include IP address, MAC address, overlay ID, and phone 254 number. 256 2.1.2. ASN 258 An Autonomous System Number. 260 2.1.3. Network Location 262 Network Location is a generic concept denoting a single endpoint or 263 group of endpoints. Whenever we say Network Location, we refer to 264 either a single endpoint or a group of endpoints. 266 2.2. ALTO Service and Protocol Scope 268 An ALTO Server conveys the network information from the perspective 269 of a network region. We say that the ALTO Server presents its "my- 270 Internet View" [14] of the network region. A network region in this 271 context can be an Autonomous System, an ISP, perhaps a smaller 272 region, or perhaps a set of ISPs; the details depend on the 273 deployment scenario and discovery mechanism. 275 To better understand the ALTO Service and the role of the ALTO 276 Protocol, we show in Figure 1 the overall system architecture. In 277 this architecture, an ALTO Server prepares ALTO Information; an ALTO 278 Client uses ALTO Service Discovery to identify an appropriate ALTO 279 Server; and the ALTO Client requests available ALTO Information from 280 the ALTO Server using the ALTO Protocol. 282 The ALTO Information provided by the ALTO Server can be updated 283 dynamically based on network conditions, or can be seen as a policy 284 which is updated at a larger time-scale. 286 More specifically, the ALTO Information provided by an ALTO Server 287 may be influenced (at the operator's discretion) by other systems. 288 Examples include (but are not limited to) static network 289 configuration databases, dynamic network information, routing 290 protocols, provisioning policies, and interfaces to outside parties. 291 These components are shown in the figure for completeness but outside 292 the scope of this specification. 294 Note that it may also be possible for ALTO Servers to exchange 295 network information with other ALTO Servers (either within the same 296 administrative domain or another administrative domain with the 297 consent of both parties) in order to adjust exported ALTO 298 information. Such a protocol is also outside the scope of this 299 specification. 301 +-------------------------------------------------------------------+ 302 | ISP | 303 | | 304 | +-----------+ | 305 | | Routing | | 306 | +--------------+ | Protocols | | 307 | | Provisioning | +-----------+ | 308 | | Policy | | | 309 | +--------------+\ | | 310 | \ | | 311 | \ | | 312 | +-----------+ \+---------+ +--------+ | 313 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 314 | |Network |.......| Server | -------------------- | Client | | 315 | |Information| +---------+ +--------+ | 316 | +-----------+ / / | 317 | / ALTO SD Query/Response / | 318 | / / | 319 | +----------+ +--------------+ | 320 | | External | | ALTO Service | | 321 | | Interface| | Discovery | | 322 | +----------+ +--------------+ | 323 | | | 324 | | Figure 1: Basic ALTO Architecture. | 325 | | | 326 +-------------------------------------------------------------------+ 327 | 328 +------------------+ 329 | Third Parties | 330 | | 331 | Content Providers| 332 +------------------+ 334 ALTO Architecture 336 3. Protocol Structure 338 The ALTO Protocol uses a simple extensible framework to convey 339 network information. In the general framework, the ALTO protocol 340 will convey properties on both Endpoints and paths between network 341 locations. 343 In this document, we focus on a particular endpoint property to 344 denote the location of an endpoint, and provider-defined costs for 345 paths between pairs of network locations. 347 The ALTO Protocol is built on a common transport protocol, messaging 348 structure and encoding, and transaction model. The protocol is 349 subdivided into services of related functionality. ALTO-Core 350 provides the Map Service. Other services can provide additional 351 functionality. There are three such services defined in this 352 document: the Map Filtering Service, Endpoint Property Service, and 353 Endpoint Cost Service. Additional services may be defined in the 354 future in companion documents. Note that functionality offered in 355 different services are not totally non-overlapping (e.g., the Map 356 Service and Map Filtering Service). 358 .--------------------------------------------------------. 359 | | 360 | .----------. .-----------. .----------. .----------. | 361 | | | | Map | | Endpoint | | Endpoint | | 362 | | | | Filtering | | Property | | Cost | | 363 | | | | Service | | Service | | Service | | 364 | | | `-----------' `----------' `----------' | 365 | | Server | .-------------------------------------. | 366 | |Capability| | Map Service | | 367 | | | | .-------------. .--------------. | | 368 | | | | | Network Map | | Cost Map | | | 369 | | | | `-------------' `--------------' | | 370 | `----------' `-------------------------------------' | 371 | | 372 `--------------------------------------------------------' 374 Figure 1: ALTO Protocol Structure 376 3.1. Server Capability 378 The Server Capability Service lists the details on the information 379 that can be provided by an ALTO Server and perhaps other ALTO Servers 380 maintained by the network provider. The configuration includes, for 381 example, details about the operations and cost metrics supported by 382 the ALTO Server. The capability document can be downloaded by ALTO 383 Clients. The capability information could also be provisioned to 384 devices, but care must be taken to update it appropriately. 386 3.2. Services 388 3.2.1. Map Service 390 The Map Service provides batch information to ALTO Clients. Two maps 391 are defined in this document. The Network Map (See Section 4) 392 provides the full set of network location groupings defined by the 393 ALTO Server and the endpoints contained with each grouping. The Cost 394 Map (see Section 5) provides costs between the defined groupings. 396 These two maps can be thought of (and implemented as) as simple files 397 with appropriate encoding provided by the ALTO Server. 399 3.2.2. Map Filtering Service 401 Resource constrained ALTO Clients may benefit from query results 402 being filtered at the ALTO Server. This avoids an ALTO Client 403 spending network bandwidth or CPU collecting results and performing 404 client-side filtering. The Map Filtering Service allows ALTO Clients 405 to query for ALTO Server maps based on additional parameters. 407 3.2.3. Endpoint Property Service 409 This service allows ALTO Clients to look up properties for individual 410 endpoints. An example endpoint property is its network location (its 411 grouping defined by the ALTO Server) or connectivity type (e.g., 412 ADSL, Cable, or FioS). 414 3.2.4. Endpoint Cost Service 416 Some ALTO Clients may also benefit from querying for costs and 417 rankings based on endpoints. The Endpoint Cost Service allows an 418 ALTO Server to return either numerical costs or ordinal costs 419 (rankings) directly amongst Endpoints. 421 4. Network Map 423 In reality, many endpoints are very close to one another in terms of 424 network connectivity, for example, endpoints on the same site of an 425 enterprise. By treating a group of endpoints together as a single 426 entity in ALTO, we can achieve much greater scalability without 427 loosing critical information. 429 The Network Location endpoint property allows an ALTO Server to group 430 endpoints together to indicate their proximity. The resulting set of 431 groupings is called the ALTO Network Map. 433 The Network Map may also be used to communicate simple preferences. 434 For example, an ISP may prefer that endpoints associated with the 435 same PoP (Point-of-Presence) in a P2P application communicate locally 436 instead of communicating with endpoints in other PoPs. [[Comment.1: 437 Preferring peers within the same PID may be a reasonable default, but 438 some ALTO providers may prefer to discourage such peering. A flag 439 (e.g., attribute in the map) might be used to communicate such non- 440 default preferences.]] 442 Note that the definition of proximity varies depending on the 443 granularity of the ALTO information configured by the provider. In 444 one deployment, endpoints on the same subnet may be considered close; 445 while in another deployment, endpoints connected to the same PoP may 446 be considered close. 448 4.1. PID 450 Each group of Endpoints is identified by a provider-defined Network 451 Location identifier called a PID. There can be many different ways 452 of grouping the endpoints and assigning PIDs. 454 A PID is an identifier providing an indirect and network-agnostic way 455 to specify a network aggregation. For example, a PID may be defined 456 (by the ALTO service provider) to denote a subnet, a set of subnets, 457 a metropolitan area, a PoP, an autonomous system, or a set of 458 autonomous systems. Aggregation of endpoints into PIDs can indicate 459 proximity and can improve scalability. In particular, network 460 preferences (costs) may be specified between PIDs, allowing cost 461 information to be more compact and updated at a smaller time scale 462 than the network aggregations themselves. 464 The current specification considers endpoints that are identified by 465 an IP address. The endpoints aggregated into a PID are denoted by a 466 list of IP prefixes. When either an ALTO Client or ALTO Server needs 467 to determine which PID in a Network Map contains a particular IP 468 address, longest-prefix matching MUST be used. 470 4.2. Example Network Map 472 Figure 2 illustrates an example Network Map. PIDs are used to 473 identify network-agnostic aggregations. 475 .-----------------------------------------------------------. 476 | ALTO Network Map | 477 | | 478 | .-----------------------------------. .---------------. | 479 | | NetLoc: PID-1 | | NetLoc: PID-2 | | 480 | | .------------------------------. | | ... | | 481 | | | 192.0.2.0/24 | | `---------------` | 482 | | | .--------------------------. | | | 483 | | | | Endpoint: 192.0.2.34 | | | .---------------. | 484 | | | `--------------------------` | | | NetLoc: PID-3 | | 485 | | `------------------------------` | | ... | | 486 | | .------------------------------. | `---------------` | 487 | | | 198.51.100.0/25 | | | 488 | | | .--------------------------. | | .---------------. | 489 | | | | Endpoint: 198.51.100.100 | | | | NetLoc: PID-4 | | 490 | | | `--------------------------` | | | ... | | 491 | | `------------------------------` | `---------------` | 492 | `-----------------------------------` | 493 | | 494 `-----------------------------------------------------------` 496 Figure 2: Example Network Map 498 5. Cost Map 500 An ALTO Server indicates preferences amongst network locations in the 501 form of Path Costs. Path Costs are generic costs and can be 502 internally computed by a network provider according to its own needs. 504 An ALTO Cost Map defines Path Costs pairwise amongst sets of source 505 and destination network locations. 507 One advantage of separating ALTO information into a Network Map and a 508 Cost Map is that the two components can be updated at different time 509 scales. For example, Network Maps may be stable for a longer time 510 while Cost Maps may be updated to reflect dynamic network conditions. 512 5.1. Cost Attributes 514 Path Costs have attributes: 516 o Type: identifies what the costs represent; 518 o Mode: identifies how the costs should be interpreted (numerical or 519 ordinal). 521 Certain queries for Cost Maps allow the ALTO Client to indicate the 522 desired Type and Mode. 524 5.1.1. Cost Type 526 The Type attribute indicates what the cost represents. For example, 527 an ALTO Server could define costs representing air-miles, hop-counts, 528 or generic routing costs. 530 Cost types are indicated in protocol messages as alphanumeric 531 strings. An ALTO Server MUST at least define the routing cost type 532 denoted by the string 'routingcost'. 534 Note that an ISP may internally compute routing cost using any method 535 it chooses (including air-miles or hop-count). 537 If an ALTO Client requests a Cost Type that is not available, the 538 ALTO Server responds with an error as specified in Section 7.3.1.3. 540 5.1.2. Cost Mode 542 The Mode attribute indicates how costs should be interpreted. For 543 example, an ALTO Server could return costs that should be interpreted 544 as numerical values or ordinal rankings. 546 It is important to communicate such information to ALTO Clients, as 547 certain operations may not be valid on certain costs returned by an 548 ALTO Server. For example, it is possible for an ALTO Server to 549 return a set of IP addresses with costs indicating a ranking of the 550 IP addresses. Arithmetic operations, such as summation, that would 551 make sense for numerical values, do not make sense for ordinal 552 rankings. ALTO Clients may want to handle such costs differently. 554 Cost Modes are indicated in protocol messages as alphanumeric 555 strings. An ALTO Server MUST at least define the modes 'numerical' 556 and 'ordinal'. 558 If an ALTO Client requests a Cost Mode that is not supported, the 559 ALTO Server MUST reply with costs having Mode either 'numerical' or 560 'ordinal'. Thus, an ALTO Server must implement at least one of 561 'numerical' or 'ordinal' Costs, but it may choose which to support. 562 ALTO Clients may choose how to handle such situations. Two 563 particular possibilities are to use the returned costs as-is (e.g., 564 treat numerical costs as ordinal rankings) or ignore the ALTO 565 information altogether. 567 5.2. Cost Map Structure 569 A query for a Cost Map either explicitly or implicitly includes a 570 list of Source Network Locations and a list of Destination Network 571 Locations. (Recall that a Network Location can be an endpoint 572 address or a PID.) 574 Specifically, assume that a query has a list of multiple Source 575 Network Locations, say [Src_1, Src_2, ..., Src_m], and a list of 576 multiple Destination Network Locations, say [Dst_1, Dst_2, ..., 577 Dst_n]. 579 The ALTO Server will return the Path Cost for each communicating pair 580 (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., Src_m -> Dst_1, ..., 581 Src_m -> Dst_n). We refer to this structure as a Cost Map. 583 If the Cost Mode is 'ordinal', the Path Cost of each communicating 584 pair is relative to the m*n entries. 586 5.3. Network Map and Cost Map Dependency 588 If a Cost Map contains PIDs in the list of Source Network Locations 589 or the list of Destination Network Locations, we say that the Path 590 Costs are generated based on a particular Network Map (which defines 591 the PIDs). Version Tags are introduced to ensure that ALTO Clients 592 are able to use consistent information even though the information is 593 provided in two maps. 595 A Version Tag is an opaque string associated with a Network Map 596 maintained by the ALTO Server. When the Network Map changes, the 597 Version Tag SHOULD also be changed. (Thus, the Version Tag is 598 defined similarly to HTTP's ETag.) Possibilities for generating a 599 Version Tag included the last-modified timestamp for the Network Map, 600 or a hash of its contents. 602 A Network Map distributed by the ALTO Server includes its Version 603 Tag. A Cost Map referring to PIDs also includes the Version Tag of 604 the Network Map on which it is based. 606 6. Protocol Overview 608 6.1. Design Approach 610 The ALTO Protocol design uses a RESTful interface with the goal of 611 leveraging current HTTP [2] [3] implementations and infrastructure. 612 ALTO messages are denoted with HTTP Content-Type "application/alto" 613 and use JSON [4] to encode message bodies. 615 These design decisions make the protocol easier to understand and 616 debug, and allows for flexible ALTO Server implementation strategies. 617 More importantly, however, this enables use of existing 618 implementations and infrastructure, and allows for simple caching and 619 redistribution of ALTO information to increase scalability. 621 6.1.1. Use of Existing Infrastructure 623 An important design consideration for the ALTO Protocol is easy 624 integration with existing applications and infrastructure. As 625 outlined above, HTTP is a natural choice. In particular, this ALTO 626 Protocol design leverages: 628 o the huge installed base of infrastructure, including HTTP caches, 630 o mature software implementations, 632 o the fact that many P2P clients already have an embedded HTTP 633 client, and 635 o authentication and encryption mechanisms in HTTP and SSL/TLS. 637 6.1.2. ALTO Information Reuse and Redistribution 639 ALTO information may be useful to a large number of applications and 640 users. Distributing ALTO information must be efficient and not 641 become a bottleneck. Therefore, the ALTO Protocol specified in this 642 document integrates with existing HTTP caching infrastructure to 643 allow reuse of ALTO information by ALTO Clients and reduce load on 644 ALTO servers. ALTO information may also be cached or redistributed 645 using application-dependent mechanisms, such as P2P DHTs or P2P file- 646 sharing. For example, a full Network Map may be reused by all ALTO 647 Clients using the ALTO Server. 649 Note that if caching or redistribution is used, the Response message 650 may be returned from another (possibly third-party) entity. Reuse 651 and Redistribution is further discussed in Section 11.4. Protocol 652 support for redistribution is specified in Section 7.6. 654 7. Protocol Messaging 656 This section specifies client and server processing, as well as 657 messages in the ALTO Protocol. Details common to ALTO Server 658 processing of all messages is first discussed, followed by details of 659 the individual messages. 661 7.1. Notation 663 This document uses C-style struct notation to define the required and 664 optional members of certain message components (i.e., JSON objects). 665 Unless explicitly noted, each member of a struct are REQUIRED. 667 The types 'JSONString', 'JSONNumber', 'JSONBool' indicate the JSON 668 string, number, and boolean types respectively. 670 This document only includes object members used by this 671 specification. It is possible that protocol extensions include 672 additional members to JSON objects defined in this document; such 673 additional members will be silently ignored by ALTO Servers and 674 Clients only implementing the base protocol defined in this document. 676 7.2. Message Format 678 Request and Response follow the standard format for HTTP Request and 679 Response messages [2] [3]. 681 The following subsections provide an overview of how ALTO Requests 682 and Responses are encoded in HTTP, and discusses rationale for 683 certain design decisions. 685 7.2.1. Protocol Versioning Approach 687 The ALTO Protocol uses a simple and clean approach to versioning that 688 permits evolution between versions even if ALTO information is being 689 served as static, pre-generated files. 691 In particular, it is assumed that a single host responding to ALTO 692 Requests implements a single protocol version. Note that virtual 693 hosting can be used if multiple protocol versions need to be 694 supported by a single physical server. 696 A common query (Server Capability, detailed in Section 7.5.1) to be 697 present in all ALTO protocol versions allows an ALTO Client to 698 discover additional ALTO Servers and the ALTO Protocol version number 699 of each. 701 This approach keeps the ALTO Server implementation free from parsing 702 and directing each request based on version number. Although ALTO 703 Requests are free from protocol version numbers, the protocol version 704 number is echoed in each ALTO Response to keep responses self- 705 contained to, for example, ease reading persisted or redistributed 706 ALTO responses. 708 This document specifies ALTO Protocol version 1. 710 7.2.2. Request Message 712 An ALTO Request is a standard HTTP Request generated by an ALTO 713 Client, with certain components defined by the ALTO Protocol. 715 The basic syntax of an ALTO Request is: 717 / HTTP/1.1 718 Host: 720 For example: 722 GET /capability HTTP/1.1 723 Host: alto.example.com:6671 725 7.2.2.1. Standard HTTP Headers 727 The Host header MUST follow the standard rules for the HTTP 1.1 Host 728 Header. 730 The Content-Length header MUST follow the standard rules defined in 731 HTTP 1.1. 733 The Content-Type HTTP Header MUST have value "application/alto" if 734 the Body is non-empty. 736 7.2.2.2. Method and Resource 738 Next, both the HTTP Method and URI-Path (denoted as Resource) 739 indicate the operation requested by the ALTO Client. In this 740 example, the ALTO Client is requesting basic capability information 741 from the ALTO Server. 743 7.2.2.3. Input Parameters 745 Certain operations defined by the ALTO Protocol (e.g., in the Map 746 Filtering Service) allow the ALTO Client to supply additional input 747 parameters. Such input parameters are encoded in a URI-Query-String 748 where possible and appropriate. However, due to practical 749 limitations (e.g. underlying HTTP implementations may have 750 limitations on the total length of a URI and the Query-String is 751 better-suited for simple unstructured parameters and lists), some 752 operations in the ALTO Protocol use input parameters encoded in the 753 HTTP Request Body. 755 7.2.3. Response Message 757 A Response message is a standard HTTP Response generated by an ALTO 758 Server with certain components defined by the ALTO Protocol. 760 The basic syntax of an ALTO Response is: 762 HTTP/1.1 763 Content-Length: 764 Content-Type: 766 768 where the HTTP Response Body is an ALTOResponse JSON Object (defined 769 in Section 7.2.3.3). For example: 771 HTTP/1.1 200 OK 772 Content-Length: 1000 773 Content-Type: application/alto 775 { 776 "meta" : { 777 "version": 1 778 ... 779 }, 780 "type" : "capability", 781 "data" : { 782 ... 783 } 784 } 786 7.2.3.1. Standard HTTP Headers 788 The Content-Length header MUST follow the standard rules defined in 789 HTTP 1.1. 791 The Content-Type HTTP Header MUST have value "application/alto" if 792 the Body is non-empty. 794 7.2.3.2. Status Code and Message 796 The HTTP Status Code MUST indicate success or an appropriate error 797 condition using standard HTTP Status Codes. The HTTP Status Message 798 MUST follow the standard rules in HTTP 1.1. 800 Since the ALTO Protocol is designed as a straightforward use of HTTP 801 to retrieve ALTO information from a server, only HTTP Status codes 802 are needed. [[Comment.2: This can be changed if a need for different 803 application-layer status codes arises.]] 805 7.2.3.3. HTTP Body 807 The Response body MUST encode a single top-level JSON object of type 808 ALTOResponse: 810 struct { 811 RspMetaData meta; 812 JSONString type; 813 [RspDataType] data; 814 } ALTOResponse; 816 The ALTOResponse object has distinct sections for: 818 o meta information encoded in an extensible way, 820 o the type of ALTO Information to follow, and 822 o the requested ALTO Information. 824 7.2.3.3.1. Meta Information 826 Meta information is encoded as a JSON object with type RspMetaData: 828 struct { 829 JSONNumber version; 830 RspRedistInfo redistribution; [OPTIONAL] 831 } RspMetaData; 833 with members: 835 o version: the ALTO Protocol version 837 o redistribution: additional meta information used by ALTO 838 information redistribution (see Section 7.6) 840 7.2.3.3.2. ALTO Information 842 If the Response is successful (i.e., HTTP status code is 2xx), then 843 the "type" and "data" members of the ALTOResponse object are 844 REQUIRED. "type" encodes a Response-specific string which indicates 845 to the ALTO Client the type of data encoded in the message. The 846 "data" member encodes the actual Response-specific data. The 847 structure of this member is detailed later in this section for each 848 particular ALTO Response. 850 7.2.3.4. Signature 852 An ALTO Server MAY additionally supply a signature asserting that it 853 generated a particular response. In order to allow the signature to 854 be computed over the entire response message, the signature itself is 855 specified in an HTTP Header or Trailer (see Section 7.6.3). 857 7.3. General Processing 859 The protocol is structured in such a way that, independent of the 860 query type, there are a set of general processing steps. The ALTO 861 Client selects a specific ALTO Server with which to communicate, 862 establishes a TCP connection, and constructs and sends ALTO Request 863 messages which MUST conform to Section 7.5. In response to Request 864 messages, an ALTO Server constructs and sends ALTO Response messages 865 which also MUST conform to Section 7.5. 867 7.3.1. Server Responses 869 7.3.1.1. Successful Request 871 If a Request message is successfully processed and the requested ALTO 872 information returned by the ALTO Server, the HTTP status code in the 873 Response MUST be set to a valid 2xx HTTP status code. 875 7.3.1.2. Invalid Request Format 877 If any component of the Request message is formatted incorrectly 878 (i.e., it does not follow Section 7.5), the ALTO Server MUST return 879 HTTP Status Code 400. 881 7.3.1.3. Unsupported Request 883 If an ALTO Server does not support the operation indicated in the 884 Request message, the ALTO Server MUST return HTTP Status Code 501. 886 7.3.2. Client Behavior 888 7.3.2.1. Successful Response 890 This specification does not indicate any required actions taken by 891 ALTO Clients upon receiving a successful response from an ALTO 892 Server. Although ALTO Clients are suggested to interpret the 893 received ALTO Information and adapt application behavior, ALTO 894 Clients may also choose to ignore the received information. 896 7.3.2.2. Error Conditions 898 If an ALTO Client does not receive a successful response from the 899 ALTO Server, it can either choose another server or fall back to a 900 default behavior (e.g., perform peer selection without the use of 901 ALTO information). 903 7.4. HTTP Usage 905 7.4.1. Authentication and Encryption 907 An ALTO Server MAY support SSL/TLS to implement server and/or client 908 authentication, as well as encryption. 910 An ALTO Server MAY support HTTP Digest authentication. 912 7.4.2. Cookies 914 Cookies MUST NOT be used. 916 7.4.3. Caching Parameters 918 If the Response generated by the ALTO Server is cachable, the ALTO 919 Server MAY include 'Cache-Control' and 'Expires' HTTP headers. 921 If a Response generated by the ALTO Server is not cachable, the ALTO 922 Server MUST specify the "Cache-Control: no-cache" HTTP Header. 924 7.5. ALTO Requests 926 This section documents the individual operations supported in the 927 ALTO Protocol. See Section 7.2.2 and Section 7.2.3 for 928 specifications of HTTP Request/Response components common to all 929 operations in the ALTO Protocol. 931 Table 1 provides an summary of the HTTP Method and URI-Paths used for 932 ALTO Requests: 934 +-------------------+-------------+----------------------------+ 935 | Service | Operation | HTTP Method and URI-Path | 936 +-------------------+-------------+----------------------------+ 937 | Server Capability | Lookup | GET /capability | 938 | | | | 939 | Map | Network Map | GET /map/core/pid/net | 940 | Map | Cost Map | GET /map/core/cost | 941 | | | | 942 | Map Filtering | Network Map | POST /map/filter/pid/net | 943 | Map Filtering | Cost Map | POST /map/filter/pid/cost | 944 | | | | 945 | Endpoint Prop. | Lookup | GET /endpoint/prop/ | 946 | | | POST /endpoint/prop/lookup | 947 | | | | 948 | Endpoint Cost | Lookup | POST /endpoint/cost/lookup | 949 +-------------------+-------------+----------------------------+ 951 Table 1: Overview of ALTO Requests 953 7.5.1. Server Capability 955 The Server Capability request allows an ALTO Client to determine the 956 functionality supported by a particular ALTO Server and references to 957 additional ALTO Servers provided by the ALTO Service Provider. 959 This operation MUST be supported by the ALTO Server. 961 7.5.1.1. Request Syntax 963 GET /capability HTTP/1.1 964 Host: 966 7.5.1.2. Response Syntax 968 HTTP/1.1 200 969 Content-Length: 970 Content-Type: application/alto 972 974 where the ALTOResponse object has "type" member equal to the string 975 "capability" and "data" member of type RspCapability: 977 enum { 978 map, 979 map_filtering, 980 endpoint_property, 981 endpoint_cost 982 } ServiceType; [Note: encoded as JSONString's] 984 struct { 985 JSONString type; 986 JSONString units; 987 } CostTypeDesc; 989 struct { 990 JSONString uri; 991 JSONNumber version; 992 ServiceType services<0..*>; 993 CostTypeDesc cost_types<0..*>; [OPTIONAL] 994 JSONBool cost_constraints; [OPTIONAL] 995 } ServerConfig; 997 struct { 998 JSONString certificate; [OPTIONAL] 999 } ServerMeta; 1001 struct { 1002 ServerConfig server_list<0..*>; 1003 ServerMeta self; 1004 } RspCapability; 1006 RspCapability has members: 1008 o server_list: Array of available ALTO Servers, detailing the URI 1009 endpoint, version, and basic capabilities provided by each. The 1010 array must at least contain an entry corresponding to the ALTO 1011 Server at the URI from which it is retrieving capability 1012 information. 1014 o self: Object encoding additional details about the ALTO Server 1015 itself. 1017 ServerConfig has members: 1019 o uri: Denotes the base HTTP URI for the ALTO Server. For example, 1020 "http://alto-v1.example.com:6671" 1022 o version: Denotes the protocol version implemented by the ALTO 1023 Server. 1025 o services: Lists the services supported by the ALTO Server. The 1026 service names defined in this document are are "map", 1027 "map_filtering", "endpoint_property", and "endpoint_cost". 1029 o cost_types: Array of cost type information for additional 1030 supported ALTO Cost types, detailing the name and units for each 1031 supported additional type. [[Comment.3: Need to discuss IANA 1032 implications or alternate approaches.]] 1034 o cost_constraints: Indicates if the ALTO Server supports cost 1035 constraints. The value 'false' is implied if this member is not 1036 present. 1038 ServerMeta has members: 1040 o certificate: PEM-encoded X.509 certificate used by the ALTO Server 1041 to sign distributed information (see Section 7.6). 1043 7.5.1.3. Example 1045 GET /capability HTTP/1.1 1046 Host: alto.example.com:6671 1048 HTTP/1.1 200 OK 1049 Content-Length: [TODO] 1050 Content-Type: application/alto 1052 { 1053 "meta" : { 1054 "version" : 1 1055 }, 1056 "type" : "capability", 1057 "data" : { 1058 "server_list" : [ 1059 { 1060 "uri": "http://alto.example.com:6671", 1061 "version" : 1, 1062 "services" : [ "map", "map-filtering" ], 1063 "cost_types": [ 1064 { "type":"latency", "units":"ms" }, 1065 { "type":"pDistance", "units":"scalar" }, 1066 { "type":"bandwidth", "units":"kbps" } 1067 ], 1068 "cost_constraints": false 1069 } 1070 ] 1071 } 1073 } 1075 7.5.2. Map Service 1077 The Map Service provides batch information to ALTO Clients in the 1078 form of two maps: a Network Map and Cost Map. 1080 An ALTO Server MUST support the Map Service and MUST implement all 1081 operations defined in this section. 1083 7.5.2.1. Network Map 1085 The full Network Map lists for each PID, the network locations 1086 (endpoints) within the PID. 1088 7.5.2.1.1. Request Syntax 1090 GET /map/core/pid/net HTTP/1.1 1091 Host: 1093 7.5.2.1.2. Response Syntax 1095 HTTP/1.1 200 1096 Content-Length: 1097 Content-Type: application/alto 1099 1101 where the ALTOResponse object has "type" member equal to the string 1102 "network_map" and "data" member of type RspNetworkMap: 1104 struct { 1105 CIDRString [pidname]<0..*>; 1106 ... 1107 } NetworkMapData; 1109 struct { 1110 JSONString map_vtag; 1111 NetworkMapData map; 1112 } RspNetworkMap; 1114 RspNetworkMap has members: 1116 o map_vtag: The Version Tag of the Network Map (Section 5.3) 1118 o map: The network map data itself. 1120 NetworkMapData is a JSON object with each member representing a 1121 single PID and its associated set of IP Prefixes (encoded as a string 1122 in CIDR notation). A member's name is a JSONString denoting the 1123 PID's name. 1125 7.5.2.1.3. Example 1127 GET /map/core/pid/net HTTP/1.1 1128 Host: alto.example.com:6671 1130 HTTP/1.1 200 OK 1131 Content-Length: [TODO] 1132 Content-Type: application/alto 1134 { 1135 "meta" : { 1136 "version" : 1 1137 }, 1138 "type" : "network_map", 1139 "data" : { 1140 "map_vtag" : "1266506139", 1141 "map" : { 1142 "PID1" : [ 1143 "192.0.2.0/24", 1144 "198.51.100.0/25" 1145 ], 1146 "PID2" : [ 1147 "198.51.100.128/25" 1148 ], 1149 "PID3" : [ 1150 "0.0.0.0/0" 1151 ] 1152 } 1153 } 1154 } 1156 7.5.2.2. Cost Map 1158 The Map Service Cost Map query is a batch operation in which the ALTO 1159 Server returns the Path Cost for each pair of source/destination PID 1160 defined by the ALTO Server. 1162 The ALTO Server provides costs using the default Cost Type 1163 ('routingcost') and default Cost Mode ('numerical'). 1165 7.5.2.2.1. Request Syntax 1167 GET /map/core/pid/cost HTTP/1.1 1168 Host: 1170 7.5.2.2.2. Response Syntax 1172 HTTP/1.1 200 1173 Content-Length: 1174 Content-Type: application/alto 1176 1178 where the ALTOResponse object has "type" member equal to the string 1179 "cost_map" and "data" member of type RspCostMap: 1181 struct DstCosts { 1182 JSONNumber [dstname]; 1183 ... 1184 }; 1186 struct { 1187 DstCosts [srcname]<0..*>; 1188 ... 1189 } CostMapData; 1191 struct { 1192 JSONString map_vtag; 1193 JSONString cost_type; 1194 JSONString cost_mode; 1195 CostMapData map; 1196 } RspCostMap; 1198 RspCostMap has members: 1200 o map_vtag: The Version Tag of the Network Map used to generate the 1201 Cost Map (Section 5.3). 1203 o cost_type: Cost Type used in the map (Section 5.1.1) 1205 o cost_mode: Cost Mode used in the map (Section 5.1.2) 1207 o map: The cost map data itself. 1209 CostMapData is a JSON object with each member representing a single 1210 Source PID. For each Source PID, a DstCosts structure denotes the 1211 associated cost to a set of destination PIDs (Section 5.2). DstCosts 1212 has a single member for each destination PID in the map. 1214 7.5.2.2.3. Example 1216 GET /map/core/pid/cost HTTP/1.1 1217 Host: alto.example.com:6671 1219 HTTP/1.1 200 OK 1220 Content-Length: [TODO] 1221 Content-Type: application/alto 1223 { 1224 "meta" : { 1225 "version" : 1 1226 }, 1227 "type" : "cost_map", 1228 "data" : { 1229 "map_vtag" : "1266506139", 1230 "cost_type" : "routingcost", 1231 "cost_mode" : "numerical", 1232 "map" : { 1233 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 1234 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 1235 "PID3": { "PID1": 20, "PID2": 15, "PID3": 1 } 1236 } 1237 } 1238 } 1240 7.5.3. Map Filtering Service 1242 The Map Filtering Service allows ALTO Clients to specify filtering 1243 criteria to return a subset of the full maps available in the Map 1244 Service. 1246 An ALTO Server MAY support the Map Filtering Service. If an ALTO 1247 Server supports the Map Filtering Service, all operations defined in 1248 this section MUST be implemented. 1250 7.5.3.1. Network Map 1252 ALTO Clients can query for a subset of the full network map (see 1253 Section 7.5.2.1). 1255 7.5.3.1.1. Request Syntax 1257 POST /map/filter/pid/net HTTP/1.1 1258 Host: 1259 Content-Length: 1261 1263 where: 1265 struct { 1266 JSONString pids<0..*>; 1267 } ReqNetworkMap; 1269 The Body of the request encodes an array of PIDs to be included in 1270 the resulting Network Map. If the list of PIDs is empty, the ALTO 1271 Server MUST interpret the list as if it contained a list of all 1272 currently-defined PIDs. 1274 7.5.3.1.2. Response Syntax 1276 The Response syntax is identical to that of the Map Service's Network 1277 Map Response (Section 7.5.2.1.2). 1279 The ALTO Server MUST only include PIDs in the Response that were 1280 specified (implicitly or explicitly) in the Request. If the Request 1281 contains a PID name that is not currently defined by the ALTO Server, 1282 the ALTO Server MUST behave as if the PID did not appear in the 1283 request. 1285 7.5.3.1.3. Example 1287 POST /map/filter/pid/net HTTP/1.1 1288 Host: alto.example.com:6671 1289 Content-Length: 1291 { 1292 pids: [ "PID1", "PID2" ] 1293 } 1295 HTTP/1.1 200 OK 1296 Content-Length: [TODO] 1297 Content-Type: application/alto 1299 { 1300 "meta" : { 1301 "version" : 1 1302 }, 1303 "type" : "network_map", 1304 "data" : { 1305 "map_vtag" : "1266506139", 1306 "map" : { 1307 "PID1" : [ 1308 "192.0.2.0/24", 1309 "198.51.100.0/24", 1310 ], 1311 "PID2" : [ 1312 "198.51.100.128/24", 1313 ] 1314 } 1315 } 1316 } 1318 7.5.3.2. Cost Map 1320 ALTO Clients can query for the Cost Map (see Section 7.5.2.2) based 1321 on additional parameters. 1323 7.5.3.2.1. Request Syntax 1325 POST /map/filter/pid/cost? HTTP/1.1 1326 Host: 1328 1330 where: 1332 struct { 1333 JSONString srcs<0..*>; 1334 JSONString dsts<0..*>; 1335 } ReqCostMap; 1337 The Query String may contain the following parameters: 1339 o type: The requested Cost Type (Section 5.1.1). If not specified, 1340 the default value is "routingcost". This parameter MUST NOT be 1341 specified multiple times. 1343 o mode: The requested Cost mode (Section 5.1.2). If not specified, 1344 the default value is "numerical". This parameter MUST NOT be 1345 specified multiple times. 1347 o constraint: Defines a constraint on which elements of the Cost Map 1348 are returned. This parameter MUST NOT be used if the Server 1349 Capability Response (Section 7.5.1) indicates that constraint 1350 support is not available. A constraint contains two entities 1351 separated by whitespace (before URL encoding): (1) an operator 1352 either 'gt' for greater than , 'lt' for less than or 'eq' for 1353 equal to with 10 percent on either side, (2) a target numerical 1354 cost. The numerical cost is a number that MUST be defined in the 1355 units specified in the Server Capability Response. If multiple 1356 'constraint' parameters are specified, the ALTO Server assumes 1357 they are related to each other with a logical AND. If no 1358 'constraint' parameters are specified, then the ALTO Server 1359 returns the full Cost Map. 1361 The Request body MAY specify a list of Source PIDs, and a list of 1362 Destination PIDs. If a list is empty, it is interpreted by the ALTO 1363 Server as the full set of currently-defined PIDs. The ALTO Server 1364 returns costs between each pair of source/destination PID. If the 1365 Request body is empty, both lists are interpreted to be empty. 1367 7.5.3.2.2. Response Syntax 1369 The Response syntax is identical to that of the Map Service's Cost 1370 Map Response (Section 7.5.2.2.2). 1372 The Response MUST NOT contain any source/destination pair that was 1373 not indicated (implicitly or explicitly) in the Request. If the 1374 Request contains a PID name that is not currently defined by the ALTO 1375 Server, the ALTO Server MUST behave as if the PID did not appear in 1376 the request. 1378 7.5.3.2.3. Example 1380 POST /map/filter/pid/cost?type=hopcount HTTP/1.1 1381 Host: alto.example.com:6671 1383 { 1384 "srcs" : [ "PID1" ], 1385 "dsts" : [ "PID1", "PID2", "PID3" ] 1386 } 1388 HTTP/1.1 200 OK 1389 Content-Length: [TODO] 1390 Content-Type: application/alto 1392 { 1393 "meta" : { 1394 "version" : 1 1395 }, 1396 "type" : "cost_map", 1397 "data" : { 1398 "map_vtag" : "1266506139", 1399 "cost_type" : "hopcount", 1400 "cost_mode" : "numerical", 1401 "map" : { 1402 "PID1": { "PID1": 0, "PID2": 1, "PID3": 2 } 1403 } 1404 } 1405 } 1407 7.5.4. Endpoint Property Service 1409 The Endpoint Property Lookup query allows an ALTO Client to lookup 1410 properties of Endpoints known to the ALTO Server. If the ALTO Server 1411 provides the Endpoint Property Service, the ALTO Server MUST define 1412 at least the 'pid' property for Endpoints. [TODO: Additional 1413 supported properties can be defined in the Server Capability 1414 response.] 1416 An ALTO Server MAY support the Endpoint Property Service. If an ALTO 1417 Server supports the Endpoint Property Service, all operations defined 1418 in this section MUST be implemented. 1420 7.5.4.1. Endpoint Property Lookup 1421 7.5.4.1.1. Request Syntax 1423 POST /endpoint/prop/lookup? HTTP/1.1 1424 Host: 1425 Content-Length: 1427 1429 where: 1431 struct { 1432 JSONString endpoints<0..*>; 1433 } ReqEndpointProp; 1435 The Query String may contain the following parameters: 1437 o prop: The requested property type. This parameter MUST be 1438 specified at least once, and MAY be specified multiple times 1439 (e.g., to query for multiple different properties at once). 1441 The body encodes a list of endpoints (IP addresses) as strings. 1443 An alternate syntax is supported for the case when properties are 1444 requested for a single endpoint: 1446 GET /endpoint/prop/? HTTP/1.1 1447 Host: 1449 where the Query String is the same as in the first form. 1451 7.5.4.1.2. Response Syntax 1453 HTTP/1.1 200 1454 Content-Length: 1455 Content-Type: application/alto 1457 1459 where the ALTOResponse object has "type" member equal to the string 1460 "endpoint_property" and "data" member of type RspEndpointProperty: 1462 struct { 1463 JSONString [propertyname]; 1464 ... 1465 } EndpointProps; 1467 struct { 1468 EndpointProps [endpointname]<0..*>; 1469 ... 1470 } RspEndpointProperty; 1472 RspEndpointProperty has one member for each endpoint indicated in the 1473 Request. The requested properties for each endpoint are encoded in a 1474 corresponding EndpointProps object, which encodes one name/value pair 1475 for each requested property. Note that property values are JSON 1476 Strings. If the ALTO Server does not define a requested property for 1477 a particular endpoint, then it MUST omit it from the Response for 1478 only that endpoint. 1480 7.5.4.1.3. Example 1482 POST /endpoint/prop/lookup?prop=pid HTTP/1.1 1483 Host: alto.example.com:6671 1484 Content-Length: [TODO] 1486 { 1487 "endpoints" : [ "192.0.2.34", "203.0.113.129" ] 1488 } 1490 HTTP/1.1 200 OK 1491 Content-Length: [TODO] 1492 Content-Type: application/alto 1494 { 1495 "meta" : , 1496 "type" : "endpoint_property", 1497 "data": { 1498 "192.0.2.34" : { "pid": "PID1" }, 1499 "203.0.113.129" : { "pid": "PID3" } 1500 } 1501 } 1503 7.5.5. Endpoint Cost Service 1505 The Endpoint Cost Service allows ALTO Clients to directly supply 1506 endpoints to an ALTO Server. The ALTO Server replies with costs 1507 (numerical or ordinal) amongst the endpoints. 1509 In particular, this service allows lists of Endpoint addresses to be 1510 ranked (ordered) by an ALTO Server. 1512 An ALTO Server MAY support the Endpoint Cost Service. If an ALTO 1513 Server supports the Endpoint Cost Service, all operations defined in 1514 this section MUST be implemented. 1516 7.5.5.1. Endpoint Cost Lookup 1518 7.5.5.1.1. Request Syntax 1520 POST /endpoint/cost/lookup? HTTP/1.1 1521 Host: 1522 Content-Length: 1524 1526 The request body includes a list of source and destination endpoints 1527 that should be assigned a cost by the ALTO Server. The allowed Query 1528 String parameters are defined identically to Section 7.5.3.2. 1530 The request body MUST specify a list of source Endpoints, and a list 1531 of destination Endpoints, using an structure identical to 1532 Section 7.5.3.2 with the exception that identifiers are endpoints 1533 instead of PIDs. If the list of source Endpoints is empty (or it is 1534 not included), the ALTO Server MUST treat it as if it contained the 1535 Endpoint address of the requesting client. The list of destination 1536 Endpoints MUST NOT be empty. The ALTO Server returns costs between 1537 each pair of source/destination Endpoint. 1539 7.5.5.1.2. Response Syntax 1541 HTTP/1.1 200 1542 Content-Length: 1543 Content-Type: application/alto 1545 1547 where ALTOResponse is encoded identically to Section 7.5.2.2.2 with 1548 the following exceptions: 1550 o ALTO Response's "type" member must be equal to 1551 "endpoint_cost_map", 1553 o The "map_vtag" member of RspCostMap MUST be omitted, and 1555 o Identifiers refer to endpoints instead of PIDs. 1557 7.5.5.1.3. Example 1559 POST /endpoint/cost/lookup?mode=ordinal HTTP/1.1 1560 Host: alto.example.com:6671 1561 Content-Length: [TODO] 1563 { 1564 "src": [ "192.0.2.2" ], 1565 "dst": [ "192.0.2.89", "198.51.100.34", "203.0.113.45" ] 1566 } 1568 HTTP/1.1 200 OK 1569 Content-Length: [TODO] 1570 Content-Type: application/alto 1572 { 1573 "meta" : { 1574 "version" : 1 1575 }, 1576 "type" : "endpoint_cost_map", 1577 "data" : { 1578 "cost-type" : "routingcost", 1579 "cost-mode" : "ordinal", 1580 "map" : { 1581 "192.0.2.2": { 1582 "192.0.2.89" : 1, 1583 "198.51.100.34" : 2, 1584 "203.0.113.45" : 3 1585 } 1586 } 1587 } 1588 } 1590 7.6. Redistributable Responses 1592 An ALTO Server MAY indicate that a response is suitable for 1593 redistribution by including the "redistribution" member in the 1594 RspMetaData JSON object of an ALTO Response message. This additional 1595 member has type RspRedistInfo: 1597 struct { 1598 JSONString server; 1599 JSONString request_uri; 1600 JSONValue request_body; 1601 JSONString expires; 1602 } RspRedistInfo; 1604 If an ALTO Server indicates the that the response is redistributable, 1605 the Response message MUST satisfy all requirements in this section. 1607 7.6.1. Server and Request Parameters 1609 The ALTO Server generating the response indicates its own address and 1610 any input parameters used to generate the response. This allows ALTO 1611 Clients to which the information is distributed to understand the 1612 context of the query and interpret the results. This information is 1613 encoded in the RspRedistInfo JSON Object. 1615 The 'server' member is REQUIRED and MUST have a value equal to the 1616 ALTO Server's hostname and port, in a format identical to the HTTP 1617 1.1 Host header. 1619 The 'request_uri' member is REQUIRED and MUST specify the HTTP 1620 Request-URI that was passed in the HTTP Request. 1622 If the HTTP Request body was non-empty, the 'request_body' member 1623 MUST specify full JSON value passed in the HTTP Request (note that 1624 whitespace may differ, as long as the JSON Value is identical). If 1625 the HTTP Request was empty, then the 'request_body' MUST NOT be 1626 included. 1628 Note that information about ALTO Client performing the Request and 1629 any HTTP Headers passed in the request are not included. If any such 1630 information or headers influence the response generated by the ALTO 1631 Server, the response SHOULD NOT be indicated as redistributable. 1633 7.6.2. Expiration Time 1635 ALTO Responses marked as redistributable SHOULD indicate a time after 1636 which the information is considered stale and should be refreshed 1637 from the ALTO Server (or possibly another ALTO Client). 1639 The 'expires' element is RECOMMENDED and, if present, MUST specify a 1640 time in UTC formatted according to [5]. 1642 If an expiration time is present, the ALTO Server SHOULD ensure that 1643 it is reasonably consistent with the expiration time that would be 1644 computed by HTTP header fields. If the expiration time in the 1645 'expires' element is earlier, some ALTO Clients may refresh data from 1646 the ALTO Server earlier than expected. If the expiration time 1647 included in the response body is later, some ALTO Clients may refresh 1648 the data later than expected. 1650 7.6.3. Signature 1652 ALTO Responses marked as redistributable MUST include a signature 1653 used to assert that the ALTO Server Provider generated the ALTO 1654 Information. 1656 Verification of the signature requires the ALTO Client to retrieve 1657 the ALTO Server's public key. There are multiple possibilities to 1658 retrieve it: 1660 o SSL/TLS connection with the ALTO Server: The public key algorithm 1661 and public key may be retrieved from the ALTO Server's X.509 1662 Certificate used on an HTTPS connection between the ALTO Server 1663 and ALTO Client. 1665 o Included in ALTO Server's Server Capability Response: If the ALTO 1666 Client requests from the ALTO Server over a non SSL/TLS 1667 connection, an X.509 certificate (including the public key and 1668 public key algorithm) can be included in the Server Capability 1669 Response. 1671 To reduce requirements on the underlying transport (i.e., requiring 1672 SSL/TLS), the ALTO Protocol uses the latter option. Thus, if an ALTO 1673 Server marks any Response as redistributable, the Server Capability 1674 Response MUST include a PEM-encoded X.509 certificate. This 1675 specification does not mandate any requirements on the X.509 1676 certificate (other than consistency between its public key and the 1677 signature in redistributable ALTO Responses), but ALTO Clients SHOULD 1678 verify that the certificate satisfies any local policies (e.g., 1679 Issuer, expiration date, etc). 1681 The ALTO Server may include the Hash Algorithm, Signature Algorithm, 1682 and Signature in either HTTP Headers or Trailers. Headers may be 1683 useful if Responses are pre-generated, while Trailers may be useful 1684 if Responses are dynamically generated (e.g., to avoid buffering 1685 large responses in memory while the hash value is computed). 1687 The following HTTP Headers (the ALTO Server MAY specify them as HTTP 1688 Trailers) are used to encode the Signature parameters: 1690 X-ALTO-HashAlgorithm: 1691 X-ALTO-SignatureAlgorithm: 1692 X-ALTO-SignatureDigest: 1694 where and are an integer values 1695 from the IANA TLS HashAlgorithm and SignatureAlgorithm registries, 1696 and is the corresponding PEM-encoded signature. 1698 ALTO Clients SHOULD pass the ALTO Server Certificate, Signature, and 1699 Signature Algorithm along with the body of the ALTO Response. The 1700 mechanism for redistributing such information is not specified by the 1701 ALTO Protocol, but one possibility is to add additional messages or 1702 fields to the application's native protocol. 1704 8. Use Cases 1706 The sections below depict typical use cases. 1708 8.1. ALTO Client Embedded in P2P Tracker 1710 Many P2P currently-deployed P2P systems use a Tracker to manage 1711 swarms and perform peer selection. P2P trackers may currently use a 1712 variety of information to perform peer selection to meet application- 1713 specific goals. By acting as an ALTO Client, an P2P tracker can use 1714 ALTO information as an additional information source to enable more 1715 network-efficient traffic patterns and improve application 1716 performance. 1718 A particular requirement of many P2P trackers is that they must 1719 handle a large number of P2P clients. A P2P tracker can obtain and 1720 locally store ALTO information (the Network Map and Cost Map) from 1721 the ISPs containing the P2P clients, and benefit from the same 1722 aggregation of network locations done by ALTO Servers. 1724 .---------. (1) Get Network Map .---------------. 1725 | | <----------------------> | | 1726 | ALTO | | P2P Tracker | 1727 | Server | (2) Get Cost Map | (ALTO Client) | 1728 | | <----------------------> | | 1729 `---------' `---------------' 1730 ^ | 1731 (3) Get Peers | | (4) Selected Peer 1732 | v List 1733 .---------. .-----------. 1734 | Peer 1 | <-------------- | P2P | 1735 `---------' | Client | 1736 . (5) Connect to `-----------' 1737 . Selected Peers / 1738 .---------. / 1739 | Peer 50 | <------------------ 1740 `---------' 1742 Figure 3: ALTO Client Embedded in P2P Tracker 1744 Figure 3 shows an example use case where a P2P tracker is an ALTO 1745 Client and applies ALTO information when selecting peers for its P2P 1746 clients. The example proceeds as follows: 1748 1. The P2P Tracker requests the Network Map covering all PIDs from 1749 the ALTO Server using the Network Map query. The Network Map 1750 includes the IP prefixes contained in each PID, allowing the P2P 1751 tracker to locally map P2P clients into a PIDs. 1753 2. The P2P Tracker requests the Cost Map amongst all PIDs from the 1754 ALTO Server. 1756 3. A P2P Client joins the swarm, and requests a peer list from the 1757 P2P Tracker. 1759 4. The P2P Tracker returns a peer list to the P2P client. The 1760 returned peer list is computed based on the Network Map and Cost 1761 Map returned by the ALTO Server, and possibly other information 1762 sources. Note that it is possible that a tracker may use only 1763 the Network Map to implement hierarchical peer selection by 1764 preferring peers within the same PID and ISP. 1766 5. The P2P Client connects to the selected peers. 1768 Note that the P2P tracker may provide peer lists to P2P clients 1769 distributed across multiple ISPs. In such a case, the P2P tracker 1770 may communicate with multiple ALTO Servers. 1772 8.2. ALTO Client Embedded in P2P Client: Numerical Costs 1774 P2P clients may also utilize ALTO information themselves when 1775 selecting from available peers. It is important to note that not all 1776 P2P systems use a P2P tracker for peer discovery and selection. 1777 Furthermore, even when a P2P tracker is used, the P2P clients may 1778 rely on other sources, such as peer exchange and DHTs, to discover 1779 peers. 1781 When an P2P Client uses ALTO information, it typically queries only 1782 the ALTO Server servicing its own ISP. The my-Internet view provided 1783 by its ISP's ALTO Server can include preferences to all potential 1784 peers. 1786 .---------. (1) Get Network Map .---------------. 1787 | | <----------------------> | | 1788 | ALTO | | P2P Client | 1789 | Server | (2) Get Cost Map | (ALTO Client) | 1790 | | <----------------------> | | .---------. 1791 `---------' `---------------' <- | P2P | 1792 .---------. / | ^ ^ | Tracker | 1793 | Peer 1 | <-------------- | | \ `---------' 1794 `---------' | (3) Gather Peers 1795 . (4) Select Peers | | \ 1796 . and Connect / .--------. .--------. 1797 .---------. / | P2P | | DHT | 1798 | Peer 50 | <---------------- | Client | `--------' 1799 `---------' | (PEX) | 1800 `--------' 1802 Figure 4: ALTO Client Embedded in P2P Client 1804 Figure 4 shows an example use case where a P2P Client locally applies 1805 ALTO information to select peers. The use case proceeds as follows: 1807 1. The P2P Client requests the Network Map covering all PIDs from 1808 the ALTO Server servicing its own ISP. 1810 2. The P2P Client requests the Cost Map amongst all PIDs from the 1811 ALTO Server. The Cost Map by default specifies numerical costs. 1813 3. The P2P Client discovers peers from sources such as Peer Exchange 1814 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 1815 P2P Trackers. 1817 4. The P2P Client uses ALTO information as part of the algorithm for 1818 selecting new peers, and connects to the selected peers. 1820 8.3. ALTO Client Embedded in P2P Client: Ranking 1822 It is also possible for a P2P Client to offload the selection and 1823 ranking process to an ALTO Server. In this use case, the ALTO Client 1824 gathers a list of known peers in the swarm, and asks the ALTO Server 1825 to rank them. 1827 As in the use case using numerical costs, the P2P Client typically 1828 only queries the ALTO Server servicing its own ISP. 1830 .---------. .---------------. 1831 | | | | 1832 | ALTO | (2) Get Endpoint Ranking | P2P Client | 1833 | Server | <----------------------> | (ALTO Client) | 1834 | | | | .---------. 1835 `---------' `---------------' <- | P2P | 1836 .---------. / | ^ ^ | Tracker | 1837 | Peer 1 | <-------------- | | \ `---------' 1838 `---------' | (1) Gather Peers 1839 . (3) Connect to | | \ 1840 . Selected Peers / .--------. .--------. 1841 .---------. / | P2P | | DHT | 1842 | Peer 50 | <---------------- | Client | `--------' 1843 `---------' | (PEX) | 1844 `--------' 1846 Figure 5: ALTO Client Embedded in P2P Client: Ranking 1848 Figure 5 shows an example of this scenario. The use case proceeds as 1849 follows: 1851 1. The P2P Client discovers peers from sources such as Peer Exchange 1852 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 1853 P2P Trackers. 1855 2. The P2P Client queries the ALTO Server's Ranking Service, 1856 including discovered peers as the set of Destination Endpoints, 1857 and indicates the 'ordinal' Cost Mode. The response indicates 1858 the ranking of the candidate peers. 1860 3. The P2P Client connects to the peers in the order specified in 1861 the ranking. 1863 9. Discussions 1865 9.1. Discovery 1867 The particular mechanism by which an ALTO Client discovers its ALTO 1868 Server is an important component to the ALTO architecture and 1869 numerous techniques have been discussed [15] [16]. However, the 1870 discovery mechanism is out of scope for this document. 1872 Some ISPs have proposed the possibility of delegation, in which an 1873 ISP provides information for customer networks which do not wish to 1874 run Portal Servers themselves. A consideration for delegation is 1875 that customer networks may wish to explicitly configure such 1876 delegation. 1878 9.2. Network Address Translation Considerations 1880 At this day and age of NAT v4<->v4, v4<->v6 [17], and possibly 1881 v6<->v6[18], a protocol should strive to be NAT friendly and minimize 1882 carrying IP addresses in the payload, or provide a mode of operation 1883 where the source IP address provide the information necessary to the 1884 server. 1886 The protocol specified in this document provides a mode of operation 1887 where the source network location is computed by the ALTO Server (via 1888 the Endpoint Property Lookup interface) from the source IP address 1889 found in the ALTO Client query packets. This is similar to how some 1890 P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS 1891 Protocol" in [19]) operate. 1893 The ALTO client SHOULD use the Session Traversal Utilities for NAT 1894 (STUN) [6] to determine a public IP address to use as a source NL-ID. 1895 If using this method, the host MUST use the "Binding Request" message 1896 and the resulting "XOR-MAPPED-ADDRESS" parameter that is returned in 1897 the response. Using STUN requires cooperation from a publicly 1898 accessible STUN server. Thus, the ALTO client also requires 1899 configuration information that identifies the STUN server, or a 1900 domain name that can be used for STUN server discovery. To be 1901 selected for this purpose, the STUN server needs to provide the 1902 public reflexive transport address of the host. 1904 9.3. Mapping IPs to ASNs 1906 It may be desired for the ALTO Protocol to provide ALTO information 1907 including ASNs. Thus, ALTO Clients may need to identify the ASN for 1908 a Resource Provider to determine the cost to that Resource Provider. 1910 Applications can already map IPs to ASNs using information from a BGP 1911 Looking Glass. To do so, they must download a file of about 1.5MB 1912 when compressed (as of October 2008, with all information not needed 1913 for IP to ASN mapping removed) and periodically (perhaps monthly) 1914 refresh it. 1916 Alternatively, the Network Map query in the Map Filtering Service 1917 defined in this document could be extended to map ASNs into a set of 1918 IP prefixes. The mappings provided by the ISP would be both smaller 1919 and more authoritative. 1921 For simplicity of implementation, it's highly desirable that clients 1922 only have to implement exactly one mechanism of mapping IPs to ASNs. 1924 9.4. Endpoint and Path Properties 1926 An ALTO Server could make available many properties about Endpoints 1927 beyond their network location or grouping. For example, connection 1928 type, geographical location, and others may be useful to 1929 applications. The current draft focuses on network location and 1930 grouping, but the protocol may be extended to handle other Endpoint 1931 properties. 1933 9.5. P2P Peer Selection 1935 This section discusses possible approaches to peer selection using 1936 ALTO information (Network Location Identifiers and associated Costs) 1937 from an ALTO Server. Specifically, the application must select which 1938 peers to use based on this and other sources of information. With 1939 this in mind, the usage of ALTO Costs is intentionally flexible, 1940 because: 1942 Different applications may use the information differently. For 1943 example, an application that connects to just one address may have 1944 a different algorithm for selecting it than an application that 1945 connects to many. 1947 Though initial experiments have been conducted [20], more 1948 investigation is needed to identify other methods. 1950 In addition, the application might account for robustness, perhaps 1951 using randomized exploration to determine if it performs better 1952 without ALTO information. 1954 9.5.1. Client-based Peer Selection 1956 One possibility is for peer selection using ALTO costs to be done 1957 entirely by a P2P client. The following are some techniques have 1958 been proposed and/or used: 1960 o Prefer network locations with lower ordinal rankings (i.e., higher 1961 priority) [21] [10]. 1963 o Optimistically unchoking low-cost peers with higher probability 1964 [10]. 1966 9.5.2. Server-based Peer Selection 1968 Another possibility is for ALTO costs to be used by an Application 1969 Tracker (e.g., BitTorrent Tracker) when returning peer lists. The 1970 following are techniques that have been proposed and/or used: 1972 o Using bandwidth matching (e.g., at an Application Tracker) and 1973 choosing solution (within bound of optimal) with minimal network 1974 cost [20]. 1976 10. IANA Considerations 1978 This document request the registration of a new media type: 1979 "application/alto" 1981 11. Security Considerations 1983 11.1. Privacy Considerations for ISPs 1985 ISPs must be cognizant of the network topology and provisioning 1986 information provided through ALTO Interfaces. ISPs should evaluate 1987 how much information is revealed and the associated risks. On the 1988 one hand, providing overly fine-grained information may make it 1989 easier for attackers to infer network topology. In particular, 1990 attackers may try to infer details regarding ISPs' operational 1991 policies, inter-ISP business relationships, etc. by intenionally 1992 posting a multitude of selective queries to an ALTO server (and 1993 carefully analyzing the responses). Such sophisticated attacks may 1994 reveal more information than an ISP hosting an ALTO server intends to 1995 disclose. On the other hand, revealing overly coarse-grained 1996 information may not provide benefits to network efficiency or 1997 performance improvements to ALTO Clients. 1999 11.2. ALTO Clients 2001 Applications using the information must be cognizant of the 2002 possibility that the information is malformed or incorrect. Even if 2003 an ALTO Server has been properly authenticated by the ALTO Client, 2004 the information provided may be malicious because the ALTO Server and 2005 its credentials have been compromised (e.g., through malware). Other 2006 considerations (e.g., relating to application performance) can be 2007 found in Section 6 of [13]. 2009 ALTO Clients should also be cognizant of revealing Network Location 2010 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, 2011 as doing so may allow the ALTO Server to infer communication 2012 patterns. One possibility is for the ALTO Client to only rely on 2013 Network Map for PIDs and Cost Map amongst PIDs to avoid passing IP 2014 addresses of their peers to the ALTO Server. 2016 In addition, ALTO clients should be cautious not to unintentionally 2017 or indirectly disclose the resource identifier (of which they try to 2018 improve the retrieval through ALTO-guidance), e.g., the name/ 2019 identifier of a certain video stream in P2P live streaming, to the 2020 ALTO server. Note that the ALTO Protocol specified in this document 2021 does not explicitly reveal any resource identifier to the ALTO 2022 Server. However, for instance, depending on the popularity or other 2023 specifics (such as language) of the resource, an ALTO server could 2024 potentially deduce information about the desired resource from 2025 information such as the Network Locations the client sends as part of 2026 its request to the server. 2028 11.3. Authentication, Integrity Protection, and Encryption 2030 SSL/TLS can provide encryption of transmitted messages as well as 2031 authentication of the ALTO Client and Server. HTTP Basic or Digest 2032 authentication can provide authentication of the client (combined 2033 with SSL/TLS, it can additionally provide encryption and 2034 authentication of the server). 2036 An ALTO Server may optionally use authentication (and potentially 2037 encryption) to protect ALTO information it provides. This can be 2038 achieved by digitally signing a hash of the ALTO information itself 2039 and attaching the signature to the ALTO information. There may be 2040 special use cases where encryption of ALTO information is desirable. 2041 In most cases, however, information sent out by an ALTO Server is 2042 most likely to be regarded as non-confidential information. 2044 ISPs should be cognizant that encryption only protects ALTO 2045 information until it is decrypted by the intended ALTO Client. 2046 Digital Rights Management (DRM) techniques and legal agreements 2047 protecting ALTO information are outside of the scope of this 2048 document. 2050 11.4. ALTO Information Redistribution 2052 It is possible for applications to redistribute ALTO information to 2053 improve scalability. Even with such a distribution scheme, ALTO 2054 Clients obtaining ALTO information must be able to validate the 2055 received ALTO information to ensure that it was actually generated by 2056 the correct ALTO Server. Further, to prevent the ALTO Server from 2057 being a target of attack, the verification scheme must not require 2058 ALTO Clients to contact the ALTO Server to validate every set of 2059 information. Note that in any case, contacting the originating ALTO 2060 server for information validation would undermine the intended effect 2061 of redistribution and is therefore not desirable. 2063 Note that the redistribution scheme must additionally handle details 2064 such as ensuring ALTO Clients retrieve ALTO information from the 2065 correct ALTO Server. See [22] and [23] for further discussion. 2067 Details of a particular redistribution scheme are outside the scope 2068 of this document. 2070 To fulfill these requirements, ALTO Information meant to be 2071 redistributable contains a digital signature which includes a hash of 2072 the ALTO information signed by the ALTO Server with its private key. 2073 The corresponding public key should either be part of the ALTO 2074 information itself, or it could be included in the server capability 2075 response. The public key SHOULD include the hostname of the ALTO 2076 Server and it SHOULD be signed by a trusted authority (i.e., in a 2077 certificate). This an ALTO client retrieving redistributed ALTO 2078 information to verify the correctness of the ALTO Server's signature, 2079 given that it trusts the authority which signed the ALTO Server's 2080 certificate. Note that in some cases this requires that the 2081 retrieving ALTO Client must be able to derive a transitive 2082 certificate chain (including a Root-CA) to the trusted authority 2083 which signed the ALTO Server's certificate. This requirement may not 2084 be possible to fulfill between every ALTO Client / ALTO Server 2085 combination on the Internet due to the lack of a world-wide public 2086 key infrastructure. 2088 11.5. Denial of Service 2090 ISPs should be cognizant of the workload at the ALTO Server generated 2091 by certain ALTO Queries, such as certain queries to the Map Filtering 2092 Service and Ranking Service. In particular, queries which can be 2093 generated with low effort but result in expensive workloads at the 2094 ALTO Server could be exploited for Denial-of-Service attacks. For 2095 instance, a simple ALTO query with n Source Network Locations and m 2096 Destination Network Locations can be generated fairly easily but 2097 results in the computation of n*m Path Costs between pairs by the 2098 ALTO Server (see Section 5.2). One way to limit Denial-of-Service 2099 attacks is to employ access control to the ALTO server. Another 2100 possible mechanism for an ALTO Server to protect itself against a 2101 multitude of computationally expensive bogus requests is to demand 2102 that each ALTO Client to solve a computational puzzle first before 2103 allocating resources for answering a request (see, e.g., [24]). The 2104 current specification the current specification does not use such 2105 computational puzzles, and discussion regarding tradeoffs of such an 2106 approach would be needed before including such a technique in the 2107 ALTO Protocol. 2109 ISPs should also leverage the fact that the the Map Service allows 2110 ALTO Servers to pre-generate maps that can be useful to many ALTO 2111 Clients. 2113 11.6. ALTO Server Access Control 2115 In order to limit access to an ALTO server (e.g., for an ISP to only 2116 allow its users to access its ALTO server, or to prevent Denial-of- 2117 Service attacks by arbitrary hosts from the Internet), an ALTO server 2118 may employ access control policies. Depending on the use-case and 2119 scenario, an ALTO server may restrict access to its services more 2120 strictly or rather openly (see [25] for a more detailed discussion on 2121 this issue). 2123 12. References 2125 12.1. Normative References 2127 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2128 Levels", BCP 14, RFC 2119, March 1997. 2130 [2] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 2131 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 2133 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 2134 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 2135 HTTP/1.1", RFC 2616, June 1999. 2137 [4] Crockford, D., "The application/json Media Type for JavaScript 2138 Object Notation (JSON)", RFC 4627, July 2006. 2140 [5] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: 2141 Timestamps", RFC 3339, July 2002. 2143 [6] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 2144 Traversal Utilities for (NAT) (STUN)", 2145 draft-ietf-behave-rfc3489bis-18 (work in progress), July 2008. 2147 12.2. Informative References 2149 [7] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, 2150 "Application-Layer Traffic Optimization (ALTO) Requirements", 2151 draft-kiesel-alto-reqs-01 (work in progress), November 2008. 2153 [8] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, "P4P: 2154 Provider Portal for P2P Applications", draft-p4p-framework-00 2155 (work in progress), November 2008. 2157 [9] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, "P4P 2158 Protocol Specification", draft-wang-alto-p4p-specification-00 2159 (work in progress), March 2009. 2161 [10] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 2162 Export Service", draft-shalunov-alto-infoexport-00 (work in 2163 progress), October 2008. 2165 [11] Das, S. and V. Narayanan, "A Client to Service Query Response 2166 Protocol for ALTO", draft-saumitra-alto-queryresponse-00 (work 2167 in progress), March 2009. 2169 [12] Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 2170 Dimensional Peer Selection Problem", 2171 draft-saumitra-alto-multi-ps-00 (work in progress), 2172 October 2008. 2174 [13] Seedorf, J. and E. Burger, "Application-Layer Traffic 2175 Optimization (ALTO) Problem Statement", RFC 5693, October 2009. 2177 [14] Yang, Y., Popkin, L., Penno, R., and S. Shalunov, "An 2178 Architecture of ALTO for P2P Applications", 2179 draft-yang-alto-architecture-00 (work in progress), March 2009. 2181 [15] Garcia, G., Tomsu, M., and Y. Wang, "ALTO Discovery Protocols", 2182 draft-wang-alto-discovery-00 (work in progress), March 2009. 2184 [16] Song, H., Even, R., Pascual, V., and Y. Zhang, "Application- 2185 Layer Traffic Optimization (ALTO): Discover ALTO Servers", 2186 draft-song-alto-server-discovery-00 (work in progress), 2187 March 2009. 2189 [17] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 2190 Translation", draft-baker-behave-v4v6-framework-02 (work in 2191 progress), February 2009. 2193 [18] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address 2194 Translation (NAT66)", draft-mrw-behave-nat66-02 (work in 2195 progress), March 2009. 2197 [19] "Bittorrent Protocol Specification v1.0", 2198 http://wiki.theory.org/BitTorrentSpecification, 2009. 2200 [20] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A. 2201 Silberschatz., "P4P: Provider Portal for (P2P) Applications", 2202 In SIGCOMM 2008. 2204 [21] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 2205 Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00 2206 (work in progress), March 2009. 2208 [22] Yingjie, G., Alimi, R., and R. Even, "ALTO Information 2209 Redistribution", draft-gu-alto-redistribution-02 (work in 2210 progress), March 2010. 2212 [23] Stiemerling, M., "ALTO Information Redistribution Considered 2213 Harmful", draft-stiemerling-alto-info-redist-00 (work in 2214 progress), August 2009. 2216 [24] Jennings, C., "Computational Puzzles for SPAM Reduction in 2217 SIP", draft-jennings-sip-hashcash-06 (work in progress), 2218 July 2007. 2220 [25] Stiemerling, M. and S. Kiesel, "ALTO Deployment 2221 Considerations", draft-stiemerling-alto-deployments-02 (work in 2222 progress), March 2010. 2224 Appendix A. ALTO Protocol Grammar 2226 All of the mechanisms specified in this document are described in 2227 both prose and an augmented Backus-Naur Form (BNF) defined in RFC 2228 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that 2229 are used by this specification, and not repeated here. Implementers 2230 need to be familiar with the notation and content of RFC 2234 in 2231 order to understand this specification. Certain basic rules are in 2232 uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle 2233 brackets are used within definitions to clarify the use of rule 2234 names. 2236 TODO 2238 Appendix B. Acknowledgments 2240 Thank you to Jan Seedorf for contributions to the Security 2241 Considerations section. 2243 We would like to thank the following people whose input and 2244 involvement was indispensable in achieving this merged proposal: 2246 Obi Akonjang (DT Labs/TU Berlin), 2248 Saumitra M. Das (Qualcomm Inc.), 2250 Syon Ding (China Telecom), 2252 Doug Pasko (Verizon), 2253 Laird Popkin (Pando Networks), 2255 Satish Raghunath (Juniper Networks), 2257 Albert Tian (Ericsson/Redback), 2259 Yu-Shun Wang (Microsoft), 2261 David Zhang (PPLive), 2263 Yunfei Zhang (China Mobile). 2265 We would also like to thank the following additional people who were 2266 involved in the projects that contributed to this merged document: 2267 Alex Gerber (AT&T), Chris Griffiths (Comcast), Ramit Hora (Pando 2268 Networks), Arvind Krishnamurthy (University of Washington), Marty 2269 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 2270 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T), 2271 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 2272 Damien Saucez (UCL) Thomas Scholl (AT&T), Emilio Sepulveda 2273 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 2274 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 2275 (Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia 2276 Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University), 2277 Haiyong Xie (Yale University). 2279 Appendix C. Authors 2281 [[Comment.4: RFC Editor: Please move information in this section to 2282 the Authors' Addresses section at publication time.]] 2284 Stefano Previdi 2285 Cisco 2287 Email: sprevidi@cisco.com 2289 Stanislav Shalunov 2290 BitTorrent 2292 Email: shalunov@bittorrent.com 2294 Richard Woundy 2295 Comcast 2297 Richard_Woundy@cable.comcast.com 2299 Authors' Addresses 2301 Richard Alimi (editor) 2302 Yale University 2304 Email: richard.alimi@yale.edu 2306 Reinaldo Penno (editor) 2307 Juniper Networks 2308 1194 N Mathilda Avenue 2309 Sunnyvale, CA 2310 USA 2312 Email: rpenno@juniper.net 2314 Y. Richard Yang (editor) 2315 Yale University 2317 Email: yry@cs.yale.edu