idnits 2.17.1 draft-ietf-alto-protocol-07.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 916 has weird spacing: '...etaData meta...' == Line 917 has weird spacing: '...NString typ...' == Line 941 has weird spacing: '...istDesc redis...' == Line 1273 has weird spacing: '...NString uri;...' == Line 1274 has weird spacing: '...NNumber vers...' == (8 more instances...) -- The document date (March 14, 2011) is 4789 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 209 -- Looks like a reference, but probably isn't: 'RspDataType' on line 918 -- Looks like a reference, but probably isn't: 'OPTIONAL' on line 1350 -- Looks like a reference, but probably isn't: 'TODO' on line 1942 ** 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) ** Obsolete normative reference: RFC 4366 (ref. '5') (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 5226 (ref. '10') (Obsoleted by RFC 8126) == Outdated reference: A later version (-02) exists of draft-kiesel-alto-reqs-01 == Outdated reference: A later version (-04) exists of draft-zyp-json-schema-03 Summary: 6 errors (**), 0 flaws (~~), 9 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 Google 4 Intended status: Standards Track R. Penno, Ed. 5 Expires: September 15, 2011 Juniper Networks 6 Y. Yang, Ed. 7 Yale University 8 March 14, 2011 10 ALTO Protocol 11 draft-ietf-alto-protocol-07.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 15, 2011. 63 Copyright Notice 65 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 1.1. Background and Problem Statement . . . . . . . . . . . . . 6 82 1.2. Design History and Merged Proposals . . . . . . . . . . . 6 83 1.3. Solution Benefits . . . . . . . . . . . . . . . . . . . . 6 84 1.3.1. Service Providers . . . . . . . . . . . . . . . . . . 6 85 1.3.2. Applications . . . . . . . . . . . . . . . . . . . . . 7 86 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 88 2.1.1. Endpoint Address . . . . . . . . . . . . . . . . . . . 7 89 2.1.2. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 8 90 2.1.3. Network Location . . . . . . . . . . . . . . . . . . . 8 91 2.1.4. ALTO Information . . . . . . . . . . . . . . . . . . . 8 92 2.1.5. ALTO Information Base . . . . . . . . . . . . . . . . 8 93 2.2. ALTO Service and Protocol Scope . . . . . . . . . . . . . 8 94 3. Protocol Structure . . . . . . . . . . . . . . . . . . . . . . 9 95 3.1. Server Information Service . . . . . . . . . . . . . . . . 10 96 3.2. ALTO Information Services . . . . . . . . . . . . . . . . 11 97 3.2.1. Map Service . . . . . . . . . . . . . . . . . . . . . 11 98 3.2.2. Map Filtering Service . . . . . . . . . . . . . . . . 11 99 3.2.3. Endpoint Property Service . . . . . . . . . . . . . . 11 100 3.2.4. Endpoint Cost Service . . . . . . . . . . . . . . . . 11 101 4. Network Map . . . . . . . . . . . . . . . . . . . . . . . . . 12 102 4.1. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 103 4.2. Endpoint Addresses . . . . . . . . . . . . . . . . . . . . 13 104 4.2.1. IP Addresses . . . . . . . . . . . . . . . . . . . . . 13 105 4.3. Example Network Map . . . . . . . . . . . . . . . . . . . 13 106 5. Cost Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 107 5.1. Cost Attributes . . . . . . . . . . . . . . . . . . . . . 14 108 5.1.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . 14 109 5.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 15 110 5.2. Cost Map Structure . . . . . . . . . . . . . . . . . . . . 15 111 5.3. Network Map and Cost Map Dependency . . . . . . . . . . . 16 112 6. Protocol Design Overview . . . . . . . . . . . . . . . . . . . 16 113 6.1. Existing Infrastructure . . . . . . . . . . . . . . . . . 17 114 6.2. ALTO Information Reuse and Redistribution . . . . . . . . 17 115 7. Protocol Messaging . . . . . . . . . . . . . . . . . . . . . . 18 116 7.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 18 117 7.2. Message Format . . . . . . . . . . . . . . . . . . . . . . 18 118 7.2.1. Protocol Versioning . . . . . . . . . . . . . . . . . 18 119 7.2.2. Content Type . . . . . . . . . . . . . . . . . . . . . 19 120 7.2.3. Request Message . . . . . . . . . . . . . . . . . . . 19 121 7.2.4. Response Message . . . . . . . . . . . . . . . . . . . 20 122 7.3. General Processing . . . . . . . . . . . . . . . . . . . . 22 123 7.4. ALTO Status Codes . . . . . . . . . . . . . . . . . . . . 22 124 7.5. Client Behavior . . . . . . . . . . . . . . . . . . . . . 23 125 7.5.1. Successful Response . . . . . . . . . . . . . . . . . 23 126 7.5.2. Error Conditions . . . . . . . . . . . . . . . . . . . 24 127 7.6. HTTP Usage . . . . . . . . . . . . . . . . . . . . . . . . 24 128 7.6.1. Authentication and Encryption . . . . . . . . . . . . 24 129 7.6.2. Cookies . . . . . . . . . . . . . . . . . . . . . . . 24 130 7.6.3. Caching Parameters . . . . . . . . . . . . . . . . . . 24 131 7.7. ALTO Types . . . . . . . . . . . . . . . . . . . . . . . . 24 132 7.7.1. PID Name . . . . . . . . . . . . . . . . . . . . . . . 24 133 7.7.2. Endpoints . . . . . . . . . . . . . . . . . . . . . . 25 134 7.7.3. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 27 135 7.7.4. Cost Type . . . . . . . . . . . . . . . . . . . . . . 27 136 7.8. ALTO Messages . . . . . . . . . . . . . . . . . . . . . . 27 137 7.8.1. Server Information Service . . . . . . . . . . . . . . 28 138 7.8.2. Map Service . . . . . . . . . . . . . . . . . . . . . 32 139 7.8.3. Map Filtering Service . . . . . . . . . . . . . . . . 36 140 7.8.4. Endpoint Property Service . . . . . . . . . . . . . . 40 141 7.8.5. Endpoint Cost Service . . . . . . . . . . . . . . . . 43 142 8. Redistributable Responses . . . . . . . . . . . . . . . . . . 45 143 8.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 46 144 8.1.1. Service ID . . . . . . . . . . . . . . . . . . . . . . 46 145 8.1.2. Expiration Time . . . . . . . . . . . . . . . . . . . 47 146 8.1.3. Signature . . . . . . . . . . . . . . . . . . . . . . 47 147 8.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 49 148 8.2.1. Response Redistribution Descriptor Fields . . . . . . 50 149 8.2.2. Signature . . . . . . . . . . . . . . . . . . . . . . 50 150 9. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 51 151 9.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 51 152 9.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 52 153 9.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 53 154 10. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 54 155 10.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 54 156 10.2. Hosts with Multiple Endpoint Addresses . . . . . . . . . . 55 157 10.3. Network Address Translation Considerations . . . . . . . . 55 158 10.4. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . 56 159 10.5. Endpoint and Path Properties . . . . . . . . . . . . . . . 56 160 10.6. REST-ful Protocol Structure . . . . . . . . . . . . . . . 56 161 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 162 11.1. application/alto Media Type . . . . . . . . . . . . . . . 57 163 11.2. ALTO Cost Type Registry . . . . . . . . . . . . . . . . . 58 164 12. Security Considerations . . . . . . . . . . . . . . . . . . . 59 165 12.1. Privacy Considerations for ISPs . . . . . . . . . . . . . 59 166 12.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 59 167 12.3. Authentication, Integrity Protection, and Encryption . . . 60 168 12.4. ALTO Information Redistribution . . . . . . . . . . . . . 60 169 12.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 61 170 12.6. ALTO Server Access Control . . . . . . . . . . . . . . . . 61 171 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 172 13.1. Normative References . . . . . . . . . . . . . . . . . . . 62 173 13.2. Informative References . . . . . . . . . . . . . . . . . . 63 175 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 64 176 Appendix B. Authors . . . . . . . . . . . . . . . . . . . . . . . 65 177 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 179 1. Introduction 181 1.1. Background and Problem Statement 183 Today, network information available to applications is mostly from 184 the view of endhosts. There is no clear mechanism to convey 185 information about the network's preferences to applications. By 186 leveraging better network-provided information, applications have the 187 potential to become more network-efficient (e.g., reduce network 188 resource consumption) and achieve better application performance 189 (e.g., accelerated download rate). The ALTO Service intends to 190 provide a simple way to convey network information to applications. 192 The goal of this document is to specify a simple and unified protocol 193 that meets the ALTO requirements [14] while providing a migration 194 path for Internet Service Providers (ISP), Content Providers, and 195 clients that have deployed protocols with similar intentions (see 196 below). This document is a work in progress and will be updated with 197 further developments. 199 1.2. Design History and Merged Proposals 201 The protocol specified here consists of contributions from 203 o P4P [15], [16], [17]; 205 o ALTO Info-Export [18]; 207 o Query/Response [19], [20]; 209 o ATTP [ATTP]; 211 o Proxidor [21]. 213 See Appendix A for a list of people that have contributed 214 significantly to this effort and the projects and proposals listed 215 above. 217 1.3. Solution Benefits 219 The ALTO Service offers many benefits to both end-users (consumers of 220 the service) and Internet Service Providers (providers of the 221 service). 223 1.3.1. Service Providers 225 The ALTO Service enables ISPs to influence the peer selection process 226 in distributed applications in order to increase locality of traffic, 227 improve user-experience, amongst others. It also helps ISPs to 228 efficiently manage traffic that traverses more expensive links such 229 as transit and backup links, thus allowing a better provisioning of 230 the networking infrastructure. 232 1.3.2. Applications 234 Applications that use the ALTO Service can benefit in multiple ways. 235 For example, they may no longer need to infer topology information, 236 and some applications can reduce reliance on measuring path 237 performance metrics themselves. They can take advantage of the ISP's 238 knowledge to avoid bottlenecks and boost performance. 240 An example type of application is a Peer-to-Peer overlay where peer 241 selection can be improved by including ALTO information in the 242 selection process. 244 2. Architecture 246 Two key design objectives of the ALTO Protocol are simplicity and 247 extensibility. At the same time, it introduces additional techniques 248 to address potential scalability and privacy issues. This section 249 first introduces the terminology, and then defines the ALTO 250 architecture and the ALTO Protocol's place in the overall 251 architecture. 253 2.1. Terminology 255 We use the following terms defined in [22]: Application, Overlay 256 Network, Peer, Resource, Resource Identifier, Resource Provider, 257 Resource Consumer, Resource Directory, Transport Address, Host 258 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 259 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 260 Transit Traffic. 262 We also use the following additional terms: Endpoint Address, 263 Autonomous System Number (ASN), and Network Location. 265 2.1.1. Endpoint Address 267 An endpoint address represents the communication address of an 268 endpoint. An endpoint address can be network-attachment based (IP 269 address) or network-attachment agnostic. Common forms of endpoint 270 addresses include IP address, MAC address, overlay ID, and phone 271 number. 273 Each Endpoint Address has an associated Address Type, which indicates 274 both its syntax and semantics. 276 2.1.2. ASN 278 An Autonomous System Number. 280 2.1.3. Network Location 282 Network Location is a generic term denoting a single endpoint or 283 group of endpoints. 285 2.1.4. ALTO Information 287 ALTO Information is a generic term referring to the network 288 information sent by an ALTO Server. 290 2.1.5. ALTO Information Base 292 Internal representation of the ALTO Information maintained by the 293 ALTO Server. Note that the structure of this internal representation 294 is not defined by this document. 296 2.2. ALTO Service and Protocol Scope 298 An ALTO Server conveys the network information from the perspective 299 of a network region; the ALTO Server presents its "my-Internet View" 300 [23] of the network region. A network region in this context can be 301 an Autonomous System, an ISP, or perhaps a smaller region or set of 302 ISPs; the details depend on the deployment scenario and discovery 303 mechanism. 305 To better understand the ALTO Service and the role of the ALTO 306 Protocol, we show in Figure 1 the overall system architecture. In 307 this architecture, an ALTO Server prepares ALTO Information; an ALTO 308 Client uses ALTO Service Discovery to identify an appropriate ALTO 309 Server; and the ALTO Client requests available ALTO Information from 310 the ALTO Server using the ALTO Protocol. 312 The ALTO Information provided by the ALTO Server can be updated 313 dynamically based on network conditions, or can be seen as a policy 314 which is updated at a larger time-scale. 316 More specifically, the ALTO Information provided by an ALTO Server 317 may be influenced (at the operator's discretion) by other systems. 318 Examples include (but are not limited to) static network 319 configuration databases, dynamic network information, routing 320 protocols, provisioning policies, and interfaces to outside parties. 321 These components are shown in the figure for completeness but outside 322 the scope of this specification. 324 Note that it may also be possible for ALTO Servers to exchange 325 network information with other ALTO Servers (either within the same 326 administrative domain or another administrative domain with the 327 consent of both parties) in order to adjust exported ALTO 328 Information. Such a protocol is also outside the scope of this 329 specification. 331 +-------------------------------------------------------------------+ 332 | ISP | 333 | | 334 | +-----------+ | 335 | | Routing | | 336 | +--------------+ | Protocols | | 337 | | Provisioning | +-----------+ | 338 | | Policy | | | 339 | +--------------+\ | | 340 | \ | | 341 | \ | | 342 | +-----------+ \+---------+ +--------+ | 343 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 344 | |Network |.......| Server | -------------------- | Client | | 345 | |Information| +---------+ +--------+ | 346 | +-----------+ / / | 347 | / ALTO SD Query/Response / | 348 | / / | 349 | +----------+ +--------------+ | 350 | | External | | ALTO Service | | 351 | | Interface| | Discovery | | 352 | +----------+ +--------------+ | 353 | | | 354 +-------------------------------------------------------------------+ 355 | 356 +------------------+ 357 | Third Parties | 358 | | 359 | Content Providers| 360 +------------------+ 362 Figure 1: Basic ALTO Architecture. 364 3. Protocol Structure 366 The ALTO Protocol uses a simple extensible framework to convey 367 network information. In the general framework, the ALTO protocol 368 will convey properties on both Network Locations and the paths 369 between Network Locations. 371 In this document, we focus on a particular Endpoint property to 372 denote the location of an endpoint, and provider-defined costs for 373 paths between pairs of Network Locations. 375 The ALTO Protocol is built on a common transport protocol, messaging 376 structure and encoding, and transaction model. The protocol is 377 subdivided into services of related functionality. ALTO-Core 378 provides the Server Information Service and the Map Service to 379 provide ALTO Information. Other ALTO Information services can 380 provide additional functionality. There are three such services 381 defined in this document: the Map Filtering Service, Endpoint 382 Property Service, and Endpoint Cost Service. Additional services may 383 be defined in companion documents. Note that functionality offered 384 in different services are not totally non-overlapping (e.g., the Map 385 Service and Map Filtering Service). 387 .------------------------------------------------------------. 388 | | 389 | .----------. .-----------------------------------------. | 390 | | | | ALTO Info Services | | 391 | | | | .-----------. .----------. .----------. | | 392 | | | | | Map | | Endpoint | | Endpoint | | | 393 | | | | | Filtering | | Property | | Cost | | | 394 | | | | | Service | | Service | | Service | | | 395 | | Server | | `-----------' `----------' `----------' | | 396 | | Info. | | .-------------------------------------. | | 397 | | Service | | | Map Service | | | 398 | | | | | .-------------. .--------------. | | | 399 | | | | | | Network Map | | Cost Map | | | | 400 | | | | | `-------------' `--------------' | | | 401 | | | | `-------------------------------------' | | 402 | `----------' `-----------------------------------------' | 403 | | 404 `------------------------------------------------------------' 406 Figure 2: ALTO Protocol Structure 408 3.1. Server Information Service 410 The Server (Capability) Information Service lists the details on the 411 information that can be provided by an ALTO Server and perhaps other 412 ALTO Servers maintained by the network provider. The configuration 413 includes, for example, details about the operations and cost metrics 414 supported by the ALTO Server and other related ALTO Servers that may 415 be usable by an ALTO Client. The capability document can be 416 downloaded by ALTO Clients. The capability information could also be 417 provisioned to devices, but care must be taken to update it 418 appropriately. 420 3.2. ALTO Information Services 422 Multiple, distinct services are defined to allow ALTO Clients to 423 query ALTO Information from an ALTO Server. The ALTO Server 424 internally maintains an ALTO Information Base that encodes the 425 network provider's preferences. The ALTO Information Base encodes 426 the Network Locations defined by the ALTO Server (and their 427 corresponding properties), as well as the provider-defined costs 428 between pairs of Network Locations. 430 3.2.1. Map Service 432 The Map Service provides batch information to ALTO Clients in the 433 form of Network Map and Cost Map. The Network Map (See Section 4) 434 provides the full set of Network Location groupings defined by the 435 ALTO Server and the endpoints contained with each grouping. The Cost 436 Map (see Section 5) provides costs between the defined groupings. 438 These two maps can be thought of (and implemented as) as simple files 439 with appropriate encoding provided by the ALTO Server. 441 3.2.2. Map Filtering Service 443 Resource constrained ALTO Clients may benefit from query results 444 being filtered at the ALTO Server. This avoids an ALTO Client 445 spending network bandwidth or CPU collecting results and performing 446 client-side filtering. The Map Filtering Service allows ALTO Clients 447 to query for the ALTO Server Network Map and Cost Map based on 448 additional parameters. 450 3.2.3. Endpoint Property Service 452 This service allows ALTO Clients to look up properties for individual 453 endpoints. An example endpoint property is its Network Location (its 454 grouping defined by the ALTO Server) or connectivity type (e.g., 455 ADSL, Cable, or FioS). 457 3.2.4. Endpoint Cost Service 459 Some ALTO Clients may also benefit from querying for costs and 460 rankings based on endpoints. The Endpoint Cost Service allows an 461 ALTO Server to return either numerical costs or ordinal costs 462 (rankings) directly amongst Endpoints. 464 4. Network Map 466 In reality, many endpoints are very close to one another in terms of 467 network connectivity, for example, endpoints on the same site of an 468 enterprise. By treating a group of endpoints together as a single 469 entity in ALTO, we can achieve much greater scalability without 470 losing critical information. 472 The Network Location endpoint property allows an ALTO Server to group 473 endpoints together to indicate their proximity. The resulting set of 474 groupings is called the ALTO Network Map. 476 The definition of proximity varies depending on the granularity of 477 the ALTO information configured by the provider. In one deployment, 478 endpoints on the same subnet may be considered close; while in 479 another deployment, endpoints connected to the same PoP may be 480 considered close. 482 As used in this document, the Network Map refers to the syntax and 483 semantics of the information distributed by the ALTO Server. This 484 document does not discuss the internal representation of this data 485 structure within the ALTO Server. 487 4.1. PID 489 Each group of Endpoints is identified by a provider-defined Network 490 Location identifier called a PID. There can be many different ways 491 of grouping the endpoints and assigning PIDs. 493 A PID is an identifier that provides an indirect and network-agnostic 494 way to specify a network aggregation. For example, a PID may be 495 defined by the ALTO service provider to denote a subnet, a set of 496 subnets, a metropolitan area, a PoP, an autonomous system, or a set 497 of autonomous systems. Aggregation of endpoints into PIDs can 498 indicate proximity and can improve scalability. In particular, 499 network preferences (costs) may be specified between PIDs, allowing 500 cost information to be more compactly represented and updated at a 501 faster time scale than the network aggregations themselves. 503 Using PIDs, the Network Map may also be used to communicate simple 504 preferences with only minimal information from the Cost Map. For 505 example, an ISP may prefer that endpoints associated with the same 506 PoP (Point-of-Presence) in a P2P application communicate locally 507 instead of communicating with endpoints in other PoPs. The ISP may 508 aggregate endhosts within a PoP into a single PID in the Network Map. 509 The Cost Map may be encoded to indicate that peering within the same 510 PID is preferred; for example, cost(PID_i, PID_i) == c* and 511 cost(PID_i, PID_j) > c* for i != j. Section 5 provides further 512 details about Cost Map structure. 514 4.2. Endpoint Addresses 516 Communicating endpoints may have many types of addresses, such as IP 517 addresses, MAC addresses, or overlay IDs. The current specification 518 only considers IP addresses. 520 4.2.1. IP Addresses 522 The endpoints aggregated into a PID are denoted by a list of IP 523 prefixes. When either an ALTO Client or ALTO Server needs to 524 determine which PID in a Network Map contains a particular IP 525 address, longest-prefix matching MUST be used. 527 A Network Map MUST define a PID for each possible address in the IP 528 address space for all of the address types contained in the map. A 529 RECOMMENDED way to satisfy this property is to define a PID that 530 contains the 0.0.0.0/0 prefix for IPv4 or ::/0 (for IPv6). 532 4.3. Example Network Map 534 Figure 3 illustrates an example Network Map. PIDs are used to 535 identify network-agnostic aggregations. 537 .-----------------------------------------------------------. 538 | ALTO Network Map | 539 | | 540 | .-----------------------------------. .---------------. | 541 | | NetLoc: PID-1 | | NetLoc: PID-2 | | 542 | | .------------------------------. | | ... | | 543 | | | 192.0.2.0/24 | | `---------------` | 544 | | | .--------------------------. | | | 545 | | | | Endpoint: 192.0.2.34 | | | .---------------. | 546 | | | `--------------------------` | | | NetLoc: PID-3 | | 547 | | `------------------------------` | | ... | | 548 | | .------------------------------. | `---------------` | 549 | | | 198.51.100.0/25 | | | 550 | | | .--------------------------. | | .---------------. | 551 | | | | Endpoint: 198.51.100.100 | | | | NetLoc: PID-4 | | 552 | | | `--------------------------` | | | ... | | 553 | | `------------------------------` | `---------------` | 554 | `-----------------------------------` | 555 | | 556 `-----------------------------------------------------------` 558 Figure 3: Example Network Map 560 5. Cost Map 562 An ALTO Server indicates preferences amongst network locations in the 563 form of Path Costs. Path Costs are generic costs and can be 564 internally computed by a network provider according to its own needs. 566 An ALTO Cost Map defines Path Costs pairwise amongst sets of source 567 and destination Network Locations. 569 One advantage of separating ALTO information into a Network Map and a 570 Cost Map is that the two components can be updated at different time 571 scales. For example, Network Maps may be stable for a longer time 572 while Cost Maps may be updated to reflect dynamic network conditions. 574 As used in this document, the Cost Map refers to the syntax and 575 semantics of the information distributed by the ALTO Server. This 576 document does not discuss the internal representation of this data 577 structure within the ALTO Server. 579 5.1. Cost Attributes 581 Path Costs have attributes: 583 o Type: identifies what the costs represent; 585 o Mode: identifies how the costs should be interpreted. 587 Certain queries for Cost Maps allow the ALTO Client to indicate the 588 desired Type and Mode. 590 5.1.1. Cost Type 592 The Type attribute indicates what the cost represents. For example, 593 an ALTO Server could define costs representing air-miles, hop-counts, 594 or generic routing costs. 596 Cost types are indicated in protocol messages as strings. 598 5.1.1.1. Cost Type: routingcost 600 An ALTO Server MUST define the 'routingcost' Cost Type. 602 This Cost Type conveys a generic measure for the cost of routing 603 traffic from a source to a destination. Lower values indicate a 604 higher preference for traffic to be sent from a source to a 605 destination. 607 Note that an ISP may internally compute routing cost using any method 608 it chooses (e.g., air-miles or hop-count) as long as it conforms to 609 these semantics. 611 5.1.2. Cost Mode 613 The Mode attribute indicates how costs should be interpreted. 614 Specifically, the Mode attribute indicates whether returned costs 615 should be interpreted as numerical values or ordinal rankings. 617 It is important to communicate such information to ALTO Clients, as 618 certain operations may not be valid on certain costs returned by an 619 ALTO Server. For example, it is possible for an ALTO Server to 620 return a set of IP addresses with costs indicating a ranking of the 621 IP addresses. Arithmetic operations, such as summation, that would 622 make sense for numerical values, do not make sense for ordinal 623 rankings. ALTO Clients may handle such costs differently. 625 Cost Modes are indicated in protocol messages as strings. 627 An ALTO Server MUST support at least one of 'numerical' and 'ordinal' 628 costs. ALTO Clients SHOULD be cognizant of operations when a desired 629 cost mode is not supported. For example, an ALTO Client desiring 630 numerical costs may adjust behavior if only the ordinal Cost Mode is 631 available. Alternatively, an ALTO Client desiring ordinal costs may 632 construct ordinal costs given numerical values if only the numerical 633 Cost Mode is available. 635 5.1.2.1. Cost Mode: numerical 637 This Cost Mode is indicated by the string 'numerical'. This mode 638 indicates that it is safe to perform numerical operations (e.g. 639 summation) on the returned costs. 641 5.1.2.2. Cost Mode: ordinal 643 This Cost Mode is indicated by the string 'ordinal'. This mode 644 indicates that the costs values to a set of Destination Network 645 Locations from a particular Source Network Location are a ranking, 646 with lower values indicating a higher preference. 648 It is important to note that the values in the Cost Map provided with 649 the ordinal Cost Mode are not necessarily the actual cost known to 650 the ALTO Server. 652 5.2. Cost Map Structure 654 A query for a Cost Map either explicitly or implicitly includes a 655 list of Source Network Locations and a list of Destination Network 656 Locations. (Recall that a Network Location can be an endpoint 657 address or a PID.) 659 Specifically, assume that a query has a list of multiple Source 660 Network Locations, say [Src_1, Src_2, ..., Src_m], and a list of 661 multiple Destination Network Locations, say [Dst_1, Dst_2, ..., 662 Dst_n]. 664 The ALTO Server will return the Path Cost for each communicating pair 665 (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., Src_m -> Dst_1, ..., 666 Src_m -> Dst_n). We refer to this structure as a Cost Map. 668 If the Cost Mode is 'ordinal', the Path Cost of each communicating 669 pair is relative to the m*n entries. 671 5.3. Network Map and Cost Map Dependency 673 If a Cost Map contains PIDs in the list of Source Network Locations 674 or the list of Destination Network Locations, the Path Costs are 675 generated based on a particular Network Map (which defines the PIDs). 676 Version Tags are introduced to ensure that ALTO Clients are able to 677 use consistent information even though the information is provided in 678 two maps. 680 A Version Tag is an opaque string associated with a Network Map 681 maintained by the ALTO Server. When the Network Map changes, the 682 Version Tag SHOULD also be changed. (Thus, the Version Tag is 683 defined similarly to HTTP's ETag.) Possibilities for generating a 684 Version Tag include the last-modified timestamp for the Network Map, 685 or a hash of its contents. 687 A Network Map distributed by the ALTO Server includes its Version 688 Tag. A Cost Map referring to PIDs also includes the Version Tag of 689 the Network Map on which it is based. 691 6. Protocol Design Overview 693 The ALTO Protocol design uses a REST-like interface with the goal of 694 leveraging current HTTP [2] [3] implementations and infrastructure, 695 as well as familiarity with existing REST-like services in popular 696 use. ALTO messages use JSON [4] to encode message bodies. 698 This document currently specifies both services and message encoding 699 in a descriptive fashion. Care is taken to make descriptions precise 700 and unambiguous, but it still lacks benefits of automatic tooling 701 that exists for certain encoding formats. 703 Standards such as WSDL 2.0 and WADL are capable of describing 704 available interfaces. JSON Schema [24] allows message encodings to 705 be specified precisely and messages may be verified against the 706 schema. It is not yet clear whether such an approach should be taken 707 in this document. 709 Benefits enabled by a REST-like interface leveraging HTTP include 710 easier understanding and debugging, flexible ALTO Server 711 implementation strategies, and more importantly, simple caching and 712 redistribution of ALTO information to increase scalability. 714 6.1. Existing Infrastructure 716 HTTP is a natural choice for integration with existing applications 717 and infrastructure. In particular, the ALTO Protocol design 718 leverages: 720 o the huge installed base of infrastructure, including HTTP caches, 722 o mature software implementations, 724 o the fact that many P2P clients already have an embedded HTTP 725 client, and 727 o authentication and encryption mechanisms in HTTP and SSL/TLS. 729 6.2. ALTO Information Reuse and Redistribution 731 ALTO information may be useful to a large number of applications and 732 users. For example, an identical Network Map may be used by all ALTO 733 Clients querying a particular ALTO Server. At the same time, 734 distributing ALTO information must be efficient and not become a 735 bottleneck. 737 Beyond integration with existing HTTP caching infrastructure, ALTO 738 information may also be cached or redistributed using application- 739 dependent mechanisms, such as P2P DHTs or P2P file-sharing. This 740 document does not define particular mechanisms for such 741 redistribution, but it does define the primitives (e.g., digital 742 signatures) that may be needed to support such a mechanism. See [25] 743 for further discussions. 745 Note that if caching or redistribution is used, the Response message 746 may be returned from another (possibly third-party) entity. Reuse 747 and Redistribution is further discussed in Section 12.4. Protocol 748 support for redistribution is specified in Section 8. 750 7. Protocol Messaging 752 This section specifies client and server processing, as well as 753 messages in the ALTO Protocol. Details common to ALTO Server 754 processing of all messages is first discussed, followed by details of 755 the individual messages. 757 7.1. Notation 759 This document uses an adaptation of the C-style struct notation to 760 define the required and optional members of JSON objects. Unless 761 explicitly noted, each member of a struct is REQUIRED. 763 The types 'JSONString', 'JSONNumber', 'JSONBool' indicate the JSON 764 string, number, and boolean types respectively. 766 This document only includes object members used by this 767 specification. It is possible that protocol extensions include 768 additional members to JSON objects defined in this document; such 769 additional members will be silently ignored by ALTO Servers and 770 Clients only implementing the base protocol defined in this document. 772 7.2. Message Format 774 Request and Response follow the standard format for HTTP Request and 775 Response messages [2] [3]. 777 The following subsections provide an overview of how ALTO Requests 778 and Responses are encoded in HTTP, and discusses rationale for 779 certain design decisions. 781 7.2.1. Protocol Versioning 783 The ALTO Protocol uses a simple versioning approach that permits 784 evolution between versions even if ALTO information is being served 785 as static, pre-generated files. 787 It is assumed that a single host responding to ALTO Requests 788 implements a single protocol version. Virtual hosting may be used if 789 multiple protocol versions need to be supported by a single physical 790 server. 792 A common query (Server List, detailed in Section 7.8.1.1) to be 793 present in all ALTO protocol versions allows an ALTO Client to 794 discover additional ALTO Servers and the ALTO Protocol version number 795 of each. 797 This approach keeps the ALTO Server implementation free from parsing 798 and directing each request based on version number. Although ALTO 799 Requests are free from protocol version numbers, the protocol version 800 number is echoed in each ALTO Response to keep responses self- 801 contained to, for example, ease reading persisted or redistributed 802 ALTO responses. 804 Using virtual hosting with TLS may require the Server Name Indication 805 extension for TLS [5] [26]. 807 This document specifies ALTO Protocol version 1. 809 7.2.2. Content Type 811 All ALTO Request and Response messages MUST set the Content-Type HTTP 812 header to "application/alto". 814 7.2.3. Request Message 816 An ALTO Request is a standard HTTP Request generated by an ALTO 817 Client, with certain components defined by the ALTO Protocol. 819 The basic syntax of an ALTO Request is: 821 / HTTP/1.1 822 Host: 824 For example: 826 GET /info/capability HTTP/1.1 827 Host: alto.example.com:6671 829 7.2.3.1. Standard HTTP Headers 831 The Host header MUST follow the standard rules for the HTTP 1.1 Host 832 Header. 834 The Content-Length header MUST follow the standard rules defined in 835 HTTP 1.1. 837 The Content-Type HTTP Header MUST have value "application/alto" if 838 the Body is non-empty. 840 7.2.3.2. Method and Resource 842 Next, both the HTTP Method and URI-Path (denoted as Resource) 843 indicate the operation requested by the ALTO Client. In this 844 example, the ALTO Client is requesting basic capability information 845 from the ALTO Server. 847 7.2.3.3. Input Parameters 849 Certain operations defined by the ALTO Protocol (e.g., in the Map 850 Filtering Service) allow the ALTO Client to supply additional input 851 parameters. Such input parameters are encoded in a URI-Query-String 852 where possible and appropriate. However, due to practical 853 limitations (e.g. underlying HTTP implementations may have 854 limitations on the total length of a URI and the Query-String is 855 better-suited for simple unstructured parameters and lists), some 856 operations in the ALTO Protocol use input parameters encoded in the 857 HTTP Request Body. 859 7.2.4. Response Message 861 A Response message is a standard HTTP Response generated by an ALTO 862 Server with certain components defined by the ALTO Protocol. 864 The basic syntax of an ALTO Response is: 866 HTTP/1.1 867 Content-Length: 868 Content-Type: 870 872 where the HTTP Response Body is an ALTOResponse JSON Object (defined 873 in Section 7.2.4.3). For example: 875 HTTP/1.1 200 OK 876 Content-Length: 1000 877 Content-Type: application/alto 879 { 880 "meta" : { 881 "version": 1, 882 "status" : { 883 "code" : "SUCCESS", 884 "reason" : "Success" 885 }, 886 ... 887 }, 888 "type" : "capability", 889 "data" : { 890 ... 891 } 892 } 894 7.2.4.1. Standard HTTP Headers 896 The Content-Length header MUST follow the standard rules defined in 897 HTTP 1.1. 899 The Content-Type HTTP Header MUST have value "application/alto" if 900 the Body is non-empty. 902 7.2.4.2. Status Code and Message 904 Two sets of status codes are used in the ALTO Protocol. First, an 905 ALTO Status Code provides detailed information about the success or 906 failure of a particular operation. Second, an HTTP Status Code 907 indicates to HTTP processing elements (e.g., intermediaries and 908 clients) how the response should be treated. 910 7.2.4.3. HTTP Body 912 The Response body MUST encode a single top-level JSON object of type 913 ALTOResponse: 915 object { 916 RspMetaData meta; 917 JSONString type; 918 [RspDataType] data; 919 } ALTOResponse; 921 The ALTOResponse object has distinct sections for: 923 o meta information encoded in an extensible way, 925 o the type of ALTO Information to follow, and 927 o the requested ALTO Information. 929 7.2.4.3.1. Meta Information 931 Meta information is encoded as a JSON object with type RspMetaData: 933 object { 934 JSONString code; 935 JSONString reason; [OPTIONAL] 936 } RspStatus; 938 object { 939 JSONNumber version; 940 RspStatus status; 941 RspRedistDesc redistribution; [OPTIONAL] 943 } RspMetaData; 945 with members: 947 o version: the ALTO Protocol version, which MUST be an integer 949 o status: an ALTO Status Code from Section 7.4 and corresponding 950 reason (free-form string) providing a human-readable explanation 951 of the particular status code. 953 o redistribution: see Section 8. 955 7.2.4.3.2. ALTO Information 957 If the Response is successful (see Section 7.4), then the "type" and 958 "data" members of the ALTOResponse object are REQUIRED. "type" 959 encodes a Response-specific string which indicates to the ALTO Client 960 the type of data encoded in the message. The "data" member encodes 961 the actual Response-specific data; the structure of this member is 962 detailed later in this section for each particular ALTO Response. 964 7.2.4.4. Signature 966 An ALTO Server MAY additionally supply a signature asserting that it 967 generated a particular response. See Section 8.2.2. 969 7.3. General Processing 971 The protocol is structured in such a way that, independent of the 972 query type, there are a set of general processing steps. The ALTO 973 Client selects a specific ALTO Server with which to communicate, 974 establishes a TCP connection, and constructs and sends ALTO Request 975 messages which MUST conform to Section 7.8. In response to Request 976 messages, an ALTO Server constructs and sends ALTO Response messages 977 which also MUST conform to Section 7.8. 979 7.4. ALTO Status Codes 981 This document defines ALTO Status Codes to support the operations 982 defined in this document. Additional status codes may be defined in 983 companion or extension documents. 985 An ALTO Server MUST return the SUCCESS status code if and only if the 986 Request message is successfully processed and the requested ALTO 987 information is returned by the ALTO Server. 989 The HTTP Status Codes corresponding to each ALTO Status Code are 990 defined to provide correct behavior with HTTP intermediaries and 991 clients. When an ALTO Server returns a particular ALTO Status Code, 992 it MUST indicate one of the corresponding HTTP Status Codes in 993 Table 1. 995 If multiple errors are present in a single ALTO Request (e.g., a 996 request uses a JSONString when a JSONInteger is expected and a 997 required field is missing), then the ALTO Server MUST return exactly 998 one of the detected errors. However, the reported error is 999 implementation defined, since specifying a particular order for 1000 message processing encroaches needlessly on implementation technique. 1002 +----------------------+------------------+-------------------------+ 1003 | ALTO Status Code | HTTP Status | Description | 1004 | | Code(s) | | 1005 +----------------------+------------------+-------------------------+ 1006 | SUCCESS | 2xx | Success | 1007 | E_JSON_SYNTAX | 400 | JSON parsing error in | 1008 | | | request | 1009 | E_JSON_FIELD_MISSING | 400 | Required field missing | 1010 | E_JSON_VALUE_TYPE | 400 | JSON Value of | 1011 | | | unexpected type | 1012 | E_INTERNAL_ERROR | 500 | Server-side error | 1013 | E_INVALID_OPERATION | 501 | Invalid operation | 1014 | | | requested | 1015 | E_INVALID_COST_TYPE | 501 | Invalid cost type | 1016 +----------------------+------------------+-------------------------+ 1018 Table 1: Defined ALTO Status Codes 1020 Status codes described in Table 1 are a work in progress. This 1021 document will be modified to update the available status codes as 1022 implementation experience is gained. Feedback is welcomed. 1024 In addition, feedback from implementers of ALTO Clients is welcomed 1025 to identify if there is a need to communicate multiple status codes 1026 in a single response. 1028 7.5. Client Behavior 1030 7.5.1. Successful Response 1032 This specification does not indicate any required actions taken by 1033 ALTO Clients upon receiving a successful response from an ALTO 1034 Server. Although ALTO Clients are suggested to interpret the 1035 received ALTO Information and adapt application behavior, ALTO 1036 Clients are not required to do so. 1038 7.5.2. Error Conditions 1040 If an ALTO Client does not receive a successful response from the 1041 ALTO Server, it can either choose another server or fall back to a 1042 default behavior (e.g., perform peer selection without the use of 1043 ALTO information). An ALTO Client may also retry the request at a 1044 later time. 1046 7.6. HTTP Usage 1048 7.6.1. Authentication and Encryption 1050 An ALTO Server MAY support SSL/TLS to implement server and/or client 1051 authentication, as well as encryption. See [6] for considerations 1052 regarding verifcation of server identity. 1054 An ALTO Server MAY support HTTP Digest authentication. 1056 7.6.2. Cookies 1058 Cookies MUST NOT be used. 1060 7.6.3. Caching Parameters 1062 If the Response generated by the ALTO Server is cachable, the ALTO 1063 Server MAY include 'Cache-Control' and 'Expires' HTTP headers. 1065 If a Response generated by the ALTO Server is not cachable, the ALTO 1066 Server MUST specify the "Cache-Control: no-cache" HTTP Header. 1068 7.7. ALTO Types 1070 This section details the encoding for particular data values used in 1071 the ALTO Protocol. 1073 7.7.1. PID Name 1075 A PID Name is encoded as a US-ASCII string. The string MUST be no 1076 more than 32 characters, and MUST NOT contain characters other than 1077 alphanumeric characters or the '.' separator. The '.' separator is 1078 reserved for future use and MUST NOT unless specifically indicated by 1079 a companion or extension document. 1081 The type 'PIDName' is used in this document to indicate a string of 1082 this format. 1084 7.7.2. Endpoints 1086 7.7.2.1. Address Type 1088 Address Types are encoded as US-ASCII strings consisting of only 1089 alphanumeric characters. This document defines the address type 1090 "ipv4" to refer to IPv4 addresses, and "ipv6" to refer to IPv6 1091 addresses. Extension documents may define additional Address Types. 1093 The type 'AddressType' is used in this document to indicate a string 1094 of this format. 1096 7.7.2.2. Endpoint Address 1098 Endpoint Addresses are encoded as US-ASCII strings. The exact 1099 characters and format depend on the type of endpoint address. 1101 The type 'EndpointAddr' is used in this document to indicate a string 1102 of this format. 1104 7.7.2.2.1. IPv4 1106 IPv4 Endpoint Addresses are encoded as specified by the 'IPv4address' 1107 rule in Section 3.2.2 of [7]. 1109 7.7.2.2.2. IPv6 1111 IPv6 Endpoint Addresses are encoded as specified in Section 2.2 of 1112 [8]. 1114 7.7.2.2.3. Typed Endpoint Addresses 1116 When an Endpoint Address is used, an ALTO implemenation must be able 1117 to determine its type. For this purpose, the ALTO Protocol allows 1118 endpoint addresses to also explicitly indicate their type. 1120 Typed Endpoint Addresses are encoded as US-ASCII strings of the 1121 format 'AddressType:EndpointAddr' (with the ':' character as a 1122 separator). The type 'TypedEndpointAddr' is used to indicate a 1123 string of this format. 1125 7.7.2.3. Endpoint Prefixes 1127 For efficiency, it is useful to denote a set of Endpoint Addresses 1128 using a special notation (if one exists). This specification makes 1129 use of the prefix notations for both IPv4 and IPv6 for this purpose. 1131 Endpoint Prefixes are encoded as US-ASCII strings. The exact 1132 characters and format depend on the type of endpoint address. 1134 The type 'EndpointPrefix' is used in this document to indicate a 1135 string of this format. 1137 7.7.2.3.1. IPv4 1139 IPv4 Endpoint Prefixes are encoded as specified in Section 3.1 of 1140 [9]. 1142 7.7.2.3.2. IPv6 1144 IPv6 Endpoint Prefixes are encoded as specified in Section 2.3 of 1145 [8]. 1147 7.7.2.4. Endpoint Address Group 1149 The ALTO Protocol includes messages that specify potentially large 1150 sets of endpoint addresses. Endpoint Address Groups provide an 1151 efficient way to encode such sets, even when the set contains 1152 endpoint addresses of different types. 1154 An Endpoint Address Group is defined as: 1156 object { 1157 EndpointPrefix [AddressType]<0..*>; 1158 ... 1159 } EndpointAddrGroup; 1161 In particular, an Endpoint Address Group is a JSON object, with the 1162 name of each member being the string corresponding to the address 1163 type, and the member's corresponding value being a list of prefixes 1164 of addresses of that type. 1166 The following is an example with both IPv4 and IPv6 endpoint 1167 addresses: 1169 { 1170 "ipv4": [ 1171 "192.0.2.0/24", 1172 "198.51.100.0/25" 1173 ], 1174 "ipv6": [ 1175 "2001:db8:0:1::/64", 1176 "2001:db8:0:2::/64" 1177 ] 1178 } 1180 7.7.3. Cost Mode 1182 A Cost Mode is encoded as a US-ASCII string. The string MUST either 1183 have the value 'numerical' or 'ordinal'. 1185 The type 'CostMode' is used in this document to indicate a string of 1186 this format. 1188 7.7.4. Cost Type 1190 A Cost Type is encoded as a US-ASCII string. The string MUST be no 1191 more than 32 characters, and MUST NOT contain characters other than 1192 alphanumeric characters or the ':' separator. 1194 Identifiers prefixed with 'priv:' are reserved for Private Use [10]. 1195 Identifiers prefixed with 'exp:' are reserved for Experimental use. 1196 All other identifiers appearing in an ALTO Request or Response MUST 1197 be registered in the ALTO Cost Types registry Section 11. 1199 The type 'CostType' is used in this document to indicate a string of 1200 this format. 1202 7.8. ALTO Messages 1204 This section documents the individual operations supported in the 1205 ALTO Protocol. See Section 7.2.3 and Section 7.2.4 for 1206 specifications of HTTP Request/Response components common to all 1207 operations in the ALTO Protocol. 1209 Table 2 provides an summary of the HTTP Method and URI-Paths used for 1210 ALTO Requests: 1212 +----------------+--------------+----------------------------+ 1213 | Service | Operation | HTTP Method and URI-Path | 1214 +----------------+--------------+----------------------------+ 1215 | Server Info | List Servers | GET /info/servers | 1216 | Server Info | Capability | GET /info/capability | 1217 | | | | 1218 | Map | Network Map | GET /map/core/pid/net | 1219 | Map | Cost Map | GET /map/core/pid/cost | 1220 | | | | 1221 | Map Filtering | Network Map | POST /map/filter/pid/net | 1222 | Map Filtering | Cost Map | POST /map/filter/pid/cost | 1223 | | | | 1224 | Endpoint Prop. | Lookup | GET /endpoint/prop/ | 1225 | | | POST /endpoint/prop/lookup | 1226 | | | | 1227 | Endpoint Cost | Lookup | POST /endpoint/cost/lookup | 1228 +----------------+--------------+----------------------------+ 1230 Table 2: Overview of ALTO Requests 1232 7.8.1. Server Information Service 1234 The Server Information Service provides information about available 1235 ALTO Servers and their capabilities (e.g., supported services). 1237 An ALTO Server MUST support the Server Information Service and MUST 1238 implement all operations defined in this section. 1240 7.8.1.1. Server List 1242 The Server List request allows an ALTO Client to discover other ALTO 1243 Servers provided by the ALTO Service Provider. Upon discovering an 1244 additional ALTO Server, the ALTO Client may then query the server 1245 capabilities (see Section 7.8.1.2) to test if it supports desired 1246 functionality. 1248 The Server List request is intended to help an ALTO Client find an 1249 ALTO Server supporting the desired ALTO Protocol version and 1250 capabilities. It is not intended to serve as a substitute for the 1251 ALTO Server Discovery which helps an ALTO Client locate an initial 1252 ALTO Server. 1254 This operation MUST be supported by the ALTO Server. 1256 7.8.1.1.1. Request Syntax 1258 GET /info/servers HTTP/1.1 1259 Host: 1261 7.8.1.1.2. Response Syntax 1263 HTTP/1.1 200 1264 Content-Length: 1265 Content-Type: application/alto 1267 1269 where the ALTOResponse object has "type" member equal to the string 1270 "server-list" and "data" member of type RspServerList: 1272 object { 1273 JSONString uri; 1274 JSONNumber version; 1275 } ServerItem; 1277 object { 1278 ServerItem servers<0..*>; 1279 } RspServerList; 1281 RspServerList has members: 1283 o servers: Array of available ALTO Servers, detailing the URI of the 1284 ALTO Server and the ALTO Protocol version that it implements. The 1285 array must at least contain an entry corresponding to the ALTO 1286 Server at the URI from which it is retrieving the server list. 1288 7.8.1.1.3. Example 1290 GET /info/servers HTTP/1.1 1291 Host: alto.example.com:6671 1292 HTTP/1.1 200 OK 1293 Content-Length: [TODO] 1294 Content-Type: application/alto 1296 { 1297 "meta" : { 1298 "version" : 1, 1299 "status" : { 1300 "code" : "SUCCESS" 1301 } 1302 }, 1303 "type" : "server-list", 1304 "data" : { 1305 "servers" : [ 1306 { 1307 "uri": "http://alto.example.com:6671", 1308 "version" : 1 1309 } 1310 ] 1311 } 1312 } 1314 7.8.1.2. Server Capability 1316 The Server Capability request allows an ALTO Client to determine the 1317 functionality supported by the queried ALTO Server. 1319 This operation MUST be supported by the ALTO Server. 1321 7.8.1.2.1. Request Syntax 1323 GET /info/capability HTTP/1.1 1324 Host: 1326 7.8.1.2.2. Response Syntax 1328 HTTP/1.1 200 1329 Content-Length: 1330 Content-Type: application/alto 1332 1334 where the ALTOResponse object has "type" member equal to the string 1335 "capability" and "data" member of type RspCapability: 1337 enum { 1338 map, 1339 map-filtering, 1340 endpoint-property, 1341 endpoint-cost 1342 } ServiceType; [Note: encoded as JSONString's] 1344 object { 1345 ServiceType services<0..*>; 1346 CostMode cost-modes<0..*>; [OPTIONAL] 1347 CostType cost-types<0..*>; [OPTIONAL] 1348 JSONBool cost-constraints; [OPTIONAL] 1349 JSONString service-id; [OPTIONAL] 1350 JSONString certificates<0..*>; [OPTIONAL] 1351 } RspCapability; 1353 RspCapability has members: 1355 o services: Lists the services supported by the ALTO Server. The 1356 service names defined in this document are are "map", "map- 1357 filtering", "endpoint-property", and "endpoint-cost". 1359 o cost-modes: Array of supported ALTO Cost Modes. 1361 o cost-types: Array of supported ALTO Cost Types. 1363 o cost-constraints: Indicates if the ALTO Server supports cost 1364 constraints. The value 'false' is implied if this member is not 1365 present. 1367 o service-id: UUID [11] indicating an one or more ALTO Servers 1368 serving equivalent ALTO Information. 1370 o certificates: List of PEM-encoded X.509 certificates used by the 1371 ALTO Server in the signing of responses. 1373 If an ALTO Server denotes a response as redistributable, the 1374 'service-id' and 'certificates' fields are REQUIRED instead of 1375 OPTIONAL. See Section 8 for detailed specification. 1377 7.8.1.2.3. Example 1379 GET /info/capability HTTP/1.1 1380 Host: alto.example.com:6671 1381 HTTP/1.1 200 OK 1382 Content-Length: [TODO] 1383 Content-Type: application/alto 1385 { 1386 "meta" : { 1387 "version" : 1, 1388 "status" : { 1389 "code" : "SUCCESS" 1390 } 1391 }, 1392 "type" : "capability", 1393 "data" : { 1394 "services" : [ "map", "map-filtering" ], 1395 "cost-modes": [ 1396 "numerical", 1397 "ordinal" 1398 ], 1399 "cost-types": [ 1400 "routingcost", 1401 "hopcount" 1402 ], 1403 "cost-constraints": false 1404 } 1405 } 1407 7.8.2. Map Service 1409 The Map Service provides batch information to ALTO Clients in the 1410 form of two maps: a Network Map and Cost Map. 1412 An ALTO Server MUST support the Map Service and MUST implement all 1413 operations defined in this section. 1415 7.8.2.1. Network Map 1417 The full Network Map lists for each PID, the network locations 1418 (endpoints) within the PID. 1420 7.8.2.1.1. Request Syntax 1422 GET /map/core/pid/net HTTP/1.1 1423 Host: 1425 7.8.2.1.2. Response Syntax 1427 HTTP/1.1 200 1428 Content-Length: 1429 Content-Type: application/alto 1431 1433 where the ALTOResponse object has "type" member equal to the string 1434 "network-map" and "data" member of type RspNetworkMap: 1436 object { 1437 EndpointAddrGroup [pidname]<0..*>; 1438 ... 1439 } NetworkMapData; 1441 object { 1442 JSONString map-vtag; 1443 NetworkMapData map; 1444 } RspNetworkMap; 1446 RspNetworkMap has members: 1448 o map-vtag: The Version Tag of the Network Map (Section 5.3) 1450 o map: The network map data itself. 1452 NetworkMapData is a JSON object with each member representing a 1453 single PID and its associated set of endpoint addresses. A member's 1454 name is a PIDName string denoting the PID's name. 1456 7.8.2.1.3. Example 1458 GET /map/core/pid/net HTTP/1.1 1459 Host: alto.example.com:6671 1460 HTTP/1.1 200 OK 1461 Content-Length: [TODO] 1462 Content-Type: application/alto 1464 { 1465 "meta" : { 1466 "version" : 1, 1467 "status" : { 1468 "code" : "SUCCESS" 1469 } 1470 }, 1471 "type" : "network-map", 1472 "data" : { 1473 "map-vtag" : "1266506139", 1474 "map" : { 1475 "PID1" : { 1476 "ipv4" : [ 1477 "192.0.2.0/24", 1478 "198.51.100.0/25" 1479 ] 1480 }, 1481 "PID2" : { 1482 "ipv4" : [ 1483 "198.51.100.128/25" 1484 ] 1485 }, 1486 "PID3" : { 1487 "ipv4" : [ 1488 "0.0.0.0/0" 1489 ], 1490 "ipv6" : [ 1491 "::/0" 1492 ] 1493 ] 1494 } 1495 } 1496 } 1498 7.8.2.2. Cost Map 1500 The Map Service Cost Map query is a batch operation in which the ALTO 1501 Server returns the Path Cost for each pair of source/destination PID 1502 defined by the ALTO Server. 1504 The ALTO Server provides costs using the default Cost Type 1505 ('routingcost') and default Cost Mode ('numerical'). 1507 7.8.2.2.1. Request Syntax 1509 GET /map/core/pid/cost HTTP/1.1 1510 Host: 1512 7.8.2.2.2. Response Syntax 1514 HTTP/1.1 200 1515 Content-Length: 1516 Content-Type: application/alto 1518 1520 where the ALTOResponse object has "type" member equal to the string 1521 "cost-map" and "data" member of type RspCostMap: 1523 object DstCosts { 1524 JSONNumber [dstname]; 1525 ... 1526 }; 1528 object { 1529 DstCosts [srcname]<0..*>; 1530 ... 1531 } CostMapData; 1533 object { 1534 JSONString map-vtag; 1535 CostType cost-type; 1536 CostMode cost-mode; 1537 CostMapData map; 1538 } RspCostMap; 1540 RspCostMap has members: 1542 o map-vtag: The Version Tag of the Network Map used to generate the 1543 Cost Map (Section 5.3). 1545 o cost-type: Cost Type used in the map (Section 5.1.1) 1547 o cost-mode: Cost Mode used in the map (Section 5.1.2) 1549 o map: The cost map data itself. 1551 CostMapData is a JSON object with each member representing a single 1552 Source PID; the name for a member is the PIDName string identifying 1553 the corresponding Source PID. For each Source PID, a DstCosts object 1554 denotes the associated cost to a set of destination PIDs 1555 (Section 5.2); the name for each member in the object is the PIDName 1556 string identifying the corresponding Destination PID. DstCosts has a 1557 single member for each destination PID in the map. 1559 7.8.2.2.3. Example 1561 GET /map/core/pid/cost HTTP/1.1 1562 Host: alto.example.com:6671 1564 HTTP/1.1 200 OK 1565 Content-Length: [TODO] 1566 Content-Type: application/alto 1568 { 1569 "meta" : { 1570 "version" : 1, 1571 "status" : { 1572 "code" : "SUCCESS" 1573 } 1574 }, 1575 "type" : "cost-map", 1576 "data" : { 1577 "map-vtag" : "1266506139", 1578 "cost-type" : "routingcost", 1579 "cost-mode" : "numerical", 1580 "map" : { 1581 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 1582 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 1583 "PID3": { "PID1": 20, "PID2": 15, "PID3": 1 } 1584 } 1585 } 1586 } 1588 7.8.3. Map Filtering Service 1590 The Map Filtering Service allows ALTO Clients to specify filtering 1591 criteria to return a subset of the full maps available in the Map 1592 Service. 1594 An ALTO Server MAY support the Map Filtering Service. If an ALTO 1595 Server supports the Map Filtering Service, all operations defined in 1596 this section MUST be implemented. 1598 7.8.3.1. Network Map 1600 ALTO Clients can query for a subset of the full network map (see 1601 Section 7.8.2.1). 1603 7.8.3.1.1. Request Syntax 1605 POST /map/filter/pid/net HTTP/1.1 1606 Host: 1607 Content-Length: 1609 1611 where: 1613 object { 1614 PIDName pids<0..*>; 1615 } ReqNetworkMap; 1617 The Body of the request encodes an array of PIDs to be included in 1618 the resulting Network Map. If the list of PIDs is empty, the ALTO 1619 Server MUST interpret the list as if it contained a list of all 1620 currently-defined PIDs. 1622 7.8.3.1.2. Response Syntax 1624 The Response syntax is identical to that of the Map Service's Network 1625 Map Response (Section 7.8.2.1.2). 1627 The ALTO Server MUST only include PIDs in the Response that were 1628 specified (implicitly or explicitly) in the Request. If the Request 1629 contains a PID name that is not currently defined by the ALTO Server, 1630 the ALTO Server MUST behave as if the PID did not appear in the 1631 request. 1633 7.8.3.1.3. Example 1635 POST /map/filter/pid/net HTTP/1.1 1636 Host: alto.example.com:6671 1637 Content-Length: 1639 { 1640 pids: [ "PID1", "PID2" ] 1641 } 1643 HTTP/1.1 200 OK 1644 Content-Length: [TODO] 1645 Content-Type: application/alto 1647 { 1648 "meta" : { 1649 "version" : 1, 1650 "status" : { 1651 "code" : "SUCCESS" 1652 } 1653 }, 1654 "type" : "network-map", 1655 "data" : { 1656 "map-vtag" : "1266506139", 1657 "map" : { 1658 "PID1" : { 1659 "ipv4" : [ 1660 "192.0.2.0/24", 1661 "198.51.100.0/24" 1662 ] 1663 }, 1664 "PID2" : { 1665 "ipv4": [ 1666 "198.51.100.128/24" 1667 ] 1668 } 1669 } 1670 } 1671 } 1673 7.8.3.2. Cost Map 1675 ALTO Clients can query for the Cost Map (see Section 7.8.2.2) based 1676 on additional parameters. 1678 7.8.3.2.1. Request Syntax 1680 POST /map/filter/pid/cost? HTTP/1.1 1681 Host: 1683 1685 where: 1687 object { 1688 PIDName srcs<0..*>; 1689 PIDName dsts<0..*>; 1690 } ReqCostMap; 1692 The Query String may contain the following parameters: 1694 o type: The requested Cost Type (Section 5.1.1). If not specified, 1695 the default value is "routingcost". This parameter MUST NOT be 1696 specified multiple times. 1698 o mode: The requested Cost mode (Section 5.1.2). If not specified, 1699 the default value is "numerical". This parameter MUST NOT be 1700 specified multiple times. 1702 o constraint: Defines a constraint on which elements of the Cost Map 1703 are returned. This parameter MUST NOT be used if the Server 1704 Capability Response (Section 7.8.1.2) indicates that constraint 1705 support is not available. A constraint contains two entities 1706 separated by whitespace (before URL encoding): (1) an operator 1707 either 'gt' for greater than , 'lt' for less than or 'eq' for 1708 equal to with 10 percent on either side, (2) a target numerical 1709 cost. The numerical cost is a number that MUST be defined in the 1710 units specified in the Server Capability Response. If multiple 1711 'constraint' parameters are specified, the ALTO Server assumes 1712 they are related to each other with a logical AND. If no 1713 'constraint' parameters are specified, then the ALTO Server 1714 returns the full Cost Map. 1716 The Request body MAY specify a list of Source PIDs, and a list of 1717 Destination PIDs. If a list is empty, it is interpreted by the ALTO 1718 Server as the full set of currently-defined PIDs. The ALTO Server 1719 returns costs between each pair of source/destination PID. If the 1720 Request body is empty, both lists are interpreted to be empty. 1722 7.8.3.2.2. Response Syntax 1724 The Response syntax is identical to that of the Map Service's Cost 1725 Map Response (Section 7.8.2.2.2). 1727 The Response MUST NOT contain any source/destination pair that was 1728 not indicated (implicitly or explicitly) in the Request. If the 1729 Request contains a PID name that is not currently defined by the ALTO 1730 Server, the ALTO Server MUST behave as if the PID did not appear in 1731 the request. 1733 7.8.3.2.3. Example 1735 POST /map/filter/pid/cost?type=hopcount HTTP/1.1 1736 Host: alto.example.com:6671 1738 { 1739 "srcs" : [ "PID1" ], 1740 "dsts" : [ "PID1", "PID2", "PID3" ] 1741 } 1743 HTTP/1.1 200 OK 1744 Content-Length: [TODO] 1745 Content-Type: application/alto 1747 { 1748 "meta" : { 1749 "version" : 1, 1750 "status" : { 1751 "code" : "SUCCESS" 1752 } 1753 }, 1754 "type" : "cost-map", 1755 "data" : { 1756 "map-vtag" : "1266506139", 1757 "cost-type" : "hopcount", 1758 "cost-mode" : "numerical", 1759 "map" : { 1760 "PID1": { "PID1": 0, "PID2": 1, "PID3": 2 } 1761 } 1762 } 1763 } 1765 7.8.4. Endpoint Property Service 1767 The Endpoint Property Lookup query allows an ALTO Client to lookup 1768 properties of Endpoints known to the ALTO Server. If the ALTO Server 1769 provides the Endpoint Property Service, the ALTO Server MUST define 1770 at least the 'pid' property for Endpoints. 1772 An ALTO Server MAY support the Endpoint Property Service. If an ALTO 1773 Server supports the Endpoint Property Service, all operations defined 1774 in this section MUST be implemented. 1776 7.8.4.1. Endpoint Property Lookup 1778 7.8.4.1.1. Request Syntax 1780 POST /endpoint/prop/lookup? HTTP/1.1 1781 Host: 1782 Content-Length: 1784 1786 where: 1788 object { 1789 TypedEndpointAddr endpoints<0..*>; 1790 } ReqEndpointProp; 1792 The Query String may contain the following parameters: 1794 o prop: The requested property type. This parameter MUST be 1795 specified at least once, and MAY be specified multiple times 1796 (e.g., to query for multiple different properties at once). 1798 The body encodes a list of typed endpoint addresses. 1800 An alternate syntax is supported for the case when properties are 1801 requested for a single endpoint: 1803 GET /endpoint/prop/? HTTP/1.1 1804 Host: 1806 where the Query String is the same as in the first form. 1808 7.8.4.1.2. Response Syntax 1810 HTTP/1.1 200 1811 Content-Length: 1812 Content-Type: application/alto 1814 1816 where the ALTOResponse object has "type" member equal to the string 1817 "endpoint-property" and "data" member of type RspEndpointProperty: 1819 object { 1820 JSONString [propertyname]; 1821 ... 1822 } EndpointProps; 1824 object { 1825 EndpointProps [TypedEndpointAddr]<0..*>; 1826 ... 1827 } RspEndpointProperty; 1829 RspEndpointProperty has one member for each endpoint indicated in the 1830 Request (with the name being the endpoint encoded as a 1831 TypedEndpointAddr). The requested properties for each endpoint are 1832 encoded in a corresponding EndpointProps object, which encodes one 1833 name/value pair for each requested property. Note that property 1834 values are JSON Strings. If the ALTO Server does not define a 1835 requested property for a particular endpoint, then it MUST omit it 1836 from the Response for only that endpoint. 1838 7.8.4.1.3. Example 1840 POST /endpoint/prop/lookup?prop=pid HTTP/1.1 1841 Host: alto.example.com:6671 1842 Content-Length: [TODO] 1844 { 1845 "endpoints" : [ "ipv4:192.0.2.34", "ipv4:203.0.113.129" ] 1846 } 1848 HTTP/1.1 200 OK 1849 Content-Length: [TODO] 1850 Content-Type: application/alto 1852 { 1853 "meta" : { 1854 "version" : 1, 1855 "status" : { 1856 "code" : "SUCCESS" 1857 } 1858 }, 1859 "type" : "endpoint-property", 1860 "data": { 1861 "ipv4:192.0.2.34" : { "pid": "PID1" }, 1862 "ipv4:203.0.113.129" : { "pid": "PID3" } 1863 } 1864 } 1866 7.8.5. Endpoint Cost Service 1868 The Endpoint Cost Service allows ALTO Clients to directly supply 1869 endpoints to an ALTO Server. The ALTO Server replies with costs 1870 (numerical or ordinal) amongst the endpoints. 1872 In particular, this service allows lists of Endpoint prefixes (and 1873 addresses, as a special case) to be ranked (ordered) by an ALTO 1874 Server. 1876 An ALTO Server MAY support the Endpoint Cost Service. If an ALTO 1877 Server supports the Endpoint Cost Service, all operations defined in 1878 this section MUST be implemented. 1880 7.8.5.1. Endpoint Cost Lookup 1882 7.8.5.1.1. Request Syntax 1884 POST /endpoint/cost/lookup? HTTP/1.1 1885 Host: 1886 Content-Length: 1888 1890 where: 1892 object { 1893 TypedEndpointAddr srcs<0..*>; 1894 TypedEndpointAddr dsts<0..*>; 1895 } ReqEndpointCostMap; 1897 The request body includes a list of source and destination endpoints 1898 that should be assigned a cost by the ALTO Server. The allowed Query 1899 String parameters are defined identically to Section 7.8.3.2. 1901 The request body MUST specify a list of source Endpoints, and a list 1902 of destination Endpoints. If the list of source Endpoints is empty 1903 (or it is not included), the ALTO Server MUST treat it as if it 1904 contained the Endpoint address of the requesting client. The list of 1905 destination Endpoints MUST NOT be empty. The ALTO Server returns 1906 costs between each pair of source/destination Endpoint. 1908 7.8.5.1.2. Response Syntax 1910 HTTP/1.1 200 1911 Content-Length: 1912 Content-Type: application/alto 1914 1916 where ALTOResponse is encoded identically to Section 7.8.2.2.2 with 1917 the following exceptions: 1919 o ALTO Response's "type" member must be equal to "endpoint-cost- 1920 map", 1922 o The "map-vtag" member of RspCostMap MUST be omitted, and 1924 o Identifiers refer to TypedEndpointAddres instead of PIDs. 1926 7.8.5.1.3. Example 1928 POST /endpoint/cost/lookup?mode=ordinal HTTP/1.1 1929 Host: alto.example.com:6671 1930 Content-Length: [TODO] 1932 { 1933 "src": [ "ipv4:192.0.2.2" ], 1934 "dst": [ 1935 "ipv4:192.0.2.89", 1936 "ipv4:198.51.100.34", 1937 "ipv4:203.0.113.45" 1938 ] 1939 } 1941 HTTP/1.1 200 OK 1942 Content-Length: [TODO] 1943 Content-Type: application/alto 1945 { 1946 "meta" : { 1947 "version" : 1, 1948 "status" : { 1949 "code" : "SUCCESS" 1950 } 1951 }, 1952 "type" : "endpoint-cost-map", 1953 "data" : { 1954 "cost-type" : "routingcost", 1955 "cost-mode" : "ordinal", 1956 "map" : { 1957 "ipv4:192.0.2.2": { 1958 "ipv4:192.0.2.89" : 1, 1959 "ipv4:198.51.100.34" : 2, 1960 "ipv4:203.0.113.45" : 3 1961 } 1962 } 1963 } 1964 } 1966 8. Redistributable Responses 1968 This section defines how an ALTO Server enables certain responses to 1969 be redistributed by ALTO Clients. Concepts are first introduced, 1970 followed by the protocol specification. 1972 8.1. Concepts 1974 8.1.1. Service ID 1976 The Service ID is a UUID that identifies a set of ALTO Servers that 1977 would provide identical ALTO Information for any ALTO Request for any 1978 ALTO Client. Each ALTO Server within such a set is configured with 1979 an identical Service ID. 1981 If a pair of ALTO Servers would provide the same ALTO Information 1982 (same information sources, configuration, internal computations, 1983 update timescales, etc) in response to a particular ALTO Client 1984 request, then the pair of ALTO Servers SHOULD have the same Service 1985 ID. If this condition is not true, the pair of ALTO Servers MUST 1986 have a different Service ID. 1988 8.1.1.1. Rationale 1990 For scalability and fault tolerance, multiple ALTO Servers may be 1991 deployed to serve equivalent ALTO Information. In such a scenario, 1992 ALTO Responses from any such redundant server should be seen as 1993 equivalent for the purposes of redistribution. For example, if two 1994 ALTO Servers A and B are deployed by the service provider to 1995 distribute equivalent ALTO Information, then clients contacting 1996 Server A should be able to redistribute ALTO Responses to clients 1997 contacting Server B. 1999 To accomplish this behavior, ALTO Clients must be able to determine 2000 that Server A and Server B serve identical ALTO Information. One 2001 technique would be to rely on the ALTO Server's DNS name. However, 2002 such an approach would mandate that all ALTO Servers resolved by a 2003 particular DNS name would need to provide equivalent ALTO 2004 information, which may be unneccessarily restrictive. Another 2005 technique would be to rely on the server's IP adddress. However, 2006 this suffers similar problems as the DNS name in deployment scenarios 2007 using IP Anycast. 2009 To avoid such restrictions, the ALTO Protocol allows an ALTO Service 2010 Provider to explicitly denote ALTO Servers that provide equivalent 2011 ALTO Information by giving them identical Service IDs. Service IDs 2012 decouple the identification of equivalent ALTO Servers from the 2013 discovery process. 2015 8.1.1.2. Server Capability Response 2017 If an ALTO Server generates redistributable responses, the Server 2018 Capability response's 'service-id' field MUST be set to the ALTO 2019 Server's Service ID. 2021 8.1.1.3. Configuration 2023 To help prevent ALTO Servers from mistakenly claiming to distribute 2024 equivalent ALTO Information, ALTO Server implementations SHOULD by 2025 default generate a new UUID at installation time or startup if one 2026 has not explicitly been configured. 2028 8.1.2. Expiration Time 2030 ALTO Responses marked as redistributable should indicate a time after 2031 which the information is considered stale and should be refreshed 2032 from the ALTO Server (or possibly another ALTO Client). 2034 If an expiration time is present, the ALTO Server SHOULD ensure that 2035 it is reasonably consistent with the expiration time that would be 2036 computed by HTTP header fields. This specification makes no 2037 recommendation on which expiration time takes precedence, but 2038 implementers should be cognizant that HTTP intermediaries will obey 2039 only the HTTP header fields. 2041 8.1.3. Signature 2043 ALTO Responses marked as redistributable include a signature used to 2044 assert that the ALTO Server Provider generated the ALTO Information. 2046 8.1.3.1. Rationale 2048 Verification of the signature requires the ALTO Client to retrieve 2049 the ALTO Server's public key. To reduce requirements on the 2050 underlying transport (i.e., requiring SSL/TLS), an ALTO Client 2051 retrieves the public key as part of an X.509 certificate from the 2052 ALTO Server's Server Capability Response. 2054 8.1.3.2. Certificates 2056 8.1.3.2.1. Local Certificate 2058 The ALTO Server's public key is encoded within an X.509 certificate. 2059 The corresponding private key MUST be used to sign redistributable 2060 responses. This certificate is termed the Local Certificate for an 2061 ALTO Server. 2063 8.1.3.2.2. Certificate Chain 2065 To ease key provisioning, the ALTO Protocol is designed such that 2066 each ALTO Server with an identical Service ID may have a unique 2067 private key (and hence certificate). 2069 The ALTO Service Provider may configure a certificate chain at each 2070 such ALTO Server. The Local Certificate for a single ALTO Server is 2071 the bottom-most certificate in the chain. The Certificate Chains of 2072 each ALTO Server with an identical Service ID MUST share a common 2073 Root Certificate. 2075 Note that there are two simple deployment scenarios: 2077 o One-Level Certificate Chain (Local Certificate Only): In this 2078 deployment scenario, each ALTO Server with an identical Service ID 2079 may provisioned with an identical Local Certificate. 2081 o Two-Level Certificate Chain: In this deployment scenario, a Root 2082 Certificate is maintained for a set of ALTO Servers with the same 2083 Service ID. A unique Local Certificate signed by this CA is 2084 provisioned to each ALTO Server. 2086 There are advantages to using a Certificate Chain instead of 2087 deploying the same Local Certificate to each ALTO Server. 2088 Specifically, it avoids storage of the CA's private key at ALTO 2089 Servers. It is possible to revoke and re-issue a key to a single 2090 ALTO Server. 2092 8.1.3.2.3. Server Capability Response 2094 If an ALTO Server generates redistributable responses, the Server 2095 Capability response's 'certificates' field MUST be populated with the 2096 ALTO Server's full certificate chain. The first element MUST be the 2097 ALTO Server's Local Certificate, followed by the remaining 2098 Certificate Chain in ascending order to the Root Certificate. 2100 8.1.3.3. Signature Verification 2102 ALTO Clients SHOULD verify the signature on any ALTO information 2103 received via redistribution before adjusting application behavior 2104 based on it. 2106 An ALTO Client SHOULD cache its ALTO Server's Service ID and 2107 corresponding Certificate Chain included in the Server Capability 2108 response. Recall that the last certificate in this chain is the Root 2109 Certificate. The retrieval of the Service ID and certificates SHOULD 2110 be secured using HTTPS with proper validation of the server endpoint 2111 of the SSL/TLS connection [6]. 2113 An ALTO Response received via redistribution from Service ID S is 2114 declared valid if an ALTO Client can construct a transitive 2115 certificate chain from the certificate (public key) used to sign the 2116 ALTO Response to the Root Certificate corresponding to Service ID S 2117 obtained by the ALTO Client in a Server Capability response. 2119 To properly construct the chain and complete this validation, an ALTO 2120 Client may need to request additional certificates from other ALTO 2121 Clients. A simple mechanism is to request the certificate chain from 2122 the ALTO Client that received the ALTO Response. Note that these 2123 additional received certificates may be cached locally by an ALTO 2124 CLient. 2126 ALTO Clients SHOULD verify ALTO Responses received via 2127 redistribution. 2129 8.1.3.4. Redistribution by ALTO Clients 2131 ALTO Clients SHOULD pass the ALTO Server Certificate, Signature, and 2132 Signature Algorithm along with the body of the ALTO Response. The 2133 mechanism for redistributing such information is not specified by the 2134 ALTO Protocol, but one possibility is to add additional messages or 2135 fields to the application's native protocol. 2137 8.2. Protocol 2139 An ALTO Server MAY indicate that a response is suitable for 2140 redistribution by including the "redistribution" member in the 2141 RspMetaData JSON object of an ALTO Response message. This additional 2142 member, called the Response Redistribution Descriptor, has type 2143 RspRedistDesc: 2145 object { 2146 JSONString service-id; 2147 JSONString request-uri; 2148 JSONValue request-body; 2149 JSONString expires; 2150 } RspRedistDesc; 2152 The fields encoded in the Response Redistribution Descriptor allows 2153 an ALTO Client receiving redistributed ALTO Information to understand 2154 the context of the query (the ALTO Service generating the response 2155 and any input parameters) and to interpret the results. 2157 Information about ALTO Client performing the Request and any HTTP 2158 Headers passed in the request are not included in the Response 2159 Redistribution Descriptor. If any such information or headers 2160 influence the response generated by the ALTO Server, the response 2161 SHOULD NOT be indicated as redistributable. 2163 8.2.1. Response Redistribution Descriptor Fields 2165 This section defines the fields of the Response Redistribution 2166 Descriptor. 2168 8.2.1.1. Service ID 2170 The 'service-id' member is REQUIRED and MUST have a value equal to 2171 the ALTO Server's Service ID. 2173 8.2.1.2. Request URI 2175 The 'request-uri' member is REQUIRED and MUST specify the HTTP 2176 Request-URI that was passed in the HTTP Request. 2178 8.2.1.3. Request Body 2180 If the HTTP Request body was non-empty, the 'request-body' member 2181 MUST specify full JSON value passed in the HTTP Request (note that 2182 whitespace may differ, as long as the JSON Value is identical). If 2183 the HTTP Request was empty, then the 'request-body' MUST NOT be 2184 included. 2186 8.2.1.4. Expiration Time 2188 The 'expires' element is RECOMMENDED and, if present, MUST specify a 2189 time in UTC formatted according to [12]. 2191 8.2.2. Signature 2193 The Hash Algorithm, Signature Algorithm, and Signature are included 2194 as either HTTP Headers or Trailers. Headers may be useful if 2195 Responses are pre-generated, while Trailers may be useful if 2196 Responses are dynamically generated (e.g., to avoid buffering large 2197 responses in memory while the hash value is computed). 2199 The following HTTP Headers (the ALTO Server MAY specify them as HTTP 2200 Trailers instead) MUST be used to encode the Signature parameters for 2201 redistributable ALTO Responses: 2203 ALTO-HashAlgorithm: 2204 ALTO-SignatureAlgorithm: 2205 ALTO-SignatureDigest: 2207 where and are an integer values 2208 from the IANA TLS HashAlgorithm and SignatureAlgorithm registries, 2209 and is the corresponding Base64-encoded signature. 2211 9. Use Cases 2213 The sections below depict typical use cases. 2215 9.1. ALTO Client Embedded in P2P Tracker 2217 Many P2P currently-deployed P2P systems use a Tracker to manage 2218 swarms and perform peer selection. P2P trackers may currently use a 2219 variety of information to perform peer selection to meet application- 2220 specific goals. By acting as an ALTO Client, an P2P tracker can use 2221 ALTO information as an additional information source to enable more 2222 network-efficient traffic patterns and improve application 2223 performance. 2225 A particular requirement of many P2P trackers is that they must 2226 handle a large number of P2P clients. A P2P tracker can obtain and 2227 locally store ALTO information (the Network Map and Cost Map) from 2228 the ISPs containing the P2P clients, and benefit from the same 2229 aggregation of network locations done by ALTO Servers. 2231 .---------. (1) Get Network Map .---------------. 2232 | | <----------------------> | | 2233 | ALTO | | P2P Tracker | 2234 | Server | (2) Get Cost Map | (ALTO Client) | 2235 | | <----------------------> | | 2236 `---------' `---------------' 2237 ^ | 2238 (3) Get Peers | | (4) Selected Peer 2239 | v List 2240 .---------. .-----------. 2241 | Peer 1 | <-------------- | P2P | 2242 `---------' | Client | 2243 . (5) Connect to `-----------' 2244 . Selected Peers / 2245 .---------. / 2246 | Peer 50 | <------------------ 2247 `---------' 2249 Figure 4: ALTO Client Embedded in P2P Tracker 2251 Figure 4 shows an example use case where a P2P tracker is an ALTO 2252 Client and applies ALTO information when selecting peers for its P2P 2253 clients. The example proceeds as follows: 2255 1. The P2P Tracker requests the Network Map covering all PIDs from 2256 the ALTO Server using the Network Map query. The Network Map 2257 includes the IP prefixes contained in each PID, allowing the P2P 2258 tracker to locally map P2P clients into a PIDs. 2260 2. The P2P Tracker requests the Cost Map amongst all PIDs from the 2261 ALTO Server. 2263 3. A P2P Client joins the swarm, and requests a peer list from the 2264 P2P Tracker. 2266 4. The P2P Tracker returns a peer list to the P2P client. The 2267 returned peer list is computed based on the Network Map and Cost 2268 Map returned by the ALTO Server, and possibly other information 2269 sources. Note that it is possible that a tracker may use only 2270 the Network Map to implement hierarchical peer selection by 2271 preferring peers within the same PID and ISP. 2273 5. The P2P Client connects to the selected peers. 2275 Note that the P2P tracker may provide peer lists to P2P clients 2276 distributed across multiple ISPs. In such a case, the P2P tracker 2277 may communicate with multiple ALTO Servers. 2279 9.2. ALTO Client Embedded in P2P Client: Numerical Costs 2281 P2P clients may also utilize ALTO information themselves when 2282 selecting from available peers. It is important to note that not all 2283 P2P systems use a P2P tracker for peer discovery and selection. 2284 Furthermore, even when a P2P tracker is used, the P2P clients may 2285 rely on other sources, such as peer exchange and DHTs, to discover 2286 peers. 2288 When an P2P Client uses ALTO information, it typically queries only 2289 the ALTO Server servicing its own ISP. The my-Internet view provided 2290 by its ISP's ALTO Server can include preferences to all potential 2291 peers. 2293 .---------. (1) Get Network Map .---------------. 2294 | | <----------------------> | | 2295 | ALTO | | P2P Client | 2296 | Server | (2) Get Cost Map | (ALTO Client) | 2297 | | <----------------------> | | .---------. 2298 `---------' `---------------' <- | P2P | 2299 .---------. / | ^ ^ | Tracker | 2300 | Peer 1 | <-------------- | | \ `---------' 2301 `---------' | (3) Gather Peers 2302 . (4) Select Peers | | \ 2303 . and Connect / .--------. .--------. 2304 .---------. / | P2P | | DHT | 2305 | Peer 50 | <---------------- | Client | `--------' 2306 `---------' | (PEX) | 2307 `--------' 2309 Figure 5: ALTO Client Embedded in P2P Client 2311 Figure 5 shows an example use case where a P2P Client locally applies 2312 ALTO information to select peers. The use case proceeds as follows: 2314 1. The P2P Client requests the Network Map covering all PIDs from 2315 the ALTO Server servicing its own ISP. 2317 2. The P2P Client requests the Cost Map amongst all PIDs from the 2318 ALTO Server. The Cost Map by default specifies numerical costs. 2320 3. The P2P Client discovers peers from sources such as Peer Exchange 2321 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2322 P2P Trackers. 2324 4. The P2P Client uses ALTO information as part of the algorithm for 2325 selecting new peers, and connects to the selected peers. 2327 9.3. ALTO Client Embedded in P2P Client: Ranking 2329 It is also possible for a P2P Client to offload the selection and 2330 ranking process to an ALTO Server. In this use case, the ALTO Client 2331 gathers a list of known peers in the swarm, and asks the ALTO Server 2332 to rank them. 2334 As in the use case using numerical costs, the P2P Client typically 2335 only queries the ALTO Server servicing its own ISP. 2337 .---------. .---------------. 2338 | | | | 2339 | ALTO | (2) Get Endpoint Ranking | P2P Client | 2340 | Server | <----------------------> | (ALTO Client) | 2341 | | | | .---------. 2342 `---------' `---------------' <- | P2P | 2343 .---------. / | ^ ^ | Tracker | 2344 | Peer 1 | <-------------- | | \ `---------' 2345 `---------' | (1) Gather Peers 2346 . (3) Connect to | | \ 2347 . Selected Peers / .--------. .--------. 2348 .---------. / | P2P | | DHT | 2349 | Peer 50 | <---------------- | Client | `--------' 2350 `---------' | (PEX) | 2351 `--------' 2353 Figure 6: ALTO Client Embedded in P2P Client: Ranking 2355 Figure 6 shows an example of this scenario. The use case proceeds as 2356 follows: 2358 1. The P2P Client discovers peers from sources such as Peer Exchange 2359 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2360 P2P Trackers. 2362 2. The P2P Client queries the ALTO Server's Ranking Service, 2363 including discovered peers as the set of Destination Endpoints, 2364 and indicates the 'ordinal' Cost Mode. The response indicates 2365 the ranking of the candidate peers. 2367 3. The P2P Client connects to the peers in the order specified in 2368 the ranking. 2370 10. Discussions 2372 10.1. Discovery 2374 The discovery mechanism by which an ALTO Client locates an 2375 appropriate ALTO Server is out of scope for this document. This 2376 document assumes that an ALTO Client can discover an appropriate ALTO 2377 Server. Once it has done so, the ALTO Client may use the Server List 2378 query Section 7.8.1.1 to locate an ALTO Server with capabilities 2379 necessary for its application. 2381 10.2. Hosts with Multiple Endpoint Addresses 2383 In practical deployments, especially during the transition from IPv4 2384 to IPv6, a particular host may be reachable using multiple addresses. 2385 Furthermore, the particular network path followed when sending 2386 packets to the host may differ based on the address that is used. 2387 Network providers may perfer one path over another (e.g., one path my 2388 have a NAT64 middlebox). An additional consideration may be how to 2389 handle private address spaces (e.g., behind carrier-grade NATs). 2391 To support such behavior, this document allows multiple types of 2392 endpoint addresses. In supporting multiple address types, the ALTO 2393 Protocol also allows ALTO Service Provider the flexibility to 2394 indicate preferences for paths from an endpoint address of one type 2395 to an endpoint address of a different type. Note that in general, 2396 the path through the network may differ dependent on the types of 2397 addresses that are used (one such example is DS-Lite). 2399 Note that there are limitations as to what information ALTO can 2400 provide in this regard. In particular, a particular ALTO Service 2401 provider may not be able to determine if connectivity with a 2402 particular endhost will succeed over IPv4 or IPv6, as this may depend 2403 upon information unknown to the ISP such as particular application 2404 implementations. 2406 10.3. Network Address Translation Considerations 2408 At this day and age of NAT v4<->v4, v4<->v6 [27], and possibly 2409 v6<->v6[28], a protocol should strive to be NAT friendly and minimize 2410 carrying IP addresses in the payload, or provide a mode of operation 2411 where the source IP address provide the information necessary to the 2412 server. 2414 The protocol specified in this document provides a mode of operation 2415 where the source network location is computed by the ALTO Server (via 2416 the Endpoint Property Lookup interface) from the source IP address 2417 found in the ALTO Client query packets. This is similar to how some 2418 P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS 2419 Protocol" in [29]) operate. 2421 The ALTO client SHOULD use the Session Traversal Utilities for NAT 2422 (STUN) [13] to determine a public IP address to use as a source 2423 Endpoint address. If using this method, the host MUST use the 2424 "Binding Request" message and the resulting "XOR-MAPPED-ADDRESS" 2425 parameter that is returned in the response. Using STUN requires 2426 cooperation from a publicly accessible STUN server. Thus, the ALTO 2427 client also requires configuration information that identifies the 2428 STUN server, or a domain name that can be used for STUN server 2429 discovery. To be selected for this purpose, the STUN server needs to 2430 provide the public reflexive transport address of the host. 2432 10.4. Mapping IPs to ASNs 2434 It may be desired for the ALTO Protocol to provide ALTO information 2435 including ASNs. Thus, ALTO Clients may need to identify the ASN for 2436 a Resource Provider to determine the cost to that Resource Provider. 2438 Applications can already map IPs to ASNs using information from a BGP 2439 Looking Glass. To do so, they must download a file of about 1.5MB 2440 when compressed (as of October 2008, with all information not needed 2441 for IP to ASN mapping removed) and periodically (perhaps monthly) 2442 refresh it. 2444 Alternatively, the Network Map query in the Map Filtering Service 2445 defined in this document could be extended to map ASNs into a set of 2446 IP prefixes. The mappings provided by the ISP would be both smaller 2447 and more authoritative. 2449 For simplicity of implementation, it's highly desirable that clients 2450 only have to implement exactly one mechanism of mapping IPs to ASNs. 2452 10.5. Endpoint and Path Properties 2454 An ALTO Server could make available many properties about Endpoints 2455 beyond their network location or grouping. For example, connection 2456 type, geographical location, and others may be useful to 2457 applications. This specification focuses on network location and 2458 grouping, but the protocol may be extended to handle other Endpoint 2459 properties. 2461 10.6. REST-ful Protocol Structure 2463 There is an ongoing discussion as to whether the ALTO Protocol should 2464 be restructured to be REST-ful. The discussion has been captured at 2465 http://www.ietf.org/mail-archive/web/alto/current/msg00792.html and 2466 the ensuing thread. 2468 Three possible paths forward for the ALTO Protocol are: 2470 1. Keep the ALTO Protocol as it is; 2472 2. Restructure this document to allow a REST-ful protocol as an 2473 extension, while keeping the protocol unchanged; 2475 3. Restructure the protocol. 2477 This should be resolved by the ALTO Working Group before the next 2478 revision of this draft. 2480 11. IANA Considerations 2482 11.1. application/alto Media Type 2484 This document requests the registration of a new media type: 2485 "application/alto": 2487 Type name: application 2489 Subtype name: alto 2491 Required parameters: n/a 2493 Optional parameters: n/a 2495 Encoding considerations: Encoding considerations are identical to 2496 those specified for the 'application/json' media type. See [4]. 2498 Security considerations: Security considerations relating to the 2499 generation and consumption of ALTO protocol messages are discussed 2500 in Section 12. 2502 Interoperability considerations: This document specifies format of 2503 conforming messages and the interpretation thereof. 2505 Published specification: This document. 2507 Applications that use this media type: ALTO Servers and ALTO Clients 2508 either standalone or embedded within other applications. 2510 Additional information: 2512 Magic number(s): n/a 2514 File extension(s): This document uses the mime type to refer to 2515 protocol messages and thus does not require a file extension. 2517 Macintosh file type code(s): n/a 2519 Person & email address to contact for further information: See 2520 "Authors' Addresses" section. 2522 Intended usage: COMMON 2524 Restrictions on usage: n/a 2526 Author: See "Authors' Addresses" section. 2528 Change controller: See "Authors' Addresses" section. 2530 11.2. ALTO Cost Type Registry 2532 This document requests the creation of an ALTO Cost Type registry to 2533 be maintained by IANA. 2535 This registry serves two purposes. First, it ensures uniqueness of 2536 identifiers referring to ALTO Cost Types. Second, it provides 2537 references to particular semantics of allocated Cost Types to be 2538 applied by both ALTO Servers and applications utilizing ALTO Clients. 2540 New ALTO Cost Types are assigned after Expert Review [10]. The 2541 Expert Reviewer will generally consult the ALTO Working Group or its 2542 successor. Expert Review is used to ensure that proper documentation 2543 regarding ALTO Cost Type semantics and security considerations has 2544 been provided. The provided documentation should be detailed enough 2545 to provide guidance to both ALTO Service Providers and applications 2546 utilizing ALTO Clients as to how values of the registered ALTO Cost 2547 Type should be interpreted. Updates and deletions of ALTO Cost Types 2548 follow the same procedure. 2550 Registered ALTO Cost Type identifiers MUST conform to the syntatical 2551 requirements specified in Section 7.7.4. Identifiers are to be 2552 recorded and displayed as ASCII strings. 2554 Identifiers prefixed with 'priv:' are reserved for Private Use. 2555 Identifiers prefixed with 'exp:' are reserved for Experimental use. 2557 Requests to add a new value to the registry MUST include the 2558 following information: 2560 o Identifier: The name of the desired ALTO Cost Type. 2562 o Intended Semantics: ALTO Costs carry with them semantics to guide 2563 their usage by ALTO Clients. For example, if a value refers to a 2564 measurement, the measurement units must be documented. For proper 2565 implementation of the ordinal Cost Mode (e.g., by a third-party 2566 service), it should be documented whether higher or lower values 2567 of the cost are more preferred. 2569 o Security Considerations: ALTO Costs expose information to ALTO 2570 Clients. As such, proper usage of a particular Cost Type may 2571 require certain information to be exposed by an ALTO Service 2572 Provider. Since network information is frequently regarded as 2573 proprietary or confidential, ALTO Service Providers should be made 2574 aware of the security ramifications related to usage of a Cost 2575 Type. 2577 This specification requests registration of the identifier 2578 'routingcost'. Semantics for the this Cost Type are documented in 2579 Section 5.1.1.1, and security considerations are documented in 2580 Section 12.1. 2582 12. Security Considerations 2584 12.1. Privacy Considerations for ISPs 2586 ISPs must be cognizant of the network topology and provisioning 2587 information provided through ALTO Interfaces. ISPs should evaluate 2588 how much information is revealed and the associated risks. On the 2589 one hand, providing overly fine-grained information may make it 2590 easier for attackers to infer network topology. In particular, 2591 attackers may try to infer details regarding ISPs' operational 2592 policies or inter-ISP business relationships by intentionally posting 2593 a multitude of selective queries to an ALTO server and analyzing the 2594 responses. Such sophisticated attacks may reveal more information 2595 than an ISP hosting an ALTO server intends to disclose. On the other 2596 hand, revealing overly coarse-grained information may not provide 2597 benefits to network efficiency or performance improvements to ALTO 2598 Clients. 2600 12.2. ALTO Clients 2602 Applications using the information must be cognizant of the 2603 possibility that the information is malformed or incorrect. Even if 2604 an ALTO Server has been properly authenticated by the ALTO Client, 2605 the information provided may be malicious because the ALTO Server and 2606 its credentials have been compromised (e.g., through malware). Other 2607 considerations (e.g., relating to application performance) can be 2608 found in Section 6 of [22]. 2610 ALTO Clients should also be cognizant of revealing Network Location 2611 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, 2612 as doing so may allow the ALTO Server to infer communication 2613 patterns. One possibility is for the ALTO Client to only rely on 2614 Network Map for PIDs and Cost Map amongst PIDs to avoid passing IP 2615 addresses of their peers to the ALTO Server. 2617 In addition, ALTO clients should be cautious not to unintentionally 2618 or indirectly disclose the resource identifier (of which they try to 2619 improve the retrieval through ALTO-guidance), e.g., the name/ 2620 identifier of a certain video stream in P2P live streaming, to the 2621 ALTO server. Note that the ALTO Protocol specified in this document 2622 does not explicitly reveal any resource identifier to the ALTO 2623 Server. However, for instance, depending on the popularity or other 2624 specifics (such as language) of the resource, an ALTO server could 2625 potentially deduce information about the desired resource from 2626 information such as the Network Locations the client sends as part of 2627 its request to the server. 2629 12.3. Authentication, Integrity Protection, and Encryption 2631 SSL/TLS can provide encryption of transmitted messages as well as 2632 authentication of the ALTO Client and Server. HTTP Basic or Digest 2633 authentication can provide authentication of the client (combined 2634 with SSL/TLS, it can additionally provide encryption and 2635 authentication of the server). 2637 An ALTO Server may optionally use authentication (and potentially 2638 encryption) to protect ALTO information it provides. This can be 2639 achieved by digitally signing a hash of the ALTO information itself 2640 and attaching the signature to the ALTO information. There may be 2641 special use cases where encryption of ALTO information is desirable. 2642 In many cases, however, information sent out by an ALTO Server may be 2643 regarded as non-confidential information. 2645 ISPs should be cognizant that encryption only protects ALTO 2646 information until it is decrypted by the intended ALTO Client. 2647 Digital Rights Management (DRM) techniques and legal agreements 2648 protecting ALTO information are outside of the scope of this 2649 document. 2651 12.4. ALTO Information Redistribution 2653 It is possible for applications to redistribute ALTO information to 2654 improve scalability. Even with such a distribution scheme, ALTO 2655 Clients obtaining ALTO information must be able to validate the 2656 received ALTO information to ensure that it was generated by an 2657 appropriate ALTO Server. Further, to prevent the ALTO Server from 2658 being a target of attack, the verification scheme must not require 2659 ALTO Clients to contact the ALTO Server to validate every set of 2660 information. Contacting an ALTO server for information validation 2661 would also undermine the intended effect of redistribution and is 2662 therefore not desirable. 2664 Note that the redistribution scheme must additionally handle details 2665 such as ensuring ALTO Clients retrieve ALTO information from the 2666 correct ALTO Server. See [25] for further discussion. Details of a 2667 particular redistribution scheme are outside the scope of this 2668 document. 2670 To fulfill these requirements, ALTO Information meant to be 2671 redistributable contains a digital signature which includes a hash of 2672 the ALTO information signed by the ALTO Server with its private key. 2673 The corresponding public key is included in the Server Capability 2674 response Section 7.8.1.2, along with the certificate chain to a Root 2675 Certificate generated by the ALTO Service Provider. To prevent man- 2676 in-the-middle attacks, an ALTO Client SHOULD perform the Server 2677 Capability Query over SSL/TLS and verify the server identity 2678 according to [6]. 2680 The signature verification algorithm is detailed in Section 8.1.3.3. 2682 12.5. Denial of Service 2684 ISPs should be cognizant of the workload at the ALTO Server generated 2685 by certain ALTO Queries, such as certain queries to the Map Filtering 2686 Service and Ranking Service. In particular, queries which can be 2687 generated with low effort but result in expensive workloads at the 2688 ALTO Server could be exploited for Denial-of-Service attacks. For 2689 instance, a simple ALTO query with n Source Network Locations and m 2690 Destination Network Locations can be generated fairly easily but 2691 results in the computation of n*m Path Costs between pairs by the 2692 ALTO Server (see Section 5.2). One way to limit Denial-of-Service 2693 attacks is to employ access control to the ALTO server. Another 2694 possible mechanism for an ALTO Server to protect itself against a 2695 multitude of computationally expensive bogus requests is to demand 2696 that each ALTO Client to solve a computational puzzle first before 2697 allocating resources for answering a request (see, e.g., [30]). The 2698 current specification does not use such computational puzzles, and 2699 discussion regarding tradeoffs of such an approach would be needed 2700 before including such a technique in the ALTO Protocol. 2702 ISPs should also leverage the fact that the the Map Service allows 2703 ALTO Servers to pre-generate maps that can be useful to many ALTO 2704 Clients. 2706 12.6. ALTO Server Access Control 2708 In order to limit access to an ALTO server (e.g., for an ISP to only 2709 allow its users to access its ALTO server, or to prevent Denial-of- 2710 Service attacks by arbitrary hosts from the Internet), an ALTO server 2711 may employ access control policies. Depending on the use-case and 2712 scenario, an ALTO server may restrict access to its services more 2713 strictly or rather openly (see [31] for a more detailed discussion on 2714 this issue). 2716 13. References 2718 13.1. Normative References 2720 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2721 Levels", BCP 14, RFC 2119, March 1997. 2723 [2] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 2724 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 2726 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 2727 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 2728 HTTP/1.1", RFC 2616, June 1999. 2730 [4] Crockford, D., "The application/json Media Type for JavaScript 2731 Object Notation (JSON)", RFC 4627, July 2006. 2733 [5] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 2734 T. Wright, "Transport Layer Security (TLS) Extensions", 2735 RFC 4366, April 2006. 2737 [6] Saint-Andre, P. and J. Hodges, "Representation and Verification 2738 of Domain-Based Application Service Identity within Internet 2739 Public Key Infrastructure Using X.509 (PKIX) Certificates in 2740 the Context of Transport Layer Security (TLS)", 2741 draft-saintandre-tls-server-id-check-14 (work in progress), 2742 January 2011. 2744 [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2745 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 2746 January 2005. 2748 [8] Hinden, R. and S. Deering, "IP Version 6 Addressing 2749 Architecture", RFC 4291, February 2006. 2751 [9] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): 2752 The Internet Address Assignment and Aggregation Plan", BCP 122, 2753 RFC 4632, August 2006. 2755 [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2756 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 2758 [11] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 2759 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 2761 [12] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: 2762 Timestamps", RFC 3339, July 2002. 2764 [13] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 2765 Traversal Utilities for (NAT) (STUN)", 2766 draft-ietf-behave-rfc3489bis-18 (work in progress), July 2008. 2768 13.2. Informative References 2770 [14] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, 2771 "Application-Layer Traffic Optimization (ALTO) Requirements", 2772 draft-kiesel-alto-reqs-01 (work in progress), November 2008. 2774 [15] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, "P4P: 2775 Provider Portal for P2P Applications", draft-p4p-framework-00 2776 (work in progress), November 2008. 2778 [16] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A. 2779 Silberschatz., "P4P: Provider Portal for (P2P) Applications", 2780 In SIGCOMM 2008. 2782 [17] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, "P4P 2783 Protocol Specification", draft-wang-alto-p4p-specification-00 2784 (work in progress), March 2009. 2786 [18] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 2787 Export Service", draft-shalunov-alto-infoexport-00 (work in 2788 progress), October 2008. 2790 [19] Das, S. and V. Narayanan, "A Client to Service Query Response 2791 Protocol for ALTO", draft-saumitra-alto-queryresponse-00 (work 2792 in progress), March 2009. 2794 [20] Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 2795 Dimensional Peer Selection Problem", 2796 draft-saumitra-alto-multi-ps-00 (work in progress), 2797 October 2008. 2799 [21] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 2800 Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00 2801 (work in progress), March 2009. 2803 [22] Seedorf, J. and E. Burger, "Application-Layer Traffic 2804 Optimization (ALTO) Problem Statement", RFC 5693, October 2009. 2806 [23] Yang, Y., Popkin, L., Penno, R., and S. Shalunov, "An 2807 Architecture of ALTO for P2P Applications", 2808 draft-yang-alto-architecture-00 (work in progress), March 2009. 2810 [24] Zyp, K. and G. Court, "A JSON Media Type for Describing the 2811 Structure and Meaning of JSON Documents", 2812 draft-zyp-json-schema-03 (work in progress), November 2010. 2814 [25] Yingjie, G., Alimi, R., and R. Even, "ALTO Information 2815 Redistribution", draft-gu-alto-redistribution-03 (work in 2816 progress), July 2010. 2818 [26] 3rd, D., "Transport Layer Security (TLS) Extensions: Extension 2819 Definitions", draft-ietf-tls-rfc4366-bis-12 (work in progress), 2820 September 2010. 2822 [27] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 2823 Translation", draft-baker-behave-v4v6-framework-02 (work in 2824 progress), February 2009. 2826 [28] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address 2827 Translation (NAT66)", draft-mrw-behave-nat66-02 (work in 2828 progress), March 2009. 2830 [29] "Bittorrent Protocol Specification v1.0", 2831 http://wiki.theory.org/BitTorrentSpecification, 2009. 2833 [30] Jennings, C., "Computational Puzzles for SPAM Reduction in 2834 SIP", draft-jennings-sip-hashcash-06 (work in progress), 2835 July 2007. 2837 [31] Stiemerling, M. and S. Kiesel, "ALTO Deployment 2838 Considerations", draft-stiemerling-alto-deployments-06 (work in 2839 progress), January 2011. 2841 Appendix A. Acknowledgments 2843 Thank you to Jan Seedorf for contributions to the Security 2844 Considerations section. We would like to thank Yingjie Gu and Roni 2845 Even for helpful input and design concerning ALTO Information 2846 redistribution. 2848 We would like to thank the following people whose input and 2849 involvement was indispensable in achieving this merged proposal: 2851 Obi Akonjang (DT Labs/TU Berlin), 2853 Saumitra M. Das (Qualcomm Inc.), 2855 Syon Ding (China Telecom), 2856 Doug Pasko (Verizon), 2858 Laird Popkin (Pando Networks), 2860 Satish Raghunath (Juniper Networks), 2862 Albert Tian (Ericsson/Redback), 2864 Yu-Shun Wang (Microsoft), 2866 David Zhang (PPLive), 2868 Yunfei Zhang (China Mobile). 2870 We would also like to thank the following additional people who were 2871 involved in the projects that contributed to this merged document: 2872 Alex Gerber (AT&T), Chris Griffiths (Comcast), Ramit Hora (Pando 2873 Networks), Arvind Krishnamurthy (University of Washington), Marty 2874 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 2875 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T), 2876 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 2877 Damien Saucez (UCL) Thomas Scholl (AT&T), Emilio Sepulveda 2878 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 2879 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 2880 (Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia 2881 Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University), 2882 Haiyong Xie (Yale University). 2884 Appendix B. Authors 2886 [[Comment.1: RFC Editor: Please move information in this section to 2887 the Authors' Addresses section at publication time.]] 2889 Stefano Previdi 2890 Cisco 2892 Email: sprevidi@cisco.com 2894 Stanislav Shalunov 2895 BitTorrent 2897 Email: shalunov@bittorrent.com 2898 Richard Woundy 2899 Comcast 2901 Richard_Woundy@cable.comcast.com 2903 Authors' Addresses 2905 Richard Alimi (editor) 2906 Google 2907 1600 Amphitheatre Parkway 2908 Mountain View CA 2909 USA 2911 Email: ralimi@google.com 2913 Reinaldo Penno (editor) 2914 Juniper Networks 2915 1194 N Mathilda Avenue 2916 Sunnyvale CA 2917 USA 2919 Email: rpenno@juniper.net 2921 Y. Richard Yang (editor) 2922 Yale University 2923 51 Prospect St 2924 New Haven CT 2925 USA 2927 Email: yry@cs.yale.edu