idnits 2.17.1 draft-ietf-alto-protocol-06.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 914 has weird spacing: '...etaData meta...' == Line 915 has weird spacing: '...NString typ...' == Line 939 has weird spacing: '...istDesc redis...' == Line 1174 has weird spacing: '...NString uri;...' == Line 1175 has weird spacing: '...NNumber vers...' == (8 more instances...) -- The document date (October 25, 2010) is 4931 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 212 -- Looks like a reference, but probably isn't: 'RspDataType' on line 916 -- Looks like a reference, but probably isn't: 'OPTIONAL' on line 1251 -- Looks like a reference, but probably isn't: 'TODO' on line 1819 ** 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) == Outdated reference: A later version (-14) exists of draft-saintandre-tls-server-id-check-10 ** Obsolete normative reference: RFC 5226 (ref. '7') (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-02 == Outdated reference: A later version (-06) exists of draft-stiemerling-alto-deployments-05 Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG R. Alimi, Ed. 3 Internet-Draft Google 4 Intended status: Standards Track R. Penno, Ed. 5 Expires: April 28, 2011 Juniper Networks 6 Y. Yang, Ed. 7 Yale University 8 October 25, 2010 10 ALTO Protocol 11 draft-ietf-alto-protocol-06.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 April 28, 2011. 63 Copyright Notice 65 Copyright (c) 2010 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 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. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 25 134 7.7.3. Cost Type . . . . . . . . . . . . . . . . . . . . . . 25 135 7.8. ALTO Messages . . . . . . . . . . . . . . . . . . . . . . 25 136 7.8.1. Server Information Service . . . . . . . . . . . . . . 26 137 7.8.2. Map Service . . . . . . . . . . . . . . . . . . . . . 30 138 7.8.3. Map Filtering Service . . . . . . . . . . . . . . . . 34 139 7.8.4. Endpoint Property Service . . . . . . . . . . . . . . 38 140 7.8.5. Endpoint Cost Service . . . . . . . . . . . . . . . . 41 141 8. Redistributable Responses . . . . . . . . . . . . . . . . . . 43 142 8.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 43 143 8.1.1. Service ID . . . . . . . . . . . . . . . . . . . . . . 43 144 8.1.2. Expiration Time . . . . . . . . . . . . . . . . . . . 44 145 8.1.3. Signature . . . . . . . . . . . . . . . . . . . . . . 44 146 8.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 46 147 8.2.1. Response Redistribution Descriptor Fields . . . . . . 47 148 8.2.2. Signature . . . . . . . . . . . . . . . . . . . . . . 48 149 9. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 48 150 9.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 48 151 9.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 50 152 9.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 51 153 10. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 51 154 10.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 52 155 10.2. Hosts with Multiple Endpoint Addresses . . . . . . . . . . 52 156 10.3. Network Address Translation Considerations . . . . . . . . 52 157 10.4. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . 53 158 10.5. Endpoint and Path Properties . . . . . . . . . . . . . . . 53 159 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 160 11.1. application/alto Media Type . . . . . . . . . . . . . . . 54 161 11.2. ALTO Cost Type Registry . . . . . . . . . . . . . . . . . 55 162 12. Security Considerations . . . . . . . . . . . . . . . . . . . 56 163 12.1. Privacy Considerations for ISPs . . . . . . . . . . . . . 56 164 12.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 56 165 12.3. Authentication, Integrity Protection, and Encryption . . . 57 166 12.4. ALTO Information Redistribution . . . . . . . . . . . . . 57 167 12.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 58 168 12.6. ALTO Server Access Control . . . . . . . . . . . . . . . . 58 169 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 170 13.1. Normative References . . . . . . . . . . . . . . . . . . . 59 171 13.2. Informative References . . . . . . . . . . . . . . . . . . 59 172 Appendix A. TO BE MOVED . . . . . . . . . . . . . . . . . . . . . 61 173 A.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 61 174 A.2. P2P Peer Selection . . . . . . . . . . . . . . . . . . . . 61 175 A.2.1. Client-based Peer Selection . . . . . . . . . . . . . 62 176 A.2.2. Server-based Peer Selection . . . . . . . . . . . . . 62 177 A.2.3. Location-Only Peer Selection . . . . . . . . . . . . . 62 178 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 63 179 Appendix C. Authors . . . . . . . . . . . . . . . . . . . . . . . 64 180 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 182 1. Introduction 184 1.1. Background and Problem Statement 186 Today, network information available to applications is mostly from 187 the view of endhosts. There is no clear mechanism to convey 188 information about the network's preferences to applications. By 189 leveraging better network-provided information, applications have the 190 potential to become more network-efficient (e.g., reduce network 191 resource consumption) and achieve better application performance 192 (e.g., accelerated download rate). The ALTO Service intends to 193 provide a simple way to convey network information to applications. 195 The goal of this document is to specify a simple and unified protocol 196 that meets the ALTO requirements [11] while providing a migration 197 path for Internet Service Providers (ISP), Content Providers, and 198 clients that have deployed protocols with similar intentions (see 199 below). This document is a work in progress and will be updated with 200 further developments. 202 1.2. Design History and Merged Proposals 204 The protocol specified here consists of contributions from 206 o P4P [12], [13]; 208 o ALTO Info-Export [14]; 210 o Query/Response [15], [16]; 212 o ATTP [ATTP]; 214 o Proxidor [17]. 216 See Appendix B for a list of people that have contributed 217 significantly to this effort and the projects and proposals listed 218 above. 220 1.3. Solution Benefits 222 The ALTO Service offers many benefits to both end-users (consumers of 223 the service) and Internet Service Providers (providers of the 224 service). 226 1.3.1. Service Providers 228 The ALTO Service enables ISPs to influence the peer selection process 229 in distributed applications in order to increase locality of traffic, 230 improve user-experience, amongst others. It also helps ISPs to 231 efficiently engineer traffic that traverses more expensive links such 232 as transit and backup links, thus allowing a better provisioning of 233 the networking infrastructure. 235 1.3.2. Applications 237 Applications that use the ALTO Service can benefit in multiple ways. 238 For example, they may no longer need to infer topology information, 239 and some applications can reduce reliance on measuring path 240 performance metrics themselves. They can take advantage of the ISP's 241 knowledge to avoid bottlenecks and boost performance. 243 An example type of application is a Peer-to-Peer overlay where peer 244 selection can be improved by including ALTO information in the 245 selection process. 247 2. Architecture 249 Two key design objectives of the ALTO Protocol are simplicity and 250 extensibility. At the same time, it introduces additional techniques 251 to address potential scalability and privacy issues. After an 252 introduction to the terminology, the ALTO architecture and the ALTO 253 Protocol's place in the overall architecture are defined. 255 2.1. Terminology 257 We use the following terms defined in [18]: Application, Overlay 258 Network, Peer, Resource, Resource Identifier, Resource Provider, 259 Resource Consumer, Resource Directory, Transport Address, Host 260 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 261 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 262 Transit Traffic. 264 We also use the following additional terms: Endpoint Address, ASN, 265 and Network Location. 267 2.1.1. Endpoint Address 269 An endpoint address represents the communication address of an 270 endpoint. An endpoint address can be network-attachment based (IP 271 address) or network-attachment agnostic. Common forms of endpoint 272 addresses include IP address, MAC address, overlay ID, and phone 273 number. 275 2.1.2. ASN 277 An Autonomous System Number. 279 2.1.3. Network Location 281 Network Location is a generic term denoting a single endpoint or 282 group of endpoints. 284 2.1.4. ALTO Information 286 ALTO Information is a generic term referring to the network 287 information sent by an ALTO Server. 289 2.1.5. ALTO Information Base 291 Internal representation of the ALTO Information maintained by the 292 ALTO Server. Note that the structure of this internal representation 293 is not defined by this document. 295 2.2. ALTO Service and Protocol Scope 297 An ALTO Server conveys the network information from the perspective 298 of a network region; the ALTO Server presents its "my-Internet View" 299 [19] of the network region. A network region in this context can be 300 an Autonomous System, an ISP, or perhaps a smaller region or set of 301 ISPs; the details depend on the deployment scenario and discovery 302 mechanism. 304 To better understand the ALTO Service and the role of the ALTO 305 Protocol, we show in Figure 1 the overall system architecture. In 306 this architecture, an ALTO Server prepares ALTO Information; an ALTO 307 Client uses ALTO Service Discovery to identify an appropriate ALTO 308 Server; and the ALTO Client requests available ALTO Information from 309 the ALTO Server using the ALTO Protocol. 311 The ALTO Information provided by the ALTO Server can be updated 312 dynamically based on network conditions, or can be seen as a policy 313 which is updated at a larger time-scale. 315 More specifically, the ALTO Information provided by an ALTO Server 316 may be influenced (at the operator's discretion) by other systems. 317 Examples include (but are not limited to) static network 318 configuration databases, dynamic network information, routing 319 protocols, provisioning policies, and interfaces to outside parties. 320 These components are shown in the figure for completeness but outside 321 the scope of this specification. 323 Note that it may also be possible for ALTO Servers to exchange 324 network information with other ALTO Servers (either within the same 325 administrative domain or another administrative domain with the 326 consent of both parties) in order to adjust exported ALTO 327 information. Such a protocol is also outside the scope of this 328 specification. 330 +-------------------------------------------------------------------+ 331 | ISP | 332 | | 333 | +-----------+ | 334 | | Routing | | 335 | +--------------+ | Protocols | | 336 | | Provisioning | +-----------+ | 337 | | Policy | | | 338 | +--------------+\ | | 339 | \ | | 340 | \ | | 341 | +-----------+ \+---------+ +--------+ | 342 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 343 | |Network |.......| Server | -------------------- | Client | | 344 | |Information| +---------+ +--------+ | 345 | +-----------+ / / | 346 | / ALTO SD Query/Response / | 347 | / / | 348 | +----------+ +--------------+ | 349 | | External | | ALTO Service | | 350 | | Interface| | Discovery | | 351 | +----------+ +--------------+ | 352 | | | 353 +-------------------------------------------------------------------+ 354 | 355 +------------------+ 356 | Third Parties | 357 | | 358 | Content Providers| 359 +------------------+ 361 Figure 1: Basic ALTO Architecture 363 3. Protocol Structure 365 The ALTO Protocol uses a simple extensible framework to convey 366 network information. In the general framework, the ALTO protocol 367 will convey properties on both Network Locations and the paths 368 between Network Locations. 370 In this document, we focus on a particular Endpoint property to 371 denote the location of an endpoint, and provider-defined costs for 372 paths between pairs of Network Locations. 374 The ALTO Protocol is built on a common transport protocol, messaging 375 structure and encoding, and transaction model. The protocol is 376 subdivided into services of related functionality. ALTO-Core 377 provides the Server Information Service and the Map Service to 378 provide ALTO Information. Other ALTO Information services can 379 provide additional functionality. There are three such services 380 defined in this document: the Map Filtering Service, Endpoint 381 Property Service, and Endpoint Cost Service. Additional services may 382 be defined in in companion documents. Note that functionality 383 offered in different services are not totally non-overlapping (e.g., 384 the Map Service and Map Filtering Service). 386 .------------------------------------------------------------. 387 | | 388 | .----------. .-----------------------------------------. | 389 | | | | ALTO Info Services | | 390 | | | | .-----------. .----------. .----------. | | 391 | | | | | Map | | Endpoint | | Endpoint | | | 392 | | | | | Filtering | | Property | | Cost | | | 393 | | | | | Service | | Service | | Service | | | 394 | | Server | | `-----------' `----------' `----------' | | 395 | | Info | | .-------------------------------------. | | 396 | | Service | | | Map Service | | | 397 | | | | | .-------------. .--------------. | | | 398 | | | | | | Network Map | | Cost Map | | | | 399 | | | | | `-------------' `--------------' | | | 400 | | | | `-------------------------------------' | | 401 | `----------' `-----------------------------------------' | 402 | | 403 `------------------------------------------------------------' 405 Figure 2: ALTO Protocol Structure 407 3.1. Server Information Service 409 The Server Capability Service lists the details on the information 410 that can be provided by an ALTO Server and perhaps other ALTO Servers 411 maintained by the network provider. The configuration includes, for 412 example, details about the operations and cost metrics supported by 413 the ALTO Server and other related ALTO Servers that may be usable by 414 an ALTO Client. The capability document can be downloaded by ALTO 415 Clients. The capability information could also be provisioned to 416 devices, but care must be taken to update it appropriately. 418 3.2. ALTO Information Services 420 Multiple, distinct services are defined to allow ALTO Clients to 421 query ALTO Information from an ALTO Server. The ALTO Server 422 internally maintains an ALTO Information Base that encodes the 423 network provider's preferences. The ALTO Information Base encodes 424 the Network Locations defined by the ALTO Server (and their 425 corresponding properties), as well as the provider-defined costs 426 between pairs of Network Locations. 428 3.2.1. Map Service 430 The Map Service provides batch information to ALTO Clients in the 431 form of a Network Map and Cost Map. The Network Map (See Section 4) 432 provides the full set of Network Location groupings defined by the 433 ALTO Server and the endpoints contained with each grouping. The Cost 434 Map (see Section 5) provides costs between the defined groupings. 436 These two maps can be thought of (and implemented as) as simple files 437 with appropriate encoding provided by the ALTO Server. 439 3.2.2. Map Filtering Service 441 Resource constrained ALTO Clients may benefit from query results 442 being filtered at the ALTO Server. This avoids an ALTO Client 443 spending network bandwidth or CPU collecting results and performing 444 client-side filtering. The Map Filtering Service allows ALTO Clients 445 to query for the ALTO Server Network Map and Cost Map based on 446 additional parameters. 448 3.2.3. Endpoint Property Service 450 This service allows ALTO Clients to look up properties for individual 451 endpoints. An example endpoint property is its Network Location (its 452 grouping defined by the ALTO Server) or connectivity type (e.g., 453 ADSL, Cable, or FioS). 455 3.2.4. Endpoint Cost Service 457 Some ALTO Clients may also benefit from querying for costs and 458 rankings based on endpoints. The Endpoint Cost Service allows an 459 ALTO Server to return either numerical costs or ordinal costs 460 (rankings) directly amongst Endpoints. 462 4. Network Map 464 In reality, many endpoints are very close to one another in terms of 465 network connectivity, for example, endpoints on the same site of an 466 enterprise. By treating a group of endpoints together as a single 467 entity in ALTO, we can achieve much greater scalability without 468 losing critical information. 470 The Network Location endpoint property allows an ALTO Server to group 471 endpoints together to indicate their proximity. The resulting set of 472 groupings is called the ALTO Network Map. 474 The definition of proximity varies depending on the granularity of 475 the ALTO information configured by the provider. In one deployment, 476 endpoints on the same subnet may be considered close; while in 477 another deployment, endpoints connected to the same PoP may be 478 considered close. 480 As used in this document, the Network Map refers to the syntax and 481 semantics of the information distributed by the ALTO Server. This 482 document does not discuss the internal representation of this data 483 structure within the ALTO Server. 485 4.1. PID 487 Each group of Endpoints is identified by a provider-defined Network 488 Location identifier called a PID. There can be many different ways 489 of grouping the endpoints and assigning PIDs. 491 A PID is an identifier that provides an indirect and network-agnostic 492 way to specify a network aggregation. For example, a PID may be 493 defined by the ALTO service provider to denote a subnet, a set of 494 subnets, a metropolitan area, a PoP, an autonomous system, or a set 495 of autonomous systems. Aggregation of endpoints into PIDs can 496 indicate proximity and can improve scalability. In particular, 497 network preferences (costs) may be specified between PIDs, allowing 498 cost information to be more compact and updated at a smaller time 499 scale than the network aggregations themselves. 501 Using PIDs, the Network Map may also be used to communicate simple 502 preferences with only minimal information from the Cost Map. For 503 example, an ISP may prefer that endpoints associated with the same 504 PoP (Point-of-Presence) in a P2P application communicate locally 505 instead of communicating with endpoints in other PoPs. The ISP may 506 aggregate endhosts within a PoP into a single PID in the Network Map. 507 The Cost Map may be encoded to indicate that peering within the same 508 PID is preferred; for example, cost(PID_i, PID_i) == c* and 509 cost(PID_i, PID_j) > c* for i != j. Section 5 provides further 510 details about Cost Map structure. 512 4.2. Endpoint Addresses 514 Communicating endpoints may have many types of addresses, such as IP 515 addresses, MAC addresses, or overlay IDs. The current specification 516 only considers IP addresses. 518 4.2.1. IP Addresses 520 The endpoints aggregated into a PID are denoted by a list of IP 521 prefixes. When either an ALTO Client or ALTO Server needs to 522 determine which PID in a Network Map contains a particular IP 523 address, longest-prefix matching MUST be used. 525 A Network Map MUST define a PID for each possible address in the IP 526 address space. A RECOMMENDED way to satisfy this property is to 527 define a PID containing the 0.0.0.0/0 prefix for IPv4 or ::/0 (for 528 IPv6). 530 4.3. Example Network Map 532 Figure 3 illustrates an example Network Map. PIDs are used to 533 identify network-agnostic aggregations. 535 .-----------------------------------------------------------. 536 | ALTO Network Map | 537 | | 538 | .-----------------------------------. .---------------. | 539 | | NetLoc: PID-1 | | NetLoc: PID-2 | | 540 | | .------------------------------. | | ... | | 541 | | | 192.0.2.0/24 | | `---------------` | 542 | | | .--------------------------. | | | 543 | | | | Endpoint: 192.0.2.34 | | | .---------------. | 544 | | | `--------------------------` | | | NetLoc: PID-3 | | 545 | | `------------------------------` | | ... | | 546 | | .------------------------------. | `---------------` | 547 | | | 198.51.100.0/25 | | | 548 | | | .--------------------------. | | .---------------. | 549 | | | | Endpoint: 198.51.100.100 | | | | NetLoc: PID-4 | | 550 | | | `--------------------------` | | | ... | | 551 | | `------------------------------` | `---------------` | 552 | `-----------------------------------` | 553 | | 554 `-----------------------------------------------------------` 556 Figure 3: Example Network Map 558 5. Cost Map 560 An ALTO Server indicates preferences amongst network locations in the 561 form of Path Costs. Path Costs are generic costs and can be 562 internally computed by a network provider according to its own needs. 564 An ALTO Cost Map defines Path Costs pairwise amongst sets of source 565 and destination Network Locations. 567 One advantage of separating ALTO information into a Network Map and a 568 Cost Map is that the two components can be updated at different time 569 scales. For example, Network Maps may be stable for a longer time 570 while Cost Maps may be updated to reflect dynamic network conditions. 572 As used in this document, the Cost Map refers to the syntax and 573 semantics of the information distributed by the ALTO Server. This 574 document does not discuss the internal representation of this data 575 structure within the ALTO Server. 577 5.1. Cost Attributes 579 Path Costs have attributes: 581 o Type: identifies what the costs represent; 583 o Mode: identifies how the costs should be interpreted. 585 Certain queries for Cost Maps allow the ALTO Client to indicate the 586 desired Type and Mode. 588 5.1.1. Cost Type 590 The Type attribute indicates what the cost represents. For example, 591 an ALTO Server could define costs representing air-miles, hop-counts, 592 or generic routing costs. 594 Cost types are indicated in protocol messages as strings. 596 5.1.1.1. Cost Type: routingcost 598 An ALTO Server MUST define the 'routingcost' Cost Type. 600 This Cost Type conveys a generic measure for the cost of routing 601 traffic from a source to a destination. Lower values indicate a 602 higher preference for traffic to be sent from a source to a 603 destination. 605 Note that an ISP may internally compute routing cost using any method 606 it chooses (e.g., air-miles or hop-count) as long as it conforms to 607 these semantics. 609 5.1.2. Cost Mode 611 The Mode attribute indicates how costs should be interpreted. An 612 ALTO Server return costs that are interpreted as either numerical 613 values or ordinal rankings. 615 It is important to communicate such information to ALTO Clients, as 616 certain operations may not be valid on certain costs returned by an 617 ALTO Server. For example, it is possible for an ALTO Server to 618 return a set of IP addresses with costs indicating a ranking of the 619 IP addresses. Arithmetic operations, such as summation, that would 620 make sense for numerical values, do not make sense for ordinal 621 rankings. ALTO Clients may handle such costs differently. 623 Cost Modes are indicated in protocol messages as strings. 625 An ALTO Server MUST support at least one of 'numerical' and 'ordinal' 626 costs. ALTO Clients SHOULD be cognizant of operation when a desired 627 cost mode is not supported. For example, an ALTO Client desiring 628 numerical costs may adjust behavior if only the ordinal Cost Mode is 629 available. Alternatively, an ALTO Client desiring ordinal costs may 630 construct ordinal costs given numerical values if only the numerical 631 Cost Mode is available. 633 5.1.2.1. Cost Mode: numerical 635 This Cost Mode is indicated by the string 'numerical'. This mode 636 indicates that it is safe to perform numerical operations (e.g. 637 summation) on the returned costs. 639 5.1.2.2. Cost Mode: ordinal 641 This Cost Mode is indicated by the string 'ordinal'. This mode 642 indicates that the costs values to a set of Destination Network 643 Locations from a particular Source Network Location are a ranking, 644 with lower values indicating a higher preference. 646 It is important to note that the values in the Cost Map provided with 647 the ordinal Cost Mode are not necessarily the actual cost known to 648 the ALTO Server. 650 5.2. Cost Map Structure 652 A query for a Cost Map either explicitly or implicitly includes a 653 list of Source Network Locations and a list of Destination Network 654 Locations. (Recall that a Network Location can be an endpoint 655 address or a PID.) 657 Specifically, assume that a query has a list of multiple Source 658 Network Locations, say [Src_1, Src_2, ..., Src_m], and a list of 659 multiple Destination Network Locations, say [Dst_1, Dst_2, ..., 660 Dst_n]. 662 The ALTO Server will return the Path Cost for each communicating pair 663 (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., Src_m -> Dst_1, ..., 664 Src_m -> Dst_n). We refer to this structure as a Cost Map. 666 If the Cost Mode is 'ordinal', the Path Cost of each communicating 667 pair is relative to the m*n entries. 669 5.3. Network Map and Cost Map Dependency 671 If a Cost Map contains PIDs in the list of Source Network Locations 672 or the list of Destination Network Locations, the Path Costs are 673 generated based on a particular Network Map (which defines the PIDs). 674 Version Tags are introduced to ensure that ALTO Clients are able to 675 use consistent information even though the information is provided in 676 two maps. 678 A Version Tag is an opaque string associated with a Network Map 679 maintained by the ALTO Server. When the Network Map changes, the 680 Version Tag SHOULD also be changed. (Thus, the Version Tag is 681 defined similarly to HTTP's ETag.) Possibilities for generating a 682 Version Tag included the last-modified timestamp for the Network Map, 683 or a hash of its contents. 685 A Network Map distributed by the ALTO Server includes its Version 686 Tag. A Cost Map referring to PIDs also includes the Version Tag of 687 the Network Map on which it is based. 689 6. Protocol Design Overview 691 The ALTO Protocol design uses a REST-like interface with the goal of 692 leveraging current HTTP [2] [3] implementations and infrastructure, 693 as well as familiarity with existing REST-like services in popular 694 use. ALTO messages use JSON [4] to encode message bodies. 696 This document currently specifies both services and and the message 697 encoding in a descriptive fashion. Care is taken to make 698 descriptions precise and unambiguous, but it still lacks benefits of 699 automatic tooling that exists for certain encoding formats. 701 Standards such as WSDL 2.0 and WADL are capable of describing 702 available interfaces. JSON Schema [20] allows message encodings to 703 be specified precisely and messages may be verified against the 704 schema. It is not yet clear whether such an approach should be taken 705 in this document. 707 Other benefits enabled by these design choices include easier 708 understanding and debugging, flexible ALTO Server implementation 709 strategies, and more importantly, simple caching and redistribution 710 of ALTO information to increase scalability. 712 6.1. Existing Infrastructure 714 HTTP is a natural choice for integration with existing applications 715 and infrastructure. In particular, the ALTO Protocol design 716 leverages: 718 o the huge installed base of infrastructure, including HTTP caches, 720 o mature software implementations, 722 o the fact that many P2P clients already have an embedded HTTP 723 client, and 725 o authentication and encryption mechanisms in HTTP and SSL/TLS. 727 6.2. ALTO Information Reuse and Redistribution 729 ALTO information may be useful to a large number of applications and 730 users. For example, an identical Network Map may be used by all ALTO 731 Clients querying a particular ALTO Server. At the same time, 732 distributing ALTO information must be efficient and not become a 733 bottleneck. 735 Beyond integration with existing HTTP caching infrastructure, ALTO 736 information may also be cached or redistributed using application- 737 dependent mechanisms, such as P2P DHTs or P2P file-sharing. This 738 document does not define particular mechanisms for such 739 redistribution, but it does define the primitives (e.g., digital 740 signatures) needed to support such a mechanism. See [21] for further 741 discussion. 743 Note that if caching or redistribution is used, the Response message 744 may be returned from another (possibly third-party) entity. Reuse 745 and Redistribution is further discussed in Section 12.4. Protocol 746 support for redistribution is specified in Section 8. 748 7. Protocol Messaging 750 This section specifies client and server processing, as well as 751 messages in the ALTO Protocol. Details common to ALTO Server 752 processing of all messages is first discussed, followed by details of 753 the individual messages. 755 7.1. Notation 757 This document uses an adaptation of the C-style struct notation to 758 define the required and optional members of JSON objects. Unless 759 explicitly noted, each member of a struct is REQUIRED. 761 The types 'JSONString', 'JSONNumber', 'JSONBool' indicate the JSON 762 string, number, and boolean types respectively. 764 This document only includes object members used by this 765 specification. It is possible that protocol extensions include 766 additional members to JSON objects defined in this document; such 767 additional members will be silently ignored by ALTO Servers and 768 Clients only implementing the base protocol defined in this document. 770 7.2. Message Format 772 Request and Response follow the standard format for HTTP Request and 773 Response messages [2] [3]. 775 The following subsections provide an overview of how ALTO Requests 776 and Responses are encoded in HTTP, and discusses rationale for 777 certain design decisions. 779 7.2.1. Protocol Versioning 781 The ALTO Protocol uses a simple versioning approach that permits 782 evolution between versions even if ALTO information is being served 783 as static, pre-generated files. 785 It is assumed that a single host responding to ALTO Requests 786 implements a single protocol version. Virtual hosting may be used if 787 multiple protocol versions need to be supported by a single physical 788 server. 790 A common query (Server List, detailed in Section 7.8.1.1) to be 791 present in all ALTO protocol versions allows an ALTO Client to 792 discover additional ALTO Servers and the ALTO Protocol version number 793 of each. 795 This approach keeps the ALTO Server implementation free from parsing 796 and directing each request based on version number. Although ALTO 797 Requests are free from protocol version numbers, the protocol version 798 number is echoed in each ALTO Response to keep responses self- 799 contained to, for example, ease reading persisted or redistributed 800 ALTO responses. 802 Using virtual hosting with TLS may require the Server Name Indication 803 extension for TLS [5] [22]. 805 This document specifies ALTO Protocol version 1. 807 7.2.2. Content Type 809 All ALTO Request and Response messages MUST set the Content-Type HTTP 810 header to "application/alto". 812 7.2.3. Request Message 814 An ALTO Request is a standard HTTP Request generated by an ALTO 815 Client, with certain components defined by the ALTO Protocol. 817 The basic syntax of an ALTO Request is: 819 / HTTP/1.1 820 Host: 822 For example: 824 GET /info/capability HTTP/1.1 825 Host: alto.example.com:6671 827 7.2.3.1. Standard HTTP Headers 829 The Host header MUST follow the standard rules for the HTTP 1.1 Host 830 Header. 832 The Content-Length header MUST follow the standard rules defined in 833 HTTP 1.1. 835 The Content-Type HTTP Header MUST have value "application/alto" if 836 the Body is non-empty. 838 7.2.3.2. Method and Resource 840 Next, both the HTTP Method and URI-Path (denoted as Resource) 841 indicate the operation requested by the ALTO Client. In this 842 example, the ALTO Client is requesting basic capability information 843 from the ALTO Server. 845 7.2.3.3. Input Parameters 847 Certain operations defined by the ALTO Protocol (e.g., in the Map 848 Filtering Service) allow the ALTO Client to supply additional input 849 parameters. Such input parameters are encoded in a URI-Query-String 850 where possible and appropriate. However, due to practical 851 limitations (e.g. underlying HTTP implementations may have 852 limitations on the total length of a URI and the Query-String is 853 better-suited for simple unstructured parameters and lists), some 854 operations in the ALTO Protocol use input parameters encoded in the 855 HTTP Request Body. 857 7.2.4. Response Message 859 A Response message is a standard HTTP Response generated by an ALTO 860 Server with certain components defined by the ALTO Protocol. 862 The basic syntax of an ALTO Response is: 864 HTTP/1.1 865 Content-Length: 866 Content-Type: 868 870 where the HTTP Response Body is an ALTOResponse JSON Object (defined 871 in Section 7.2.4.3). For example: 873 HTTP/1.1 200 OK 874 Content-Length: 1000 875 Content-Type: application/alto 877 { 878 "meta" : { 879 "version": 1, 880 "status" : { 881 "code" : 1, 882 "reason" : "Success" 883 }, 884 ... 885 }, 886 "type" : "capability", 887 "data" : { 888 ... 889 } 890 } 892 7.2.4.1. Standard HTTP Headers 894 The Content-Length header MUST follow the standard rules defined in 895 HTTP 1.1. 897 The Content-Type HTTP Header MUST have value "application/alto" if 898 the Body is non-empty. 900 7.2.4.2. Status Code and Message 902 Two sets of status codes are used in the ALTO Protocol. First, an 903 ALTO Status Code provides detailed information about the success or 904 failure of a particular operation. Second, an HTTP Status Code 905 indicates to HTTP processing elements (e.g., intermediaries and 906 clients) how the response should be treated. 908 7.2.4.3. HTTP Body 910 The Response body MUST encode a single top-level JSON object of type 911 ALTOResponse: 913 object { 914 RspMetaData meta; 915 JSONString type; 916 [RspDataType] data; 917 } ALTOResponse; 919 The ALTOResponse object has distinct sections for: 921 o meta information encoded in an extensible way, 923 o the type of ALTO Information to follow, and 925 o the requested ALTO Information. 927 7.2.4.3.1. Meta Information 929 Meta information is encoded as a JSON object with type RspMetaData: 931 object { 932 JSONString code; 933 JSONString reason; [OPTIONAL] 934 } RspStatus; 936 object { 937 JSONNumber version; 938 RspStatus status; 939 RspRedistDesc redistribution; [OPTIONAL] 941 } RspMetaData; 943 with members: 945 o version: the ALTO Protocol version 947 o status: an ALTO Status Code from Section 7.4 and corresponding 948 reason (free-form string) providing a human-readable explanation 949 of the particular status code. 951 o redistribution: see Section 8. 953 7.2.4.3.2. ALTO Information 955 If the Response is successful (see Section 7.4), then the "type" and 956 "data" members of the ALTOResponse object are REQUIRED. "type" 957 encodes a Response-specific string which indicates to the ALTO Client 958 the type of data encoded in the message. The "data" member encodes 959 the actual Response-specific data; the structure of this member is 960 detailed later in this section for each particular ALTO Response. 962 7.2.4.4. Signature 964 An ALTO Server MAY additionally supply a signature asserting that it 965 generated a particular response. See Section 8.2.2. 967 7.3. General Processing 969 The protocol is structured in such a way that, independent of the 970 query type, there are a set of general processing steps. The ALTO 971 Client selects a specific ALTO Server with which to communicate, 972 establishes a TCP connection, and constructs and sends ALTO Request 973 messages which MUST conform to Section 7.8. In response to Request 974 messages, an ALTO Server constructs and sends ALTO Response messages 975 which also MUST conform to Section 7.8. 977 7.4. ALTO Status Codes 979 This document defines ALTO Status Codes to support the operations 980 defined in this document. Additional status codes may be defined in 981 companion or extension documents. 983 An ALTO Server MUST return the SUCCESS status code if and only if the 984 Request message is successfully processed and the requested ALTO 985 information is returned by the ALTO Server. 987 The HTTP Status Codes corresponding to each ALTO Status Code are 988 defined to provide correct behavior with HTTP intermediaries and 989 clients. When an ALTO Server returns a particular ALTO Status Code, 990 it MUST indicate one of the corresponding HTTP Status Codes in 991 Table 1. 993 If multiple errors are present in a single ALTO Request (e.g., a 994 request uses a JSONString when a JSONInteger is expected and a 995 required field is missing), then the ALTO Server MUST return exactly 996 one of the detected errors. However, the reported error is 997 implementation defined, since specifying a particular order for 998 message processing encroaches needlessly on implementation technique. 1000 +----------------------+------------------+-------------------------+ 1001 | ALTO Status Code | HTTP Status | Description | 1002 | | Code(s) | | 1003 +----------------------+------------------+-------------------------+ 1004 | SUCCESS | 2xx | Success | 1005 | E_JSON_SYNTAX | 400 | JSON parsing error in | 1006 | | | request | 1007 | E_JSON_FIELD_MISSING | 400 | Required field missing | 1008 | E_JSON_VALUE_TYPE | 400 | JSON Value of | 1009 | | | unexpected type | 1010 | E_INVALID_OPERATION | 501 | Invalid operation | 1011 | | | requested | 1012 | E_INVALID_COST_TYPE | 501 | Invalid cost type | 1013 +----------------------+------------------+-------------------------+ 1015 Table 1: Defined ALTO Status Codes 1017 Status codes described in Table 1 are a work in progress. This 1018 document will be modified to update the available status codes as 1019 implementation experience is gained. Feedback is welcomed. 1021 In addition, feedback from implementers of ALTO Clients is welcomed 1022 to identify if there is a need to communicate multiple status codes 1023 in a single response. 1025 7.5. Client Behavior 1027 7.5.1. Successful Response 1029 This specification does not indicate any required actions taken by 1030 ALTO Clients upon receiving a successful response from an ALTO 1031 Server. Although ALTO Clients are suggested to interpret the 1032 received ALTO Information and adapt application behavior, ALTO 1033 Clients are not required to do so. 1035 7.5.2. Error Conditions 1037 If an ALTO Client does not receive a successful response from the 1038 ALTO Server, it can either choose another server or fall back to a 1039 default behavior (e.g., perform peer selection without the use of 1040 ALTO information). An ALTO Client may also retry the request at a 1041 later time. 1043 7.6. HTTP Usage 1045 7.6.1. Authentication and Encryption 1047 An ALTO Server MAY support SSL/TLS to implement server and/or client 1048 authentication, as well as encryption. See [6] for considerations 1049 regarding verifcation of server identity. 1051 An ALTO Server MAY support HTTP Digest authentication. 1053 7.6.2. Cookies 1055 Cookies MUST NOT be used. 1057 7.6.3. Caching Parameters 1059 If the Response generated by the ALTO Server is cachable, the ALTO 1060 Server MAY include 'Cache-Control' and 'Expires' HTTP headers. 1062 If a Response generated by the ALTO Server is not cachable, the ALTO 1063 Server MUST specify the "Cache-Control: no-cache" HTTP Header. 1065 7.7. ALTO Types 1067 This section details the encoding for particular data values used in 1068 the ALTO Protocol. 1070 7.7.1. PID Name 1072 A PID Name is encoded as a US-ASCII string. The string MUST be no 1073 more than 32 characters, and MUST NOT contain characters other than 1074 alphanumeric characters or the '.' separator. The '.' separator is 1075 reserved for future use and MUST NOT unless specifically indicated by 1076 a companion or extension document. 1078 The type 'PIDName' is used in this document to indicate a string of 1079 this format. 1081 7.7.2. Cost Mode 1083 A Cost Mode is encoded as a US-ASCII string. The string MUST either 1084 have the value 'numerical' or 'ordinal'. 1086 The type 'CostMode' is used in this document to indicate a string of 1087 this format. 1089 7.7.3. Cost Type 1091 A Cost Type is encoded as a US-ASCII string. The string MUST be no 1092 more than 32 characters, and MUST NOT contain characters other than 1093 alphanumeric characters or the ':' separator. 1095 Identifiers prefixed with 'priv:' are reserved for Private Use [7]. 1096 Identifiers prefixed with 'exp:' are reserved for Experimental use. 1097 All other identifiers appearing in an ALTO Request or Response MUST 1098 be registered in the ALTO Cost Types registry Section 11. 1100 The type 'CostType' is used in this document to indicate a string of 1101 this format. 1103 7.8. ALTO Messages 1105 This section documents the individual operations supported in the 1106 ALTO Protocol. See Section 7.2.3 and Section 7.2.4 for 1107 specifications of HTTP Request/Response components common to all 1108 operations in the ALTO Protocol. 1110 Table 2 provides an summary of the HTTP Method and URI-Paths used for 1111 ALTO Requests: 1113 +----------------+--------------+----------------------------+ 1114 | Service | Operation | HTTP Method and URI-Path | 1115 +----------------+--------------+----------------------------+ 1116 | Server Info | List Servers | GET /info/servers | 1117 | Server Info | Capability | GET /info/capability | 1118 | | | | 1119 | Map | Network Map | GET /map/core/pid/net | 1120 | Map | Cost Map | GET /map/core/pid/cost | 1121 | | | | 1122 | Map Filtering | Network Map | POST /map/filter/pid/net | 1123 | Map Filtering | Cost Map | POST /map/filter/pid/cost | 1124 | | | | 1125 | Endpoint Prop. | Lookup | GET /endpoint/prop/ | 1126 | | | POST /endpoint/prop/lookup | 1127 | | | | 1128 | Endpoint Cost | Lookup | POST /endpoint/cost/lookup | 1129 +----------------+--------------+----------------------------+ 1131 Table 2: Overview of ALTO Requests 1133 7.8.1. Server Information Service 1135 The Server Information Service provides information about available 1136 ALTO Servers and their capabilities (e.g., supported services). 1138 An ALTO Server MUST support the Server Information Service and MUST 1139 implement all operations defined in this section. 1141 7.8.1.1. Server List 1143 The Server List request allows an ALTO Client to discover other ALTO 1144 Servers provided by the ALTO Service Provider. Upon discovering an 1145 additional ALTO Server, the ALTO Client may then query the server 1146 capabilities (see Section 7.8.1.2) to test if it supports desired 1147 functionality. 1149 The Server List request is intended to help an ALTO Client find an 1150 ALTO Server supporting the desired ALTO Protocol version and 1151 capabilities. It is not intended to serve as a substitute for the 1152 ALTO Server Discovery which helps an ALTO Client locate an initial 1153 ALTO Server. 1155 This operation MUST be supported by the ALTO Server. 1157 7.8.1.1.1. Request Syntax 1159 GET /info/servers HTTP/1.1 1160 Host: 1162 7.8.1.1.2. Response Syntax 1164 HTTP/1.1 200 1165 Content-Length: 1166 Content-Type: application/alto 1168 1170 where the ALTOResponse object has "type" member equal to the string 1171 "server-list" and "data" member of type RspServerList: 1173 object { 1174 JSONString uri; 1175 JSONNumber version; 1176 } ServerItem; 1178 object { 1179 ServerItem servers<0..*>; 1180 } RspServerList; 1182 RspServerList has members: 1184 o servers: Array of available ALTO Servers, detailing the URI of the 1185 ALTO Server and the ALTO Protocol version that it implements. The 1186 array must at least contain an entry corresponding to the ALTO 1187 Server at the URI from which it is retrieving the server list. 1189 7.8.1.1.3. Example 1191 GET /info/servers HTTP/1.1 1192 Host: alto.example.com:6671 1193 HTTP/1.1 200 OK 1194 Content-Length: [TODO] 1195 Content-Type: application/alto 1197 { 1198 "meta" : { 1199 "version" : 1, 1200 "status" : { 1201 "code" : 1 1202 } 1203 }, 1204 "type" : "server-list", 1205 "data" : { 1206 "servers" : [ 1207 { 1208 "uri": "http://alto.example.com:6671", 1209 "version" : 1 1210 } 1211 ] 1212 } 1213 } 1215 7.8.1.2. Server Capability 1217 The Server Capability request allows an ALTO Client to determine the 1218 functionality supported by the queried ALTO Server. 1220 This operation MUST be supported by the ALTO Server. 1222 7.8.1.2.1. Request Syntax 1224 GET /info/capability HTTP/1.1 1225 Host: 1227 7.8.1.2.2. Response Syntax 1229 HTTP/1.1 200 1230 Content-Length: 1231 Content-Type: application/alto 1233 1235 where the ALTOResponse object has "type" member equal to the string 1236 "capability" and "data" member of type RspCapability: 1238 enum { 1239 map, 1240 map-filtering, 1241 endpoint-property, 1242 endpoint-cost 1243 } ServiceType; [Note: encoded as JSONString's] 1245 object { 1246 ServiceType services<0..*>; 1247 CostMode cost-modes<0..*>; [OPTIONAL] 1248 CostType cost-types<0..*>; [OPTIONAL] 1249 JSONBool cost-constraints; [OPTIONAL] 1250 JSONString service-id; [OPTIONAL] 1251 JSONString certificates<0..*>; [OPTIONAL] 1252 } RspCapability; 1254 RspCapability has members: 1256 o services: Lists the services supported by the ALTO Server. The 1257 service names defined in this document are are "map", "map- 1258 filtering", "endpoint-property", and "endpoint-cost". 1260 o cost-modes: Array of supported ALTO Cost Modes. 1262 o cost-types: Array of supported ALTO Cost Types. 1264 o cost-constraints: Indicates if the ALTO Server supports cost 1265 constraints. The value 'false' is implied if this member is not 1266 present. 1268 o service-id: UUID [8] indicating an one or more ALTO Servers 1269 serving equivalent ALTO Information. 1271 o certificates: List of PEM-encoded X.509 certificates used by the 1272 ALTO Server in the signing of responses. 1274 If an ALTO Server denotes a response as redistributable, the 1275 'service-id' and 'certificates' fields are REQUIRED instead of 1276 OPTIONAL. See Section 8 for detailed specification. 1278 7.8.1.2.3. Example 1280 GET /info/capability HTTP/1.1 1281 Host: alto.example.com:6671 1282 HTTP/1.1 200 OK 1283 Content-Length: [TODO] 1284 Content-Type: application/alto 1286 { 1287 "meta" : { 1288 "version" : 1, 1289 "status" : { 1290 "code" : 1 1291 } 1292 }, 1293 "type" : "capability", 1294 "data" : { 1295 "services" : [ "map", "map-filtering" ], 1296 "cost-modes": [ 1297 "numerical", 1298 "ordinal" 1299 ], 1300 "cost-types": [ 1301 "routingcost", 1302 "hopcount" 1303 ], 1304 "cost-constraints": false 1305 } 1306 } 1308 7.8.2. Map Service 1310 The Map Service provides batch information to ALTO Clients in the 1311 form of two maps: a Network Map and Cost Map. 1313 An ALTO Server MUST support the Map Service and MUST implement all 1314 operations defined in this section. 1316 7.8.2.1. Network Map 1318 The full Network Map lists for each PID, the network locations 1319 (endpoints) within the PID. 1321 7.8.2.1.1. Request Syntax 1323 GET /map/core/pid/net HTTP/1.1 1324 Host: 1326 7.8.2.1.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 "network-map" and "data" member of type RspNetworkMap: 1337 object { 1338 CIDRString [pidname]<0..*>; 1339 ... 1340 } NetworkMapData; 1342 object { 1343 JSONString map-vtag; 1344 NetworkMapData map; 1345 } RspNetworkMap; 1347 RspNetworkMap has members: 1349 o map-vtag: The Version Tag of the Network Map (Section 5.3) 1351 o map: The network map data itself. 1353 NetworkMapData is a JSON object with each member representing a 1354 single PID and its associated set of IP Prefixes (encoded as a string 1355 in CIDR notation). A member's name is a PIDName string denoting the 1356 PID's name. 1358 7.8.2.1.3. Example 1360 GET /map/core/pid/net HTTP/1.1 1361 Host: alto.example.com:6671 1362 HTTP/1.1 200 OK 1363 Content-Length: [TODO] 1364 Content-Type: application/alto 1366 { 1367 "meta" : { 1368 "version" : 1, 1369 "status" : { 1370 "code" : 1 1371 } 1372 }, 1373 "type" : "network-map", 1374 "data" : { 1375 "map-vtag" : "1266506139", 1376 "map" : { 1377 "PID1" : [ 1378 "192.0.2.0/24", 1379 "198.51.100.0/25" 1380 ], 1381 "PID2" : [ 1382 "198.51.100.128/25" 1383 ], 1384 "PID3" : [ 1385 "0.0.0.0/0" 1386 ] 1387 } 1388 } 1389 } 1391 7.8.2.2. Cost Map 1393 The Map Service Cost Map query is a batch operation in which the ALTO 1394 Server returns the Path Cost for each pair of source/destination PID 1395 defined by the ALTO Server. 1397 The ALTO Server provides costs using the default Cost Type 1398 ('routingcost') and default Cost Mode ('numerical'). 1400 7.8.2.2.1. Request Syntax 1402 GET /map/core/pid/cost HTTP/1.1 1403 Host: 1405 7.8.2.2.2. Response Syntax 1407 HTTP/1.1 200 1408 Content-Length: 1409 Content-Type: application/alto 1411 1413 where the ALTOResponse object has "type" member equal to the string 1414 "cost-map" and "data" member of type RspCostMap: 1416 object DstCosts { 1417 JSONNumber [dstname]; 1418 ... 1419 }; 1421 object { 1422 DstCosts [srcname]<0..*>; 1423 ... 1424 } CostMapData; 1426 object { 1427 JSONString map-vtag; 1428 CostType cost-type; 1429 CostMode cost-mode; 1430 CostMapData map; 1431 } RspCostMap; 1433 RspCostMap has members: 1435 o map-vtag: The Version Tag of the Network Map used to generate the 1436 Cost Map (Section 5.3). 1438 o cost-type: Cost Type used in the map (Section 5.1.1) 1440 o cost-mode: Cost Mode used in the map (Section 5.1.2) 1442 o map: The cost map data itself. 1444 CostMapData is a JSON object with each member representing a single 1445 Source PID; the name for a member is the PIDName string identifying 1446 the corresponding Source PID. For each Source PID, a DstCosts object 1447 denotes the associated cost to a set of destination PIDs 1448 (Section 5.2); the name for each member in the object is the PIDName 1449 string identifying the corresponding Destination PID. DstCosts has a 1450 single member for each destination PID in the map. 1452 7.8.2.2.3. Example 1454 GET /map/core/pid/cost HTTP/1.1 1455 Host: alto.example.com:6671 1457 HTTP/1.1 200 OK 1458 Content-Length: [TODO] 1459 Content-Type: application/alto 1461 { 1462 "meta" : { 1463 "version" : 1, 1464 "status" : { 1465 "code" : 1 1466 } 1467 }, 1468 "type" : "cost-map", 1469 "data" : { 1470 "map-vtag" : "1266506139", 1471 "cost-type" : "routingcost", 1472 "cost-mode" : "numerical", 1473 "map" : { 1474 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 1475 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 1476 "PID3": { "PID1": 20, "PID2": 15, "PID3": 1 } 1477 } 1478 } 1479 } 1481 7.8.3. Map Filtering Service 1483 The Map Filtering Service allows ALTO Clients to specify filtering 1484 criteria to return a subset of the full maps available in the Map 1485 Service. 1487 An ALTO Server MAY support the Map Filtering Service. If an ALTO 1488 Server supports the Map Filtering Service, all operations defined in 1489 this section MUST be implemented. 1491 7.8.3.1. Network Map 1493 ALTO Clients can query for a subset of the full network map (see 1494 Section 7.8.2.1). 1496 7.8.3.1.1. Request Syntax 1498 POST /map/filter/pid/net HTTP/1.1 1499 Host: 1500 Content-Length: 1502 1504 where: 1506 object { 1507 PIDName pids<0..*>; 1508 } ReqNetworkMap; 1510 The Body of the request encodes an array of PIDs to be included in 1511 the resulting Network Map. If the list of PIDs is empty, the ALTO 1512 Server MUST interpret the list as if it contained a list of all 1513 currently-defined PIDs. 1515 7.8.3.1.2. Response Syntax 1517 The Response syntax is identical to that of the Map Service's Network 1518 Map Response (Section 7.8.2.1.2). 1520 The ALTO Server MUST only include PIDs in the Response that were 1521 specified (implicitly or explicitly) in the Request. If the Request 1522 contains a PID name that is not currently defined by the ALTO Server, 1523 the ALTO Server MUST behave as if the PID did not appear in the 1524 request. 1526 7.8.3.1.3. Example 1528 POST /map/filter/pid/net HTTP/1.1 1529 Host: alto.example.com:6671 1530 Content-Length: 1532 { 1533 pids: [ "PID1", "PID2" ] 1534 } 1536 HTTP/1.1 200 OK 1537 Content-Length: [TODO] 1538 Content-Type: application/alto 1540 { 1541 "meta" : { 1542 "version" : 1, 1543 "status" : { 1544 "code" : 1 1545 } 1546 }, 1547 "type" : "network-map", 1548 "data" : { 1549 "map-vtag" : "1266506139", 1550 "map" : { 1551 "PID1" : [ 1552 "192.0.2.0/24", 1553 "198.51.100.0/24", 1554 ], 1555 "PID2" : [ 1556 "198.51.100.128/24", 1557 ] 1558 } 1559 } 1560 } 1562 7.8.3.2. Cost Map 1564 ALTO Clients can query for the Cost Map (see Section 7.8.2.2) based 1565 on additional parameters. 1567 7.8.3.2.1. Request Syntax 1569 POST /map/filter/pid/cost? HTTP/1.1 1570 Host: 1572 1574 where: 1576 object { 1577 PIDName srcs<0..*>; 1578 PIDName dsts<0..*>; 1579 } ReqCostMap; 1581 The Query String may contain the following parameters: 1583 o type: The requested Cost Type (Section 5.1.1). If not specified, 1584 the default value is "routingcost". This parameter MUST NOT be 1585 specified multiple times. 1587 o mode: The requested Cost mode (Section 5.1.2). If not specified, 1588 the default value is "numerical". This parameter MUST NOT be 1589 specified multiple times. 1591 o constraint: Defines a constraint on which elements of the Cost Map 1592 are returned. This parameter MUST NOT be used if the Server 1593 Capability Response (Section 7.8.1.2) indicates that constraint 1594 support is not available. A constraint contains two entities 1595 separated by whitespace (before URL encoding): (1) an operator 1596 either 'gt' for greater than , 'lt' for less than or 'eq' for 1597 equal to with 10 percent on either side, (2) a target numerical 1598 cost. The numerical cost is a number that MUST be defined in the 1599 units specified in the Server Capability Response. If multiple 1600 'constraint' parameters are specified, the ALTO Server assumes 1601 they are related to each other with a logical AND. If no 1602 'constraint' parameters are specified, then the ALTO Server 1603 returns the full Cost Map. 1605 The Request body MAY specify a list of Source PIDs, and a list of 1606 Destination PIDs. If a list is empty, it is interpreted by the ALTO 1607 Server as the full set of currently-defined PIDs. The ALTO Server 1608 returns costs between each pair of source/destination PID. If the 1609 Request body is empty, both lists are interpreted to be empty. 1611 7.8.3.2.2. Response Syntax 1613 The Response syntax is identical to that of the Map Service's Cost 1614 Map Response (Section 7.8.2.2.2). 1616 The Response MUST NOT contain any source/destination pair that was 1617 not indicated (implicitly or explicitly) in the Request. If the 1618 Request contains a PID name that is not currently defined by the ALTO 1619 Server, the ALTO Server MUST behave as if the PID did not appear in 1620 the request. 1622 7.8.3.2.3. Example 1624 POST /map/filter/pid/cost?type=hopcount HTTP/1.1 1625 Host: alto.example.com:6671 1627 { 1628 "srcs" : [ "PID1" ], 1629 "dsts" : [ "PID1", "PID2", "PID3" ] 1630 } 1632 HTTP/1.1 200 OK 1633 Content-Length: [TODO] 1634 Content-Type: application/alto 1636 { 1637 "meta" : { 1638 "version" : 1, 1639 "status" : { 1640 "code" : 1 1641 } 1642 }, 1643 "type" : "cost-map", 1644 "data" : { 1645 "map-vtag" : "1266506139", 1646 "cost-type" : "hopcount", 1647 "cost-mode" : "numerical", 1648 "map" : { 1649 "PID1": { "PID1": 0, "PID2": 1, "PID3": 2 } 1650 } 1651 } 1652 } 1654 7.8.4. Endpoint Property Service 1656 The Endpoint Property Lookup query allows an ALTO Client to lookup 1657 properties of Endpoints known to the ALTO Server. If the ALTO Server 1658 provides the Endpoint Property Service, the ALTO Server MUST define 1659 at least the 'pid' property for Endpoints. 1661 An ALTO Server MAY support the Endpoint Property Service. If an ALTO 1662 Server supports the Endpoint Property Service, all operations defined 1663 in this section MUST be implemented. 1665 7.8.4.1. Endpoint Property Lookup 1666 7.8.4.1.1. Request Syntax 1668 POST /endpoint/prop/lookup? HTTP/1.1 1669 Host: 1670 Content-Length: 1672 1674 where: 1676 object { 1677 JSONString endpoints<0..*>; 1678 } ReqEndpointProp; 1680 The Query String may contain the following parameters: 1682 o prop: The requested property type. This parameter MUST be 1683 specified at least once, and MAY be specified multiple times 1684 (e.g., to query for multiple different properties at once). 1686 The body encodes a list of endpoints (IP addresses) as strings. 1688 An alternate syntax is supported for the case when properties are 1689 requested for a single endpoint: 1691 GET /endpoint/prop/? HTTP/1.1 1692 Host: 1694 where the Query String is the same as in the first form. 1696 7.8.4.1.2. Response Syntax 1698 HTTP/1.1 200 1699 Content-Length: 1700 Content-Type: application/alto 1702 1704 where the ALTOResponse object has "type" member equal to the string 1705 "endpoint-property" and "data" member of type RspEndpointProperty: 1707 object { 1708 JSONString [propertyname]; 1709 ... 1710 } EndpointProps; 1712 object { 1713 EndpointProps [endpointname]<0..*>; 1714 ... 1715 } RspEndpointProperty; 1717 RspEndpointProperty has one member for each endpoint indicated in the 1718 Request. The requested properties for each endpoint are encoded in a 1719 corresponding EndpointProps object, which encodes one name/value pair 1720 for each requested property. Note that property values are JSON 1721 Strings. If the ALTO Server does not define a requested property for 1722 a particular endpoint, then it MUST omit it from the Response for 1723 only that endpoint. 1725 7.8.4.1.3. Example 1727 POST /endpoint/prop/lookup?prop=pid HTTP/1.1 1728 Host: alto.example.com:6671 1729 Content-Length: [TODO] 1731 { 1732 "endpoints" : [ "192.0.2.34", "203.0.113.129" ] 1733 } 1735 HTTP/1.1 200 OK 1736 Content-Length: [TODO] 1737 Content-Type: application/alto 1739 { 1740 "meta" : { 1741 "version" : 1, 1742 "status" : { 1743 "code" : 1 1744 } 1745 }, 1746 "type" : "endpoint-property", 1747 "data": { 1748 "192.0.2.34" : { "pid": "PID1" }, 1749 "203.0.113.129" : { "pid": "PID3" } 1750 } 1751 } 1753 7.8.5. Endpoint Cost Service 1755 The Endpoint Cost Service allows ALTO Clients to directly supply 1756 endpoints to an ALTO Server. The ALTO Server replies with costs 1757 (numerical or ordinal) amongst the endpoints. 1759 In particular, this service allows lists of Endpoint addresses to be 1760 ranked (ordered) by an ALTO Server. 1762 An ALTO Server MAY support the Endpoint Cost Service. If an ALTO 1763 Server supports the Endpoint Cost Service, all operations defined in 1764 this section MUST be implemented. 1766 7.8.5.1. Endpoint Cost Lookup 1768 7.8.5.1.1. Request Syntax 1770 POST /endpoint/cost/lookup? HTTP/1.1 1771 Host: 1772 Content-Length: 1774 1776 The request body includes a list of source and destination endpoints 1777 that should be assigned a cost by the ALTO Server. The allowed Query 1778 String parameters are defined identically to Section 7.8.3.2. 1780 The request body MUST specify a list of source Endpoints, and a list 1781 of destination Endpoints, using an structure identical to 1782 Section 7.8.3.2 with the exception that identifiers are endpoints 1783 instead of PIDs. If the list of source Endpoints is empty (or it is 1784 not included), the ALTO Server MUST treat it as if it contained the 1785 Endpoint address of the requesting client. The list of destination 1786 Endpoints MUST NOT be empty. The ALTO Server returns costs between 1787 each pair of source/destination Endpoint. 1789 7.8.5.1.2. Response Syntax 1791 HTTP/1.1 200 1792 Content-Length: 1793 Content-Type: application/alto 1795 1797 where ALTOResponse is encoded identically to Section 7.8.2.2.2 with 1798 the following exceptions: 1800 o ALTO Response's "type" member must be equal to "endpoint-cost- 1801 map", 1803 o The "map-vtag" member of RspCostMap MUST be omitted, and 1805 o Identifiers refer to endpoints instead of PIDs. 1807 7.8.5.1.3. Example 1809 POST /endpoint/cost/lookup?mode=ordinal HTTP/1.1 1810 Host: alto.example.com:6671 1811 Content-Length: [TODO] 1813 { 1814 "src": [ "192.0.2.2" ], 1815 "dst": [ "192.0.2.89", "198.51.100.34", "203.0.113.45" ] 1816 } 1818 HTTP/1.1 200 OK 1819 Content-Length: [TODO] 1820 Content-Type: application/alto 1822 { 1823 "meta" : { 1824 "version" : 1, 1825 "status" : { 1826 "code" : 1 1827 } 1828 }, 1829 "type" : "endpoint-cost-map", 1830 "data" : { 1831 "cost-type" : "routingcost", 1832 "cost-mode" : "ordinal", 1833 "map" : { 1834 "192.0.2.2": { 1835 "192.0.2.89" : 1, 1836 "198.51.100.34" : 2, 1837 "203.0.113.45" : 3 1838 } 1839 } 1840 } 1841 } 1843 8. Redistributable Responses 1845 This section defines how an ALTO Server enables certain responses to 1846 be redistributed by ALTO Clients. Concepts are first introduced, 1847 followed by the protocol specification. 1849 8.1. Concepts 1851 8.1.1. Service ID 1853 The Service ID is a UUID that identifies a set of ALTO Servers that 1854 would provide identical ALTO Information for any ALTO Request for any 1855 ALTO Client. Each ALTO Server within such a set is configured with 1856 an identical Service ID. 1858 If a pair of ALTO Servers would provide different ALTO Information in 1859 response to a particular ALTO Client request, then the pair of ALTO 1860 Servers MUST have a different Service ID. 1862 8.1.1.1. Rationale 1864 For scalability and fault tolerance, multiple ALTO Servers may be 1865 deployed to serve equivalent ALTO Information. In such a scenario, 1866 ALTO Responses from any such redundant server should be seen as 1867 equivalent for the purposes of redistribution. For example, if two 1868 ALTO Servers A and B are deployed by the service provider to 1869 distribute equivalent ALTO Information, then clients contacting 1870 Server A should be able to redistribute ALTO Responses to clients 1871 contacting Server B. 1873 To accomplish this behavior, ALTO Clients must be able to determine 1874 that Server A and Server B serve identical ALTO Information. One 1875 technique would be to rely on the ALTO Server's DNS name. However, 1876 such an approach would mandate that all ALTO Servers resolved by a 1877 particular DNS name would need to provide equivalent ALTO 1878 information, which may be unneccessarily restrictive. Another 1879 technique would be to rely on the server's IP adddress. However, 1880 this suffers similar problems as the DNS name in deployment scenarios 1881 using IP Anycast. 1883 To avoid such restrictions, the ALTO Protocol allows an ALTO Service 1884 Provider to explicitly denote ALTO Servers that provide equivalent 1885 ALTO Information by giving them identical Service IDs. Service IDs 1886 decouple the identification of equivalent ALTO Servers from the 1887 discovery process. 1889 8.1.1.2. Server Capability Response 1891 If an ALTO Server generates redistributable responses, the Server 1892 Capability response's 'service-id' field MUST be set to the ALTO 1893 Server's Service ID. 1895 8.1.1.3. Configuration 1897 To help prevent ALTO Servers from mistakenly claiming to distribute 1898 equivalent ALTO Information, ALTO Server implementations SHOULD by 1899 default generate a new UUID at installation time or startup if one 1900 has not explicitly been configured. 1902 8.1.2. Expiration Time 1904 ALTO Responses marked as redistributable should indicate a time after 1905 which the information is considered stale and should be refreshed 1906 from the ALTO Server (or possibly another ALTO Client). 1908 If an expiration time is present, the ALTO Server SHOULD ensure that 1909 it is reasonably consistent with the expiration time that would be 1910 computed by HTTP header fields. This specification makes no 1911 recommendation on which expiration time takes precedence, but 1912 implementers should be cognizant that HTTP intermediaries will obey 1913 only the HTTP header fields. 1915 8.1.3. Signature 1917 ALTO Responses marked as redistributable include a signature used to 1918 assert that the ALTO Server Provider generated the ALTO Information. 1920 8.1.3.1. Rationale 1922 Verification of the signature requires the ALTO Client to retrieve 1923 the ALTO Server's public key. There are multiple possibilities 1924 through which the ALTO Protocol could be designed to retrieve it: 1926 o SSL/TLS connection with the ALTO Server: The public key algorithm 1927 and public key may be retrieved from the ALTO Server's X.509 1928 Certificate used on an HTTPS connection between the ALTO Server 1929 and ALTO Client. 1931 o Included in ALTO Server's Server Capability Response: An X.509 1932 certificate (including the public key and public key algorithm) 1933 can be included in the Server Capability Response. This could be 1934 achieved even if the ALTO Server and ALTO Client do not have a 1935 SSL/TLS channel. 1937 To reduce requirements on the underlying transport (i.e., requiring 1938 SSL/TLS), the ALTO Protocol uses the latter option. 1940 8.1.3.2. Certificates 1942 8.1.3.2.1. Local Certificate 1944 The ALTO Server's public key is encoded within an X.509 certificate. 1945 The corresponding private key MUST be used to sign redistributable 1946 responses. This certificate is termed the Local Certificate for an 1947 ALTO Server. 1949 8.1.3.2.2. Certificate Chain 1951 To ease key provisioning, the ALTO Protocol is designed such that 1952 each ALTO Server with an identical Service ID may have a unique 1953 private key (and hence certificate). 1955 The ALTO Service Provider may configure a certificate chain at each 1956 such ALTO Server. The Local Certificate for a single ALTO Server is 1957 the bottom-most certificate in the chain. The Certificate Chains of 1958 each ALTO Server with an identical Service ID MUST share a common 1959 Root Certificate. 1961 Note that there are two simple deployment scenarios: 1963 o One-Level Certificate Chain (Local Certificate Only): In this 1964 deployment scenario, each ALTO Server with an identical Service ID 1965 may provisioned with an identical Local Certificate. 1967 o Two-Level Certificate Chain: In this deployment scenario, a Root 1968 Certificate is maintained for a set of ALTO Servers with the same 1969 Service ID. A unique Local Certificate signed by this CA is 1970 provisioned to each ALTO Server. 1972 There are advantages to using a Certificate Chain instead of 1973 deploying the same Local Certificate to each ALTO Server. 1974 Specifically, it avoids storage of the CA's private key at ALTO 1975 Servers. It is possible to revoke and re-issue a key to a single 1976 ALTO Server. 1978 8.1.3.2.3. Server Capability Response 1980 If an ALTO Server generates redistributable responses, the Server 1981 Capability response's 'certificates' field MUST be populated with the 1982 ALTO Server's full certificate chain. The first element MUST be the 1983 ALTO Server's Local Certificate, followed by the remaining 1984 Certificate Chain in ascending order to the Root Certificate. 1986 8.1.3.3. Signature Verification 1988 ALTO Clients SHOULD verify the signature on any ALTO information 1989 received via redistribution before adjusting application behavior 1990 based on it. 1992 An ALTO Client SHOULD cache its ALTO Server's Service ID and 1993 corresponding Certificate Chain included in the Server Capability 1994 response. Recall that the last certificate in this chain is the Root 1995 Certificate. The retrieval of the Service ID and certificates SHOULD 1996 be secured using HTTPS with proper validation of the server endpoint 1997 of the SSL/TLS connection [6]. 1999 An ALTO Response received via redistribution from Service ID S is 2000 declared valid if an ALTO Client can construct a transitive 2001 certificate chain from the certificate (public key) used to sign the 2002 ALTO Response to the Root Certificate corresponding to Service ID S 2003 obtained by the ALTO Client in a Server Capability response. 2005 To properly construct the chain and complete this validation, an ALTO 2006 Client may need to request additional certificates from other ALTO 2007 Clients. A simple mechanism is to request the certificate chain from 2008 the ALTO Client that received the ALTO Response. Note that these 2009 additional received certificates may be cached locally by an ALTO 2010 CLient. 2012 ALTO Clients SHOULD verify ALTO Responses received via 2013 redistribution. 2015 8.1.3.4. Redistribution by ALTO Clients 2017 ALTO Clients SHOULD pass the ALTO Server Certificate, Signature, and 2018 Signature Algorithm along with the body of the ALTO Response. The 2019 mechanism for redistributing such information is not specified by the 2020 ALTO Protocol, but one possibility is to add additional messages or 2021 fields to the application's native protocol. 2023 8.2. Protocol 2025 An ALTO Server MAY indicate that a response is suitable for 2026 redistribution by including the "redistribution" member in the 2027 RspMetaData JSON object of an ALTO Response message. This additional 2028 member, called the Response Redistribution Descriptor, has type 2029 RspRedistDesc: 2031 object { 2032 JSONString service-id; 2033 JSONString request-uri; 2034 JSONValue request-body; 2035 JSONString expires; 2036 } RspRedistDesc; 2038 The fields encoded in the Response Redistribution Descriptor allows 2039 an ALTO Client receiving redistributed ALTO Information to understand 2040 the context of the query (the ALTO Service generating the response 2041 and any input parameters) and to interpret the results. 2043 Information about ALTO Client performing the Request and any HTTP 2044 Headers passed in the request are not included in the Response 2045 Redistribution Descriptor. If any such information or headers 2046 influence the response generated by the ALTO Server, the response 2047 SHOULD NOT be indicated as redistributable. 2049 8.2.1. Response Redistribution Descriptor Fields 2051 This section defines the fields of the Response Redistribution 2052 Descriptor. 2054 8.2.1.1. Service ID 2056 The 'service-id' member is REQUIRED and MUST have a value equal to 2057 the ALTO Server's Service ID. 2059 8.2.1.2. Request URI 2061 The 'request-uri' member is REQUIRED and MUST specify the HTTP 2062 Request-URI that was passed in the HTTP Request. 2064 8.2.1.3. Request Body 2066 If the HTTP Request body was non-empty, the 'request-body' member 2067 MUST specify full JSON value passed in the HTTP Request (note that 2068 whitespace may differ, as long as the JSON Value is identical). If 2069 the HTTP Request was empty, then the 'request-body' MUST NOT be 2070 included. 2072 8.2.1.4. Expiration Time 2074 The 'expires' element is RECOMMENDED and, if present, MUST specify a 2075 time in UTC formatted according to [9]. 2077 8.2.2. Signature 2079 The Hash Algorithm, Signature Algorithm, and Signature are included 2080 as either HTTP Headers or Trailers. Headers may be useful if 2081 Responses are pre-generated, while Trailers may be useful if 2082 Responses are dynamically generated (e.g., to avoid buffering large 2083 responses in memory while the hash value is computed). 2085 The following HTTP Headers (the ALTO Server MAY specify them as HTTP 2086 Trailers instead) MUST be used to encode the Signature parameters for 2087 redistributable ALTO Responses: 2089 ALTO-HashAlgorithm: 2090 ALTO-SignatureAlgorithm: 2091 ALTO-SignatureDigest: 2093 where and are an integer values 2094 from the IANA TLS HashAlgorithm and SignatureAlgorithm registries, 2095 and is the corresponding PEM-encoded signature. 2097 9. Use Cases 2099 The sections below depict typical use cases. 2101 9.1. ALTO Client Embedded in P2P Tracker 2103 Many P2P currently-deployed P2P systems use a Tracker to manage 2104 swarms and perform peer selection. P2P trackers may currently use a 2105 variety of information to perform peer selection to meet application- 2106 specific goals. By acting as an ALTO Client, an P2P tracker can use 2107 ALTO information as an additional information source to enable more 2108 network-efficient traffic patterns and improve application 2109 performance. 2111 A particular requirement of many P2P trackers is that they must 2112 handle a large number of P2P clients. A P2P tracker can obtain and 2113 locally store ALTO information (the Network Map and Cost Map) from 2114 the ISPs containing the P2P clients, and benefit from the same 2115 aggregation of network locations done by ALTO Servers. 2117 .---------. (1) Get Network Map .---------------. 2118 | | <----------------------> | | 2119 | ALTO | | P2P Tracker | 2120 | Server | (2) Get Cost Map | (ALTO Client) | 2121 | | <----------------------> | | 2122 `---------' `---------------' 2123 ^ | 2124 (3) Get Peers | | (4) Selected Peer 2125 | v List 2126 .---------. .-----------. 2127 | Peer 1 | <-------------- | P2P | 2128 `---------' | Client | 2129 . (5) Connect to `-----------' 2130 . Selected Peers / 2131 .---------. / 2132 | Peer 50 | <------------------ 2133 `---------' 2135 Figure 4: ALTO Client Embedded in P2P Tracker 2137 Figure 4 shows an example use case where a P2P tracker is an ALTO 2138 Client and applies ALTO information when selecting peers for its P2P 2139 clients. The example proceeds as follows: 2141 1. The P2P Tracker requests the Network Map covering all PIDs from 2142 the ALTO Server using the Network Map query. The Network Map 2143 includes the IP prefixes contained in each PID, allowing the P2P 2144 tracker to locally map P2P clients into a PIDs. 2146 2. The P2P Tracker requests the Cost Map amongst all PIDs from the 2147 ALTO Server. 2149 3. A P2P Client joins the swarm, and requests a peer list from the 2150 P2P Tracker. 2152 4. The P2P Tracker returns a peer list to the P2P client. The 2153 returned peer list is computed based on the Network Map and Cost 2154 Map returned by the ALTO Server, and possibly other information 2155 sources. Note that it is possible that a tracker may use only 2156 the Network Map to implement hierarchical peer selection by 2157 preferring peers within the same PID and ISP. 2159 5. The P2P Client connects to the selected peers. 2161 Note that the P2P tracker may provide peer lists to P2P clients 2162 distributed across multiple ISPs. In such a case, the P2P tracker 2163 may communicate with multiple ALTO Servers. 2165 9.2. ALTO Client Embedded in P2P Client: Numerical Costs 2167 P2P clients may also utilize ALTO information themselves when 2168 selecting from available peers. It is important to note that not all 2169 P2P systems use a P2P tracker for peer discovery and selection. 2170 Furthermore, even when a P2P tracker is used, the P2P clients may 2171 rely on other sources, such as peer exchange and DHTs, to discover 2172 peers. 2174 When an P2P Client uses ALTO information, it typically queries only 2175 the ALTO Server servicing its own ISP. The my-Internet view provided 2176 by its ISP's ALTO Server can include preferences to all potential 2177 peers. 2179 .---------. (1) Get Network Map .---------------. 2180 | | <----------------------> | | 2181 | ALTO | | P2P Client | 2182 | Server | (2) Get Cost Map | (ALTO Client) | 2183 | | <----------------------> | | .---------. 2184 `---------' `---------------' <- | P2P | 2185 .---------. / | ^ ^ | Tracker | 2186 | Peer 1 | <-------------- | | \ `---------' 2187 `---------' | (3) Gather Peers 2188 . (4) Select Peers | | \ 2189 . and Connect / .--------. .--------. 2190 .---------. / | P2P | | DHT | 2191 | Peer 50 | <---------------- | Client | `--------' 2192 `---------' | (PEX) | 2193 `--------' 2195 Figure 5: ALTO Client Embedded in P2P Client 2197 Figure 5 shows an example use case where a P2P Client locally applies 2198 ALTO information to select peers. The use case proceeds as follows: 2200 1. The P2P Client requests the Network Map covering all PIDs from 2201 the ALTO Server servicing its own ISP. 2203 2. The P2P Client requests the Cost Map amongst all PIDs from the 2204 ALTO Server. The Cost Map by default specifies numerical costs. 2206 3. The P2P Client discovers peers from sources such as Peer Exchange 2207 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2208 P2P Trackers. 2210 4. The P2P Client uses ALTO information as part of the algorithm for 2211 selecting new peers, and connects to the selected peers. 2213 9.3. ALTO Client Embedded in P2P Client: Ranking 2215 It is also possible for a P2P Client to offload the selection and 2216 ranking process to an ALTO Server. In this use case, the ALTO Client 2217 gathers a list of known peers in the swarm, and asks the ALTO Server 2218 to rank them. 2220 As in the use case using numerical costs, the P2P Client typically 2221 only queries the ALTO Server servicing its own ISP. 2223 .---------. .---------------. 2224 | | | | 2225 | ALTO | (2) Get Endpoint Ranking | P2P Client | 2226 | Server | <----------------------> | (ALTO Client) | 2227 | | | | .---------. 2228 `---------' `---------------' <- | P2P | 2229 .---------. / | ^ ^ | Tracker | 2230 | Peer 1 | <-------------- | | \ `---------' 2231 `---------' | (1) Gather Peers 2232 . (3) Connect to | | \ 2233 . Selected Peers / .--------. .--------. 2234 .---------. / | P2P | | DHT | 2235 | Peer 50 | <---------------- | Client | `--------' 2236 `---------' | (PEX) | 2237 `--------' 2239 Figure 6: ALTO Client Embedded in P2P Client: Ranking 2241 Figure 6 shows an example of this scenario. The use case proceeds as 2242 follows: 2244 1. The P2P Client discovers peers from sources such as Peer Exchange 2245 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2246 P2P Trackers. 2248 2. The P2P Client queries the ALTO Server's Ranking Service, 2249 including discovered peers as the set of Destination Endpoints, 2250 and indicates the 'ordinal' Cost Mode. The response indicates 2251 the ranking of the candidate peers. 2253 3. The P2P Client connects to the peers in the order specified in 2254 the ranking. 2256 10. Discussions 2257 10.1. Discovery 2259 The discovery mechanism by which an ALTO Client locates an 2260 appropriate ALTO Server is out of scope for this document. This 2261 document assumes that an ALTO Client can discover an appropriate ALTO 2262 Server. Once it has done so, the ALTO Client may use the Server List 2263 query Section 7.8.1.1 to locate an ALTO Server with capabilities 2264 necessary for its application. 2266 10.2. Hosts with Multiple Endpoint Addresses 2268 In practical deployments, especially during the transition from IPv4 2269 to IPv6, a particular host may be reachable using multiple addresses. 2270 Furthermore, the particular network path followed when sending 2271 packets to the host may differ based on the address that is used. 2272 Network providers may perfer one path over another (e.g., one path my 2273 have a NAT64 middlebox). An additional consideration may be how to 2274 handle private address spaces (e.g., behind carrier-grade NATs). 2276 Note that to support such behavior, Endpoints must be associated with 2277 a particular address type (e.g., IPv4 or IPv6). One simple 2278 possibility may be to prefix each endpoint address with its type 2279 (e.g., "ipv4:198.51.100.128/25"). However, we may want to discuss if 2280 a more efficient/compact encoding is possible in some cases (e.g., 2281 all addresses in the same PID are IPv6). 2283 There are limitations as to what information ALTO can provide in this 2284 regard. In particular, a particular ALTO Service provider may not be 2285 able to determine if connectivity with a particular endhost will 2286 succeed over IPv4 or IPv6, as this may depend upon information 2287 unknown to the ISP such as particular application implementations. 2289 Exploration of these issues is being considered in a separate 2290 Internet Draft [23]. Once a suitable solution emerges, it will be 2291 included in this document. 2293 10.3. Network Address Translation Considerations 2295 At this day and age of NAT v4<->v4, v4<->v6 [24], and possibly 2296 v6<->v6[25], a protocol should strive to be NAT friendly and minimize 2297 carrying IP addresses in the payload, or provide a mode of operation 2298 where the source IP address provide the information necessary to the 2299 server. 2301 The protocol specified in this document provides a mode of operation 2302 where the source network location is computed by the ALTO Server (via 2303 the Endpoint Property Lookup interface) from the source IP address 2304 found in the ALTO Client query packets. This is similar to how some 2305 P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS 2306 Protocol" in [26]) operate. 2308 The ALTO client SHOULD use the Session Traversal Utilities for NAT 2309 (STUN) [10] to determine a public IP address to use as a source 2310 Endpoint address. If using this method, the host MUST use the 2311 "Binding Request" message and the resulting "XOR-MAPPED-ADDRESS" 2312 parameter that is returned in the response. Using STUN requires 2313 cooperation from a publicly accessible STUN server. Thus, the ALTO 2314 client also requires configuration information that identifies the 2315 STUN server, or a domain name that can be used for STUN server 2316 discovery. To be selected for this purpose, the STUN server needs to 2317 provide the public reflexive transport address of the host. 2319 10.4. Mapping IPs to ASNs 2321 It may be desired for the ALTO Protocol to provide ALTO information 2322 including ASNs. Thus, ALTO Clients may need to identify the ASN for 2323 a Resource Provider to determine the cost to that Resource Provider. 2325 Applications can already map IPs to ASNs using information from a BGP 2326 Looking Glass. To do so, they must download a file of about 1.5MB 2327 when compressed (as of October 2008, with all information not needed 2328 for IP to ASN mapping removed) and periodically (perhaps monthly) 2329 refresh it. 2331 Alternatively, the Network Map query in the Map Filtering Service 2332 defined in this document could be extended to map ASNs into a set of 2333 IP prefixes. The mappings provided by the ISP would be both smaller 2334 and more authoritative. 2336 For simplicity of implementation, it's highly desirable that clients 2337 only have to implement exactly one mechanism of mapping IPs to ASNs. 2339 10.5. Endpoint and Path Properties 2341 An ALTO Server could make available many properties about Endpoints 2342 beyond their network location or grouping. For example, connection 2343 type, geographical location, and others may be useful to 2344 applications. The current draft focuses on network location and 2345 grouping, but the protocol may be extended to handle other Endpoint 2346 properties. 2348 11. IANA Considerations 2349 11.1. application/alto Media Type 2351 This document requests the registration of a new media type: 2352 "application/alto": 2354 Type name: application 2356 Subtype name: alto 2358 Required parameters: n/a 2360 Optional parameters: n/a 2362 Encoding considerations: Encoding considerations are identical to 2363 those specified for the 'application/json' media type. See [4]. 2365 Security considerations: Security considerations relating to the 2366 generation and consumption of ALTO protocol messages are discussed 2367 in Section 12. 2369 Interoperability considerations: This document specifies format of 2370 conforming messages and the interpretation thereof. 2372 Published specification: This document. 2374 Applications that use this media type: ALTO Servers and ALTO Clients 2375 either standalone or embedded within other applications. 2377 Additional information: 2379 Magic number(s): n/a 2381 File extension(s): This document uses the mime type to refer to 2382 protocol messages and thus does not require a file extension. 2384 Macintosh file type code(s): n/a 2386 Person & email address to contact for further information: See 2387 "Authors' Addresses" section. 2389 Intended usage: COMMON 2391 Restrictions on usage: n/a 2393 Author: See "Authors' Addresses" section. 2395 Change controller: See "Authors' Addresses" section. 2397 11.2. ALTO Cost Type Registry 2399 This document requests the creation of an ALTO Cost Type registry to 2400 be maintained by IANA. 2402 This registry serves two purposes. First, it ensures uniqueness of 2403 identifiers referring to ALTO Cost Types. Second, it provides 2404 references to particular semantics of allocated Cost Types to be 2405 applied by both ALTO Servers and applications utilizing ALTO Clients. 2407 New ALTO Cost Types are assigned after Expert Review [7]. The Expert 2408 Reviewer will generally consult the ALTO Working Group or its 2409 successor. Expert Review is used to ensure that proper documentation 2410 regarding ALTO Cost Type semantics and security considerations has 2411 been provided. The provided documentation should be detailed enough 2412 to provide guidance to both ALTO Service Providers and applications 2413 utilizing ALTO Clients as to how values of the registered ALTO Cost 2414 Type should be interpreted. Updates and deletions of ALTO Cost Types 2415 follow the same procedure. 2417 Registered ALTO Cost Type identifiers MUST conform to the syntatical 2418 requirements specified in Section 7.7.3. Identifiers are to be 2419 recorded and displayed as ASCII strings. 2421 Identifiers prefixed with 'priv:' are reserved for Private Use. 2422 Identifiers prefixed with 'exp:' are reserved for Experimental use. 2424 Requests to add a new value to the registry MUST include the 2425 following information: 2427 o Identifier: The name of the desired ALTO Cost Type. 2429 o Intended Semantics: ALTO Costs carry with them semantics to guide 2430 their usage by ALTO Clients. For example, if a value refers to a 2431 measurement, the measurement units must be documented. For proper 2432 implementation of the ordinal Cost Mode (e.g., by a third-party 2433 service), it should be documented whether higher or lower values 2434 of the cost are more preferred. 2436 o Security Considerations: ALTO Costs expose information to ALTO 2437 Clients. As such, proper usage of a particular Cost Type may 2438 require certain information to be exposed by an ALTO Service 2439 Provider. Since network information is frequently regarded as 2440 proprietary or confidential, ALTO Service Providers should be made 2441 aware of the security ramifications related to usage of a Cost 2442 Type. 2444 This specification requests registration of the identifier 2445 'routingcost'. Semantics for the this Cost Type are documented in 2446 Section 5.1.1.1, and security considerations are documented in 2447 Section 12.1. 2449 12. Security Considerations 2451 12.1. Privacy Considerations for ISPs 2453 ISPs must be cognizant of the network topology and provisioning 2454 information provided through ALTO Interfaces. ISPs should evaluate 2455 how much information is revealed and the associated risks. On the 2456 one hand, providing overly fine-grained information may make it 2457 easier for attackers to infer network topology. In particular, 2458 attackers may try to infer details regarding ISPs' operational 2459 policies or inter-ISP business relationships by intentionally posting 2460 a multitude of selective queries to an ALTO server and analyzing the 2461 responses. Such sophisticated attacks may reveal more information 2462 than an ISP hosting an ALTO server intends to disclose. On the other 2463 hand, revealing overly coarse-grained information may not provide 2464 benefits to network efficiency or performance improvements to ALTO 2465 Clients. 2467 12.2. ALTO Clients 2469 Applications using the information must be cognizant of the 2470 possibility that the information is malformed or incorrect. Even if 2471 an ALTO Server has been properly authenticated by the ALTO Client, 2472 the information provided may be malicious because the ALTO Server and 2473 its credentials have been compromised (e.g., through malware). Other 2474 considerations (e.g., relating to application performance) can be 2475 found in Section 6 of [18]. 2477 ALTO Clients should also be cognizant of revealing Network Location 2478 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, 2479 as doing so may allow the ALTO Server to infer communication 2480 patterns. One possibility is for the ALTO Client to only rely on 2481 Network Map for PIDs and Cost Map amongst PIDs to avoid passing IP 2482 addresses of their peers to the ALTO Server. 2484 In addition, ALTO clients should be cautious not to unintentionally 2485 or indirectly disclose the resource identifier (of which they try to 2486 improve the retrieval through ALTO-guidance), e.g., the name/ 2487 identifier of a certain video stream in P2P live streaming, to the 2488 ALTO server. Note that the ALTO Protocol specified in this document 2489 does not explicitly reveal any resource identifier to the ALTO 2490 Server. However, for instance, depending on the popularity or other 2491 specifics (such as language) of the resource, an ALTO server could 2492 potentially deduce information about the desired resource from 2493 information such as the Network Locations the client sends as part of 2494 its request to the server. 2496 12.3. Authentication, Integrity Protection, and Encryption 2498 SSL/TLS can provide encryption of transmitted messages as well as 2499 authentication of the ALTO Client and Server. HTTP Basic or Digest 2500 authentication can provide authentication of the client (combined 2501 with SSL/TLS, it can additionally provide encryption and 2502 authentication of the server). 2504 An ALTO Server may optionally use authentication (and potentially 2505 encryption) to protect ALTO information it provides. This can be 2506 achieved by digitally signing a hash of the ALTO information itself 2507 and attaching the signature to the ALTO information. There may be 2508 special use cases where encryption of ALTO information is desirable. 2509 In many cases, however, information sent out by an ALTO Server may be 2510 regarded as non-confidential information. 2512 ISPs should be cognizant that encryption only protects ALTO 2513 information until it is decrypted by the intended ALTO Client. 2514 Digital Rights Management (DRM) techniques and legal agreements 2515 protecting ALTO information are outside of the scope of this 2516 document. 2518 12.4. ALTO Information Redistribution 2520 It is possible for applications to redistribute ALTO information to 2521 improve scalability. Even with such a distribution scheme, ALTO 2522 Clients obtaining ALTO information must be able to validate the 2523 received ALTO information to ensure that it was generated by an 2524 appropriate ALTO Server. Further, to prevent the ALTO Server from 2525 being a target of attack, the verification scheme must not require 2526 ALTO Clients to contact the ALTO Server to validate every set of 2527 information. Contacting an ALTO server for information validation 2528 would also undermine the intended effect of redistribution and is 2529 therefore not desirable. 2531 Note that the redistribution scheme must additionally handle details 2532 such as ensuring ALTO Clients retrieve ALTO information from the 2533 correct ALTO Server. See [21] for further discussion. Details of a 2534 particular redistribution scheme are outside the scope of this 2535 document. 2537 To fulfill these requirements, ALTO Information meant to be 2538 redistributable contains a digital signature which includes a hash of 2539 the ALTO information signed by the ALTO Server with its private key. 2540 The corresponding public key is included in the Server Capability 2541 response Section 7.8.1.2, along with the certificate chain to a Root 2542 Certificate generated by the ALTO Service Provider. To prevent man- 2543 in-the-middle attacks, an ALTO Client SHOULD perform the Server 2544 Capability Query over SSL/TLS and verify the server identity 2545 according to [6]. 2547 The signature verification algorithm is detailed in Section 8.1.3.3. 2549 12.5. Denial of Service 2551 ISPs should be cognizant of the workload at the ALTO Server generated 2552 by certain ALTO Queries, such as certain queries to the Map Filtering 2553 Service and Ranking Service. In particular, queries which can be 2554 generated with low effort but result in expensive workloads at the 2555 ALTO Server could be exploited for Denial-of-Service attacks. For 2556 instance, a simple ALTO query with n Source Network Locations and m 2557 Destination Network Locations can be generated fairly easily but 2558 results in the computation of n*m Path Costs between pairs by the 2559 ALTO Server (see Section 5.2). One way to limit Denial-of-Service 2560 attacks is to employ access control to the ALTO server. Another 2561 possible mechanism for an ALTO Server to protect itself against a 2562 multitude of computationally expensive bogus requests is to demand 2563 that each ALTO Client to solve a computational puzzle first before 2564 allocating resources for answering a request (see, e.g., [27]). The 2565 current specification does not use such computational puzzles, and 2566 discussion regarding tradeoffs of such an approach would be needed 2567 before including such a technique in the ALTO Protocol. 2569 ISPs should also leverage the fact that the the Map Service allows 2570 ALTO Servers to pre-generate maps that can be useful to many ALTO 2571 Clients. 2573 12.6. ALTO Server Access Control 2575 In order to limit access to an ALTO server (e.g., for an ISP to only 2576 allow its users to access its ALTO server, or to prevent Denial-of- 2577 Service attacks by arbitrary hosts from the Internet), an ALTO server 2578 may employ access control policies. Depending on the use-case and 2579 scenario, an ALTO server may restrict access to its services more 2580 strictly or rather openly (see [28] for a more detailed discussion on 2581 this issue). 2583 13. References 2584 13.1. Normative References 2586 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2587 Levels", BCP 14, RFC 2119, March 1997. 2589 [2] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 2590 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 2592 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 2593 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 2594 HTTP/1.1", RFC 2616, June 1999. 2596 [4] Crockford, D., "The application/json Media Type for JavaScript 2597 Object Notation (JSON)", RFC 4627, July 2006. 2599 [5] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 2600 T. Wright, "Transport Layer Security (TLS) Extensions", 2601 RFC 4366, April 2006. 2603 [6] Saint-Andre, P. and J. Hodges, "Representation and Verification 2604 of Domain-Based Application Service Identity within Internet 2605 Public Key Infrastructure Using X.509 (PKIX) Certificates in 2606 the Context of Transport Layer Security (TLS)", 2607 draft-saintandre-tls-server-id-check-10 (work in progress), 2608 October 2010. 2610 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2611 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 2613 [8] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 2614 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 2616 [9] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: 2617 Timestamps", RFC 3339, July 2002. 2619 [10] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 2620 Traversal Utilities for (NAT) (STUN)", 2621 draft-ietf-behave-rfc3489bis-18 (work in progress), July 2008. 2623 13.2. Informative References 2625 [11] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, 2626 "Application-Layer Traffic Optimization (ALTO) Requirements", 2627 draft-kiesel-alto-reqs-01 (work in progress), November 2008. 2629 [12] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, "P4P: 2630 Provider Portal for P2P Applications", draft-p4p-framework-00 2631 (work in progress), November 2008. 2633 [13] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, "P4P 2634 Protocol Specification", draft-wang-alto-p4p-specification-00 2635 (work in progress), March 2009. 2637 [14] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 2638 Export Service", draft-shalunov-alto-infoexport-00 (work in 2639 progress), October 2008. 2641 [15] Das, S. and V. Narayanan, "A Client to Service Query Response 2642 Protocol for ALTO", draft-saumitra-alto-queryresponse-00 (work 2643 in progress), March 2009. 2645 [16] Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 2646 Dimensional Peer Selection Problem", 2647 draft-saumitra-alto-multi-ps-00 (work in progress), 2648 October 2008. 2650 [17] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 2651 Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00 2652 (work in progress), March 2009. 2654 [18] Seedorf, J. and E. Burger, "Application-Layer Traffic 2655 Optimization (ALTO) Problem Statement", RFC 5693, October 2009. 2657 [19] Yang, Y., Popkin, L., Penno, R., and S. Shalunov, "An 2658 Architecture of ALTO for P2P Applications", 2659 draft-yang-alto-architecture-00 (work in progress), March 2009. 2661 [20] Zyp, K., "A JSON Media Type for Describing the Structure and 2662 Meaning of JSON Documents", draft-zyp-json-schema-02 (work in 2663 progress), March 2010. 2665 [21] Yingjie, G., Alimi, R., and R. Even, "ALTO Information 2666 Redistribution", draft-gu-alto-redistribution-03 (work in 2667 progress), July 2010. 2669 [22] 3rd, D., "Transport Layer Security (TLS) Extensions: Extension 2670 Definitions", draft-ietf-tls-rfc4366-bis-12 (work in progress), 2671 September 2010. 2673 [23] Penno, R. and J. Medved, "ALTO and IPv4/IPv6 Co-existence and 2674 Transition", draft-penno-alto-ipv4v6-00 (work in progress), 2675 June 2010. 2677 [24] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 2678 Translation", draft-baker-behave-v4v6-framework-02 (work in 2679 progress), February 2009. 2681 [25] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address 2682 Translation (NAT66)", draft-mrw-behave-nat66-02 (work in 2683 progress), March 2009. 2685 [26] "Bittorrent Protocol Specification v1.0", 2686 http://wiki.theory.org/BitTorrentSpecification, 2009. 2688 [27] Jennings, C., "Computational Puzzles for SPAM Reduction in 2689 SIP", draft-jennings-sip-hashcash-06 (work in progress), 2690 July 2007. 2692 [28] Stiemerling, M. and S. Kiesel, "ALTO Deployment 2693 Considerations", draft-stiemerling-alto-deployments-05 (work in 2694 progress), October 2010. 2696 [29] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A. 2697 Silberschatz., "P4P: Provider Portal for (P2P) Applications", 2698 In SIGCOMM 2008. 2700 Appendix A. TO BE MOVED 2702 The text in this section is intended to be moved to a more 2703 appropriate document. 2705 A.1. Discovery 2707 Some ISPs have proposed the possibility of delegation, in which an 2708 ISP provides information for customer networks which do not wish to 2709 run ALTO Servers themselves. A consideration for delegation is that 2710 customer networks may wish to explicitly configure such delegation. 2712 A.2. P2P Peer Selection 2714 This section discusses possible approaches to peer selection using 2715 ALTO information (Network Location Identifiers and associated Costs) 2716 from an ALTO Server. Specifically, the application must select which 2717 peers to use based on this and other sources of information. With 2718 this in mind, the usage of ALTO Costs is intentionally flexible, 2719 because: 2721 Different applications may use the information differently. For 2722 example, an application that connects to just one address may have 2723 a different algorithm for selecting it than an application that 2724 connects to many. 2726 Though initial experiments have been conducted [29], more 2727 investigation is needed to identify other methods. 2729 In addition, the application might account for robustness, perhaps 2730 using randomized exploration to determine if it performs better 2731 without ALTO information. 2733 A.2.1. Client-based Peer Selection 2735 One possibility is for peer selection using ALTO costs to be done 2736 entirely by a P2P client. The following are some techniques have 2737 been proposed and/or used: 2739 o Prefer network locations with lower ordinal rankings (i.e., higher 2740 priority) [17] [14]. 2742 o Optimistically unchoking low-cost peers with higher probability 2743 [14]. 2745 A.2.2. Server-based Peer Selection 2747 Another possibility is for ALTO costs to be used by an Application 2748 Tracker (e.g., BitTorrent Tracker) when returning peer lists. The 2749 following are techniques that have been proposed and/or used: 2751 o Using bandwidth matching (e.g., at an Application Tracker) and 2752 choosing solution (within bound of optimal) with minimal network 2753 cost [29]. 2755 A.2.3. Location-Only Peer Selection 2757 This section discusses a promising peer selection algorithm that was 2758 recently used in experiments with a P2P live streaming application. 2760 Experiments in the context of live streaming have shown significant 2761 benefits of a simple "location-only" algorithm that primarily makes 2762 use of the Network Map. A benefit of this algorithm is that it can 2763 provide a simple integration path for applications wishing to utilize 2764 ALTO. 2766 In particular, the algorithm proceeds as follows to select an ordered 2767 list of peers for a particular incoming (or existing peer): 2769 1. Insert into the result list a number (up to a threshold) of peers 2770 from the same PID as the incoming peer. 2772 2. Insert into the result list a number (up to a threshold) of peers 2773 from the same ISP as the incoming peer. 2775 3. Insert into the result list a number (up to a threshold) of peers 2776 from different ISPs than the incoming peer. 2778 In the experiments, this algorithm was implemented at a tracker and 2779 executed for peer selection when peers initially join and when 2780 requesting new peers. 2782 This algorithm makes two assumptions about the preferences 2783 communicated by the Network Map: 2785 o The ISP prefers peers within the same PID to peer with each other 2786 (see Section 4); and 2788 o The ALTO Client can distinguish between peers within the same ISP 2789 and peers outside of the ISP. In implementation at the ALTO 2790 Client, it may may estimate a threshold based on costs read from 2791 the Cost Map. 2793 Appendix B. Acknowledgments 2795 Thank you to Jan Seedorf for contributions to the Security 2796 Considerations section. We would like to thank Yingjie Gu and Roni 2797 Even for helpful input and design concerning ALTO Information 2798 redistribution. 2800 We would like to thank the following people whose input and 2801 involvement was indispensable in achieving this merged proposal: 2803 Obi Akonjang (DT Labs/TU Berlin), 2805 Saumitra M. Das (Qualcomm Inc.), 2807 Syon Ding (China Telecom), 2809 Doug Pasko (Verizon), 2811 Laird Popkin (Pando Networks), 2813 Satish Raghunath (Juniper Networks), 2815 Albert Tian (Ericsson/Redback), 2817 Yu-Shun Wang (Microsoft), 2819 David Zhang (PPLive), 2821 Yunfei Zhang (China Mobile). 2823 We would also like to thank the following additional people who were 2824 involved in the projects that contributed to this merged document: 2826 Alex Gerber (AT&T), Chris Griffiths (Comcast), Ramit Hora (Pando 2827 Networks), Arvind Krishnamurthy (University of Washington), Marty 2828 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 2829 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T), 2830 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 2831 Damien Saucez (UCL) Thomas Scholl (AT&T), Emilio Sepulveda 2832 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 2833 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 2834 (Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia 2835 Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University), 2836 Haiyong Xie (Yale University). 2838 Appendix C. Authors 2840 [[Comment.1: RFC Editor: Please move information in this section to 2841 the Authors' Addresses section at publication time.]] 2843 Stefano Previdi 2844 Cisco 2846 Email: sprevidi@cisco.com 2848 Stanislav Shalunov 2849 BitTorrent 2851 Email: shalunov@bittorrent.com 2853 Richard Woundy 2854 Comcast 2856 Richard_Woundy@cable.comcast.com 2858 Authors' Addresses 2860 Richard Alimi (editor) 2861 Google 2862 1600 Amphitheatre Parkway 2863 Mountain View CA 2864 USA 2866 Email: ralimi@google.com 2867 Reinaldo Penno (editor) 2868 Juniper Networks 2869 1194 N Mathilda Avenue 2870 Sunnyvale CA 2871 USA 2873 Email: rpenno@juniper.net 2875 Y. Richard Yang (editor) 2876 Yale University 2877 51 Prospect St 2878 New Haven CT 2879 USA 2881 Email: yry@cs.yale.edu