idnits 2.17.1 draft-ietf-alto-protocol-05.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 878 has weird spacing: '...etaData meta...' == Line 879 has weird spacing: '...NString typ...' == Line 903 has weird spacing: '...istInfo redis...' == Line 1103 has weird spacing: '...NString uri;...' == Line 1104 has weird spacing: '...NNumber vers...' == (9 more instances...) -- The document date (July 12, 2010) is 5036 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 202 -- Looks like a reference, but probably isn't: 'RspDataType' on line 880 -- Looks like a reference, but probably isn't: 'OPTIONAL' on line 1178 -- Looks like a reference, but probably isn't: 'TODO' on line 1744 ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '2') ** Obsolete normative reference: RFC 2616 (ref. '3') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4627 (ref. '4') (Obsoleted by RFC 7158, RFC 7159) == Outdated reference: A later version (-02) exists of draft-kiesel-alto-reqs-01 == Outdated reference: A later version (-04) exists of draft-zyp-json-schema-02 == Outdated reference: A later version (-03) exists of draft-song-alto-server-discovery-00 == Outdated reference: A later version (-06) exists of draft-stiemerling-alto-deployments-04 Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG R. Alimi, Ed. 3 Internet-Draft Yale University 4 Intended status: Standards Track R. Penno, Ed. 5 Expires: January 13, 2011 Juniper Networks 6 Y. Yang, Ed. 7 Yale University 8 July 12, 2010 10 ALTO Protocol 11 draft-ietf-alto-protocol-05.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 January 13, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 1.1. Background and Problem Statement . . . . . . . . . . . . . 5 82 1.2. Design History and Merged Proposals . . . . . . . . . . . 5 83 1.3. Solution Benefits . . . . . . . . . . . . . . . . . . . . 5 84 1.3.1. Service Providers . . . . . . . . . . . . . . . . . . 5 85 1.3.2. Applications . . . . . . . . . . . . . . . . . . . . . 6 86 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 87 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 88 2.1.1. Endpoint Address . . . . . . . . . . . . . . . . . . . 6 89 2.1.2. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 7 90 2.1.3. Network Location . . . . . . . . . . . . . . . . . . . 7 91 2.1.4. ALTO Information . . . . . . . . . . . . . . . . . . . 7 92 2.1.5. ALTO Information Base . . . . . . . . . . . . . . . . 7 93 2.2. ALTO Service and Protocol Scope . . . . . . . . . . . . . 7 94 3. Protocol Structure . . . . . . . . . . . . . . . . . . . . . . 8 95 3.1. Server Information Service . . . . . . . . . . . . . . . . 9 96 3.2. ALTO Information Services . . . . . . . . . . . . . . . . 10 97 3.2.1. Map Service . . . . . . . . . . . . . . . . . . . . . 10 98 3.2.2. Map Filtering Service . . . . . . . . . . . . . . . . 10 99 3.2.3. Endpoint Property Service . . . . . . . . . . . . . . 10 100 3.2.4. Endpoint Cost Service . . . . . . . . . . . . . . . . 10 101 4. Network Map . . . . . . . . . . . . . . . . . . . . . . . . . 10 102 4.1. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 103 4.2. Endpoint Addresses . . . . . . . . . . . . . . . . . . . . 12 104 4.2.1. IP Addresses . . . . . . . . . . . . . . . . . . . . . 12 105 4.3. Example Network Map . . . . . . . . . . . . . . . . . . . 12 106 5. Cost Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 107 5.1. Cost Attributes . . . . . . . . . . . . . . . . . . . . . 13 108 5.1.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . 13 109 5.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 13 110 5.2. Cost Map Structure . . . . . . . . . . . . . . . . . . . . 14 111 5.3. Network Map and Cost Map Dependency . . . . . . . . . . . 14 112 6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 15 113 6.1. Design Approach . . . . . . . . . . . . . . . . . . . . . 15 114 6.1.1. Use of Existing Infrastructure . . . . . . . . . . . . 15 115 6.1.2. ALTO Information Reuse and Redistribution . . . . . . 16 116 7. Protocol Messaging . . . . . . . . . . . . . . . . . . . . . . 16 117 7.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 16 118 7.2. Message Format . . . . . . . . . . . . . . . . . . . . . . 17 119 7.2.1. Protocol Versioning Approach . . . . . . . . . . . . . 17 120 7.2.2. Request Message . . . . . . . . . . . . . . . . . . . 17 121 7.2.3. Response Message . . . . . . . . . . . . . . . . . . . 18 122 7.3. General Processing . . . . . . . . . . . . . . . . . . . . 21 123 7.4. ALTO Status Codes . . . . . . . . . . . . . . . . . . . . 21 124 7.5. Client Behavior . . . . . . . . . . . . . . . . . . . . . 22 125 7.5.1. Successful Response . . . . . . . . . . . . . . . . . 22 126 7.5.2. Error Conditions . . . . . . . . . . . . . . . . . . . 22 127 7.6. HTTP Usage . . . . . . . . . . . . . . . . . . . . . . . . 22 128 7.6.1. Authentication and Encryption . . . . . . . . . . . . 23 129 7.6.2. Cookies . . . . . . . . . . . . . . . . . . . . . . . 23 130 7.6.3. Caching Parameters . . . . . . . . . . . . . . . . . . 23 131 7.7. ALTO Requests . . . . . . . . . . . . . . . . . . . . . . 23 132 7.7.1. Server Information Service . . . . . . . . . . . . . . 24 133 7.7.2. Map Service . . . . . . . . . . . . . . . . . . . . . 27 134 7.7.3. Map Filtering Service . . . . . . . . . . . . . . . . 31 135 7.7.4. Endpoint Property Service . . . . . . . . . . . . . . 35 136 7.7.5. Endpoint Cost Service . . . . . . . . . . . . . . . . 38 137 7.8. Redistributable Responses . . . . . . . . . . . . . . . . 40 138 7.8.1. Server Capability Requirements . . . . . . . . . . . . 40 139 7.8.2. Service ID . . . . . . . . . . . . . . . . . . . . . . 40 140 7.8.3. Server and Request Parameters . . . . . . . . . . . . 41 141 7.8.4. Expiration Time . . . . . . . . . . . . . . . . . . . 41 142 7.8.5. Signature . . . . . . . . . . . . . . . . . . . . . . 42 143 8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 43 144 8.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 43 145 8.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 45 146 8.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 46 147 9. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 46 148 9.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 47 149 9.2. Hosts with Multiple Endpoint Addresses . . . . . . . . . . 47 150 9.3. Network Address Translation Considerations . . . . . . . . 47 151 9.4. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . 48 152 9.5. Endpoint and Path Properties . . . . . . . . . . . . . . . 48 153 9.6. P2P Peer Selection . . . . . . . . . . . . . . . . . . . . 49 154 9.6.1. Client-based Peer Selection . . . . . . . . . . . . . 49 155 9.6.2. Server-based Peer Selection . . . . . . . . . . . . . 49 156 9.6.3. Protocol Extension: 'Location-Only' Peer Selection . . 50 157 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 158 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 159 11.1. Privacy Considerations for ISPs . . . . . . . . . . . . . 51 160 11.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 51 161 11.3. Authentication, Integrity Protection, and Encryption . . . 52 162 11.4. ALTO Information Redistribution . . . . . . . . . . . . . 52 163 11.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 53 164 11.6. ALTO Server Access Control . . . . . . . . . . . . . . . . 53 165 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 166 12.1. Normative References . . . . . . . . . . . . . . . . . . . 54 167 12.2. Informative References . . . . . . . . . . . . . . . . . . 54 168 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 56 169 Appendix B. Authors . . . . . . . . . . . . . . . . . . . . . . . 57 170 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 172 1. Introduction 174 1.1. Background and Problem Statement 176 Today, network information available to applications is mostly from 177 the view of endhosts. There is no clear mechanism to convey 178 information about the network's preferences to applications. By 179 leveraging better network-provided information, applications have the 180 potential to become more network-efficient (e.g., reduce network 181 resource consumption) and achieve better application performance 182 (e.g., accelerated download rate). The ALTO Service intends to 183 provide a simple way to convey network information to applications. 185 The goal of this document is to specify a simple and unified protocol 186 that meets the ALTO requirements [8] while providing a migration path 187 for Internet Service Providers (ISP), Content Providers, and clients 188 that have deployed protocols with similar intentions (see below). 189 This document is a work in progress and will be updated with further 190 developments. 192 1.2. Design History and Merged Proposals 194 The protocol specified here consists of contributions from 196 o P4P [9], [10]; 198 o ALTO Info-Export [11]; 200 o Query/Response [12], [13]; 202 o ATTP [ATTP]; 204 o Proxidor [14]. 206 See Appendix A for a list of people that have contributed 207 significantly to this effort and the projects and proposals listed 208 above. 210 1.3. Solution Benefits 212 The ALTO Service offers many benefits to both end-users (consumers of 213 the service) and Internet Service Providers (providers of the 214 service). 216 1.3.1. Service Providers 218 The ALTO Service enables ISPs to influence the peer selection process 219 in distributed applications in order to increase locality of traffic, 220 improve user-experience, amongst others. It also helps ISPs to 221 efficiently engineer traffic that traverses more expensive links such 222 as transit and backup links, thus allowing a better provisioning of 223 the networking infrastructure. 225 1.3.2. Applications 227 Applications that use the ALTO Service can benefit in multiple ways. 228 For example, they may no longer need to infer topology information, 229 and some applications can reduce reliance on measuring path 230 performance metrics themselves. They can take advantage of the ISP's 231 knowledge to avoid bottlenecks and boost performance. 233 An example type of application is a Peer-to-Peer overlay where peer 234 selection can be improved by including ALTO information in the 235 selection process. 237 2. Architecture 239 Two key design objectives of the ALTO Protocol are simplicity and 240 extensibility. At the same time, it introduces additional techniques 241 to address potential scalability and privacy issues. After an 242 introduction to the terminology, the ALTO architecture and the ALTO 243 Protocol's place in the overall architecture are defined. 245 2.1. Terminology 247 We use the following terms defined in [15]: Application, Overlay 248 Network, Peer, Resource, Resource Identifier, Resource Provider, 249 Resource Consumer, Resource Directory, Transport Address, Host 250 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 251 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 252 Transit Traffic. 254 We also use the following additional terms: Endpoint Address, ASN, 255 and Network Location. 257 2.1.1. Endpoint Address 259 An endpoint address represents the communication address of an 260 endpoint. An endpoint address can be network-attachment based (IP 261 address) or network-attachment agnostic. Common forms of endpoint 262 addresses include IP address, MAC address, overlay ID, and phone 263 number. 265 2.1.2. ASN 267 An Autonomous System Number. 269 2.1.3. Network Location 271 Network Location is a generic term denoting a single endpoint or 272 group of endpoints. 274 2.1.4. ALTO Information 276 ALTO Information is a generic term referring to the network 277 information sent by an ALTO Server. 279 2.1.5. ALTO Information Base 281 Internal representation of the ALTO Information maintained by the 282 ALTO Server. Note that the structure of this internal representation 283 is not defined by this document. 285 2.2. ALTO Service and Protocol Scope 287 An ALTO Server conveys the network information from the perspective 288 of a network region; the ALTO Server presents its "my-Internet View" 289 [16] of the network region. A network region in this context can be 290 an Autonomous System, an ISP, or perhaps a smaller region or set of 291 ISPs; the details depend on the deployment scenario and discovery 292 mechanism. 294 To better understand the ALTO Service and the role of the ALTO 295 Protocol, we show in Figure 1 the overall system architecture. In 296 this architecture, an ALTO Server prepares ALTO Information; an ALTO 297 Client uses ALTO Service Discovery to identify an appropriate ALTO 298 Server; and the ALTO Client requests available ALTO Information from 299 the ALTO Server using the ALTO Protocol. 301 The ALTO Information provided by the ALTO Server can be updated 302 dynamically based on network conditions, or can be seen as a policy 303 which is updated at a larger time-scale. 305 More specifically, the ALTO Information provided by an ALTO Server 306 may be influenced (at the operator's discretion) by other systems. 307 Examples include (but are not limited to) static network 308 configuration databases, dynamic network information, routing 309 protocols, provisioning policies, and interfaces to outside parties. 310 These components are shown in the figure for completeness but outside 311 the scope of this specification. 313 Note that it may also be possible for ALTO Servers to exchange 314 network information with other ALTO Servers (either within the same 315 administrative domain or another administrative domain with the 316 consent of both parties) in order to adjust exported ALTO 317 information. Such a protocol is also outside the scope of this 318 specification. 320 +-------------------------------------------------------------------+ 321 | ISP | 322 | | 323 | +-----------+ | 324 | | Routing | | 325 | +--------------+ | Protocols | | 326 | | Provisioning | +-----------+ | 327 | | Policy | | | 328 | +--------------+\ | | 329 | \ | | 330 | \ | | 331 | +-----------+ \+---------+ +--------+ | 332 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 333 | |Network |.......| Server | -------------------- | Client | | 334 | |Information| +---------+ +--------+ | 335 | +-----------+ / / | 336 | / ALTO SD Query/Response / | 337 | / / | 338 | +----------+ +--------------+ | 339 | | External | | ALTO Service | | 340 | | Interface| | Discovery | | 341 | +----------+ +--------------+ | 342 | | | 343 +-------------------------------------------------------------------+ 344 | 345 +------------------+ 346 | Third Parties | 347 | | 348 | Content Providers| 349 +------------------+ 351 Figure 1: Basic ALTO Architecture 353 3. Protocol Structure 355 The ALTO Protocol uses a simple extensible framework to convey 356 network information. In the general framework, the ALTO protocol 357 will convey properties on both Network Locations and the paths 358 between Network Locations. 360 In this document, we focus on a particular Endpoint property to 361 denote the location of an endpoint, and provider-defined costs for 362 paths between pairs of Network Locations. 364 The ALTO Protocol is built on a common transport protocol, messaging 365 structure and encoding, and transaction model. The protocol is 366 subdivided into services of related functionality. ALTO-Core 367 provides the Server Information Service and the Map Service to 368 provide ALTO Information. Other ALTO Information services can 369 provide additional functionality. There are three such services 370 defined in this document: the Map Filtering Service, Endpoint 371 Property Service, and Endpoint Cost Service. Additional services may 372 be defined in in companion documents. Note that functionality 373 offered in different services are not totally non-overlapping (e.g., 374 the Map Service and Map Filtering Service). 376 .------------------------------------------------------------. 377 | | 378 | .----------. .-----------------------------------------. | 379 | | | | ALTO Info Services | | 380 | | | | .-----------. .----------. .----------. | | 381 | | | | | Map | | Endpoint | | Endpoint | | | 382 | | | | | Filtering | | Property | | Cost | | | 383 | | | | | Service | | Service | | Service | | | 384 | | Server | | `-----------' `----------' `----------' | | 385 | | Info | | .-------------------------------------. | | 386 | | Service | | | Map Service | | | 387 | | | | | .-------------. .--------------. | | | 388 | | | | | | Network Map | | Cost Map | | | | 389 | | | | | `-------------' `--------------' | | | 390 | | | | `-------------------------------------' | | 391 | `----------' `-----------------------------------------' | 392 | | 393 `------------------------------------------------------------' 395 Figure 2: ALTO Protocol Structure 397 3.1. Server Information Service 399 The Server Capability Service lists the details on the information 400 that can be provided by an ALTO Server and perhaps other ALTO Servers 401 maintained by the network provider. The configuration includes, for 402 example, details about the operations and cost metrics supported by 403 the ALTO Server and other related ALTO Servers that may be usable by 404 an ALTO Client. The capability document can be downloaded by ALTO 405 Clients. The capability information could also be provisioned to 406 devices, but care must be taken to update it appropriately. 408 3.2. ALTO Information Services 410 Multiple, distinct services are defined to allow ALTO Clients to 411 query ALTO Information from an ALTO Server. The ALTO Server 412 internally maintains an ALTO Information Base that encodes the 413 network provider's preferences. The ALTO Information Base encodes 414 the Network Locations defined by the ALTO Server (and their 415 corresponding properties), as well as the provider-defined costs 416 between pairs of Network Locations. 418 3.2.1. Map Service 420 The Map Service provides batch information to ALTO Clients in the 421 form of a Network Map and Cost Map. The Network Map (See Section 4) 422 provides the full set of Network Location groupings defined by the 423 ALTO Server and the endpoints contained with each grouping. The Cost 424 Map (see Section 5) provides costs between the defined groupings. 426 These two maps can be thought of (and implemented as) as simple files 427 with appropriate encoding provided by the ALTO Server. 429 3.2.2. Map Filtering Service 431 Resource constrained ALTO Clients may benefit from query results 432 being filtered at the ALTO Server. This avoids an ALTO Client 433 spending network bandwidth or CPU collecting results and performing 434 client-side filtering. The Map Filtering Service allows ALTO Clients 435 to query for the ALTO Server Network Map and Cost Map based on 436 additional parameters. 438 3.2.3. Endpoint Property Service 440 This service allows ALTO Clients to look up properties for individual 441 endpoints. An example endpoint property is its Network Location (its 442 grouping defined by the ALTO Server) or connectivity type (e.g., 443 ADSL, Cable, or FioS). 445 3.2.4. Endpoint Cost Service 447 Some ALTO Clients may also benefit from querying for costs and 448 rankings based on endpoints. The Endpoint Cost Service allows an 449 ALTO Server to return either numerical costs or ordinal costs 450 (rankings) directly amongst Endpoints. 452 4. Network Map 454 In reality, many endpoints are very close to one another in terms of 455 network connectivity, for example, endpoints on the same site of an 456 enterprise. By treating a group of endpoints together as a single 457 entity in ALTO, we can achieve much greater scalability without 458 losing critical information. 460 The Network Location endpoint property allows an ALTO Server to group 461 endpoints together to indicate their proximity. The resulting set of 462 groupings is called the ALTO Network Map. 464 The definition of proximity varies depending on the granularity of 465 the ALTO information configured by the provider. In one deployment, 466 endpoints on the same subnet may be considered close; while in 467 another deployment, endpoints connected to the same PoP may be 468 considered close. 470 As used in this document, the Network Map refers to the syntax and 471 semantics of the information distributed by the ALTO Server. This 472 document does not discuss the internal representation of this data 473 structure within the ALTO Server. 475 4.1. PID 477 Each group of Endpoints is identified by a provider-defined Network 478 Location identifier called a PID. There can be many different ways 479 of grouping the endpoints and assigning PIDs. 481 A PID is an identifier that provides an indirect and network-agnostic 482 way to specify a network aggregation. For example, a PID may be 483 defined by the ALTO service provider to denote a subnet, a set of 484 subnets, a metropolitan area, a PoP, an autonomous system, or a set 485 of autonomous systems. Aggregation of endpoints into PIDs can 486 indicate proximity and can improve scalability. In particular, 487 network preferences (costs) may be specified between PIDs, allowing 488 cost information to be more compact and updated at a smaller time 489 scale than the network aggregations themselves. 491 Using PIDs, the Network Map may also be used to communicate simple 492 preferences with only minimal information from the Cost Map. For 493 example, an ISP may prefer that endpoints associated with the same 494 PoP (Point-of-Presence) in a P2P application communicate locally 495 instead of communicating with endpoints in other PoPs. The ISP may 496 aggregate endhosts within a PoP into a single PID in the Network Map. 497 The Cost Map may be encoded to indicate that peering within the same 498 PID is preferred; for example, cost(PID_i, PID_i) == c* and 499 cost(PID_i, PID_j) > c* for i != j. Section 5 provides further 500 details about Cost Map structure. 502 4.2. Endpoint Addresses 504 Communicating endpoints may have many types of addresses, such as IP 505 addresses, MAC addresses, or overlay IDs. The current specification 506 only considers IP addresses. 508 4.2.1. IP Addresses 510 The endpoints aggregated into a PID are denoted by a list of IP 511 prefixes. When either an ALTO Client or ALTO Server needs to 512 determine which PID in a Network Map contains a particular IP 513 address, longest-prefix matching MUST be used. 515 A Network Map MUST define a PID for each possible address in the IP 516 address space. A RECOMMENDED way to satisfy this property is to 517 define a PID containing the 0.0.0.0/0 prefix for IPv4 or ::/0 (for 518 IPv6). 520 4.3. Example Network Map 522 Figure 3 illustrates an example Network Map. PIDs are used to 523 identify network-agnostic aggregations. 525 .-----------------------------------------------------------. 526 | ALTO Network Map | 527 | | 528 | .-----------------------------------. .---------------. | 529 | | NetLoc: PID-1 | | NetLoc: PID-2 | | 530 | | .------------------------------. | | ... | | 531 | | | 192.0.2.0/24 | | `---------------` | 532 | | | .--------------------------. | | | 533 | | | | Endpoint: 192.0.2.34 | | | .---------------. | 534 | | | `--------------------------` | | | NetLoc: PID-3 | | 535 | | `------------------------------` | | ... | | 536 | | .------------------------------. | `---------------` | 537 | | | 198.51.100.0/25 | | | 538 | | | .--------------------------. | | .---------------. | 539 | | | | Endpoint: 198.51.100.100 | | | | NetLoc: PID-4 | | 540 | | | `--------------------------` | | | ... | | 541 | | `------------------------------` | `---------------` | 542 | `-----------------------------------` | 543 | | 544 `-----------------------------------------------------------` 546 Figure 3: Example Network Map 548 5. Cost Map 550 An ALTO Server indicates preferences amongst network locations in the 551 form of Path Costs. Path Costs are generic costs and can be 552 internally computed by a network provider according to its own needs. 554 An ALTO Cost Map defines Path Costs pairwise amongst sets of source 555 and destination Network Locations. 557 One advantage of separating ALTO information into a Network Map and a 558 Cost Map is that the two components can be updated at different time 559 scales. For example, Network Maps may be stable for a longer time 560 while Cost Maps may be updated to reflect dynamic network conditions. 562 As used in this document, the Cost Map refers to the syntax and 563 semantics of the information distributed by the ALTO Server. This 564 document does not discuss the internal representation of this data 565 structure within the ALTO Server. 567 5.1. Cost Attributes 569 Path Costs have attributes: 571 o Type: identifies what the costs represent; 573 o Mode: identifies how the costs should be interpreted (numerical or 574 ordinal). 576 Certain queries for Cost Maps allow the ALTO Client to indicate the 577 desired Type and Mode. 579 5.1.1. Cost Type 581 The Type attribute indicates what the cost represents. For example, 582 an ALTO Server could define costs representing air-miles, hop-counts, 583 or generic routing costs. 585 Cost types are indicated in protocol messages as alphanumeric 586 strings. An ALTO Server MUST at least define the routing cost type 587 denoted by the string 'routingcost'. 589 Note that an ISP may internally compute routing cost using any method 590 it chooses (including air-miles or hop-count). 592 5.1.2. Cost Mode 594 The Mode attribute indicates how costs should be interpreted. For 595 example, an ALTO Server could return costs that should be interpreted 596 as numerical values or ordinal rankings. 598 It is important to communicate such information to ALTO Clients, as 599 certain operations may not be valid on certain costs returned by an 600 ALTO Server. For example, it is possible for an ALTO Server to 601 return a set of IP addresses with costs indicating a ranking of the 602 IP addresses. Arithmetic operations, such as summation, that would 603 make sense for numerical values, do not make sense for ordinal 604 rankings. ALTO Clients may handle such costs differently. 606 Cost Modes are indicated in protocol messages as alphanumeric 607 strings. An ALTO Server MUST at least define the modes 'numerical' 608 and 'ordinal'. 610 If an ALTO Client requests a Cost Mode that is not supported, the 611 ALTO Server MUST reply with costs having Mode either 'numerical' or 612 'ordinal'. Thus, an ALTO Server must implement at least one of 613 'numerical' or 'ordinal' Costs, but it may choose which to support. 614 ALTO Clients may choose how to handle such situations. Two 615 particular possibilities are to use the returned costs as-is (e.g., 616 treat numerical costs as ordinal rankings) or ignore the ALTO 617 information altogether. 619 5.2. Cost Map Structure 621 A query for a Cost Map either explicitly or implicitly includes a 622 list of Source Network Locations and a list of Destination Network 623 Locations. (Recall that a Network Location can be an endpoint 624 address or a PID.) 626 Specifically, assume that a query has a list of multiple Source 627 Network Locations, say [Src_1, Src_2, ..., Src_m], and a list of 628 multiple Destination Network Locations, say [Dst_1, Dst_2, ..., 629 Dst_n]. 631 The ALTO Server will return the Path Cost for each communicating pair 632 (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., Src_m -> Dst_1, ..., 633 Src_m -> Dst_n). We refer to this structure as a Cost Map. 635 If the Cost Mode is 'ordinal', the Path Cost of each communicating 636 pair is relative to the m*n entries. 638 5.3. Network Map and Cost Map Dependency 640 If a Cost Map contains PIDs in the list of Source Network Locations 641 or the list of Destination Network Locations, the Path Costs are 642 generated based on a particular Network Map (which defines the PIDs). 643 Version Tags are introduced to ensure that ALTO Clients are able to 644 use consistent information even though the information is provided in 645 two maps. 647 A Version Tag is an opaque string associated with a Network Map 648 maintained by the ALTO Server. When the Network Map changes, the 649 Version Tag SHOULD also be changed. (Thus, the Version Tag is 650 defined similarly to HTTP's ETag.) Possibilities for generating a 651 Version Tag included the last-modified timestamp for the Network Map, 652 or a hash of its contents. 654 A Network Map distributed by the ALTO Server includes its Version 655 Tag. A Cost Map referring to PIDs also includes the Version Tag of 656 the Network Map on which it is based. 658 6. Protocol Overview 660 6.1. Design Approach 662 The ALTO Protocol design uses a REST-like interface with the goal of 663 leveraging current HTTP [2] [3] implementations and infrastructure, 664 as well as familiarity with existing REST-like services in popular 665 use. ALTO messages are denoted with HTTP Content-Type "application/ 666 alto" and use JSON [4] to encode message bodies. 668 This document currently specifies both services and and the message 669 encoding in a descriptive fashion. Care is taken to make 670 descriptions precise and unambiguous, but it still lacks benefits of 671 automatic tooling that exists for certain encoding formats. 673 Standards such as WSDL 2.0 and WADL are capable of describing 674 available interfaces. JSON Schema [17] allows message encodings to 675 be specified precisely and messages may be verified against the 676 schema. It is not yet clear whether such an approach should be taken 677 in this document. 679 Other benefits enabled by these design choices include easier 680 understanding and debugging, flexible ALTO Server implementation 681 strategies, and more importantly, simple caching and redistribution 682 of ALTO information to increase scalability. 684 6.1.1. Use of Existing Infrastructure 686 HTTP is a natural choice for integration with existing applications 687 and infrastructure. In particular, the ALTO Protocol design 688 leverages: 690 o the huge installed base of infrastructure, including HTTP caches, 692 o mature software implementations, 694 o the fact that many P2P clients already have an embedded HTTP 695 client, and 697 o authentication and encryption mechanisms in HTTP and SSL/TLS. 699 6.1.2. ALTO Information Reuse and Redistribution 701 ALTO information may be useful to a large number of applications and 702 users. For example, an identical Network Map may be used by all ALTO 703 Clients querying a particular ALTO Server. At the same time, 704 distributing ALTO information must be efficient and not become a 705 bottleneck. Therefore, the ALTO Protocol specified in this document 706 integrates with existing HTTP caching infrastructure to allow reuse 707 of ALTO information by ALTO Clients and reduce load on ALTO servers. 709 ALTO information may also be cached or redistributed using 710 application-dependent mechanisms, such as P2P DHTs or P2P file- 711 sharing. This document does not define particular mechanisms for 712 such redistribution, but it does define the primitives (e.g., digital 713 signatures) needed to support such a mechanism. See [18] for further 714 discussion. 716 Note that if caching or redistribution is used, the Response message 717 may be returned from another (possibly third-party) entity. Reuse 718 and Redistribution is further discussed in Section 11.4. Protocol 719 support for redistribution is specified in Section 7.8. 721 7. Protocol Messaging 723 This section specifies client and server processing, as well as 724 messages in the ALTO Protocol. Details common to ALTO Server 725 processing of all messages is first discussed, followed by details of 726 the individual messages. 728 7.1. Notation 730 This document uses C-style struct notation to define the required and 731 optional members of JSON objects. Unless explicitly noted, each 732 member of a struct is REQUIRED. 734 The types 'JSONString', 'JSONNumber', 'JSONBool' indicate the JSON 735 string, number, and boolean types respectively. 737 This document only includes object members used by this 738 specification. It is possible that protocol extensions include 739 additional members to JSON objects defined in this document; such 740 additional members will be silently ignored by ALTO Servers and 741 Clients only implementing the base protocol defined in this document. 743 7.2. Message Format 745 Request and Response follow the standard format for HTTP Request and 746 Response messages [2] [3]. 748 The following subsections provide an overview of how ALTO Requests 749 and Responses are encoded in HTTP, and discusses rationale for 750 certain design decisions. 752 7.2.1. Protocol Versioning Approach 754 The ALTO Protocol uses a simple and clean approach to versioning that 755 permits evolution between versions even if ALTO information is being 756 served as static, pre-generated files. 758 In particular, it is assumed that a single host responding to ALTO 759 Requests implements a single protocol version. Note that virtual 760 hosting can be used if multiple protocol versions need to be 761 supported by a single physical server. 763 A common query (Server List, detailed in Section 7.7.1.1) to be 764 present in all ALTO protocol versions allows an ALTO Client to 765 discover additional ALTO Servers and the ALTO Protocol version number 766 of each. 768 This approach keeps the ALTO Server implementation free from parsing 769 and directing each request based on version number. Although ALTO 770 Requests are free from protocol version numbers, the protocol version 771 number is echoed in each ALTO Response to keep responses self- 772 contained to, for example, ease reading persisted or redistributed 773 ALTO responses. 775 This document specifies ALTO Protocol version 1. 777 7.2.2. Request Message 779 An ALTO Request is a standard HTTP Request generated by an ALTO 780 Client, with certain components defined by the ALTO Protocol. 782 The basic syntax of an ALTO Request is: 784 / HTTP/1.1 785 Host: 787 For example: 789 GET /info/capability HTTP/1.1 790 Host: alto.example.com:6671 792 7.2.2.1. Standard HTTP Headers 794 The Host header MUST follow the standard rules for the HTTP 1.1 Host 795 Header. 797 The Content-Length header MUST follow the standard rules defined in 798 HTTP 1.1. 800 The Content-Type HTTP Header MUST have value "application/alto" if 801 the Body is non-empty. 803 7.2.2.2. Method and Resource 805 Next, both the HTTP Method and URI-Path (denoted as Resource) 806 indicate the operation requested by the ALTO Client. In this 807 example, the ALTO Client is requesting basic capability information 808 from the ALTO Server. 810 7.2.2.3. Input Parameters 812 Certain operations defined by the ALTO Protocol (e.g., in the Map 813 Filtering Service) allow the ALTO Client to supply additional input 814 parameters. Such input parameters are encoded in a URI-Query-String 815 where possible and appropriate. However, due to practical 816 limitations (e.g. underlying HTTP implementations may have 817 limitations on the total length of a URI and the Query-String is 818 better-suited for simple unstructured parameters and lists), some 819 operations in the ALTO Protocol use input parameters encoded in the 820 HTTP Request Body. 822 7.2.3. Response Message 824 A Response message is a standard HTTP Response generated by an ALTO 825 Server with certain components defined by the ALTO Protocol. 827 The basic syntax of an ALTO Response is: 829 HTTP/1.1 830 Content-Length: 831 Content-Type: 832 834 where the HTTP Response Body is an ALTOResponse JSON Object (defined 835 in Section 7.2.3.3). For example: 837 HTTP/1.1 200 OK 838 Content-Length: 1000 839 Content-Type: application/alto 841 { 842 "meta" : { 843 "version": 1, 844 "status" : { 845 "code" : 1, 846 "reason" : "Success" 847 }, 848 ... 849 }, 850 "type" : "capability", 851 "data" : { 852 ... 853 } 854 } 856 7.2.3.1. Standard HTTP Headers 858 The Content-Length header MUST follow the standard rules defined in 859 HTTP 1.1. 861 The Content-Type HTTP Header MUST have value "application/alto" if 862 the Body is non-empty. 864 7.2.3.2. Status Code and Message 866 Two sets of status codes are used in the ALTO Protocol. First, an 867 ALTO Status Code provides detailed information about the success or 868 failure of a particular operation. Second, an HTTP Status Code 869 indicates to HTTP processing elements (e.g., intermediaries and 870 clients) how the response should be treated. 872 7.2.3.3. HTTP Body 874 The Response body MUST encode a single top-level JSON object of type 875 ALTOResponse: 877 struct { 878 RspMetaData meta; 879 JSONString type; 880 [RspDataType] data; 881 } ALTOResponse; 883 The ALTOResponse object has distinct sections for: 885 o meta information encoded in an extensible way, 887 o the type of ALTO Information to follow, and 889 o the requested ALTO Information. 891 7.2.3.3.1. Meta Information 893 Meta information is encoded as a JSON object with type RspMetaData: 895 struct { 896 JSONNumber code; 897 JSONString reason; [OPTIONAL] 898 } RspStatus; 900 struct { 901 JSONNumber version; 902 RspStatus status; 903 RspRedistInfo redistribution; [OPTIONAL] 904 } RspMetaData; 906 with members: 908 o version: the ALTO Protocol version 910 o status: the ALTO Status Code indicating a more detailed reason for 911 the success or failure of a request than HTTP Status Codes permit. 912 See Section 7.4 for a list of ALTO Status Codes defined in this 913 document. The corresponding 'reason' is a free-form string 914 providing a human-readable indication of the particular status 915 code. 917 o redistribution: additional meta information used by ALTO 918 information redistribution (see Section 7.8) 920 7.2.3.3.2. ALTO Information 922 If the Response is successful (see Section 7.4), then the "type" and 923 "data" members of the ALTOResponse object are REQUIRED. "type" 924 encodes a Response-specific string which indicates to the ALTO Client 925 the type of data encoded in the message. The "data" member encodes 926 the actual Response-specific data. The structure of this member is 927 detailed later in this section for each particular ALTO Response. 929 7.2.3.4. Signature 931 An ALTO Server MAY additionally supply a signature asserting that it 932 generated a particular response. In order to allow the signature to 933 be computed over the entire response message, the signature itself is 934 specified in an HTTP Header or Trailer (see Section 7.8.5). 936 7.3. General Processing 938 The protocol is structured in such a way that, independent of the 939 query type, there are a set of general processing steps. The ALTO 940 Client selects a specific ALTO Server with which to communicate, 941 establishes a TCP connection, and constructs and sends ALTO Request 942 messages which MUST conform to Section 7.7. In response to Request 943 messages, an ALTO Server constructs and sends ALTO Response messages 944 which also MUST conform to Section 7.7. 946 7.4. ALTO Status Codes 948 This document defines ALTO Status Codes to support the operations 949 defined in this document. Additional status codes may be defined in 950 companion or extension documents. 952 An ALTO Server MUST return the 'Success' code in Table 1 if and only 953 if the Request message is successfully processed and the requested 954 ALTO information is returned by the ALTO Server. 956 The HTTP Status Codes corresponding to each ALTO Status Code are 957 defined to provide correct behavior with HTTP intermediaries and 958 clients. When an ALTO Server returns a particular ALTO Status Code, 959 it MUST indicate one of the corresponding HTTP Status Codes in 960 Table 1. 962 If multiple errors are present in a single ALTO Request (e.g., a 963 request uses a JSONString when a JSONInteger is expected and a 964 required field is missing), then the ALTO Server MUST return exactly 965 one of the detected errors. However, the reported error is 966 implementation defined, since specifying a particular order for 967 message processing encroaches needlessly on implementation technique. 969 +----------------------+------------------+-------------------------+ 970 | ALTO Status Code | HTTP Status | Description | 971 | | Code(s) | | 972 +----------------------+------------------+-------------------------+ 973 | SUCCESS | 2xx | Success | 974 | E_JSON_SYNTAX | 400 | JSON parsing error in | 975 | | | request | 976 | E_JSON_FIELD_MISSING | 400 | Required field missing | 977 | E_JSON_VALUE_TYPE | 400 | JSON Value of | 978 | | | unexpected type | 979 | E_INVALID_OPERATION | 501 | Invalid operation | 980 | | | requested | 981 | E_INVALID_COST_TYPE | 501 | Invalid cost type | 982 +----------------------+------------------+-------------------------+ 984 Table 1: Defined ALTO Status Codes 986 Status codes described in Table 1 are a work in progress. The set of 987 status codes will be modified or expanded as implementation 988 experience is gained; feedback is welcomed. 990 In addition, feedback from implementers of ALTO Clients is welcomed 991 to identify if there is a need to communicate multiple status codes 992 in a single response. 994 7.5. Client Behavior 996 7.5.1. Successful Response 998 This specification does not indicate any required actions taken by 999 ALTO Clients upon receiving a successful response from an ALTO 1000 Server. Although ALTO Clients are suggested to interpret the 1001 received ALTO Information and adapt application behavior, ALTO 1002 Clients may also choose to ignore the received information. 1004 7.5.2. Error Conditions 1006 If an ALTO Client does not receive a successful response from the 1007 ALTO Server, it can either choose another server or fall back to a 1008 default behavior (e.g., perform peer selection without the use of 1009 ALTO information). An ALTO Client may also retry the request at a 1010 later time. 1012 7.6. HTTP Usage 1013 7.6.1. Authentication and Encryption 1015 An ALTO Server MAY support SSL/TLS to implement server and/or client 1016 authentication, as well as encryption. 1018 An ALTO Server MAY support HTTP Digest authentication. 1020 7.6.2. Cookies 1022 Cookies MUST NOT be used. 1024 7.6.3. Caching Parameters 1026 If the Response generated by the ALTO Server is cachable, the ALTO 1027 Server MAY include 'Cache-Control' and 'Expires' HTTP headers. 1029 If a Response generated by the ALTO Server is not cachable, the ALTO 1030 Server MUST specify the "Cache-Control: no-cache" HTTP Header. 1032 7.7. ALTO Requests 1034 This section documents the individual operations supported in the 1035 ALTO Protocol. See Section 7.2.2 and Section 7.2.3 for 1036 specifications of HTTP Request/Response components common to all 1037 operations in the ALTO Protocol. 1039 Table 2 provides an summary of the HTTP Method and URI-Paths used for 1040 ALTO Requests: 1042 +----------------+--------------+----------------------------+ 1043 | Service | Operation | HTTP Method and URI-Path | 1044 +----------------+--------------+----------------------------+ 1045 | Server Info | List Servers | GET /info/servers | 1046 | Server Info | Capability | GET /info/capability | 1047 | | | | 1048 | Map | Network Map | GET /map/core/pid/net | 1049 | Map | Cost Map | GET /map/core/pid/cost | 1050 | | | | 1051 | Map Filtering | Network Map | POST /map/filter/pid/net | 1052 | Map Filtering | Cost Map | POST /map/filter/pid/cost | 1053 | | | | 1054 | Endpoint Prop. | Lookup | GET /endpoint/prop/ | 1055 | | | POST /endpoint/prop/lookup | 1056 | | | | 1057 | Endpoint Cost | Lookup | POST /endpoint/cost/lookup | 1058 +----------------+--------------+----------------------------+ 1060 Table 2: Overview of ALTO Requests 1062 7.7.1. Server Information Service 1064 The Server Information Service provides information about available 1065 ALTO Servers and their capabilities (e.g., supported services). 1067 An ALTO Server MUST support the Server Information Service and MUST 1068 implement all operations defined in this section. 1070 7.7.1.1. Server List 1072 The Server List request allows an ALTO Client to discover other ALTO 1073 Servers provided by the ALTO Service Provider. Upon discovering an 1074 additional ALTO Server, the ALTO Client may then query the server 1075 capabilities (see Section 7.7.1.2) to test if it supports desired 1076 functionality. 1078 The Server List request is intended to help an ALTO Client find an 1079 ALTO Server supporting the desired ALTO Protocol version and 1080 capabilities. It is not intended to serve as a substitute for the 1081 ALTO Server Discovery which helps an ALTO Client locate an initial 1082 ALTO Server. 1084 This operation MUST be supported by the ALTO Server. 1086 7.7.1.1.1. Request Syntax 1088 GET /info/servers HTTP/1.1 1089 Host: 1091 7.7.1.1.2. Response Syntax 1093 HTTP/1.1 200 1094 Content-Length: 1095 Content-Type: application/alto 1097 1099 where the ALTOResponse object has "type" member equal to the string 1100 "server-list" and "data" member of type RspServerList: 1102 struct { 1103 JSONString uri; 1104 JSONNumber version; 1105 } ServerItem; 1107 struct { 1108 ServerItem servers<0..*>; 1109 } RspServerList; 1111 RspServerList has members: 1113 o servers: Array of available ALTO Servers, detailing the URI of the 1114 ALTO Server and the ALTO Protocol version that it implements. The 1115 array must at least contain an entry corresponding to the ALTO 1116 Server at the URI from which it is retrieving the server list. 1118 7.7.1.1.3. Example 1120 GET /info/servers HTTP/1.1 1121 Host: alto.example.com:6671 1123 HTTP/1.1 200 OK 1124 Content-Length: [TODO] 1125 Content-Type: application/alto 1127 { 1128 "meta" : { 1129 "version" : 1, 1130 "status" : { 1131 "code" : 1 1132 } 1133 }, 1134 "type" : "server-list", 1135 "data" : { 1136 "servers" : [ 1137 { 1138 "uri": "http://alto.example.com:6671", 1139 "version" : 1 1140 } 1141 ] 1142 } 1143 } 1145 7.7.1.2. Server Capability 1147 The Server Capability request allows an ALTO Client to determine the 1148 functionality supported by the queried ALTO Server. 1150 This operation MUST be supported by the ALTO Server. 1152 7.7.1.2.1. Request Syntax 1154 GET /info/capability HTTP/1.1 1155 Host: 1157 7.7.1.2.2. Response Syntax 1159 HTTP/1.1 200 1160 Content-Length: 1161 Content-Type: application/alto 1163 1165 where the ALTOResponse object has "type" member equal to the string 1166 "capability" and "data" member of type RspCapability: 1168 enum { 1169 map, 1170 map_filtering, 1171 endpoint_property, 1172 endpoint_cost 1173 } ServiceType; [Note: encoded as JSONString's] 1175 struct { 1176 ServiceType services<0..*>; 1177 JSONString cost_types<0..*>; [OPTIONAL] 1178 JSONBool cost_constraints; [OPTIONAL] 1179 JSONString service_id; [OPTIONAL+] 1180 JSONString certificate; [OPTIONAL+] 1181 } RspCapability; 1183 See Section 7.8.1 for additional notes concerning the 'service_id' 1184 and 'certificate' fields for ALTO Servers enabling response 1185 redistribution. 1187 RspCapability has members: 1189 o services: Lists the services supported by the ALTO Server. The 1190 service names defined in this document are are "map", 1191 "map_filtering", "endpoint_property", and "endpoint_cost". 1193 o cost_types: Array of cost type information for additional 1194 supported ALTO Cost types, detailing the name for each supported 1195 additional type. [[Comment.1: Need to discuss IANA implications 1196 or alternate approaches. Note that current definition assumes the 1197 unit for a cost type is fixed.]] 1199 o cost_constraints: Indicates if the ALTO Server supports cost 1200 constraints. The value 'false' is implied if this member is not 1201 present. 1203 o service_id: UUID [5] indicating an set of ALTO Servers (possibly 1204 just a single ALTO Server) serving equivalent ALTO Information 1205 (see Section 7.8). 1207 o certificate: PEM-encoded X.509 certificate used by the ALTO Server 1208 to sign distributed information (see Section 7.8). 1210 7.7.1.2.3. Example 1212 GET /info/capability HTTP/1.1 1213 Host: alto.example.com:6671 1215 HTTP/1.1 200 OK 1216 Content-Length: [TODO] 1217 Content-Type: application/alto 1219 { 1220 "meta" : { 1221 "version" : 1, 1222 "status" : { 1223 "code" : 1 1224 } 1225 }, 1226 "type" : "capability", 1227 "data" : { 1228 "services" : [ "map", "map-filtering" ], 1229 "cost_types": [ 1230 "routingcost", 1231 "hopcount" 1232 ], 1233 "cost_constraints": false 1234 } 1235 } 1237 7.7.2. Map Service 1239 The Map Service provides batch information to ALTO Clients in the 1240 form of two maps: a Network Map and Cost Map. 1242 An ALTO Server MUST support the Map Service and MUST implement all 1243 operations defined in this section. 1245 7.7.2.1. Network Map 1247 The full Network Map lists for each PID, the network locations 1248 (endpoints) within the PID. 1250 7.7.2.1.1. Request Syntax 1252 GET /map/core/pid/net HTTP/1.1 1253 Host: 1255 7.7.2.1.2. Response Syntax 1257 HTTP/1.1 200 1258 Content-Length: 1259 Content-Type: application/alto 1261 1263 where the ALTOResponse object has "type" member equal to the string 1264 "network_map" and "data" member of type RspNetworkMap: 1266 struct { 1267 CIDRString [pidname]<0..*>; 1268 ... 1269 } NetworkMapData; 1271 struct { 1272 JSONString map_vtag; 1273 NetworkMapData map; 1274 } RspNetworkMap; 1276 RspNetworkMap has members: 1278 o map_vtag: The Version Tag of the Network Map (Section 5.3) 1280 o map: The network map data itself. 1282 NetworkMapData is a JSON object with each member representing a 1283 single PID and its associated set of IP Prefixes (encoded as a string 1284 in CIDR notation). A member's name is a JSONString denoting the 1285 PID's name. 1287 7.7.2.1.3. Example 1289 GET /map/core/pid/net HTTP/1.1 1290 Host: alto.example.com:6671 1291 HTTP/1.1 200 OK 1292 Content-Length: [TODO] 1293 Content-Type: application/alto 1295 { 1296 "meta" : { 1297 "version" : 1, 1298 "status" : { 1299 "code" : 1 1300 } 1301 }, 1302 "type" : "network_map", 1303 "data" : { 1304 "map_vtag" : "1266506139", 1305 "map" : { 1306 "PID1" : [ 1307 "192.0.2.0/24", 1308 "198.51.100.0/25" 1309 ], 1310 "PID2" : [ 1311 "198.51.100.128/25" 1312 ], 1313 "PID3" : [ 1314 "0.0.0.0/0" 1315 ] 1316 } 1317 } 1318 } 1320 7.7.2.2. Cost Map 1322 The Map Service Cost Map query is a batch operation in which the ALTO 1323 Server returns the Path Cost for each pair of source/destination PID 1324 defined by the ALTO Server. 1326 The ALTO Server provides costs using the default Cost Type 1327 ('routingcost') and default Cost Mode ('numerical'). 1329 7.7.2.2.1. Request Syntax 1331 GET /map/core/pid/cost HTTP/1.1 1332 Host: 1334 7.7.2.2.2. Response Syntax 1336 HTTP/1.1 200 1337 Content-Length: 1338 Content-Type: application/alto 1340 1342 where the ALTOResponse object has "type" member equal to the string 1343 "cost_map" and "data" member of type RspCostMap: 1345 struct DstCosts { 1346 JSONNumber [dstname]; 1347 ... 1348 }; 1350 struct { 1351 DstCosts [srcname]<0..*>; 1352 ... 1353 } CostMapData; 1355 struct { 1356 JSONString map_vtag; 1357 JSONString cost_type; 1358 JSONString cost_mode; 1359 CostMapData map; 1360 } RspCostMap; 1362 RspCostMap has members: 1364 o map_vtag: The Version Tag of the Network Map used to generate the 1365 Cost Map (Section 5.3). 1367 o cost_type: Cost Type used in the map (Section 5.1.1) 1369 o cost_mode: Cost Mode used in the map (Section 5.1.2) 1371 o map: The cost map data itself. 1373 CostMapData is a JSON object with each member representing a single 1374 Source PID. For each Source PID, a DstCosts structure denotes the 1375 associated cost to a set of destination PIDs (Section 5.2). DstCosts 1376 has a single member for each destination PID in the map. 1378 7.7.2.2.3. Example 1380 GET /map/core/pid/cost HTTP/1.1 1381 Host: alto.example.com:6671 1382 HTTP/1.1 200 OK 1383 Content-Length: [TODO] 1384 Content-Type: application/alto 1386 { 1387 "meta" : { 1388 "version" : 1, 1389 "status" : { 1390 "code" : 1 1391 } 1392 }, 1393 "type" : "cost_map", 1394 "data" : { 1395 "map_vtag" : "1266506139", 1396 "cost_type" : "routingcost", 1397 "cost_mode" : "numerical", 1398 "map" : { 1399 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 1400 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 1401 "PID3": { "PID1": 20, "PID2": 15, "PID3": 1 } 1402 } 1403 } 1404 } 1406 7.7.3. Map Filtering Service 1408 The Map Filtering Service allows ALTO Clients to specify filtering 1409 criteria to return a subset of the full maps available in the Map 1410 Service. 1412 An ALTO Server MAY support the Map Filtering Service. If an ALTO 1413 Server supports the Map Filtering Service, all operations defined in 1414 this section MUST be implemented. 1416 7.7.3.1. Network Map 1418 ALTO Clients can query for a subset of the full network map (see 1419 Section 7.7.2.1). 1421 7.7.3.1.1. Request Syntax 1423 POST /map/filter/pid/net HTTP/1.1 1424 Host: 1425 Content-Length: 1427 1429 where: 1431 struct { 1432 JSONString pids<0..*>; 1433 } ReqNetworkMap; 1435 The Body of the request encodes an array of PIDs to be included in 1436 the resulting Network Map. If the list of PIDs is empty, the ALTO 1437 Server MUST interpret the list as if it contained a list of all 1438 currently-defined PIDs. 1440 7.7.3.1.2. Response Syntax 1442 The Response syntax is identical to that of the Map Service's Network 1443 Map Response (Section 7.7.2.1.2). 1445 The ALTO Server MUST only include PIDs in the Response that were 1446 specified (implicitly or explicitly) in the Request. If the Request 1447 contains a PID name that is not currently defined by the ALTO Server, 1448 the ALTO Server MUST behave as if the PID did not appear in the 1449 request. 1451 7.7.3.1.3. Example 1453 POST /map/filter/pid/net HTTP/1.1 1454 Host: alto.example.com:6671 1455 Content-Length: 1457 { 1458 pids: [ "PID1", "PID2" ] 1459 } 1461 HTTP/1.1 200 OK 1462 Content-Length: [TODO] 1463 Content-Type: application/alto 1465 { 1466 "meta" : { 1467 "version" : 1, 1468 "status" : { 1469 "code" : 1 1470 } 1471 }, 1472 "type" : "network_map", 1473 "data" : { 1474 "map_vtag" : "1266506139", 1475 "map" : { 1476 "PID1" : [ 1477 "192.0.2.0/24", 1478 "198.51.100.0/24", 1479 ], 1480 "PID2" : [ 1481 "198.51.100.128/24", 1482 ] 1483 } 1484 } 1485 } 1487 7.7.3.2. Cost Map 1489 ALTO Clients can query for the Cost Map (see Section 7.7.2.2) based 1490 on additional parameters. 1492 7.7.3.2.1. Request Syntax 1494 POST /map/filter/pid/cost? HTTP/1.1 1495 Host: 1497 1499 where: 1501 struct { 1502 JSONString srcs<0..*>; 1503 JSONString dsts<0..*>; 1504 } ReqCostMap; 1506 The Query String may contain the following parameters: 1508 o type: The requested Cost Type (Section 5.1.1). If not specified, 1509 the default value is "routingcost". This parameter MUST NOT be 1510 specified multiple times. 1512 o mode: The requested Cost mode (Section 5.1.2). If not specified, 1513 the default value is "numerical". This parameter MUST NOT be 1514 specified multiple times. 1516 o constraint: Defines a constraint on which elements of the Cost Map 1517 are returned. This parameter MUST NOT be used if the Server 1518 Capability Response (Section 7.7.1.2) indicates that constraint 1519 support is not available. A constraint contains two entities 1520 separated by whitespace (before URL encoding): (1) an operator 1521 either 'gt' for greater than , 'lt' for less than or 'eq' for 1522 equal to with 10 percent on either side, (2) a target numerical 1523 cost. The numerical cost is a number that MUST be defined in the 1524 units specified in the Server Capability Response. If multiple 1525 'constraint' parameters are specified, the ALTO Server assumes 1526 they are related to each other with a logical AND. If no 1527 'constraint' parameters are specified, then the ALTO Server 1528 returns the full Cost Map. 1530 The Request body MAY specify a list of Source PIDs, and a list of 1531 Destination PIDs. If a list is empty, it is interpreted by the ALTO 1532 Server as the full set of currently-defined PIDs. The ALTO Server 1533 returns costs between each pair of source/destination PID. If the 1534 Request body is empty, both lists are interpreted to be empty. 1536 7.7.3.2.2. Response Syntax 1538 The Response syntax is identical to that of the Map Service's Cost 1539 Map Response (Section 7.7.2.2.2). 1541 The Response MUST NOT contain any source/destination pair that was 1542 not indicated (implicitly or explicitly) in the Request. If the 1543 Request contains a PID name that is not currently defined by the ALTO 1544 Server, the ALTO Server MUST behave as if the PID did not appear in 1545 the request. 1547 7.7.3.2.3. Example 1549 POST /map/filter/pid/cost?type=hopcount HTTP/1.1 1550 Host: alto.example.com:6671 1552 { 1553 "srcs" : [ "PID1" ], 1554 "dsts" : [ "PID1", "PID2", "PID3" ] 1555 } 1557 HTTP/1.1 200 OK 1558 Content-Length: [TODO] 1559 Content-Type: application/alto 1561 { 1562 "meta" : { 1563 "version" : 1, 1564 "status" : { 1565 "code" : 1 1566 } 1567 }, 1568 "type" : "cost_map", 1569 "data" : { 1570 "map_vtag" : "1266506139", 1571 "cost_type" : "hopcount", 1572 "cost_mode" : "numerical", 1573 "map" : { 1574 "PID1": { "PID1": 0, "PID2": 1, "PID3": 2 } 1575 } 1576 } 1577 } 1579 7.7.4. Endpoint Property Service 1581 The Endpoint Property Lookup query allows an ALTO Client to lookup 1582 properties of Endpoints known to the ALTO Server. If the ALTO Server 1583 provides the Endpoint Property Service, the ALTO Server MUST define 1584 at least the 'pid' property for Endpoints. 1586 An ALTO Server MAY support the Endpoint Property Service. If an ALTO 1587 Server supports the Endpoint Property Service, all operations defined 1588 in this section MUST be implemented. 1590 7.7.4.1. Endpoint Property Lookup 1591 7.7.4.1.1. Request Syntax 1593 POST /endpoint/prop/lookup? HTTP/1.1 1594 Host: 1595 Content-Length: 1597 1599 where: 1601 struct { 1602 JSONString endpoints<0..*>; 1603 } ReqEndpointProp; 1605 The Query String may contain the following parameters: 1607 o prop: The requested property type. This parameter MUST be 1608 specified at least once, and MAY be specified multiple times 1609 (e.g., to query for multiple different properties at once). 1611 The body encodes a list of endpoints (IP addresses) as strings. 1613 An alternate syntax is supported for the case when properties are 1614 requested for a single endpoint: 1616 GET /endpoint/prop/? HTTP/1.1 1617 Host: 1619 where the Query String is the same as in the first form. 1621 7.7.4.1.2. Response Syntax 1623 HTTP/1.1 200 1624 Content-Length: 1625 Content-Type: application/alto 1627 1629 where the ALTOResponse object has "type" member equal to the string 1630 "endpoint_property" and "data" member of type RspEndpointProperty: 1632 struct { 1633 JSONString [propertyname]; 1634 ... 1635 } EndpointProps; 1637 struct { 1638 EndpointProps [endpointname]<0..*>; 1639 ... 1640 } RspEndpointProperty; 1642 RspEndpointProperty has one member for each endpoint indicated in the 1643 Request. The requested properties for each endpoint are encoded in a 1644 corresponding EndpointProps object, which encodes one name/value pair 1645 for each requested property. Note that property values are JSON 1646 Strings. If the ALTO Server does not define a requested property for 1647 a particular endpoint, then it MUST omit it from the Response for 1648 only that endpoint. 1650 7.7.4.1.3. Example 1652 POST /endpoint/prop/lookup?prop=pid HTTP/1.1 1653 Host: alto.example.com:6671 1654 Content-Length: [TODO] 1656 { 1657 "endpoints" : [ "192.0.2.34", "203.0.113.129" ] 1658 } 1660 HTTP/1.1 200 OK 1661 Content-Length: [TODO] 1662 Content-Type: application/alto 1664 { 1665 "meta" : { 1666 "version" : 1, 1667 "status" : { 1668 "code" : 1 1669 } 1670 }, 1671 "type" : "endpoint_property", 1672 "data": { 1673 "192.0.2.34" : { "pid": "PID1" }, 1674 "203.0.113.129" : { "pid": "PID3" } 1675 } 1676 } 1678 7.7.5. Endpoint Cost Service 1680 The Endpoint Cost Service allows ALTO Clients to directly supply 1681 endpoints to an ALTO Server. The ALTO Server replies with costs 1682 (numerical or ordinal) amongst the endpoints. 1684 In particular, this service allows lists of Endpoint addresses to be 1685 ranked (ordered) by an ALTO Server. 1687 An ALTO Server MAY support the Endpoint Cost Service. If an ALTO 1688 Server supports the Endpoint Cost Service, all operations defined in 1689 this section MUST be implemented. 1691 7.7.5.1. Endpoint Cost Lookup 1693 7.7.5.1.1. Request Syntax 1695 POST /endpoint/cost/lookup? HTTP/1.1 1696 Host: 1697 Content-Length: 1699 1701 The request body includes a list of source and destination endpoints 1702 that should be assigned a cost by the ALTO Server. The allowed Query 1703 String parameters are defined identically to Section 7.7.3.2. 1705 The request body MUST specify a list of source Endpoints, and a list 1706 of destination Endpoints, using an structure identical to 1707 Section 7.7.3.2 with the exception that identifiers are endpoints 1708 instead of PIDs. If the list of source Endpoints is empty (or it is 1709 not included), the ALTO Server MUST treat it as if it contained the 1710 Endpoint address of the requesting client. The list of destination 1711 Endpoints MUST NOT be empty. The ALTO Server returns costs between 1712 each pair of source/destination Endpoint. 1714 7.7.5.1.2. Response Syntax 1716 HTTP/1.1 200 1717 Content-Length: 1718 Content-Type: application/alto 1720 1722 where ALTOResponse is encoded identically to Section 7.7.2.2.2 with 1723 the following exceptions: 1725 o ALTO Response's "type" member must be equal to 1726 "endpoint_cost_map", 1728 o The "map_vtag" member of RspCostMap MUST be omitted, and 1730 o Identifiers refer to endpoints instead of PIDs. 1732 7.7.5.1.3. Example 1734 POST /endpoint/cost/lookup?mode=ordinal HTTP/1.1 1735 Host: alto.example.com:6671 1736 Content-Length: [TODO] 1738 { 1739 "src": [ "192.0.2.2" ], 1740 "dst": [ "192.0.2.89", "198.51.100.34", "203.0.113.45" ] 1741 } 1743 HTTP/1.1 200 OK 1744 Content-Length: [TODO] 1745 Content-Type: application/alto 1747 { 1748 "meta" : { 1749 "version" : 1, 1750 "status" : { 1751 "code" : 1 1752 } 1753 }, 1754 "type" : "endpoint_cost_map", 1755 "data" : { 1756 "cost-type" : "routingcost", 1757 "cost-mode" : "ordinal", 1758 "map" : { 1759 "192.0.2.2": { 1760 "192.0.2.89" : 1, 1761 "198.51.100.34" : 2, 1762 "203.0.113.45" : 3 1763 } 1764 } 1765 } 1766 } 1768 7.8. Redistributable Responses 1770 An ALTO Server MAY indicate that a response is suitable for 1771 redistribution by including the "redistribution" member in the 1772 RspMetaData JSON object of an ALTO Response message. This additional 1773 member has type RspRedistInfo: 1775 struct { 1776 JSONString service_id; 1777 JSONString request_uri; 1778 JSONValue request_body; 1779 JSONString expires; 1780 } RspRedistInfo; 1782 If an ALTO Server indicates the that the response is redistributable, 1783 the Response message MUST satisfy all requirements in this section. 1785 The ALTO Server generating the response indicates its own unique 1786 identifier (Service ID) and any input parameters used to generate the 1787 response. This allows ALTO Clients to which the information is 1788 distributed to understand the context of the query and interpret the 1789 results. This information is encoded in the RspRedistInfo JSON 1790 Object. 1792 7.8.1. Server Capability Requirements 1794 The 'service_id' and 'certificate' fields of the Server Capability 1795 response are REQUIRED if an ALTO Server generates redistributable 1796 responses. 1798 7.8.2. Service ID 1800 For scalability and fault tolerance, multiple ALTO Servers may be 1801 deployed to serve equivalent ALTO Information. In such a scenario, 1802 ALTO Responses from any such redundant server should be seen as 1803 equivalent for the purposes of redistribution. For example, if two 1804 ALTO Servers A and B are deployed by the service provider to 1805 distribute equivalent ALTO Information, then clients contacting 1806 Server A should be able to redistribute ALTO Responses to Server B. 1808 One technique for doing this would be to rely on the server's DNS 1809 name. However, such an approach would mandate that all ALTO Servers 1810 resolved by a particular DNS name would need to provide equivalent 1811 ALTO information, which may be unneccessarily restrictive. Another 1812 technique would be to rely on the server's IP adddress. However, 1813 this suffers similar problems as the DNS name in deployment scenarios 1814 using IP Anycast. 1816 To avoid such restrictions, the ALTO Protocol allows an ALTO Service 1817 Provider to explicitly denote ALTO Servers that provide equivalent 1818 ALTO Information by giving them identical Service IDs. 1820 If an ALTO Server generates redistributable responses, the Server 1821 Capability response's 'service_id' field MUST be set to the ALTO 1822 Server's Service ID. 1824 To help prevent ALTO Servers from mistakenly claiming to distribute 1825 equivalent ALTO Information, ALTO Server Implementations SHOULD by 1826 default generate a new UUID at installation time. The default, 1827 generated UUID may be overridden by the service provider. 1829 7.8.3. Server and Request Parameters 1831 This section defines the members of the RspRedistInfo JSON object. 1833 The 'service_id' member is REQUIRED and MUST have a value equal to 1834 the ALTO Server's Service ID. 1836 The 'request_uri' member is REQUIRED and MUST specify the HTTP 1837 Request-URI that was passed in the HTTP Request. 1839 If the HTTP Request body was non-empty, the 'request_body' member 1840 MUST specify full JSON value passed in the HTTP Request (note that 1841 whitespace may differ, as long as the JSON Value is identical). If 1842 the HTTP Request was empty, then the 'request_body' MUST NOT be 1843 included. 1845 Note that information about ALTO Client performing the Request and 1846 any HTTP Headers passed in the request are not included. If any such 1847 information or headers influence the response generated by the ALTO 1848 Server, the response SHOULD NOT be indicated as redistributable. 1850 7.8.4. Expiration Time 1852 ALTO Responses marked as redistributable SHOULD indicate a time after 1853 which the information is considered stale and should be refreshed 1854 from the ALTO Server (or possibly another ALTO Client). 1856 The 'expires' element is RECOMMENDED and, if present, MUST specify a 1857 time in UTC formatted according to [6]. 1859 If an expiration time is present, the ALTO Server SHOULD ensure that 1860 it is reasonably consistent with the expiration time that would be 1861 computed by HTTP header fields. If the expiration time in the 1862 'expires' element is earlier, some ALTO Clients may refresh data from 1863 the ALTO Server earlier than expected. If the expiration time 1864 included in the response body is later, some ALTO Clients may refresh 1865 the data later than expected. 1867 7.8.5. Signature 1869 ALTO Responses marked as redistributable MUST include a signature 1870 used to assert that the ALTO Server Provider generated the ALTO 1871 Information. 1873 Verification of the signature requires the ALTO Client to retrieve 1874 the ALTO Server's public key. There are multiple possibilities to 1875 retrieve it: 1877 o SSL/TLS connection with the ALTO Server: The public key algorithm 1878 and public key may be retrieved from the ALTO Server's X.509 1879 Certificate used on an HTTPS connection between the ALTO Server 1880 and ALTO Client. 1882 o Included in ALTO Server's Server Capability Response: If the ALTO 1883 Client requests from the ALTO Server over a non SSL/TLS 1884 connection, an X.509 certificate (including the public key and 1885 public key algorithm) can be included in the Server Capability 1886 Response. 1888 To reduce requirements on the underlying transport (i.e., requiring 1889 SSL/TLS), the ALTO Protocol uses the latter option. This 1890 specification makes the following requirements of the X.509 1891 certificates: 1893 o The certificate's corresponding private key MUST be used to sign 1894 redistributable responses. 1896 o The certificate for each ALTO Server with an identical Service ID 1897 MUST be identical. 1899 ALTO Clients SHOULD verify that the certificate satisfies any local 1900 policies (e.g., Issuer, expiration date, etc). 1902 The ALTO Server may include the Hash Algorithm, Signature Algorithm, 1903 and Signature in either HTTP Headers or Trailers. Headers may be 1904 useful if Responses are pre-generated, while Trailers may be useful 1905 if Responses are dynamically generated (e.g., to avoid buffering 1906 large responses in memory while the hash value is computed). 1908 The following HTTP Headers (the ALTO Server MAY specify them as HTTP 1909 Trailers) MUST be used to encode the Signature parameters for 1910 redistributable ALTO Responses: 1912 ALTO-HashAlgorithm: 1913 ALTO-SignatureAlgorithm: 1914 ALTO-SignatureDigest: 1916 where and are an integer values 1917 from the IANA TLS HashAlgorithm and SignatureAlgorithm registries, 1918 and is the corresponding PEM-encoded signature. 1920 ALTO Clients SHOULD verify the signature on any ALTO information 1921 received via redistribution before adjusting application behavior 1922 based on it. 1924 If an ALTO Client consumes ALTO Information from multiple ALTO 1925 Servers, it can locally maintain a map of the corresponding 1926 certificate for each ALTO Server. Upon receiving redistributed 1927 information, it may lookup the appropriate certificate to use for 1928 signature verification based on the Service ID contained in the 1929 redistributed ALTO Response. Note that verifying the signature also 1930 protects against hijacking of a Service ID as long as the initial 1931 certificate retrieval (via the Server Capability Response) is secure 1932 from hijacking. 1934 ALTO Clients SHOULD pass the ALTO Server Certificate, Signature, and 1935 Signature Algorithm along with the body of the ALTO Response. The 1936 mechanism for redistributing such information is not specified by the 1937 ALTO Protocol, but one possibility is to add additional messages or 1938 fields to the application's native protocol. 1940 8. Use Cases 1942 The sections below depict typical use cases. 1944 8.1. ALTO Client Embedded in P2P Tracker 1946 Many P2P currently-deployed P2P systems use a Tracker to manage 1947 swarms and perform peer selection. P2P trackers may currently use a 1948 variety of information to perform peer selection to meet application- 1949 specific goals. By acting as an ALTO Client, an P2P tracker can use 1950 ALTO information as an additional information source to enable more 1951 network-efficient traffic patterns and improve application 1952 performance. 1954 A particular requirement of many P2P trackers is that they must 1955 handle a large number of P2P clients. A P2P tracker can obtain and 1956 locally store ALTO information (the Network Map and Cost Map) from 1957 the ISPs containing the P2P clients, and benefit from the same 1958 aggregation of network locations done by ALTO Servers. 1960 .---------. (1) Get Network Map .---------------. 1961 | | <----------------------> | | 1962 | ALTO | | P2P Tracker | 1963 | Server | (2) Get Cost Map | (ALTO Client) | 1964 | | <----------------------> | | 1965 `---------' `---------------' 1966 ^ | 1967 (3) Get Peers | | (4) Selected Peer 1968 | v List 1969 .---------. .-----------. 1970 | Peer 1 | <-------------- | P2P | 1971 `---------' | Client | 1972 . (5) Connect to `-----------' 1973 . Selected Peers / 1974 .---------. / 1975 | Peer 50 | <------------------ 1976 `---------' 1978 Figure 4: ALTO Client Embedded in P2P Tracker 1980 Figure 4 shows an example use case where a P2P tracker is an ALTO 1981 Client and applies ALTO information when selecting peers for its P2P 1982 clients. The example proceeds as follows: 1984 1. The P2P Tracker requests the Network Map covering all PIDs from 1985 the ALTO Server using the Network Map query. The Network Map 1986 includes the IP prefixes contained in each PID, allowing the P2P 1987 tracker to locally map P2P clients into a PIDs. 1989 2. The P2P Tracker requests the Cost Map amongst all PIDs from the 1990 ALTO Server. 1992 3. A P2P Client joins the swarm, and requests a peer list from the 1993 P2P Tracker. 1995 4. The P2P Tracker returns a peer list to the P2P client. The 1996 returned peer list is computed based on the Network Map and Cost 1997 Map returned by the ALTO Server, and possibly other information 1998 sources. Note that it is possible that a tracker may use only 1999 the Network Map to implement hierarchical peer selection by 2000 preferring peers within the same PID and ISP. 2002 5. The P2P Client connects to the selected peers. 2004 Note that the P2P tracker may provide peer lists to P2P clients 2005 distributed across multiple ISPs. In such a case, the P2P tracker 2006 may communicate with multiple ALTO Servers. 2008 8.2. ALTO Client Embedded in P2P Client: Numerical Costs 2010 P2P clients may also utilize ALTO information themselves when 2011 selecting from available peers. It is important to note that not all 2012 P2P systems use a P2P tracker for peer discovery and selection. 2013 Furthermore, even when a P2P tracker is used, the P2P clients may 2014 rely on other sources, such as peer exchange and DHTs, to discover 2015 peers. 2017 When an P2P Client uses ALTO information, it typically queries only 2018 the ALTO Server servicing its own ISP. The my-Internet view provided 2019 by its ISP's ALTO Server can include preferences to all potential 2020 peers. 2022 .---------. (1) Get Network Map .---------------. 2023 | | <----------------------> | | 2024 | ALTO | | P2P Client | 2025 | Server | (2) Get Cost Map | (ALTO Client) | 2026 | | <----------------------> | | .---------. 2027 `---------' `---------------' <- | P2P | 2028 .---------. / | ^ ^ | Tracker | 2029 | Peer 1 | <-------------- | | \ `---------' 2030 `---------' | (3) Gather Peers 2031 . (4) Select Peers | | \ 2032 . and Connect / .--------. .--------. 2033 .---------. / | P2P | | DHT | 2034 | Peer 50 | <---------------- | Client | `--------' 2035 `---------' | (PEX) | 2036 `--------' 2038 Figure 5: ALTO Client Embedded in P2P Client 2040 Figure 5 shows an example use case where a P2P Client locally applies 2041 ALTO information to select peers. The use case proceeds as follows: 2043 1. The P2P Client requests the Network Map covering all PIDs from 2044 the ALTO Server servicing its own ISP. 2046 2. The P2P Client requests the Cost Map amongst all PIDs from the 2047 ALTO Server. The Cost Map by default specifies numerical costs. 2049 3. The P2P Client discovers peers from sources such as Peer Exchange 2050 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2051 P2P Trackers. 2053 4. The P2P Client uses ALTO information as part of the algorithm for 2054 selecting new peers, and connects to the selected peers. 2056 8.3. ALTO Client Embedded in P2P Client: Ranking 2058 It is also possible for a P2P Client to offload the selection and 2059 ranking process to an ALTO Server. In this use case, the ALTO Client 2060 gathers a list of known peers in the swarm, and asks the ALTO Server 2061 to rank them. 2063 As in the use case using numerical costs, the P2P Client typically 2064 only queries the ALTO Server servicing its own ISP. 2066 .---------. .---------------. 2067 | | | | 2068 | ALTO | (2) Get Endpoint Ranking | P2P Client | 2069 | Server | <----------------------> | (ALTO Client) | 2070 | | | | .---------. 2071 `---------' `---------------' <- | P2P | 2072 .---------. / | ^ ^ | Tracker | 2073 | Peer 1 | <-------------- | | \ `---------' 2074 `---------' | (1) Gather Peers 2075 . (3) Connect to | | \ 2076 . Selected Peers / .--------. .--------. 2077 .---------. / | P2P | | DHT | 2078 | Peer 50 | <---------------- | Client | `--------' 2079 `---------' | (PEX) | 2080 `--------' 2082 Figure 6: ALTO Client Embedded in P2P Client: Ranking 2084 Figure 6 shows an example of this scenario. The use case proceeds as 2085 follows: 2087 1. The P2P Client discovers peers from sources such as Peer Exchange 2088 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2089 P2P Trackers. 2091 2. The P2P Client queries the ALTO Server's Ranking Service, 2092 including discovered peers as the set of Destination Endpoints, 2093 and indicates the 'ordinal' Cost Mode. The response indicates 2094 the ranking of the candidate peers. 2096 3. The P2P Client connects to the peers in the order specified in 2097 the ranking. 2099 9. Discussions 2100 9.1. Discovery 2102 The particular mechanism by which an ALTO Client discovers its ALTO 2103 Server is an important component to the ALTO architecture and 2104 numerous techniques have been discussed [19]. However, the discovery 2105 mechanism is out of scope for this document. This document assumes 2106 that an ALTO Client can discover an appropriate ALTO Server. Note 2107 that the Server List query in the Server Information Service is 2108 intended to aid an ALTO Client in selecting an available ALTO Server 2109 with the capabilities necessary for its application. 2111 Some ISPs have proposed the possibility of delegation, in which an 2112 ISP provides information for customer networks which do not wish to 2113 run ALTO Servers themselves. A consideration for delegation is that 2114 customer networks may wish to explicitly configure such delegation. 2116 9.2. Hosts with Multiple Endpoint Addresses 2118 In practical deployments, especially during the transition from IPv4 2119 to IPv6, a particular host may be reachable using multiple addresses. 2120 Furthermore, the particular network path followed when sending 2121 packets to the host may differ based on the address that is used. 2122 Network providers may perfer one path over another (e.g., one path my 2123 have a NAT64 middlebox). An additional consideration may be how to 2124 handle private address spaces (e.g., behind carrier-grade NATs). 2126 Note that to support such behavior, Endpoints must be associated with 2127 a particular address type (e.g., IPv4 or IPv6). One simple 2128 possibility may be to prefix each endpoint address with its type 2129 (e.g., "ipv4:198.51.100.128/25"). However, we may want to discuss if 2130 a more efficient/compact encoding is possible in some cases (e.g., 2131 all addresses in the same PID are IPv6). 2133 There are limitations as to what information ALTO can provide in this 2134 regard. In particular, a particular ALTO Service provider may not be 2135 able to determine if connectivity with a particular endhost will 2136 succeed over IPv4 or IPv6, as this may depend upon information 2137 unknown to the ISP such as particular application implementations. 2139 Exploration of these issues is being considered in a separate 2140 Internet Draft [20]. Once a suitable solution emerges, it will be 2141 included in this document. 2143 9.3. Network Address Translation Considerations 2145 At this day and age of NAT v4<->v4, v4<->v6 [21], and possibly 2146 v6<->v6[22], a protocol should strive to be NAT friendly and minimize 2147 carrying IP addresses in the payload, or provide a mode of operation 2148 where the source IP address provide the information necessary to the 2149 server. 2151 The protocol specified in this document provides a mode of operation 2152 where the source network location is computed by the ALTO Server (via 2153 the Endpoint Property Lookup interface) from the source IP address 2154 found in the ALTO Client query packets. This is similar to how some 2155 P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS 2156 Protocol" in [23]) operate. 2158 The ALTO client SHOULD use the Session Traversal Utilities for NAT 2159 (STUN) [7] to determine a public IP address to use as a source 2160 Endpoint address. If using this method, the host MUST use the 2161 "Binding Request" message and the resulting "XOR-MAPPED-ADDRESS" 2162 parameter that is returned in the response. Using STUN requires 2163 cooperation from a publicly accessible STUN server. Thus, the ALTO 2164 client also requires configuration information that identifies the 2165 STUN server, or a domain name that can be used for STUN server 2166 discovery. To be selected for this purpose, the STUN server needs to 2167 provide the public reflexive transport address of the host. 2169 9.4. Mapping IPs to ASNs 2171 It may be desired for the ALTO Protocol to provide ALTO information 2172 including ASNs. Thus, ALTO Clients may need to identify the ASN for 2173 a Resource Provider to determine the cost to that Resource Provider. 2175 Applications can already map IPs to ASNs using information from a BGP 2176 Looking Glass. To do so, they must download a file of about 1.5MB 2177 when compressed (as of October 2008, with all information not needed 2178 for IP to ASN mapping removed) and periodically (perhaps monthly) 2179 refresh it. 2181 Alternatively, the Network Map query in the Map Filtering Service 2182 defined in this document could be extended to map ASNs into a set of 2183 IP prefixes. The mappings provided by the ISP would be both smaller 2184 and more authoritative. 2186 For simplicity of implementation, it's highly desirable that clients 2187 only have to implement exactly one mechanism of mapping IPs to ASNs. 2189 9.5. Endpoint and Path Properties 2191 An ALTO Server could make available many properties about Endpoints 2192 beyond their network location or grouping. For example, connection 2193 type, geographical location, and others may be useful to 2194 applications. The current draft focuses on network location and 2195 grouping, but the protocol may be extended to handle other Endpoint 2196 properties. 2198 9.6. P2P Peer Selection 2200 This section discusses possible approaches to peer selection using 2201 ALTO information (Network Location Identifiers and associated Costs) 2202 from an ALTO Server. Specifically, the application must select which 2203 peers to use based on this and other sources of information. With 2204 this in mind, the usage of ALTO Costs is intentionally flexible, 2205 because: 2207 Different applications may use the information differently. For 2208 example, an application that connects to just one address may have 2209 a different algorithm for selecting it than an application that 2210 connects to many. 2212 Though initial experiments have been conducted [24], more 2213 investigation is needed to identify other methods. 2215 In addition, the application might account for robustness, perhaps 2216 using randomized exploration to determine if it performs better 2217 without ALTO information. 2219 9.6.1. Client-based Peer Selection 2221 One possibility is for peer selection using ALTO costs to be done 2222 entirely by a P2P client. The following are some techniques have 2223 been proposed and/or used: 2225 o Prefer network locations with lower ordinal rankings (i.e., higher 2226 priority) [14] [11]. 2228 o Optimistically unchoking low-cost peers with higher probability 2229 [11]. 2231 9.6.2. Server-based Peer Selection 2233 Another possibility is for ALTO costs to be used by an Application 2234 Tracker (e.g., BitTorrent Tracker) when returning peer lists. The 2235 following are techniques that have been proposed and/or used: 2237 o Using bandwidth matching (e.g., at an Application Tracker) and 2238 choosing solution (within bound of optimal) with minimal network 2239 cost [24]. 2241 9.6.3. Protocol Extension: 'Location-Only' Peer Selection 2243 This section discusses a promising peer selection algorithm that was 2244 recently used in experiments with a P2P live streaming application. 2245 However, to support it, a small protocol extension would be required, 2246 but the protocol extension is general and may be applicable in other 2247 contexts as well. Feedback from the WG is greatly encouraged. 2249 Experiments in the context of live streaming have shown significant 2250 benefits of a simple "location-only" algorithm that primarily makes 2251 use of the Network Map. A benefit of this algorithm is that it can 2252 provide a simple integration path for applications wishing to utilize 2253 ALTO. 2255 In particular, the algorithm proceeds as follows to select an ordered 2256 list of peers for a particular incoming (or existing peer): 2258 1. Insert into the result list a number (up to a threshold) of peers 2259 from the same PID as the incoming peer. 2261 2. Insert into the result list a number (up to a threshold) of peers 2262 from the same ISP as the incoming peer. 2264 3. Insert into the result list a number (up to a threshold) of peers 2265 from different ISPs than the incoming peer. 2267 In the experiments, this algorithm was implemented at a tracker and 2268 executed for peer selection when peers initially join and when 2269 requesting new peers. 2271 This algorithm makes two assumptions about the preferences 2272 communicated by the Network Map: 2274 o The ISP prefers peers within the same PID to peer with each other 2275 (see Section 4); and 2277 o The ALTO Server can indicate which PIDs describe network locations 2278 within the same ISP. 2280 The second assumption is currently not satisfied by the ALTO 2281 protocol, but could be accomplished by including a PID attribute. 2282 For example, a boolean attribute name "Intra-Region" with value 2283 'true' could be added to PIDs within the ALTO Server's Network 2284 Region. 2286 10. IANA Considerations 2288 This document request the registration of a new media type: 2289 "application/alto" 2291 11. Security Considerations 2293 11.1. Privacy Considerations for ISPs 2295 ISPs must be cognizant of the network topology and provisioning 2296 information provided through ALTO Interfaces. ISPs should evaluate 2297 how much information is revealed and the associated risks. On the 2298 one hand, providing overly fine-grained information may make it 2299 easier for attackers to infer network topology. In particular, 2300 attackers may try to infer details regarding ISPs' operational 2301 policies, inter-ISP business relationships, etc. by intentionally 2302 posting a multitude of selective queries to an ALTO server (and 2303 carefully analyzing the responses). Such sophisticated attacks may 2304 reveal more information than an ISP hosting an ALTO server intends to 2305 disclose. On the other hand, revealing overly coarse-grained 2306 information may not provide benefits to network efficiency or 2307 performance improvements to ALTO Clients. 2309 11.2. ALTO Clients 2311 Applications using the information must be cognizant of the 2312 possibility that the information is malformed or incorrect. Even if 2313 an ALTO Server has been properly authenticated by the ALTO Client, 2314 the information provided may be malicious because the ALTO Server and 2315 its credentials have been compromised (e.g., through malware). Other 2316 considerations (e.g., relating to application performance) can be 2317 found in Section 6 of [15]. 2319 ALTO Clients should also be cognizant of revealing Network Location 2320 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, 2321 as doing so may allow the ALTO Server to infer communication 2322 patterns. One possibility is for the ALTO Client to only rely on 2323 Network Map for PIDs and Cost Map amongst PIDs to avoid passing IP 2324 addresses of their peers to the ALTO Server. 2326 In addition, ALTO clients should be cautious not to unintentionally 2327 or indirectly disclose the resource identifier (of which they try to 2328 improve the retrieval through ALTO-guidance), e.g., the name/ 2329 identifier of a certain video stream in P2P live streaming, to the 2330 ALTO server. Note that the ALTO Protocol specified in this document 2331 does not explicitly reveal any resource identifier to the ALTO 2332 Server. However, for instance, depending on the popularity or other 2333 specifics (such as language) of the resource, an ALTO server could 2334 potentially deduce information about the desired resource from 2335 information such as the Network Locations the client sends as part of 2336 its request to the server. 2338 11.3. Authentication, Integrity Protection, and Encryption 2340 SSL/TLS can provide encryption of transmitted messages as well as 2341 authentication of the ALTO Client and Server. HTTP Basic or Digest 2342 authentication can provide authentication of the client (combined 2343 with SSL/TLS, it can additionally provide encryption and 2344 authentication of the server). 2346 An ALTO Server may optionally use authentication (and potentially 2347 encryption) to protect ALTO information it provides. This can be 2348 achieved by digitally signing a hash of the ALTO information itself 2349 and attaching the signature to the ALTO information. There may be 2350 special use cases where encryption of ALTO information is desirable. 2351 In most cases, however, information sent out by an ALTO Server is 2352 most likely to be regarded as non-confidential information. 2354 ISPs should be cognizant that encryption only protects ALTO 2355 information until it is decrypted by the intended ALTO Client. 2356 Digital Rights Management (DRM) techniques and legal agreements 2357 protecting ALTO information are outside of the scope of this 2358 document. 2360 11.4. ALTO Information Redistribution 2362 It is possible for applications to redistribute ALTO information to 2363 improve scalability. Even with such a distribution scheme, ALTO 2364 Clients obtaining ALTO information must be able to validate the 2365 received ALTO information to ensure that it was actually generated by 2366 the correct ALTO Server. Further, to prevent the ALTO Server from 2367 being a target of attack, the verification scheme must not require 2368 ALTO Clients to contact the ALTO Server to validate every set of 2369 information. Note that in any case, contacting the originating ALTO 2370 server for information validation would undermine the intended effect 2371 of redistribution and is therefore not desirable. 2373 Note that the redistribution scheme must additionally handle details 2374 such as ensuring ALTO Clients retrieve ALTO information from the 2375 correct ALTO Server. See [18] for further discussion. Details of a 2376 particular redistribution scheme are outside the scope of this 2377 document. 2379 To fulfill these requirements, ALTO Information meant to be 2380 redistributable contains a digital signature which includes a hash of 2381 the ALTO information signed by the ALTO Server with its private key. 2382 The corresponding public key should either be part of the ALTO 2383 information itself, or it could be included in the server capability 2384 response. The public key SHOULD include the hostname of the ALTO 2385 Server and it SHOULD be signed by a trusted authority (i.e., in a 2386 certificate). This enables an ALTO client retrieving redistributed 2387 ALTO information to verify the correctness of the ALTO Server's 2388 signature, given that it trusts the authority which signed the ALTO 2389 Server's certificate. Note that in some cases this requires that the 2390 retrieving ALTO Client must be able to derive a transitive 2391 certificate chain (including a Root-CA) to the trusted authority 2392 which signed the ALTO Server's certificate. This requirement may not 2393 be possible to fulfill between every ALTO Client / ALTO Server 2394 combination on the Internet due to the lack of a world-wide public 2395 key infrastructure. 2397 11.5. Denial of Service 2399 ISPs should be cognizant of the workload at the ALTO Server generated 2400 by certain ALTO Queries, such as certain queries to the Map Filtering 2401 Service and Ranking Service. In particular, queries which can be 2402 generated with low effort but result in expensive workloads at the 2403 ALTO Server could be exploited for Denial-of-Service attacks. For 2404 instance, a simple ALTO query with n Source Network Locations and m 2405 Destination Network Locations can be generated fairly easily but 2406 results in the computation of n*m Path Costs between pairs by the 2407 ALTO Server (see Section 5.2). One way to limit Denial-of-Service 2408 attacks is to employ access control to the ALTO server. Another 2409 possible mechanism for an ALTO Server to protect itself against a 2410 multitude of computationally expensive bogus requests is to demand 2411 that each ALTO Client to solve a computational puzzle first before 2412 allocating resources for answering a request (see, e.g., [25]). The 2413 current specification does not use such computational puzzles, and 2414 discussion regarding tradeoffs of such an approach would be needed 2415 before including such a technique in the ALTO Protocol. 2417 ISPs should also leverage the fact that the the Map Service allows 2418 ALTO Servers to pre-generate maps that can be useful to many ALTO 2419 Clients. 2421 11.6. ALTO Server Access Control 2423 In order to limit access to an ALTO server (e.g., for an ISP to only 2424 allow its users to access its ALTO server, or to prevent Denial-of- 2425 Service attacks by arbitrary hosts from the Internet), an ALTO server 2426 may employ access control policies. Depending on the use-case and 2427 scenario, an ALTO server may restrict access to its services more 2428 strictly or rather openly (see [26] for a more detailed discussion on 2429 this issue). 2431 12. References 2433 12.1. Normative References 2435 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2436 Levels", BCP 14, RFC 2119, March 1997. 2438 [2] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 2439 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 2441 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 2442 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 2443 HTTP/1.1", RFC 2616, June 1999. 2445 [4] Crockford, D., "The application/json Media Type for JavaScript 2446 Object Notation (JSON)", RFC 4627, July 2006. 2448 [5] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 2449 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 2451 [6] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: 2452 Timestamps", RFC 3339, July 2002. 2454 [7] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 2455 Traversal Utilities for (NAT) (STUN)", 2456 draft-ietf-behave-rfc3489bis-18 (work in progress), July 2008. 2458 12.2. Informative References 2460 [8] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, 2461 "Application-Layer Traffic Optimization (ALTO) Requirements", 2462 draft-kiesel-alto-reqs-01 (work in progress), November 2008. 2464 [9] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, "P4P: 2465 Provider Portal for P2P Applications", draft-p4p-framework-00 2466 (work in progress), November 2008. 2468 [10] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, "P4P 2469 Protocol Specification", draft-wang-alto-p4p-specification-00 2470 (work in progress), March 2009. 2472 [11] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 2473 Export Service", draft-shalunov-alto-infoexport-00 (work in 2474 progress), October 2008. 2476 [12] Das, S. and V. Narayanan, "A Client to Service Query Response 2477 Protocol for ALTO", draft-saumitra-alto-queryresponse-00 (work 2478 in progress), March 2009. 2480 [13] Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 2481 Dimensional Peer Selection Problem", 2482 draft-saumitra-alto-multi-ps-00 (work in progress), 2483 October 2008. 2485 [14] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 2486 Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00 2487 (work in progress), March 2009. 2489 [15] Seedorf, J. and E. Burger, "Application-Layer Traffic 2490 Optimization (ALTO) Problem Statement", RFC 5693, October 2009. 2492 [16] Yang, Y., Popkin, L., Penno, R., and S. Shalunov, "An 2493 Architecture of ALTO for P2P Applications", 2494 draft-yang-alto-architecture-00 (work in progress), March 2009. 2496 [17] Zyp, K., "A JSON Media Type for Describing the Structure and 2497 Meaning of JSON Documents", draft-zyp-json-schema-02 (work in 2498 progress), March 2010. 2500 [18] Yingjie, G., Alimi, R., and R. Even, "ALTO Information 2501 Redistribution", draft-gu-alto-redistribution-03 (work in 2502 progress), July 2010. 2504 [19] Song, H., Even, R., Pascual, V., and Y. Zhang, "Application- 2505 Layer Traffic Optimization (ALTO): Discover ALTO Servers", 2506 draft-song-alto-server-discovery-00 (work in progress), 2507 March 2009. 2509 [20] Penno, R. and J. Medved, "ALTO and IPv4/IPv6 Co-existence and 2510 Transition", draft-penno-alto-ipv4v6-00 (work in progress), 2511 June 2010. 2513 [21] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 2514 Translation", draft-baker-behave-v4v6-framework-02 (work in 2515 progress), February 2009. 2517 [22] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address 2518 Translation (NAT66)", draft-mrw-behave-nat66-02 (work in 2519 progress), March 2009. 2521 [23] "Bittorrent Protocol Specification v1.0", 2522 http://wiki.theory.org/BitTorrentSpecification, 2009. 2524 [24] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A. 2525 Silberschatz., "P4P: Provider Portal for (P2P) Applications", 2526 In SIGCOMM 2008. 2528 [25] Jennings, C., "Computational Puzzles for SPAM Reduction in 2529 SIP", draft-jennings-sip-hashcash-06 (work in progress), 2530 July 2007. 2532 [26] Stiemerling, M. and S. Kiesel, "ALTO Deployment 2533 Considerations", draft-stiemerling-alto-deployments-04 (work in 2534 progress), July 2010. 2536 Appendix A. Acknowledgments 2538 Thank you to Jan Seedorf for contributions to the Security 2539 Considerations section. We would like to thank Yingjie Gu and Roni 2540 Even for helpful input and design concerning ALTO Information 2541 redistribution. 2543 We would like to thank the following people whose input and 2544 involvement was indispensable in achieving this merged proposal: 2546 Obi Akonjang (DT Labs/TU Berlin), 2548 Saumitra M. Das (Qualcomm Inc.), 2550 Syon Ding (China Telecom), 2552 Doug Pasko (Verizon), 2554 Laird Popkin (Pando Networks), 2556 Satish Raghunath (Juniper Networks), 2558 Albert Tian (Ericsson/Redback), 2560 Yu-Shun Wang (Microsoft), 2562 David Zhang (PPLive), 2564 Yunfei Zhang (China Mobile). 2566 We would also like to thank the following additional people who were 2567 involved in the projects that contributed to this merged document: 2568 Alex Gerber (AT&T), Chris Griffiths (Comcast), Ramit Hora (Pando 2569 Networks), Arvind Krishnamurthy (University of Washington), Marty 2570 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 2571 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T), 2572 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 2573 Damien Saucez (UCL) Thomas Scholl (AT&T), Emilio Sepulveda 2574 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 2575 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 2576 (Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia 2577 Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University), 2578 Haiyong Xie (Yale University). 2580 Appendix B. Authors 2582 [[Comment.2: RFC Editor: Please move information in this section to 2583 the Authors' Addresses section at publication time.]] 2585 Stefano Previdi 2586 Cisco 2588 Email: sprevidi@cisco.com 2590 Stanislav Shalunov 2591 BitTorrent 2593 Email: shalunov@bittorrent.com 2595 Richard Woundy 2596 Comcast 2598 Richard_Woundy@cable.comcast.com 2600 Authors' Addresses 2602 Richard Alimi (editor) 2603 Yale University 2605 Email: richard.alimi@yale.edu 2606 Reinaldo Penno (editor) 2607 Juniper Networks 2608 1194 N Mathilda Avenue 2609 Sunnyvale, CA 2610 USA 2612 Email: rpenno@juniper.net 2614 Y. Richard Yang (editor) 2615 Yale University 2617 Email: yry@cs.yale.edu