idnits 2.17.1 draft-ietf-alto-protocol-09.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 945 has weird spacing: '...etaData meta...' == Line 951 has weird spacing: '... meta meta-...' == Line 953 has weird spacing: '... data the d...' == Line 1271 has weird spacing: '...NString uri;...' == Line 1272 has weird spacing: '...NString medi...' == (12 more instances...) -- The document date (June 27, 2011) is 4686 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) == Missing Reference: 'ATTP' is mentioned on line 221, but not defined == Missing Reference: 'InfoResourceDataType' is mentioned on line 946, but not defined == Missing Reference: 'OPTIONAL' is mentioned on line 2151, but not defined == Missing Reference: 'TODO' is mentioned on line 2242, but not defined == Missing Reference: 'PIDName' is mentioned on line 1701, but not defined == Missing Reference: 'EndpointProperty' is mentioned on line 2057, but not defined == Missing Reference: 'TypedEndpointAddr' is mentioned on line 2188, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.2008' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-08 == Outdated reference: A later version (-10) exists of draft-ietf-alto-server-discovery-00 Summary: 6 errors (**), 0 flaws (~~), 16 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG R. Alimi, Ed. 3 Internet-Draft Google 4 Intended status: Standards Track R. Penno, Ed. 5 Expires: December 29, 2011 Juniper Networks 6 Y. Yang, Ed. 7 Yale University 8 June 27, 2011 10 ALTO Protocol 11 draft-ietf-alto-protocol-09.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 [RFC2119]. 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 December 29, 2011. 63 Copyright Notice 65 Copyright (c) 2011 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 1.1. Background and Problem Statement . . . . . . . . . . . . . 6 82 1.2. Design History and Merged Proposals . . . . . . . . . . . 6 83 1.3. Solution Benefits . . . . . . . . . . . . . . . . . . . . 6 84 1.3.1. Service Providers . . . . . . . . . . . . . . . . . . 7 85 1.3.2. Applications . . . . . . . . . . . . . . . . . . . . . 7 86 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 88 2.1.1. Endpoint Address . . . . . . . . . . . . . . . . . . . 7 89 2.1.2. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 8 90 2.1.3. Network Location . . . . . . . . . . . . . . . . . . . 8 91 2.1.4. ALTO Information . . . . . . . . . . . . . . . . . . . 8 92 2.1.5. ALTO Information Base . . . . . . . . . . . . . . . . 8 93 2.2. ALTO Service and Protocol Scope . . . . . . . . . . . . . 8 94 3. Protocol Structure . . . . . . . . . . . . . . . . . . . . . . 10 95 3.1. Server Information Service . . . . . . . . . . . . . . . . 11 96 3.2. ALTO Information Services . . . . . . . . . . . . . . . . 11 97 3.2.1. Map Service . . . . . . . . . . . . . . . . . . . . . 11 98 3.2.2. Map Filtering Service . . . . . . . . . . . . . . . . 11 99 3.2.3. Endpoint Property Service . . . . . . . . . . . . . . 11 100 3.2.4. Endpoint Cost Service . . . . . . . . . . . . . . . . 12 101 4. Network Map . . . . . . . . . . . . . . . . . . . . . . . . . 12 102 4.1. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 103 4.2. Endpoint Addresses . . . . . . . . . . . . . . . . . . . . 13 104 4.2.1. IP Addresses . . . . . . . . . . . . . . . . . . . . . 13 105 4.3. Example Network Map . . . . . . . . . . . . . . . . . . . 13 106 5. Cost Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 107 5.1. Cost Attributes . . . . . . . . . . . . . . . . . . . . . 14 108 5.1.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . 15 109 5.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 15 110 5.2. Cost Map Structure . . . . . . . . . . . . . . . . . . . . 16 111 5.3. Network Map and Cost Map Dependency . . . . . . . . . . . 17 112 6. Protocol Design Overview . . . . . . . . . . . . . . . . . . . 17 113 6.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 17 114 6.1.1. Existing Infrastructure . . . . . . . . . . . . . . . 17 115 6.1.2. ALTO Information Reuse and Redistribution . . . . . . 18 116 6.2. Protocol Design . . . . . . . . . . . . . . . . . . . . . 18 117 7. Protocol Specification . . . . . . . . . . . . . . . . . . . . 18 118 7.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 19 119 7.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 19 120 7.2.1. Discovering Information Resources . . . . . . . . . . 19 121 7.2.2. Requesting Information Resources . . . . . . . . . . . 19 122 7.2.3. Response . . . . . . . . . . . . . . . . . . . . . . . 20 123 7.2.4. Client Behavior . . . . . . . . . . . . . . . . . . . 20 124 7.2.5. Authentication and Encryption . . . . . . . . . . . . 21 125 7.2.6. HTTP Cookies . . . . . . . . . . . . . . . . . . . . . 21 126 7.2.7. Parsing . . . . . . . . . . . . . . . . . . . . . . . 21 127 7.3. Information Resource . . . . . . . . . . . . . . . . . . . 21 128 7.3.1. Capabilities . . . . . . . . . . . . . . . . . . . . . 21 129 7.3.2. Input Parameters Media Type . . . . . . . . . . . . . 21 130 7.3.3. Media Type . . . . . . . . . . . . . . . . . . . . . . 21 131 7.3.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . 22 132 7.4. ALTO Errors . . . . . . . . . . . . . . . . . . . . . . . 23 133 7.4.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 23 134 7.4.2. Resource Format . . . . . . . . . . . . . . . . . . . 23 135 7.4.3. Error Codes . . . . . . . . . . . . . . . . . . . . . 24 136 7.5. ALTO Types . . . . . . . . . . . . . . . . . . . . . . . . 25 137 7.5.1. PID Name . . . . . . . . . . . . . . . . . . . . . . . 25 138 7.5.2. Endpoints . . . . . . . . . . . . . . . . . . . . . . 25 139 7.5.3. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 27 140 7.5.4. Cost Type . . . . . . . . . . . . . . . . . . . . . . 28 141 7.5.5. Endpoint Property . . . . . . . . . . . . . . . . . . 28 142 7.6. Information Resource Directory . . . . . . . . . . . . . . 28 143 7.6.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 29 144 7.6.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . 29 145 7.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 30 146 7.6.4. Usage Considerations . . . . . . . . . . . . . . . . . 33 147 7.7. Information Resources . . . . . . . . . . . . . . . . . . 34 148 7.7.1. Server Information Service . . . . . . . . . . . . . . 34 149 7.7.2. Map Service . . . . . . . . . . . . . . . . . . . . . 36 150 7.7.3. Map Filtering Service . . . . . . . . . . . . . . . . 41 151 7.7.4. Endpoint Property Service . . . . . . . . . . . . . . 46 152 7.7.5. Endpoint Cost Service . . . . . . . . . . . . . . . . 49 153 8. Redistributable Responses . . . . . . . . . . . . . . . . . . 53 154 8.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 53 155 8.1.1. Service ID . . . . . . . . . . . . . . . . . . . . . . 53 156 8.1.2. Expiration Time . . . . . . . . . . . . . . . . . . . 54 157 8.1.3. Signature . . . . . . . . . . . . . . . . . . . . . . 54 158 8.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 56 159 8.2.1. Response Redistribution Descriptor Fields . . . . . . 57 160 8.2.2. Signature . . . . . . . . . . . . . . . . . . . . . . 57 161 9. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 58 162 9.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 58 163 9.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 60 164 9.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 61 165 10. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 61 166 10.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 62 167 10.2. Hosts with Multiple Endpoint Addresses . . . . . . . . . . 62 168 10.3. Network Address Translation Considerations . . . . . . . . 62 169 10.4. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . 63 170 10.5. Endpoint and Path Properties . . . . . . . . . . . . . . . 63 171 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 172 11.1. application/alto-* Media Types . . . . . . . . . . . . . . 63 173 11.2. ALTO Cost Type Registry . . . . . . . . . . . . . . . . . 65 174 11.3. ALTO Endpoint Property Registry . . . . . . . . . . . . . 66 175 12. Security Considerations . . . . . . . . . . . . . . . . . . . 67 176 12.1. Privacy Considerations for ISPs . . . . . . . . . . . . . 67 177 12.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 68 178 12.3. Authentication, Integrity Protection, and Encryption . . . 68 179 12.4. ALTO Information Redistribution . . . . . . . . . . . . . 69 180 12.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 69 181 12.6. ALTO Server Access Control . . . . . . . . . . . . . . . . 70 182 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 183 13.1. Normative References . . . . . . . . . . . . . . . . . . . 70 184 13.2. Informative References . . . . . . . . . . . . . . . . . . 71 185 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 73 186 Appendix B. Authors . . . . . . . . . . . . . . . . . . . . . . . 74 187 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 74 189 1. Introduction 191 1.1. Background and Problem Statement 193 Today, network information available to applications is mostly from 194 the view of endhosts. There is no clear mechanism to convey 195 information about the network's preferences to applications. By 196 leveraging better network-provided information, applications have the 197 potential to become more network-efficient (e.g., reduce network 198 resource consumption) and achieve better application performance 199 (e.g., accelerated download rate). The ALTO Service intends to 200 provide a simple way to convey network information to applications. 202 The goal of this document is to specify a simple and unified protocol 203 that meets the ALTO requirements [I-D.ietf-alto-reqs] while providing 204 a migration path for Internet Service Providers (ISP), Content 205 Providers, and clients that have deployed protocols with similar 206 intentions (see below). This document is a work in progress and will 207 be updated with further developments. 209 1.2. Design History and Merged Proposals 211 The protocol specified here consists of contributions from 213 o P4P [I-D.p4p-framework], [P4P-SIGCOMM08], 214 [I-D.wang-alto-p4p-specification]; 216 o ALTO Info-Export [I-D.shalunov-alto-infoexport]; 218 o Query/Response [I-D.saumitra-alto-queryresponse], 219 [I-D.saumitra-alto-multi-ps]; 221 o ATTP [ATTP]; 223 o Proxidor [I-D.akonjang-alto-proxidor]. 225 See Appendix A for a list of people that have contributed 226 significantly to this effort and the projects and proposals listed 227 above. 229 1.3. Solution Benefits 231 The ALTO Service offers many benefits to both end-users (consumers of 232 the service) and Internet Service Providers (providers of the 233 service). 235 1.3.1. Service Providers 237 The ALTO Service enables ISPs to influence the peer selection process 238 in distributed applications in order to increase locality of traffic, 239 improve user-experience, amongst others. It also helps ISPs to 240 efficiently manage traffic that traverses more expensive links such 241 as transit and backup links, thus allowing a better provisioning of 242 the networking infrastructure. 244 1.3.2. Applications 246 Applications that use the ALTO Service can benefit in multiple ways. 247 For example, they may no longer need to infer topology information, 248 and some applications can reduce reliance on measuring path 249 performance metrics themselves. They can take advantage of the ISP's 250 knowledge to avoid bottlenecks and boost performance. 252 An example type of application is a Peer-to-Peer overlay where peer 253 selection can be improved by including ALTO information in the 254 selection process. 256 2. Architecture 258 Two key design objectives of the ALTO Protocol are simplicity and 259 extensibility. At the same time, it introduces additional techniques 260 to address potential scalability and privacy issues. This section 261 first introduces the terminology, and then defines the ALTO 262 architecture and the ALTO Protocol's place in the overall 263 architecture. 265 2.1. Terminology 267 We use the following terms defined in [RFC5693]: Application, Overlay 268 Network, Peer, Resource, Resource Identifier, Resource Provider, 269 Resource Consumer, Resource Directory, Transport Address, Host 270 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 271 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 272 Transit Traffic. 274 We also use the following additional terms: Endpoint Address, 275 Autonomous System Number (ASN), and Network Location. 277 2.1.1. Endpoint Address 279 An endpoint address represents the communication address of an 280 endpoint. An endpoint address can be network-attachment based (IP 281 address) or network-attachment agnostic. Common forms of endpoint 282 addresses include IP address, MAC address, overlay ID, and phone 283 number. 285 Each Endpoint Address has an associated Address Type, which indicates 286 both its syntax and semantics. 288 2.1.2. ASN 290 An Autonomous System Number. 292 2.1.3. Network Location 294 Network Location is a generic term denoting a single endpoint or 295 group of endpoints. 297 2.1.4. ALTO Information 299 ALTO Information is a generic term referring to the network 300 information sent by an ALTO Server. 302 2.1.5. ALTO Information Base 304 Internal representation of the ALTO Information maintained by the 305 ALTO Server. Note that the structure of this internal representation 306 is not defined by this document. 308 2.2. ALTO Service and Protocol Scope 310 An ALTO Server conveys the network information from the perspective 311 of a network region; the ALTO Server presents its "my-Internet View" 312 of the network region. In particular, an ALTO Server defines network 313 Endpoints (and aggregations thereof) and generic costs amongst them, 314 both from the network region's own perspective. A network region in 315 this context can be an Autonomous System, an ISP, or perhaps a 316 smaller region or set of ISPs; the details depend on the deployment 317 scenario and discovery mechanism. 319 To better understand the ALTO Service and the role of the ALTO 320 Protocol, we show in Figure 1 the overall system architecture. In 321 this architecture, an ALTO Server prepares ALTO Information; an ALTO 322 Client uses ALTO Service Discovery to identify an appropriate ALTO 323 Server; and the ALTO Client requests available ALTO Information from 324 the ALTO Server using the ALTO Protocol. 326 The ALTO Information provided by the ALTO Server can be updated 327 dynamically based on network conditions, or can be seen as a policy 328 which is updated at a larger time-scale. 330 More specifically, the ALTO Information provided by an ALTO Server 331 may be influenced (at the operator's discretion) by other systems. 332 Examples include (but are not limited to) static network 333 configuration databases, dynamic network information, routing 334 protocols, provisioning policies, and interfaces to outside parties. 335 These components are shown in the figure for completeness but outside 336 the scope of this specification. 338 Note that it may also be possible for ALTO Servers to exchange 339 network information with other ALTO Servers (either within the same 340 administrative domain or another administrative domain with the 341 consent of both parties) in order to adjust exported ALTO 342 Information. Such a protocol is also outside the scope of this 343 specification. 345 +-------------------------------------------------------------------+ 346 | ISP | 347 | | 348 | +-----------+ | 349 | | Routing | | 350 | +--------------+ | Protocols | | 351 | | Provisioning | +-----------+ | 352 | | Policy | | | 353 | +--------------+\ | | 354 | \ | | 355 | \ | | 356 | +-----------+ \+---------+ +--------+ | 357 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 358 | |Network |.......| Server | -------------------- | Client | | 359 | |Information| +---------+ +--------+ | 360 | +-----------+ / / | 361 | / ALTO SD Query/Response / | 362 | / / | 363 | +----------+ +--------------+ | 364 | | External | | ALTO Service | | 365 | | Interface| | Discovery | | 366 | +----------+ +--------------+ | 367 | | | 368 +-------------------------------------------------------------------+ 369 | 370 +------------------+ 371 | Third Parties | 372 | | 373 | Content Providers| 374 +------------------+ 376 Figure 1: Basic ALTO Architecture. 378 3. Protocol Structure 380 The ALTO Protocol uses a simple extensible framework to convey 381 network information. In the general framework, the ALTO protocol 382 will convey properties on both Network Locations and the paths 383 between Network Locations. 385 In this document, we focus on a particular Endpoint property to 386 denote the location of an endpoint, and provider-defined costs for 387 paths between pairs of Network Locations. 389 The ALTO Protocol is built on a common transport protocol, messaging 390 structure and encoding, and transaction model. The protocol is 391 subdivided into services of related functionality. ALTO-Core 392 provides the Server Information Service and the Map Service to 393 provide ALTO Information. Other ALTO Information services can 394 provide additional functionality. There are three such services 395 defined in this document: the Map Filtering Service, Endpoint 396 Property Service, and Endpoint Cost Service. Additional services may 397 be defined in companion documents. Note that functionality offered 398 in different services are not totally non-overlapping (e.g., the Map 399 Service and Map Filtering Service). 401 .------------------------------------------------------------. 402 | | 403 | .----------. .-----------------------------------------. | 404 | | | | ALTO Info Services | | 405 | | | | .-----------. .----------. .----------. | | 406 | | | | | Map | | Endpoint | | Endpoint | | | 407 | | | | | Filtering | | Property | | Cost | | | 408 | | | | | Service | | Service | | Service | | | 409 | | Server | | `-----------' `----------' `----------' | | 410 | | Info. | | .-------------------------------------. | | 411 | | Service | | | Map Service | | | 412 | | | | | .-------------. .--------------. | | | 413 | | | | | | Network Map | | Cost Map | | | | 414 | | | | | `-------------' `--------------' | | | 415 | | | | `-------------------------------------' | | 416 | `----------' `-----------------------------------------' | 417 | | 418 `------------------------------------------------------------' 420 Figure 2: ALTO Protocol Structure 422 3.1. Server Information Service 424 The Server Information Service lists the details on the information 425 that can be provided by an ALTO Server and perhaps other ALTO Servers 426 maintained by the network provider. The configuration includes, for 427 example, details about the operations and cost metrics supported by 428 the ALTO Server and other related ALTO Servers that may be usable by 429 an ALTO Client. 431 3.2. ALTO Information Services 433 Multiple, distinct services are defined to allow ALTO Clients to 434 query ALTO Information from an ALTO Server. The ALTO Server 435 internally maintains an ALTO Information Base that encodes the 436 network provider's preferences. The ALTO Information Base encodes 437 the Network Locations defined by the ALTO Server (and their 438 corresponding properties), as well as the provider-defined costs 439 between pairs of Network Locations. 441 3.2.1. Map Service 443 The Map Service provides batch information to ALTO Clients in the 444 form of Network Map and Cost Map. The Network Map (See Section 4) 445 provides the full set of Network Location groupings defined by the 446 ALTO Server and the endpoints contained with each grouping. The Cost 447 Map (see Section 5) provides costs between the defined groupings. 449 These two maps can be thought of (and implemented as) as simple files 450 with appropriate encoding provided by the ALTO Server. 452 3.2.2. Map Filtering Service 454 Resource constrained ALTO Clients may benefit from query results 455 being filtered at the ALTO Server. This avoids an ALTO Client 456 spending network bandwidth or CPU collecting results and performing 457 client-side filtering. The Map Filtering Service allows ALTO Clients 458 to query for the ALTO Server Network Map and Cost Map based on 459 additional parameters. 461 3.2.3. Endpoint Property Service 463 This service allows ALTO Clients to look up properties for individual 464 endpoints. An example endpoint property is its Network Location (its 465 grouping defined by the ALTO Server) or connectivity type (e.g., 466 ADSL, Cable, or FTTH). 468 3.2.4. Endpoint Cost Service 470 Some ALTO Clients may also benefit from querying for costs and 471 rankings based on endpoints. The Endpoint Cost Service allows an 472 ALTO Server to return either numerical costs or ordinal costs 473 (rankings) directly amongst Endpoints. 475 4. Network Map 477 In reality, many endpoints are very close to one another in terms of 478 network connectivity, for example, endpoints on the same site of an 479 enterprise. By treating a group of endpoints together as a single 480 entity in ALTO, we can achieve much greater scalability without 481 losing critical information. 483 The Network Location endpoint property allows an ALTO Server to group 484 endpoints together to indicate their proximity. The resulting set of 485 groupings is called the ALTO Network Map. 487 The definition of proximity varies depending on the granularity of 488 the ALTO information configured by the provider. In one deployment, 489 endpoints on the same subnet may be considered close; while in 490 another deployment, endpoints connected to the same PoP may be 491 considered close. 493 As used in this document, the Network Map refers to the syntax and 494 semantics of the information distributed by the ALTO Server. This 495 document does not discuss the internal representation of this data 496 structure within the ALTO Server. 498 4.1. PID 500 Each group of Endpoints is identified by a provider-defined Network 501 Location identifier called a PID. There can be many different ways 502 of grouping the endpoints and assigning PIDs. 504 A PID is an identifier that provides an indirect and network-agnostic 505 way to specify an aggregation of network endpoints that may be 506 treated similarly, based on network topology, type, or other 507 properties. For example, a PID may be defined by the ALTO service 508 provider to denote a subnet, a set of subnets, a metropolitan area, a 509 PoP, an autonomous system, or a set of autonomous systems. 510 Aggregation of endpoints into PIDs can indicate proximity and can 511 improve scalability. In particular, network preferences (costs) may 512 be specified between PIDs, allowing cost information to be more 513 compactly represented and updated at a faster time scale than the 514 network aggregations themselves. 516 Using PIDs, the Network Map may also be used to communicate simple 517 preferences with only minimal information from the Cost Map. For 518 example, an ISP may prefer that endpoints associated with the same 519 PoP (Point-of-Presence) in a P2P application communicate locally 520 instead of communicating with endpoints in other PoPs. The ISP may 521 aggregate endhosts within a PoP into a single PID in the Network Map. 522 The Cost Map may be encoded to indicate that peering within the same 523 PID is preferred; for example, cost(PID_i, PID_i) == c* and 524 cost(PID_i, PID_j) > c* for i != j. Section 5 provides further 525 details about Cost Map structure. 527 4.2. Endpoint Addresses 529 Communicating endpoints may have many types of addresses, such as IP 530 addresses, MAC addresses, or overlay IDs. The current specification 531 only considers IP addresses. 533 4.2.1. IP Addresses 535 The endpoints aggregated into a PID are denoted by a list of IP 536 prefixes. When either an ALTO Client or ALTO Server needs to 537 determine which PID in a Network Map contains a particular IP 538 address, longest-prefix matching MUST be used. 540 A Network Map MUST define a PID for each possible address in the IP 541 address space for all of the address types contained in the map. A 542 RECOMMENDED way to satisfy this property is to define a PID that 543 contains the 0.0.0.0/0 prefix for IPv4 or ::/0 (for IPv6). 545 Each endpoint MUST map into exactly one PID. Since longest-prefix 546 matching is used to map an endpoint to a PID, this can be 547 accomplished by ensuring that no two PIDs contain an identical IP 548 prefix. 550 4.3. Example Network Map 552 Figure 3 illustrates an example Network Map. PIDs are used to 553 identify network-agnostic aggregations. 555 .-----------------------------------------------------------. 556 | ALTO Network Map | 557 | | 558 | .-----------------------------------. .---------------. | 559 | | NetLoc: PID-1 | | NetLoc: PID-2 | | 560 | | .------------------------------. | | ... | | 561 | | | 192.0.2.0/24 | | `---------------` | 562 | | | .--------------------------. | | | 563 | | | | Endpoint: 192.0.2.34 | | | .---------------. | 564 | | | `--------------------------` | | | NetLoc: PID-3 | | 565 | | `------------------------------` | | ... | | 566 | | .------------------------------. | `---------------` | 567 | | | 198.51.100.0/25 | | | 568 | | | .--------------------------. | | .---------------. | 569 | | | | Endpoint: 198.51.100.100 | | | | NetLoc: PID-4 | | 570 | | | `--------------------------` | | | ... | | 571 | | `------------------------------` | `---------------` | 572 | `-----------------------------------` | 573 | | 574 `-----------------------------------------------------------` 576 Figure 3: Example Network Map 578 5. Cost Map 580 An ALTO Server indicates preferences amongst network locations in the 581 form of Path Costs. Path Costs are generic costs and can be 582 internally computed by a network provider according to its own needs. 584 An ALTO Cost Map defines Path Costs pairwise amongst sets of source 585 and destination Network Locations. 587 One advantage of separating ALTO information into a Network Map and a 588 Cost Map is that the two components can be updated at different time 589 scales. For example, Network Maps may be stable for a longer time 590 while Cost Maps may be updated to reflect dynamic network conditions. 592 As used in this document, the Cost Map refers to the syntax and 593 semantics of the information distributed by the ALTO Server. This 594 document does not discuss the internal representation of this data 595 structure within the ALTO Server. 597 5.1. Cost Attributes 599 Path Costs have attributes: 601 o Type: identifies what the costs represent; 603 o Mode: identifies how the costs should be interpreted. 605 Certain queries for Cost Maps allow the ALTO Client to indicate the 606 desired Type and Mode. 608 5.1.1. Cost Type 610 The Type attribute indicates what the cost represents. For example, 611 an ALTO Server could define costs representing air-miles, hop-counts, 612 or generic routing costs. 614 Cost types are indicated in protocol messages as strings. 616 5.1.1.1. Cost Type: routingcost 618 An ALTO Server MUST define the 'routingcost' Cost Type. 620 This Cost Type conveys a generic measure for the cost of routing 621 traffic from a source to a destination. Lower values indicate a 622 higher preference for traffic to be sent from a source to a 623 destination. 625 Note that an ISP may internally compute routing cost using any method 626 it chooses (e.g., air-miles or hop-count) as long as it conforms to 627 these semantics. 629 5.1.2. Cost Mode 631 The Mode attribute indicates how costs should be interpreted. 632 Specifically, the Mode attribute indicates whether returned costs 633 should be interpreted as numerical values or ordinal rankings. 635 It is important to communicate such information to ALTO Clients, as 636 certain operations may not be valid on certain costs returned by an 637 ALTO Server. For example, it is possible for an ALTO Server to 638 return a set of IP addresses with costs indicating a ranking of the 639 IP addresses. Arithmetic operations, such as summation, that would 640 make sense for numerical values, do not make sense for ordinal 641 rankings. ALTO Clients may handle such costs differently. 643 Cost Modes are indicated in protocol messages as strings. 645 An ALTO Server MUST support at least one of 'numerical' and 'ordinal' 646 costs. ALTO Clients SHOULD be cognizant of operations when a desired 647 cost mode is not supported. For example, an ALTO Client desiring 648 numerical costs may adjust behavior if only the ordinal Cost Mode is 649 available. Alternatively, an ALTO Client desiring ordinal costs may 650 construct ordinal costs given numerical values if only the numerical 651 Cost Mode is available. 653 5.1.2.1. Cost Mode: numerical 655 This Cost Mode is indicated by the string 'numerical'. This mode 656 indicates that it is safe to perform numerical operations (e.g. 657 summation) on the returned costs. 659 5.1.2.2. Cost Mode: ordinal 661 This Cost Mode is indicated by the string 'ordinal'. This mode 662 indicates that the costs values to a set of Destination Network 663 Locations from a particular Source Network Location are a ranking, 664 with lower values indicating a higher preference. The values are 665 non-negative integers. Ordinal cost values from a particular Source 666 Network Location to a set of Destination Network Locations need not 667 be unique nor contiguous. In particular, from the perspective of a 668 particular Source Network Location, two Destination Network Locations 669 may have an identical rank (ordinal cost value). This document does 670 not specify any behavior by an ALTO Client in this case; an ALTO 671 Client may decide to break ties by random selection, other 672 application knowledge, or some other means. 674 It is important to note that the values in the Cost Map provided with 675 the ordinal Cost Mode are not necessarily the actual cost known to 676 the ALTO Server. 678 5.2. Cost Map Structure 680 A query for a Cost Map either explicitly or implicitly includes a 681 list of Source Network Locations and a list of Destination Network 682 Locations. (Recall that a Network Location can be an endpoint 683 address or a PID.) 685 Specifically, assume that a query has a list of multiple Source 686 Network Locations, say [Src_1, Src_2, ..., Src_m], and a list of 687 multiple Destination Network Locations, say [Dst_1, Dst_2, ..., 688 Dst_n]. 690 The ALTO Server will return the Path Cost for each communicating pair 691 (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., Src_m -> Dst_1, ..., 692 Src_m -> Dst_n). We refer to this structure as a Cost Map. 694 If the Cost Mode is 'ordinal', the Path Cost of each communicating 695 pair is relative to the m*n entries. 697 5.3. Network Map and Cost Map Dependency 699 If a Cost Map contains PIDs in the list of Source Network Locations 700 or the list of Destination Network Locations, the Path Costs are 701 generated based on a particular Network Map (which defines the PIDs). 702 Version Tags are introduced to ensure that ALTO Clients are able to 703 use consistent information even though the information is provided in 704 two maps. 706 A Version Tag is an opaque string associated with a Network Map 707 maintained by the ALTO Server. When the Network Map changes, the 708 Version Tag MUST also be changed. (Thus, the Version Tag is defined 709 similarly to HTTP's Entity Tags; see Section 3.11 of [RFC2616].) 710 Possibilities for generating a Version Tag include the last-modified 711 timestamp for the Network Map, or a hash of its contents. 713 A Network Map distributed by the ALTO Server includes its Version 714 Tag. A Cost Map referring to PIDs also includes the Version Tag of 715 the Network Map on which it is based. 717 6. Protocol Design Overview 719 The ALTO Protocol design uses a REST-ful design with the goal of 720 leveraging current HTTP [RFC2616] implementations and infrastructure. 721 The REST-ful design supports flexible deployment strategies and 722 provides extensibility. ALTO requests and responses are encoded with 723 JSON [RFC4627]. 725 6.1. Benefits 727 Benefits enabled by these design choices include easier understanding 728 and debugging, mature libraries, tools, infrastructure, and caching 729 and redistribution of ALTO information for increased scalability. 731 6.1.1. Existing Infrastructure 733 HTTP is a natural choice for integration with existing applications 734 and infrastructure. In particular, the ALTO Protocol design 735 leverages: 737 o the huge installed base of infrastructure, including HTTP caches, 739 o mature software implementations, 741 o the fact that many P2P clients already have an embedded HTTP 742 client, and 744 o authentication and encryption mechanisms in HTTP and SSL/TLS. 746 6.1.2. ALTO Information Reuse and Redistribution 748 ALTO information may be useful to a large number of applications and 749 users. For example, an identical Network Map may be used by all ALTO 750 Clients querying a particular ALTO Server. At the same time, 751 distributing ALTO information must be efficient and not become a 752 bottleneck. 754 Beyond integration with existing HTTP caching infrastructure, ALTO 755 information may also be cached or redistributed using application- 756 dependent mechanisms, such as P2P DHTs or P2P file-sharing. This 757 document does not define particular mechanisms for such 758 redistribution, but it does define the primitives (e.g., digital 759 signatures) needed to support such a mechanism. See 760 [I-D.gu-alto-redistribution] for further discussion. 762 Note that if caching or redistribution is used, the response message 763 may be returned from another (possibly third-party) entity. Reuse 764 and Redistribution is further discussed in Section 12.4. Protocol 765 support for redistribution is specified in Section 8. 767 6.2. Protocol Design 769 The ALTO Protocol uses a REST-ful design. There are two primary 770 components to this design: 772 o Information Resources: Each service provides network information 773 as a set of resources, which are distinguished by their media 774 types [RFC2046]. An ALTO Client may construct an HTTP request for 775 a particular resource (including any parameters, if necessary), 776 and an ALTO Server returns the requested resource in an HTTP 777 response. 779 o Information Resource Directory: An ALTO Server provides to ALTO 780 Clients a list of available resources and the URI at which each is 781 provided. This document refers to this list as the Information 782 Resource Directory. This directory is the single entry point to 783 an ALTO Service. ALTO Clients consult the directory to determine 784 the services provided by an ALTO Server. 786 7. Protocol Specification 788 This section first specifies general client and server processing, 789 followed by a detailed specification for each ALTO Information 790 Resource. 792 7.1. Notation 794 This document uses an adaptation of the C-style struct notation to 795 define the required and optional members of JSON objects. Unless 796 explicitly noted, each member of a struct is REQUIRED. 798 The types 'JSONString', 'JSONNumber', 'JSONBool' indicate the JSON 799 string, number, and boolean types, respectively. 801 Note that no standard, machine-readable interface definition or 802 schema is provided. Extension documents may document these as 803 necessary. 805 7.2. Basic Operation 807 The ALTO Protocol employs standard HTTP [RFC2616]. It is used for 808 discovering available Information Resources at an ALTO Server and 809 retrieving Information Resources. ALTO Clients and ALTO Servers use 810 HTTP requests and responses carrying ALTO-specific content with 811 encoding as specified in this document, and MUST be compliant with 812 [RFC2616]. 814 7.2.1. Discovering Information Resources 816 To discover available resources, an ALTO Client may request the 817 Information Resource Directory, which an ALTO Server provides at the 818 URI found by the ALTO Discovery protocol. 820 Informally, an Information Resource Directory enumerates URIs at 821 which an ALTO Server offers Information Resources. Each entry in the 822 directory indicates a URI at which an ALTO Server accepts requests, 823 and returns either the requested Information Resource or an 824 Information Resource Directory that references additional Information 825 Resources. See Section 7.6 for a detailed specification. 827 7.2.2. Requesting Information Resources 829 Through the retrieved Information Resource Directories, an ALTO 830 Client can determine whether an ALTO Server supports the desired 831 Information Resource, and if it is supported, the URI at which it is 832 available. 834 Where possible, the ALTO Protocol uses the HTTP GET method to request 835 resources. However, some ALTO services provide Information Resources 836 that are the function of one or more input parameters. Input 837 parameters are encoded in the HTTP request's entity body, and the 838 request uses the HTTP POST method. 840 Note that it is possible for an ALTO Server to employ caching for the 841 response to a POST request. This can be accomplished by returning an 842 HTTP 303 status code ("See Other") indicating to the ALTO Client that 843 the resulting Cost Map is available via a GET request to an alternate 844 URL (which may be cached). 846 When requesting an ALTO Information Resource that requires input 847 parameters specified in a HTTP POST request, an ALTO Client MUST set 848 the Content-Type HTTP header to the media type corresponding to the 849 format of the supplied input parameters. 851 7.2.3. Response 853 Upon receiving a request, an ALTO server either returns the requested 854 resource, provides the ALTO Client an Information Resource Directory 855 indicating how to reach the desired resource, or returns an error. 857 The type of response MUST be indicated by the media type attached to 858 the response (the Content-Type HTTP header). If an ALTO Client 859 receives an Information Resource Directory, it can consult the 860 received directory to determine if any of the offered URIs contain 861 the desired Information Resource. 863 The generic encoding for an Information Resource is specified in 864 Section 7.3. 866 Errors are indicated via either ALTO-level error codes, or via HTTP 867 status codes; see Section 7.4. 869 7.2.4. Client Behavior 871 7.2.4.1. Using Information Resources 873 This specification does not indicate any required actions taken by 874 ALTO Clients upon successfully receiving an Information Resource from 875 an ALTO Server. Although ALTO Clients are suggested to interpret the 876 received ALTO Information and adapt application behavior, ALTO 877 Clients are not required to do so. 879 7.2.4.2. Error Conditions 881 If an ALTO Client does not successfully receive a desired Information 882 Resource from a particular ALTO Server, it can either choose another 883 server (if one is available) or fall back to a default behavior 884 (e.g., perform peer selection without the use of ALTO information). 885 An ALTO Client may also retry the request at a later time. 887 7.2.5. Authentication and Encryption 889 An ALTO Server MAY support SSL/TLS to implement server and/or client 890 authentication, as well as encryption. See [RFC6125] for 891 considerations regarding verification of server identity. 893 7.2.6. HTTP Cookies 895 If cookies are included in an HTTP request received by an ALTO 896 Server, they MUST be ignored. 898 7.2.7. Parsing 900 This document only details object members used by this specification. 901 Extensions may include additional members within JSON objects defined 902 in this document. ALTO implementations MUST ignore such unknown 903 fields when processing ALTO messages. 905 7.3. Information Resource 907 An Information Resource is an HTTP entity body received by an ALTO 908 Server that encodes the ALTO Information desired by an ALTO Client. 910 This document specifies multiple Information Resources that can be 911 provided by an ALTO Server. Each Information Resource has certain 912 attributes associated with it, indicating its data format, the input 913 parameters it supports, and format of the input parameters. 915 7.3.1. Capabilities 917 An ALTO Server may advertise to an ALTO Client that it supports 918 certain capabilities in requests for an Information Resource. For 919 example, if an ALTO Server allows requests for a Cost Map to include 920 constraints, it may advertise that it supports this capability. 922 7.3.2. Input Parameters Media Type 924 An ALTO Server may allow an ALTO Client to supply input parameters 925 when requesting certain Information Resources. The format of the 926 input parameters (i.e., as contained in the entity body of the HTTP 927 POST request) is indicated by the media type [RFC2046]. 929 7.3.3. Media Type 931 The media type [RFC2046] uniquely indicates the data format of the 932 Information Resource as returned by an ALTO Server in the HTTP entity 933 body. 935 7.3.4. Encoding 937 Though each Information Resource may have a distinct syntax, they are 938 designed to have a common structure containing generic ALTO-layer 939 metadata about the resource, as well as data itself. 941 An Information Resource has a single top-level JSON object of type 942 InfoResourceEntity: 944 object { 945 InfoResourceMetaData meta; 946 [InfoResourceDataType] data; 947 } InfoResourceEntity; 949 with members: 951 meta meta-information pertaining to the Information Resource 953 data the data contained in the Information Resource 955 7.3.4.1. Meta Information 957 Meta information is encoded as a JSON object with type 958 InfoResourceMetaData: 960 object { 961 InfoResourceRedistDesc redistribution; [OPTIONAL] 962 } InfoResourceMetaData; 964 with members: 966 redistribution Additional data for use in Information Resources that 967 may be redistributed amongst ALTO Clients. See Section 8. 969 7.3.4.2. ALTO Information 971 The "data" member of the InfoResourceEntity encodes the resource- 972 specific data; the structure of this member is detailed later in this 973 section for each particular Information Resource. 975 7.3.4.3. Signature 977 An ALTO Server MAY additionally supply a signature asserting that it 978 generated a particular response. See Section 8.2.2. 980 7.3.4.4. Example 982 The following is an example of the encoding for an Information 983 Resource: 985 HTTP/1.1 200 OK 986 Content-Length: [TODO] 987 Content-Type: application/alto-costmap+json 989 { 990 "meta" : { 991 "redistribution" : { ... } 992 }, 993 "data" : { 994 ... 995 } 996 } 998 7.4. ALTO Errors 1000 If there is an error processing a request, an ALTO Server SHOULD 1001 return additional ALTO-layer information, if it is available, in the 1002 form of an ALTO Error Resource encoded in the HTTP response's entity 1003 body. 1005 If no ALTO-layer information is available, an ALTO Server may omit an 1006 ALTO Error resource from the response. An appropriate HTTP status 1007 code MUST be set. 1009 It is important to note that the HTTP Status Code and ALTO Error Code 1010 have distinct roles. An ALTO Error Code provides detailed 1011 information about the why a particular request for an ALTO Resource 1012 was not successful. The HTTP status code indicates to HTTP 1013 processing elements (e.g., intermediaries and clients) how the 1014 response should be treated. 1016 7.4.1. Media Type 1018 The media type for an Error Resource is "application/ 1019 alto-error+json". 1021 7.4.2. Resource Format 1023 An Error Resource has the format: 1025 object { 1026 JSONString code; 1027 JSONString reason; [OPTIONAL] 1028 } ErrorResourceEntity; 1030 where: 1032 code An ALTO Error Code defined in Table 1 1034 reason A (free-form) human-readable explanation of the particular 1035 error 1037 7.4.3. Error Codes 1039 This document defines ALTO Error Codes to support the error 1040 conditions needed for purposes of this document. Additional status 1041 codes may be defined in companion or extension documents. 1043 The HTTP status codes corresponding to each ALTO Error Code are 1044 defined to provide correct behavior with HTTP intermediaries and 1045 clients. When an ALTO Server returns a particular ALTO Error Code, 1046 it MUST indicate one of the corresponding HTTP status codes in 1047 Table 1in the HTTP response. 1049 If multiple errors are present in a single request (e.g., a request 1050 uses a JSONString when a JSONInteger is expected and a required field 1051 is missing), then the ALTO Server MUST return exactly one of the 1052 detected errors. However, the reported error is implementation 1053 defined, since specifying a particular order for message processing 1054 encroaches needlessly on implementation technique. 1056 +-------------------------+-------------+---------------------------+ 1057 | ALTO Error Code | HTTP Status | Description | 1058 | | Code(s) | | 1059 +-------------------------+-------------+---------------------------+ 1060 | E_SYNTAX | 400 | Parsing error in request | 1061 | | | (including identifiers) | 1062 | | | | 1063 | E_JSON_FIELD_MISSING | 400 | Required field missing | 1064 | | | | 1065 | E_JSON_VALUE_TYPE | 400 | JSON Value of unexpected | 1066 | | | type | 1067 | | | | 1068 | E_INVALID_COST_MODE | 400 | Invalid cost mode | 1069 | | | | 1070 | E_INVALID_COST_TYPE | 400 | Invalid cost type | 1071 | | | | 1072 | E_INVALID_PROPERTY_TYPE | 400 | Invalid property type | 1073 +-------------------------+-------------+---------------------------+ 1075 Table 1: Defined ALTO Error Codes 1077 7.5. ALTO Types 1079 This section details the format for particular data values used in 1080 the ALTO Protocol. 1082 7.5.1. PID Name 1084 A PID Name is encoded as a US-ASCII string. The string MUST be no 1085 more than 64 characters, and MUST NOT contain characters other than 1086 alphanumeric characters or the '.' separator. The '.' separator is 1087 reserved for future use and MUST NOT be used unless specifically 1088 indicated by a companion or extension document. 1090 The type 'PIDName' is used in this document to indicate a string of 1091 this format. 1093 7.5.2. Endpoints 1095 This section defines formats used to encode addresses for Endpoints. 1096 In a case that multiple textual representations encode the same 1097 Endpoint address or prefix (within the guidelines outlined in this 1098 document), the ALTO Protocol does not require ALTO Clients or ALTO 1099 Servers to use a particular textual representation, nor does it 1100 require that ALTO Servers reply to requests using the same textual 1101 representation used by requesting ALTO Clients. ALTO Clients must be 1102 cognizant of this. 1104 7.5.2.1. Address Type 1106 Address Types are encoded as US-ASCII strings consisting of only 1107 alphanumeric characters. This document defines the address type 1108 "ipv4" to refer to IPv4 addresses, and "ipv6" to refer to IPv6 1109 addresses. Extension documents may define additional Address Types. 1111 The type 'AddressType' is used in this document to indicate a string 1112 of this format. 1114 7.5.2.2. Endpoint Address 1116 Endpoint Addresses are encoded as US-ASCII strings. The exact 1117 characters and format depend on the type of endpoint address. 1119 The type 'EndpointAddr' is used in this document to indicate a string 1120 of this format. 1122 7.5.2.2.1. IPv4 1124 IPv4 Endpoint Addresses are encoded as specified by the 'IPv4address' 1125 rule in Section 3.2.2 of [RFC3986]. 1127 7.5.2.2.2. IPv6 1129 IPv6 Endpoint Addresses are encoded as specified in Section 4 of 1130 [RFC5952]. 1132 7.5.2.2.3. Typed Endpoint Addresses 1134 When an Endpoint Address is used, an ALTO implementation must be able 1135 to determine its type. For this purpose, the ALTO Protocol allows 1136 endpoint addresses to also explicitly indicate their type. 1138 Typed Endpoint Addresses are encoded as US-ASCII strings of the 1139 format 'AddressType:EndpointAddr' (with the ':' character as a 1140 separator). The type 'TypedEndpointAddr' is used to indicate a 1141 string of this format. 1143 7.5.2.3. Endpoint Prefixes 1145 For efficiency, it is useful to denote a set of Endpoint Addresses 1146 using a special notation (if one exists). This specification makes 1147 use of the prefix notations for both IPv4 and IPv6 for this purpose. 1149 Endpoint Prefixes are encoded as US-ASCII strings. The exact 1150 characters and format depend on the type of endpoint address. 1152 The type 'EndpointPrefix' is used in this document to indicate a 1153 string of this format. 1155 7.5.2.3.1. IPv4 1157 IPv4 Endpoint Prefixes are encoded as specified in Section 3.1 of 1158 [RFC4632]. 1160 7.5.2.3.2. IPv6 1162 IPv6 Endpoint Prefixes are encoded as specified in Section 7 of 1163 [RFC5952]. 1165 7.5.2.4. Endpoint Address Group 1167 The ALTO Protocol includes messages that specify potentially large 1168 sets of endpoint addresses. Endpoint Address Groups provide a more 1169 efficient way to encode such sets, even when the set contains 1170 endpoint addresses of different types. 1172 An Endpoint Address Group is defined as: 1174 object { 1175 EndpointPrefix [AddressType]<0..*>; 1176 ... 1177 } EndpointAddrGroup; 1179 In particular, an Endpoint Address Group is a JSON object with the 1180 name of each member being the string corresponding to the address 1181 type, and the member's corresponding value being a list of prefixes 1182 of addresses of that type. 1184 The following is an example with both IPv4 and IPv6 endpoint 1185 addresses: 1187 { 1188 "ipv4": [ 1189 "192.0.2.0/24", 1190 "198.51.100.0/25" 1191 ], 1192 "ipv6": [ 1193 "2001:db8:0:1::/64", 1194 "2001:db8:0:2::/64" 1195 ] 1196 } 1198 7.5.3. Cost Mode 1200 A Cost Mode is encoded as a US-ASCII string. The string MUST either 1201 have the value 'numerical' or 'ordinal'. 1203 The type 'CostMode' is used in this document to indicate a string of 1204 this format. 1206 7.5.4. Cost Type 1208 A Cost Type is encoded as a US-ASCII string. The string MUST be no 1209 more than 32 characters, and MUST NOT contain characters other than 1210 alphanumeric characters, the hyphen ('-'), or the ':' separator. 1212 Identifiers prefixed with 'priv:' are reserved for Private Use 1213 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for 1214 Experimental use. All other identifiers appearing in an HTTP request 1215 or response with an 'application/alto-*' media type MUST be 1216 registered in the ALTO Cost Types registry Section 11.2. 1218 The type 'CostType' is used in this document to indicate a string of 1219 this format. 1221 7.5.5. Endpoint Property 1223 An Endpoint Property is encoded as a US-ASCII string. The string 1224 MUST be no more than 32 characters, and MUST NOT contain characters 1225 other than alphanumeric characters, the hyphen ('-'), or the ':' 1226 separator. 1228 Identifiers prefixed with 'priv:' are reserved for Private Use 1229 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for 1230 Experimental use. All other identifiers appearing in an HTTP request 1231 or response with an 'application/alto-*' media type MUST be 1232 registered in the ALTO Endpoint Property registry Section 11.3. 1234 The type 'EndpointProperty' is used in this document to indicate a 1235 string of this format. 1237 7.6. Information Resource Directory 1239 An Information Resource Directory indicates to ALTO Clients which 1240 Information Resources are made available by an ALTO Server. 1242 Since resource selection happens after consumption of the Information 1243 Resource Directory, the format of the Information Resource Directory 1244 is designed to be simple with the intention of future ALTO Protocol 1245 versions maintaining backwards compatibility. Future extensions or 1246 versions of the ALTO Protocol SHOULD be accomplished by extending 1247 existing media types or adding new media types, but retaining the 1248 same format for the Information Resource Directory. 1250 An ALTO Server MUST make an Information Resource Directory available 1251 via the HTTP GET method to a URI discoverable by an ALTO Client. 1252 Discovery of this URI is out of scope of this document, but could be 1253 accomplished by manual configuration or by returning the URI of an 1254 Information Resource Directory from the ALTO Discovery Protocol 1255 [I-D.ietf-alto-server-discovery]. 1257 7.6.1. Media Type 1259 The media type is "application/alto-directory+json". 1261 7.6.2. Encoding 1263 An Information Resource Directory is a JSON object of type 1264 InfoResourceDirectory: 1266 object { 1267 ... 1268 } Capabilities; 1270 object { 1271 JSONString uri; 1272 JSONString media-types<1..*>; 1273 JSONString accepts<0..*>; [OPTIONAL] 1274 Capabilities capabilities; [OPTIONAL] 1275 } ResourceEntry; 1277 object { 1278 ResourceEntry resources<0..*>; 1279 } InfoResourceDirectory; 1281 where the "resources" array indicates a list of Information Resources 1282 provided by an ALTO Server. Note that the list of available 1283 resources is enclosed in a JSON object for extensibility; future 1284 protocol versions may specify additional members in the 1285 InfoResourceDirectory object. 1287 Each entry MUST indicate a URI that either directly provides the 1288 indicated Information Resource, or responds to a HTTP OPTIONS request 1289 which provides an Information Resource Directory with entries of 1290 additional Information Resources. 1292 If an ALTO Client makes a GET or POST request to a URI that does not 1293 directly provide an indicated Information Resource, the ALTO Server 1294 MUST either reply with an HTTP 300 status code ("Multiple Choices") 1295 and an Information Resource Directory in the HTTP response's entity 1296 body, or indicate an appropriate HTTP status code. Note that in 1297 general, it is preferred that ALTO Clients use HTTP OPTIONS requests 1298 to discover additional Information Resources. 1300 A URI that directly provides an Information Resource MAY also respond 1301 to HTTP OPTIONS requests, but it is not required to do so (in which 1302 case, it MUST respond with HTTP 405 status code ("Method Not 1303 Allowed"). This allows certain Information Resources to be 1304 configured as static files with minimal configuration on some HTTP 1305 servers. 1307 Each entry in the directory specifies: 1309 uri A URI at which the ALTO Server provides one or more Information 1310 Resources, or an Information Resource Directory indicating 1311 additional Information Resources. 1313 media-types The list of all media types of Information Resources 1314 (see Section 7.3.3) available via GET or POST requests to the 1315 corresponding URI or URIs discoverable via the URI. 1317 accepts The list of all media types of input parameters (see 1318 Section 7.3.2) accepted by POST requests to the corresponding URI 1319 or URIs discoverable via the URI. If this member is not present, 1320 it MUST be assumed to be an empty array. 1322 capabilities A JSON Object enumerating capabilities of an ALTO 1323 Server in providing the Information Resource at the corresponding 1324 URI and Information Resources discoverable via the URI. If this 1325 member is not present, it MUST be assumed to be an empty array. 1326 If a capability for one of the offered Information Resources is 1327 not explicitly listed here, an ALTO Client may either issue an 1328 OPTIONS HTTP request to the corresponding URI to determine if the 1329 capability is supported, or assume its default value. 1331 If an entry has an empty list for "accepts", then the corresponding 1332 URI MUST support GET requests. If an entry has a non-empty list for 1333 "accepts", then the corresponding URI MUST support POST requests. If 1334 an ALTO Server wishes to support both GET and POST on a single URI, 1335 it MUST specify two entries in the Information Resource Directory. 1337 7.6.3. Example 1339 The following is an example Information Resource Directory returned 1340 by an ALTO Server. In this example, the ALTO Server provides 1341 additional Network and Cost Maps via a separate subdomain, 1342 "custom.alto.example.com". The maps available via this subdomain are 1343 Filtered Network and Cost Maps as well as pre-generated maps for the 1344 "hopcount" and "routingcost" Cost Types in the "ordinal" Cost Mode. 1346 An ALTO Client can discover the maps available by 1347 "custom.alto.example.com" by successfully performing an OPTIONS 1348 request to "http://custom.alto.example.com/maps". 1350 GET /directory HTTP/1.1 1351 Host: alto.example.com 1352 Accept: application/alto-directory+json,application/alto-error+json 1354 HTTP/1.1 200 OK 1355 Content-Length: [TODO] 1356 Content-Type: application/alto-directory+json 1358 { 1359 "resources" : [ 1360 { 1361 "uri" : "http://alto.example.com/serverinfo", 1362 "media-types" : [ "application/alto-serverinfo+json" ] 1363 }, { 1364 "uri" : "http://alto.example.com/networkmap", 1365 "media-types" : [ "application/alto-networkmap+json" ] 1366 }, { 1367 "uri" : "http://alto.example.com/costmap/num/routingcost", 1368 "media-types" : [ "application/alto-costmap+json" ], 1369 "capabilities" : { 1370 "cost-modes" : [ "numerical" ], 1371 "cost-types" : [ "routingcost" ] 1372 } 1373 }, { 1374 "uri" : "http://alto.example.com/costmap/num/hopcount", 1375 "media-types" : [ "application/alto-costmap+json" ], 1376 "capabilities" : { 1377 "cost-modes" : [ "numerical" ], 1378 "cost-types" : [ "hopcount" ] 1379 } 1380 }, { 1381 "uri" : "http://custom.alto.example.com/maps", 1382 "media-types" : [ 1383 "application/alto-networkmap+json", 1384 "application/alto-costmap+json" 1385 ], 1386 "accepts" : [ 1387 "application/alto-networkmapfilter+json", 1388 "application/alto-costmapfilter+json" 1389 ] 1390 }, { 1391 "uri" : "http://alto.example.com/endpointprop/lookup", 1392 "media-types" : [ "application/alto-endpointprop+json" ], 1393 "accepts" : [ "application/alto-endpointpropparams+json" ], 1394 "capabilities" : { 1395 "prop-types" : [ "pid" ] 1396 } 1397 }, { 1398 "uri" : "http://alto.example.com/endpointcost/lookup", 1399 "media-types" : [ "application/alto-endpointcost+json" ], 1400 "accepts" : [ "application/alto-endpointcostparams+json" ], 1401 "capabilities" : { 1402 "cost-constraints" : true, 1403 "cost-modes" : [ "ordinal", "numerical" ], 1404 "cost-types" : [ "routingcost", "hopcount" ] 1405 } 1406 } 1407 ] 1408 } 1410 OPTIONS /maps HTTP/1.1 1411 Host: custom.alto.example.com 1412 Accept: application/alto-directory+json,application/alto-error+json 1413 HTTP/1.1 200 OK 1414 Content-Length: [TODO] 1415 Content-Type: application/alto-directory+json 1417 { 1418 "resources" : [ 1419 { 1420 "uri" : "http://custom.alto.example.com/networkmap/filtered", 1421 "media-types" : [ "application/alto-networkmap+json" ], 1422 "accepts" : [ "application/alto-networkmapfilter+json" ] 1423 }, { 1424 "uri" : "http://custom.alto.example.com/costmap/filtered", 1425 "media-types" : [ "application/alto-costmap+json" ], 1426 "accepts" : [ "application/alto-costmapfilter+json" ], 1427 "capabilities" : { 1428 "cost-constraints" : true, 1429 "cost-modes" : [ "ordinal", "numerical" ], 1430 "cost-types" : [ "routingcost", "hopcount" ] 1431 } 1432 }, { 1433 "uri" : "http://custom.alto.example.com/ord/routingcost", 1434 "media-types" : [ "application/alto-costmap+json" ], 1435 "capabilities" : { 1436 "cost-modes" : [ "ordinal" ], 1437 "cost-types" : [ "routingcost" ] 1438 } 1439 }, { 1440 "uri" : "http://custom.alto.example.com/ord/hopcount", 1441 "media-types" : [ "application/alto-costmap+json" ], 1442 "capabilities" : { 1443 "cost-modes" : [ "ordinal" ], 1444 "cost-types" : [ "hopcount" ] 1445 } 1446 } 1447 ] 1448 } 1450 7.6.4. Usage Considerations 1452 7.6.4.1. ALTO Client 1454 This document specifies no requirements or constraints on ALTO 1455 Clients with regards to how they process an Information Resource 1456 Directory to identify the URI corresponding to a desired Information 1457 Resource. However, some advice is provided for implementors. 1459 It is possible that multiple entries in the directory match a desired 1460 Information Resource. For instance, in the example in Section 7.6.3, 1461 a full Cost Map with "numerical" Cost Mode and "routingcost" Cost 1462 Type could be retrieved via a GET request to 1463 "http://alto.example.com/costmap/num/routingcost", or via a POST 1464 request to "http://custom.alto.example.com/costmap/filtered". 1466 In general, it is preferred for ALTO Clients to use GET requests 1467 where appropriate, since it is more likely for responses to be 1468 cacheable. 1470 7.6.4.2. ALTO Server 1472 This document indicates that an ALTO Server may or may not provide 1473 the Information Resources specified in the Map Filtering Service. If 1474 these resources are not provided, it is indicated to an ALTO Client 1475 by the absence of a Network Map or Cost Map with any media types 1476 listed under "accepts". 1478 7.7. Information Resources 1480 This section documents the individual Information Resources defined 1481 in the ALTO Protocol. 1483 7.7.1. Server Information Service 1485 The Server Information Service provides generic information about an 1486 ALTO Server. 1488 7.7.1.1. Server Info 1490 This Information Resource MUST be provided by an ALTO Server. 1492 7.7.1.1.1. Media Type 1494 The media type is "application/alto-serverinfo+json". 1496 7.7.1.1.2. HTTP Method 1498 This resource is requested using the HTTP GET method. 1500 7.7.1.1.3. Input Parameters 1502 None. 1504 7.7.1.1.4. Capabilities 1506 None. 1508 7.7.1.1.5. Response 1510 The returned InfoResourceEntity object has "data" member of type 1511 InfoResourceServerInfo: 1513 object { 1514 JSONString service-id; [OPTIONAL] 1515 JSONString certificates<0..*>; [OPTIONAL] 1516 } InfoResourceServerInfo; 1518 which has members: 1520 service-id UUID [RFC4122] indicating an one or more ALTO Servers 1521 serving equivalent ALTO Information. 1523 certificates List of PEM-encoded X.509 certificates used by the ALTO 1524 Server in the signing of responses. 1526 If an ALTO Server has the possibility of marking any response as 1527 redistributable, the 'service-id' and 'certificates' fields are 1528 REQUIRED instead of OPTIONAL. See Section 8&$160;for detailed 1529 specification. 1531 7.7.1.1.6. Example 1533 GET /serverinfo HTTP/1.1 1534 Host: alto.example.com 1535 Accept: application/alto-serverinfo+json,application/alto-error+json 1537 HTTP/1.1 200 OK 1538 Content-Length: [TODO] 1539 Content-Type: application/alto-serverinfo+json 1541 { 1542 "meta" : {}, 1543 "data" : { 1544 "service-id" : "c89ca72f-dead-41b5-9e2b-b65455ace1ee", 1545 "certificates" : [ ... ] 1546 } 1547 } 1549 7.7.2. Map Service 1551 The Map Service provides batch information to ALTO Clients in the 1552 form of two types of maps: a Network Map and Cost Map. 1554 7.7.2.1. Network Map 1556 The Network Map Information Resource lists for each PID, the network 1557 locations (endpoints) within the PID. It MUST be provided by an ALTO 1558 Server. 1560 7.7.2.1.1. Media Type 1562 The media type is "application/alto-networkmap+json". 1564 7.7.2.1.2. HTTP Method 1566 This resource is requested using the HTTP GET method. 1568 7.7.2.1.3. Input Parameters 1570 None. 1572 7.7.2.1.4. Capabilities 1574 None. 1576 7.7.2.1.5. Response 1578 The returned InfoResourceEntity object "data" member of type 1579 InfoResourceNetworkMap: 1581 object { 1582 EndpointAddrGroup [pidname]<0..*>; 1583 ... 1584 } NetworkMapData; 1586 object { 1587 JSONString map-vtag; 1588 NetworkMapData map; 1589 } InfoResourceNetworkMap; 1591 with members: 1593 map-vtag The Version Tag (Section 5.3) of the Network Map. 1595 map The Network Map data itself. 1597 NetworkMapData is a JSON object with each member representing a 1598 single PID and its associated set of endpoint addresses. A member's 1599 name is a string of type PIDName. 1601 The returned Network Map MUST include all PIDs known to the ALTO 1602 Server. 1604 7.7.2.1.6. Example 1606 GET /networkmap HTTP/1.1 1607 Host: alto.example.com 1608 Accept: application/alto-networkmap+json,application/alto-error+json 1609 HTTP/1.1 200 OK 1610 Content-Length: [TODO] 1611 Content-Type: application/alto-networkmap+json 1613 { 1614 "meta" : {}, 1615 "data" : { 1616 "map-vtag" : "1266506139", 1617 "map" : { 1618 "PID1" : { 1619 "ipv4" : [ 1620 "192.0.2.0/24", 1621 "198.51.100.0/25" 1622 ] 1623 }, 1624 "PID2" : { 1625 "ipv4" : [ 1626 "198.51.100.128/25" 1627 ] 1628 }, 1629 "PID3" : { 1630 "ipv4" : [ 1631 "0.0.0.0/0" 1632 ], 1633 "ipv6" : [ 1634 "::/0" 1635 ] 1636 } 1637 } 1638 } 1639 } 1641 7.7.2.2. Cost Map 1643 The Cost Map resource lists the Path Cost for each pair of source/ 1644 destination PID defined by the ALTO Server for a given Cost Type and 1645 Cost Mode. This resource MUST be provided for at least the 1646 'routingcost' Cost Type and 'numerical' Cost Mode. 1648 Note that since this resource, an unfiltered Cost Map requested by an 1649 HTTP GET, does not indicate the desired Cost Mode or Cost Type as 1650 input parameters, an ALTO Server MUST indicate in an Information 1651 Resource Directory a unfiltered Cost Map Information Resource by 1652 specifying the capabilities (Section 7.7.2.2.4) with "cost-types" and 1653 "cost-modes" members each having a single element. This technique 1654 will allow an ALTO Client to determine a URI for an unfiltered Cost 1655 Map of the desired Cost Mode and Cost Type. 1657 7.7.2.2.1. Media Type 1659 The media type is "application/alto-costmap+json". 1661 7.7.2.2.2. HTTP Method 1663 This resource is requested using the HTTP GET method. 1665 7.7.2.2.3. Input Parameters 1667 None. 1669 7.7.2.2.4. Capabilities 1671 This resource may be defined for across multiple Cost Types and Cost 1672 Modes. The capabilities of an ALTO Server URI providing this 1673 resource are defined by a JSON Object of type CostMapCapability: 1675 object { 1676 CostMode cost-modes<0..*>; 1677 CostType cost-types<0..*>; 1678 } CostMapCapability; 1680 with members: 1682 cost-modes The Cost Modes ( Section 5.1.2) supported by the 1683 corresponding URI. If not present, this member MUST be 1684 interpreted as an empty array. 1686 cost-types The Cost Types ( Section 5.1.1) supported by the 1687 corresponding URI. If not present, this member MUST be 1688 interpreted as an empty array. 1690 An ALTO Server MUST support all of the Cost Types listed here for 1691 each of the listed Cost Modes. Note that an ALTO Server may provide 1692 multiple Cost Map Information Resources, each with different 1693 capabilities. 1695 7.7.2.2.5. Response 1697 The returned InfoResourceEntity object has "data" member of type 1698 InfoResourceCostMap: 1700 object DstCosts { 1701 JSONNumber [PIDName]; 1702 ... 1703 }; 1705 object { 1706 DstCosts [PIDName]<0..*>; 1707 ... 1708 } CostMapData; 1710 object { 1711 CostMode cost-mode; 1712 CostType cost-type; 1713 JSONString map-vtag; 1714 CostMapData map; 1715 } InfoResourceCostMap; 1717 with members: 1719 cost-mode Cost Mode (Section 5.1.2) used in the Cost Map. 1721 cost-type Cost Type (Section 5.1.1) used in the Cost Map. 1723 map-vtag The Version Tag (Section 5.3) of the Network Map used to 1724 generate the Cost Map. 1726 map The Cost Map data itself. 1728 CostMapData is a JSON object with each member representing a single 1729 Source PID; the name for a member is the PIDName string identifying 1730 the corresponding Source PID. For each Source PID, a DstCosts object 1731 denotes the associated cost to a set of destination PIDs ( 1732 Section 5.2); the name for each member in the object is the PIDName 1733 string identifying the corresponding Destination PID. DstCosts MUST 1734 have a single member for each Destination PID in the map. 1736 The returned Cost Map MUST include Path Costs for each pair of Source 1737 PID and Destination PID known to the ALTO Server. 1739 7.7.2.2.6. Example 1741 GET /costmap/num/routingcost HTTP/1.1 1742 Host: alto.example.com 1743 Accept: application/alto-costmap+json,application/alto-error+json 1744 HTTP/1.1 200 OK 1745 Content-Length: [TODO] 1746 Content-Type: application/alto-costmap+json 1748 { 1749 "meta" : {}, 1750 "data" : { 1751 "cost-mode" : "numerical", 1752 "cost-type" : "routingcost", 1753 "map-vtag" : "1266506139", 1754 "map" : { 1755 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 1756 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 1757 "PID3": { "PID1": 20, "PID2": 15, "PID3": 1 } 1758 } 1759 } 1760 } 1762 7.7.3. Map Filtering Service 1764 The Map Filtering Service allows ALTO Clients to specify filtering 1765 criteria to return a subset of the full maps available in the Map 1766 Service. 1768 7.7.3.1. Filtered Network Map 1770 A Filtered Network Map is a Network Map Information Resource 1771 (Section 7.7.2.1) for which an ALTO Client may supply a list of PIDs 1772 to be included. A Filtered Network Map MAY be provided by an ALTO 1773 Server. 1775 7.7.3.1.1. Media Type 1777 See Section 7.7.2.1.1. 1779 7.7.3.1.2. HTTP Method 1781 This resource is requested using the HTTP POST method. 1783 7.7.3.1.3. Input Parameters 1785 Input parameters are supplied in the entity body of the POST request. 1786 This document specifies the input parameters with a data format 1787 indicated by the media type "application/alto-networkmapfilter+json", 1788 which is a JSON Object of type ReqFilteredNetworkMap, where: 1790 object { 1791 PIDName pids<0..*>; 1792 } ReqFilteredNetworkMap; 1794 with members: 1796 pids Specifies list of PIDs to be included in the returned Filtered 1797 Network Map. If the list of PIDs is empty, the ALTO Server MUST 1798 interpret the list as if it contained a list of all currently- 1799 defined PIDs. The ALTO Server MUST interpret entries appearing 1800 multiple times as if they appeared only once. 1802 7.7.3.1.4. Capabilities 1804 None. 1806 7.7.3.1.5. Response 1808 See Section 7.7.2.1.5 for the format. 1810 The ALTO Server MUST only include PIDs in the response that were 1811 specified (implicitly or explicitly) in the request. If the input 1812 parameters contain a PID name that is not currently defined by the 1813 ALTO Server, the ALTO Server MUST behave as if the PID did not appear 1814 in the input parameters. 1816 7.7.3.1.6. Example 1818 POST /networkmap/filtered HTTP/1.1 1819 Host: custom.alto.example.com 1820 Content-Length: [TODO] 1821 Content-Type: application/alto-networkmapfilter+json 1822 Accept: application/alto-networkmap+json,application/alto-error+json 1824 { 1825 "pids": [ "PID1", "PID2" ] 1826 } 1828 HTTP/1.1 200 OK 1829 Content-Length: [TODO] 1830 Content-Type: application/alto-networkmap+json 1832 { 1833 "meta" : {}, 1834 "data" : { 1835 "map-vtag" : "1266506139", 1836 "map" : { 1837 "PID1" : { 1838 "ipv4" : [ 1839 "192.0.2.0/24", 1840 "198.51.100.0/24" 1841 ] 1842 }, 1843 "PID2" : { 1844 "ipv4": [ 1845 "198.51.100.128/24" 1846 ] 1847 } 1848 } 1849 } 1850 } 1852 7.7.3.2. Filtered Cost Map 1854 A Filtered Cost Map is a Cost Map Information Resource 1855 (Section 7.7.2.2) for which an ALTO Client may supply additional 1856 parameters limiting the scope of the resulting Cost Map. A Filtered 1857 Cost Map MAY be provided by an ALTO Server. 1859 7.7.3.2.1. Media Type 1861 See Section 7.7.2.2.1. 1863 7.7.3.2.2. HTTP Method 1865 This resource is requested using the HTTP POST method. 1867 7.7.3.2.3. Input Parameters 1869 Input parameters are supplied in the entity body of the POST request. 1870 This document specifies the input parameters with a data format 1871 indicated by the media type "application/alto-costmapfilter+json", 1872 which is a JSON Object of type ReqFilteredCostMap, where: 1874 object { 1875 PIDName srcs<0..*>; 1876 PIDName dsts<0..*>; 1877 } PIDFilter; 1879 object { 1880 CostMode cost-mode; 1881 CostType cost-type; 1882 JSONString constraints<0..*>; [OPTIONAL] 1883 PIDFilter pids; [OPTIONAL] 1884 } ReqFilteredCostMap; 1886 with members: 1888 cost-type The Cost Type ( Section 5.1.1) for the returned costs. 1889 This MUST be one of the supported Cost Types indicated in this 1890 resource's capabilities ( Section 7.7.3.2.4). 1892 cost-mode The Cost Mode ( Section 5.1.2) for the returned costs. 1893 This MUST be one of the supported Cost Modes indicated in this 1894 resource's capabilities ( Section 7.7.3.2.4). 1896 constraints Defines a list of additional constraints on which 1897 elements of the Cost Map are returned. This parameter MUST NOT be 1898 specified if this resource's capabilities ( Section 7.7.3.2.4) 1899 indicate that constraint support is not available. A constraint 1900 contains two entities separated by whitespace: (1) an operator 1901 either 'gt' for greater than or 'lt' for less than (2) a target 1902 numerical cost. The numerical cost is a number that MUST be 1903 defined in the same units as the Cost Type indicated by the cost- 1904 type parameter. ALTO Servers SHOULD use at least IEEE 754 double- 1905 precision floating point [IEEE.754.2008] to store the numerical 1906 cost, and SHOULD perform internal computations using double- 1907 precision floating-point arithmetic. If multiple 'constraint' 1908 parameters are specified, they are interpreted as being related to 1909 each other with a logical AND. 1911 pids A list of Source PIDs and a list of Destination PIDs for which 1912 Path Costs are to be returned. If a list is empty, the ALTO 1913 Server MUST interpret it as the full set of currently-defined 1914 PIDs. The ALTO Server MUST interpret entries appearing in a list 1915 multiple times as if they appeared only once. If the "pids" 1916 member is not present, both lists MUST be interpreted by the ALTO 1917 Server as containing the full set of currently-defined PIDs. 1919 7.7.3.2.4. Capabilities 1921 The URI providing this resource supports all capabilities documented 1922 in Section 7.7.2.2.4 (with identical semantics), plus additional 1923 capabilities. In particular, the capabilities are defined by a JSON 1924 object of type FilteredCostMapCapability: 1926 object { 1927 CostMode cost-modes<0..*>; 1928 CostType cost-types<0..*>; 1929 JSONBool cost-constraints; 1930 } FilteredCostMapCapability; 1932 with members: 1934 cost-modes See Section 7.7.2.2.4. 1936 cost-types See Section 7.7.2.2.4. 1938 cost-constraints If true, then the ALTO Server allows cost 1939 constraints to be included in requests to the corresponding URI. 1940 If not present, this member MUST be interpreted as if it specified 1941 false. 1943 7.7.3.2.5. Response 1945 See Section 7.7.2.2.5 for the format. 1947 The returned Cost Map MUST NOT contain any source/destination pair 1948 that was not indicated (implicitly or explicitly) in the input 1949 parameters. If the input parameters contain a PID name that is not 1950 currently defined by the ALTO Server, the ALTO Server MUST behave as 1951 if the PID did not appear in the input parameters. 1953 If any constraints are specified, Source/Destination pairs that do 1954 for which the Path Costs do not meet the constraints MUST NOT be 1955 included in the returned Cost Map. If no constraints were specified, 1956 then all Path Costs are assumed to meet the constraints. 1958 7.7.3.2.6. Example 1960 POST /costmap/filtered HTTP/1.1 1961 Host: custom.alto.example.com 1962 Content-Type: application/alto-costmapfilter+json 1963 Accept: application/alto-costmap+json,application/alto-error+json 1965 { 1966 "cost-mode" : "numerical", 1967 "cost-type" : "routingcost", 1968 "pids" : { 1969 "srcs" : [ "PID1" ], 1970 "dsts" : [ "PID1", "PID2", "PID3" ] 1971 } 1972 } 1974 HTTP/1.1 200 OK 1975 Content-Length: [TODO] 1976 Content-Type: application/alto-costmap+json 1978 { 1979 "meta" : {}, 1980 "data" : { 1981 "cost-mode" : "numerical", 1982 "cost-type" : "routingcost", 1983 "map-vtag" : "1266506139", 1984 "map" : { 1985 "PID1": { "PID1": 0, "PID2": 1, "PID3": 2 } 1986 } 1987 } 1988 } 1990 7.7.4. Endpoint Property Service 1992 The Endpoint Property Service provides information about Endpoint 1993 properties to ALTO Clients. 1995 7.7.4.1. Endpoint Property 1997 The Endpoint Property resource provides information about properties 1998 for individual endpoints. It MAY be provided by an ALTO Server. If 1999 an ALTO Server provides the Endpoint Property resource, it MUST 2000 provide and define at least the 'pid' property for each Endpoint. 2002 7.7.4.1.1. Media Type 2004 The media type is "application/alto-endpointprop+json". 2006 7.7.4.1.2. HTTP Method 2008 This resource is requested using the HTTP POST method. 2010 7.7.4.1.3. Input Parameters 2012 Input parameters are supplied in the entity body of the POST request. 2013 This document specifies the data format of input parameteres with the 2014 media type "application/alto-endpointpropparams+json", which is a 2015 JSON Object of type ReqEndpointProp: 2017 object { 2018 EndpointProperty properties<1..*>; 2019 TypedEndpointAddr endpoints<1..*>; 2020 } ReqEndpointProp; 2022 with members: 2024 properties List of endpoint properties to returned for each 2025 endpoint. Each specified property MUST be included in the list of 2026 supported properties indicated by this resource's capabilities ( 2027 Section 7.7.4.1.4). The ALTO Server MUST interpret entries 2028 appearing multiple times as if they appeared only once. 2030 endpoints List of endpoint addresses for which the specified 2031 properties are to be returned. The ALTO Server MUST interpret 2032 entries appearing multiple times as if they appeared only once. 2034 7.7.4.1.4. Capabilities 2036 This resource may be defined across multiple types of endpoint 2037 properties. The capabilities of an ALTO Server URI providing 2038 Endpoint Properties are defined by a JSON Object of type 2039 EndpointPropertyCapability: 2041 object { 2042 EndpointProperty prop-types<0..*>; 2043 } EndpointPropertyCapability; 2045 with members: 2047 prop-types The Endpoint Property Types ( Section 3.2.3) supported by 2048 the corresponding URI. If not present, this member MUST be 2049 interpreted as an empty array. 2051 7.7.4.1.5. Response 2053 The returned InfoResourceEntity object has "data" member of type 2054 InfoResourceEndpointProperty, where: 2056 object { 2057 JSONString [EndpointProperty]; 2058 ... 2059 } EndpointProps; 2061 object { 2062 EndpointProps [TypedEndpointAddr]<0..*>; 2063 ... 2064 } InfoResourceEndpointProperty; 2066 InfoResourceEndpointProperty has one member for each endpoint 2067 indicated in the input parameters (with the name being the endpoint 2068 encoded as a TypedEndpointAddr). The requested properties for each 2069 endpoint are encoded in a corresponding EndpointProps object, which 2070 encodes one name/value pair for each requested property, where the 2071 property names are encoded as strings of type EndpointProperty and 2072 the property values encoded as JSON Strings. 2074 The ALTO Server returns the value for each of the requested endpoint 2075 properties for each of the endpoints listed in the input parameters. 2077 If the ALTO Server does not define a requested property for a 2078 particular endpoint, then it MUST omit it from the response for only 2079 that endpoint. 2081 7.7.4.1.6. Example 2083 POST /endpointprop/lookup HTTP/1.1 2084 Host: alto.example.com 2085 Content-Length: [TODO] 2086 Content-Type: application/alto-endpointpropparams+json 2087 Accept: application/alto-endpointprop+json,application/alto-error+json 2089 { 2090 "properties" : [ "pid" ], 2091 "endpoints" : [ "ipv4:192.0.2.34", "ipv4:203.0.113.129" ] 2092 } 2094 HTTP/1.1 200 OK 2095 Content-Length: [TODO] 2096 Content-Type: application/alto-endpointprop+json 2098 { 2099 "meta" : {}, 2100 "data": { 2101 "ipv4:192.0.2.34" : { "pid": "PID1" }, 2102 "ipv4:203.0.113.129" : { "pid": "PID3" } 2103 } 2104 } 2106 7.7.5. Endpoint Cost Service 2108 The Endpoint Cost Service provides information about costs between 2109 individual endpoints. 2111 In particular, this service allows lists of Endpoint prefixes (and 2112 addresses, as a special case) to be ranked (ordered) by an ALTO 2113 Server. 2115 7.7.5.1. Endpoint Cost 2117 The Endpoint Cost resource provides information about costs between 2118 individual endpoints. It MAY be provided by an ALTO Server. If it 2119 is provided. 2121 It is important to note that although this resource allows an ALTO 2122 Server to reveal costs between individual endpoints, an ALTO Server 2123 is not required to do so. A simple alternative would be to compute 2124 the cost between two endpoints as the cost between the PIDs 2125 corresponding to the endpoints. See Section 12.1 for additional 2126 details. 2128 7.7.5.1.1. Media Type 2130 The media type is "application/alto-endpointcost+json". 2132 7.7.5.1.2. HTTP Method 2134 This resource is requested using the HTTP POST method. 2136 7.7.5.1.3. Input Parameters 2138 Input parameters are supplied in the entity body of the POST request. 2139 This document specifies input parameters with a data format indicated 2140 by media type "application/alto-endpointcostparams+json", which is a 2141 JSON Object of type ReqEndpointCostMap: 2143 object { 2144 TypedEndpointAddr srcs<0..*>; [OPTIONAL] 2145 TypedEndpointAddr dsts<1..*>; 2146 } EndpointFilter; 2148 object { 2149 CostMode cost-mode; 2150 CostType cost-type; 2151 JSONString constraints; [OPTIONAL] 2152 EndpointFilter endpoints; 2153 } ReqEndpointCostMap; 2155 with members: 2157 cost-mode The Cost Mode ( Section 5.1.2) to use for returned costs. 2158 This MUST be one of the Cost Modes indicated in this resource's 2159 capabilities ( Section 7.7.5.1.4). 2161 cost-type The Cost Type ( Section 5.1.1) to use for returned costs. 2162 This MUST be one of the Cost Types indicated in this resource's 2163 capabilities ( Section 7.7.5.1.4). 2165 constraints Defined equivalently to the "constraints" input 2166 parameter of a Filtered Cost Map (see Section 7.7.3.2). 2168 endpoints A list of Source Endpoints and Destination Endpoints for 2169 which Path Costs are to be returned. If the list of Source 2170 Endpoints is empty (or not included), the ALTO Server MUST 2171 interpret it as if it contained the Endpoint Address corresponding 2172 to the client IP address from the incoming connection (see 2173 Section 10.3 for discussion and considerations regarding this 2174 mode). The list of destination Endpoints MUST NOT be empty. The 2175 ALTO Server MUST interpret entries appearing multiple times in a 2176 list as if they appeared only once. 2178 7.7.5.1.4. Capabilities 2180 See Section 7.7.3.2.4. 2182 7.7.5.1.5. Response 2184 The returned InfoResourceEntity object has "data" member equal to 2185 InfoResourceEndpointCostMap, where: 2187 object EndpointDstCosts { 2188 JSONNumber [TypedEndpointAddr]; 2189 ... 2190 }; 2192 object { 2193 EndpointDstCosts [TypedEndpointAddr]<0..*>; 2194 ... 2195 } EndpointCostMapData; 2197 object { 2198 CostMode cost-mode; 2199 CostType cost-type; 2200 EndpointCostMapData map; 2201 } InfoResourceEndpointCostMap; 2203 InfoResourceEndpointCostMap has members: 2205 cost-mode The Cost Mode used in the returned Cost Map. 2207 cost-type The Cost Type used in the returned Cost Map. 2209 map The Endpoint Cost Map data itself. 2211 EndpointCostMapData is a JSON object with each member representing a 2212 single Source Endpoint specified in the input parameters; the name 2213 for a member is the TypedEndpointAddr string identifying the 2214 corresponding Source Endpoint. For each Source Endpoint, a 2215 EndpointDstCosts object denotes the associated cost to each 2216 Destination Endpoint specified in the input parameters; the name for 2217 each member in the object is the TypedEndpointAddr string identifying 2218 the corresponding Destination Endpoint. 2220 7.7.5.1.6. Example 2222 POST /endpointcost/lookup HTTP/1.1 2223 Host: alto.example.com 2224 Content-Length: [TODO] 2225 Content-Type: application/alto-endpointcostparams+json 2226 Accept: application/alto-endpointcost+json,application/alto-error+json 2228 { 2229 "cost-mode" : "ordinal", 2230 "cost-type" : "routingcost", 2231 "endpoints" : { 2232 "srcs": [ "ipv4:192.0.2.2" ], 2233 "dsts": [ 2234 "ipv4:192.0.2.89", 2235 "ipv4:198.51.100.34", 2236 "ipv4:203.0.113.45" 2237 ] 2238 } 2239 } 2241 HTTP/1.1 200 OK 2242 Content-Length: [TODO] 2243 Content-Type: application/alto-endpointcost+json 2245 { 2246 "meta" : {}, 2247 "data" : { 2248 "cost-mode" : "ordinal", 2249 "cost-type" : "routingcost", 2250 "map" : { 2251 "ipv4:192.0.2.2": { 2252 "ipv4:192.0.2.89" : 1, 2253 "ipv4:198.51.100.34" : 2, 2254 "ipv4:203.0.113.45" : 3 2255 } 2256 } 2257 } 2258 } 2260 8. Redistributable Responses 2262 This section defines how an ALTO Server enables certain Information 2263 Resources to be redistributed by ALTO Clients. Concepts are first 2264 introduced, followed by the protocol specification. 2266 8.1. Concepts 2268 8.1.1. Service ID 2270 The Service ID is a UUID that identifies a set of ALTO Servers that 2271 would provide semantically-identical Information Resources for any 2272 request for any ALTO Client. Each ALTO Server within such a set is 2273 configured with an identical Service ID. 2275 If a pair of ALTO Servers would provide an identical Information 2276 Resource (same information sources, configuration, internal 2277 computations, update timescales, etc) in response to any particular 2278 ALTO Client request, then the pair of ALTO Servers MAY have the same 2279 Service ID. If this condition is not true, the pair of ALTO Servers 2280 MUST have a different Service ID. 2282 8.1.1.1. Rationale 2284 For scalability and fault tolerance, multiple ALTO Servers may be 2285 deployed to serve equivalent ALTO Information. In such a scenario, 2286 Information Resources from any such redundant server should be seen 2287 as equivalent for the purposes of redistribution. For example, if 2288 two ALTO Servers A and B are deployed by the service provider to 2289 distribute equivalent ALTO Information, then clients contacting 2290 Server A should be able to redistribute Information Resources to 2291 clients contacting Server B. 2293 To accomplish this behavior, ALTO Clients must be able to determine 2294 that Server A and Server B serve identical ALTO Information. One 2295 technique would be to rely on the ALTO Server's DNS name. However, 2296 such an approach would mandate that all ALTO Servers resolved by a 2297 particular DNS name would need to provide equivalent ALTO 2298 information, which may be unnecessarily restrictive. Another 2299 technique would be to rely on the server's IP address. However, this 2300 suffers similar problems as the DNS name in deployment scenarios 2301 using IP Anycast. 2303 To avoid such restrictions, the ALTO Protocol allows an ALTO Service 2304 Provider to explicitly denote ALTO Servers that provide equivalent 2305 ALTO Information by giving them identical Service IDs. Service IDs 2306 decouple the identification of equivalent ALTO Servers from the 2307 discovery process. 2309 8.1.1.2. Server Information Resource 2311 If an ALTO Server generates redistributable responses, the Server 2312 Information resource's 'service-id' field MUST be set to the ALTO 2313 Server's Service ID. 2315 8.1.1.3. Configuration 2317 To help prevent ALTO Servers from mistakenly claiming to distribute 2318 equivalent ALTO Information, ALTO Server implementations SHOULD by 2319 default generate a new UUID at installation time or startup if one 2320 has not explicitly been configured. 2322 8.1.2. Expiration Time 2324 Information Resources marked as redistributable should indicate a 2325 time after which the information is considered stale and should be 2326 refreshed from the ALTO Server (or possibly another ALTO Client). 2328 If an expiration time is present, the ALTO Server SHOULD ensure that 2329 it is reasonably consistent with the expiration time that would be 2330 computed by HTTP header fields. This specification makes no 2331 recommendation on which expiration time takes precedence, but 2332 implementers should be cognizant that HTTP intermediaries will obey 2333 only the HTTP header fields. 2335 8.1.3. Signature 2337 Information Resources marked as redistributable include a signature 2338 used to assert that the ALTO Server Provider generated the ALTO 2339 Information. 2341 8.1.3.1. Rationale 2343 Verification of the signature requires the ALTO Client to retrieve 2344 the ALTO Server's public key. To reduce requirements on the 2345 underlying transport (i.e., requiring SSL/TLS), an ALTO Client 2346 retrieves the public key as part of an X.509 certificate from the 2347 ALTO Server's Server Information resource. 2349 8.1.3.2. Certificates 2351 8.1.3.2.1. Local Certificate 2353 The ALTO Server's public key is encoded within an X.509 certificate. 2354 The corresponding private key MUST be used to sign redistributable 2355 responses. This certificate is termed the Local Certificate for an 2356 ALTO Server. 2358 8.1.3.2.2. Certificate Chain 2360 To ease key provisioning, the ALTO Protocol is designed such that 2361 each ALTO Server with an identical Service ID may have a unique 2362 private key (and hence certificate). 2364 The ALTO Service Provider may configure a certificate chain at each 2365 such ALTO Server. The Local Certificate for a single ALTO Server is 2366 the bottom-most certificate in the chain. The Certificate Chains of 2367 each ALTO Server with an identical Service ID MUST share a common 2368 Root Certificate. 2370 Note that there are two simple deployment scenarios: 2372 o One-Level Certificate Chain (Local Certificate Only): In this 2373 deployment scenario, each ALTO Server with an identical Service ID 2374 may provisioned with an identical Local Certificate. 2376 o Two-Level Certificate Chain: In this deployment scenario, a Root 2377 Certificate is maintained for a set of ALTO Servers with the same 2378 Service ID. A unique Local Certificate signed by this CA is 2379 provisioned to each ALTO Server. 2381 There are advantages to using a Certificate Chain instead of 2382 deploying the same Local Certificate to each ALTO Server. 2383 Specifically, it avoids storage of the CA's private key at ALTO 2384 Servers. It is possible to revoke and re-issue a key to a single 2385 ALTO Server. 2387 8.1.3.2.3. Server Information Resource 2389 If an ALTO Server generates redistributable responses, the Server 2390 Information resource's 'certificates' field MUST be populated with 2391 the ALTO Server's full certificate chain. The first element MUST be 2392 the ALTO Server's Local Certificate, followed by the remaining 2393 Certificate Chain in ascending order to the Root Certificate. 2395 8.1.3.3. Signature Verification 2397 ALTO Clients SHOULD verify the signature on any ALTO information 2398 received via redistribution before adjusting application behavior 2399 based on it. 2401 An ALTO Client SHOULD cache its ALTO Server's Service ID and 2402 corresponding Certificate Chain included in the Server Information 2403 resource. Recall that the last certificate in this chain is the Root 2404 Certificate. The retrieval of the Service ID and certificates SHOULD 2405 be secured using HTTPS with proper validation of the server endpoint 2406 of the SSL/TLS connection [RFC6125]. 2408 An Information Resource received via redistribution from Service ID S 2409 is declared valid if an ALTO Client can construct a transitive 2410 certificate chain from the certificate (public key) used to sign the 2411 Information Resource to the Root Certificate corresponding to Service 2412 ID S obtained by the ALTO Client in a Server Information resource. 2414 To properly construct the chain and complete this validation, an ALTO 2415 Client may need to request additional certificates from other ALTO 2416 Clients. A simple mechanism is to request the certificate chain from 2417 the ALTO Client that received the Information Resource. Note that 2418 these additional received certificates may be cached locally by an 2419 ALTO Client. 2421 ALTO Clients SHOULD verify Information Resources received via 2422 redistribution. 2424 8.1.3.4. Redistribution by ALTO Clients 2426 ALTO Clients SHOULD pass the ALTO Server Certificate, Signature, and 2427 Signature Algorithm along with the Information Resource. The 2428 mechanism for redistributing such information is not specified by the 2429 ALTO Protocol, but one possibility is to add additional messages or 2430 fields to the application's native protocol. 2432 8.2. Protocol 2434 An ALTO Server MAY indicate that a response is suitable for 2435 redistribution by including the "redistribution" member in the 2436 RspMetaData JSON object of an Information Resource. This additional 2437 member, called the Response Redistribution Descriptor, has type 2438 InfoResourceRedistDesc: 2440 object { 2441 JSONString service-id; 2442 JSONString request-uri; 2443 JSONValue request-body; 2444 JSONString media-type; 2445 JSONString expires; 2446 } InfoResourceRedistDesc; 2448 The fields encoded in the Response Redistribution Descriptor allows 2449 an ALTO Client receiving redistributed ALTO Information to understand 2450 the context of the query (the ALTO Service generating the response 2451 and any input parameters) and to interpret the results. 2453 Information about ALTO Client performing the request and any HTTP 2454 Headers passed in the request are not included in the Response 2455 Redistribution Descriptor. If any such information or headers 2456 influence the response generated by the ALTO Server, the response 2457 SHOULD NOT be indicated as redistributable. 2459 8.2.1. Response Redistribution Descriptor Fields 2461 This section defines the fields of the Response Redistribution 2462 Descriptor. 2464 8.2.1.1. Service ID 2466 The 'service-id' member is REQUIRED and MUST have a value equal to 2467 the ALTO Server's Service ID. 2469 8.2.1.2. Request URI 2471 The 'request-uri' member is REQUIRED and MUST specify the HTTP 2472 Request-URI that was passed in the HTTP request. 2474 8.2.1.3. Request Body 2476 If the HTTP request's entity body was non-empty, the 'request-body' 2477 member MUST specify full JSON value passed in the HTTP request's 2478 entity body (note that whitespace may differ, as long as the JSON 2479 Value is identical). If the HTTP request was empty, then the 2480 'request-body' MUST NOT be included. 2482 8.2.1.4. Response Media Type 2484 The 'media-type' member is REQUIRED and MUST specify the same HTTP 2485 Content-Type that is used in the HTTP response. 2487 8.2.1.5. Expiration Time 2489 The 'expires' element is RECOMMENDED and, if present, MUST specify a 2490 time in UTC formatted according to [RFC3339]. 2492 8.2.2. Signature 2494 The Hash Algorithm, Signature Algorithm, and Signature are included 2495 as either HTTP Headers or Trailers. Headers may be useful if 2496 Information Resources are pre-generated, while Trailers may be useful 2497 if Information Resources are dynamically generated (e.g., to avoid 2498 buffering large responses in memory while the hash value is 2499 computed). 2501 The following HTTP Headers (the ALTO Server MAY specify them as HTTP 2502 Trailers instead) MUST be used to encode the Signature parameters for 2503 redistributable Information Resources: 2505 ALTO-HashAlgorithm: 2506 ALTO-SignatureAlgorithm: 2507 ALTO-SignatureDigest: 2509 where and are an integer values 2510 from the IANA TLS HashAlgorithm and SignatureAlgorithm registries, 2511 and is the corresponding Base64-encoded signature. 2513 9. Use Cases 2515 The sections below depict typical use cases. 2517 9.1. ALTO Client Embedded in P2P Tracker 2519 Many P2P currently-deployed P2P systems use a Tracker to manage 2520 swarms and perform peer selection. P2P trackers may currently use a 2521 variety of information to perform peer selection to meet application- 2522 specific goals. By acting as an ALTO Client, an P2P tracker can use 2523 ALTO information as an additional information source to enable more 2524 network-efficient traffic patterns and improve application 2525 performance. 2527 A particular requirement of many P2P trackers is that they must 2528 handle a large number of P2P clients. A P2P tracker can obtain and 2529 locally store ALTO information (the Network Map and Cost Map) from 2530 the ISPs containing the P2P clients, and benefit from the same 2531 aggregation of network locations done by ALTO Servers. 2533 .---------. (1) Get Network Map .---------------. 2534 | | <----------------------> | | 2535 | ALTO | | P2P Tracker | 2536 | Server | (2) Get Cost Map | (ALTO Client) | 2537 | | <----------------------> | | 2538 `---------' `---------------' 2539 ^ | 2540 (3) Get Peers | | (4) Selected Peer 2541 | v List 2542 .---------. .-----------. 2543 | Peer 1 | <-------------- | P2P | 2544 `---------' | Client | 2545 . (5) Connect to `-----------' 2546 . Selected Peers / 2547 .---------. / 2548 | Peer 50 | <------------------ 2549 `---------' 2551 Figure 4: ALTO Client Embedded in P2P Tracker 2553 Figure 4 shows an example use case where a P2P tracker is an ALTO 2554 Client and applies ALTO information when selecting peers for its P2P 2555 clients. The example proceeds as follows: 2557 1. The P2P Tracker requests the Network Map covering all PIDs from 2558 the ALTO Server using the Network Map query. The Network Map 2559 includes the IP prefixes contained in each PID, allowing the P2P 2560 tracker to locally map P2P clients into a PIDs. 2562 2. The P2P Tracker requests the Cost Map amongst all PIDs from the 2563 ALTO Server. 2565 3. A P2P Client joins the swarm, and requests a peer list from the 2566 P2P Tracker. 2568 4. The P2P Tracker returns a peer list to the P2P client. The 2569 returned peer list is computed based on the Network Map and Cost 2570 Map returned by the ALTO Server, and possibly other information 2571 sources. Note that it is possible that a tracker may use only 2572 the Network Map to implement hierarchical peer selection by 2573 preferring peers within the same PID and ISP. 2575 5. The P2P Client connects to the selected peers. 2577 Note that the P2P tracker may provide peer lists to P2P clients 2578 distributed across multiple ISPs. In such a case, the P2P tracker 2579 may communicate with multiple ALTO Servers. 2581 9.2. ALTO Client Embedded in P2P Client: Numerical Costs 2583 P2P clients may also utilize ALTO information themselves when 2584 selecting from available peers. It is important to note that not all 2585 P2P systems use a P2P tracker for peer discovery and selection. 2586 Furthermore, even when a P2P tracker is used, the P2P clients may 2587 rely on other sources, such as peer exchange and DHTs, to discover 2588 peers. 2590 When an P2P Client uses ALTO information, it typically queries only 2591 the ALTO Server servicing its own ISP. The my-Internet view provided 2592 by its ISP's ALTO Server can include preferences to all potential 2593 peers. 2595 .---------. (1) Get Network Map .---------------. 2596 | | <----------------------> | | 2597 | ALTO | | P2P Client | 2598 | Server | (2) Get Cost Map | (ALTO Client) | 2599 | | <----------------------> | | .---------. 2600 `---------' `---------------' <- | P2P | 2601 .---------. / | ^ ^ | Tracker | 2602 | Peer 1 | <-------------- | | \ `---------' 2603 `---------' | (3) Gather Peers 2604 . (4) Select Peers | | \ 2605 . and Connect / .--------. .--------. 2606 .---------. / | P2P | | DHT | 2607 | Peer 50 | <---------------- | Client | `--------' 2608 `---------' | (PEX) | 2609 `--------' 2611 Figure 5: ALTO Client Embedded in P2P Client 2613 Figure 5 shows an example use case where a P2P Client locally applies 2614 ALTO information to select peers. The use case proceeds as follows: 2616 1. The P2P Client requests the Network Map covering all PIDs from 2617 the ALTO Server servicing its own ISP. 2619 2. The P2P Client requests the Cost Map amongst all PIDs from the 2620 ALTO Server. The Cost Map by default specifies numerical costs. 2622 3. The P2P Client discovers peers from sources such as Peer Exchange 2623 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2624 P2P Trackers. 2626 4. The P2P Client uses ALTO information as part of the algorithm for 2627 selecting new peers, and connects to the selected peers. 2629 9.3. ALTO Client Embedded in P2P Client: Ranking 2631 It is also possible for a P2P Client to offload the selection and 2632 ranking process to an ALTO Server. In this use case, the ALTO Client 2633 gathers a list of known peers in the swarm, and asks the ALTO Server 2634 to rank them. 2636 As in the use case using numerical costs, the P2P Client typically 2637 only queries the ALTO Server servicing its own ISP. 2639 .---------. .---------------. 2640 | | | | 2641 | ALTO | (2) Get Endpoint Ranking | P2P Client | 2642 | Server | <----------------------> | (ALTO Client) | 2643 | | | | .---------. 2644 `---------' `---------------' <- | P2P | 2645 .---------. / | ^ ^ | Tracker | 2646 | Peer 1 | <-------------- | | \ `---------' 2647 `---------' | (1) Gather Peers 2648 . (3) Connect to | | \ 2649 . Selected Peers / .--------. .--------. 2650 .---------. / | P2P | | DHT | 2651 | Peer 50 | <---------------- | Client | `--------' 2652 `---------' | (PEX) | 2653 `--------' 2655 Figure 6: ALTO Client Embedded in P2P Client: Ranking 2657 Figure 6 shows an example of this scenario. The use case proceeds as 2658 follows: 2660 1. The P2P Client discovers peers from sources such as Peer Exchange 2661 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2662 P2P Trackers. 2664 2. The P2P Client queries the ALTO Server's Ranking Service, 2665 including discovered peers as the set of Destination Endpoints, 2666 and indicates the 'ordinal' Cost Mode. The response indicates 2667 the ranking of the candidate peers. 2669 3. The P2P Client connects to the peers in the order specified in 2670 the ranking. 2672 10. Discussions 2673 10.1. Discovery 2675 The discovery mechanism by which an ALTO Client locates an 2676 appropriate ALTO Server is out of scope for this document. This 2677 document assumes that an ALTO Client can discover an appropriate ALTO 2678 Server. Once it has done so, the ALTO Client may use the Information 2679 Resource Directory (see Section 7.6) to locate an Information 2680 Resource with the desired ALTO Information. 2682 10.2. Hosts with Multiple Endpoint Addresses 2684 In practical deployments, especially during the transition from IPv4 2685 to IPv6, a particular host may be reachable using multiple addresses. 2686 Furthermore, the particular network path followed when sending 2687 packets to the host may differ based on the address that is used. 2688 Network providers may prefer one path over another (e.g., one path my 2689 have a NAT64 middlebox). An additional consideration may be how to 2690 handle private address spaces (e.g., behind carrier-grade NATs). 2692 To support such behavior, this document allows multiple types of 2693 endpoint addresses. In supporting multiple address types, the ALTO 2694 Protocol also allows ALTO Service Provider the flexibility to 2695 indicate preferences for paths from an endpoint address of one type 2696 to an endpoint address of a different type. Note that in general, 2697 the path through the network may differ dependent on the types of 2698 addresses that are used. 2700 Note that there are limitations as to what information ALTO can 2701 provide in this regard. In particular, a particular ALTO Service 2702 provider may not be able to determine if connectivity with a 2703 particular endhost will succeed over IPv4 or IPv6, as this may depend 2704 upon information unknown to the ISP such as particular application 2705 implementations. 2707 10.3. Network Address Translation Considerations 2709 At this day and age of NAT v4<->v4, v4<->v6 [RFC6144], and possibly 2710 v6<->v6[I-D.mrw-nat66], a protocol should strive to be NAT friendly 2711 and minimize carrying IP addresses in the payload, or provide a mode 2712 of operation where the source IP address provide the information 2713 necessary to the server. 2715 The protocol specified in this document provides a mode of operation 2716 where the source network location is computed by the ALTO Server 2717 (i.e., the the Endpoint Cost Service) from the source IP address 2718 found in the ALTO Client query packets. This is similar to how some 2719 P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS 2720 Protocol" in [BitTorrent]) operate. 2722 The ALTO client SHOULD use the Session Traversal Utilities for NAT 2723 (STUN) [RFC5389] to determine a public IP address to use as a source 2724 Endpoint address. If using this method, the host MUST use the 2725 "Binding Request" message and the resulting "XOR-MAPPED-ADDRESS" 2726 parameter that is returned in the response. Using STUN requires 2727 cooperation from a publicly accessible STUN server. Thus, the ALTO 2728 client also requires configuration information that identifies the 2729 STUN server, or a domain name that can be used for STUN server 2730 discovery. To be selected for this purpose, the STUN server needs to 2731 provide the public reflexive transport address of the host. 2733 10.4. Mapping IPs to ASNs 2735 It may be desired for the ALTO Protocol to provide ALTO information 2736 including ASNs. Thus, ALTO Clients may need to identify the ASN for 2737 a Resource Provider to determine the cost to that Resource Provider. 2739 Applications can already map IPs to ASNs using information from a BGP 2740 Looking Glass. To do so, they must download a file of about 1.5MB 2741 when compressed (as of October 2008, with all information not needed 2742 for IP to ASN mapping removed) and periodically (perhaps monthly) 2743 refresh it. 2745 Alternatively, the Network Map query in the Map Filtering Service 2746 defined in this document could be extended to map ASNs into a set of 2747 IP prefixes. The mappings provided by the ISP would be both smaller 2748 and more authoritative. 2750 For simplicity of implementation, it's highly desirable that clients 2751 only have to implement exactly one mechanism of mapping IPs to ASNs. 2753 10.5. Endpoint and Path Properties 2755 An ALTO Server could make available many properties about Endpoints 2756 beyond their network location or grouping. For example, connection 2757 type, geographical location, and others may be useful to 2758 applications. This specification focuses on network location and 2759 grouping, but the protocol may be extended to handle other Endpoint 2760 properties. 2762 11. IANA Considerations 2764 11.1. application/alto-* Media Types 2766 This document requests the registration of multiple media types, 2767 listed in Table 2. 2769 +-------------+------------------------------+-----------------+ 2770 | Type | Subtype | Specification | 2771 +-------------+------------------------------+-----------------+ 2772 | application | alto-directory+json | Section 7.6 | 2773 | application | alto-serverinfo+json | Section 7.7.1.1 | 2774 | application | alto-networkmap+json | Section 7.7.2.1 | 2775 | application | alto-networkmapfilter+json | Section 7.7.3.1 | 2776 | application | alto-costmap+json | Section 7.7.2.2 | 2777 | application | alto-costmapfilter+json | Section 7.7.3.2 | 2778 | application | alto-endpointprop+json | Section 7.7.4.1 | 2779 | application | alto-endpointpropparams+json | Section 7.7.4.1 | 2780 | application | alto-endpointcost+json | Section 7.7.5.1 | 2781 | application | alto-endpointcostparams+json | Section 7.7.5.1 | 2782 | application | alto-error+json | Section 7.4 | 2783 +-------------+------------------------------+-----------------+ 2785 Table 2: ALTO Protocol Media Types 2787 Type name: application 2789 Subtype name: This documents requests the registration of multiple 2790 subtypes, as listed in Table 2. 2792 Required parameters: n/a 2794 Optional parameters: n/a 2796 Encoding considerations: Encoding considerations are identical to 2797 those specified for the 'application/json' media type. See 2798 [RFC4627]. 2800 Security considerations: Security considerations relating to the 2801 generation and consumption of ALTO protocol messages are discussed 2802 in Section 12. 2804 Interoperability considerations: This document specifies format of 2805 conforming messages and the interpretation thereof. 2807 Published specification: This document is the specification for 2808 these media types; see Table 2for the section documenting each 2809 media type. 2811 Applications that use this media type: ALTO Servers and ALTO Clients 2812 either standalone or embedded within other applications. 2814 Additional information: 2816 Magic number(s): n/a 2818 File extension(s): This document uses the mime type to refer to 2819 protocol messages and thus does not require a file extension. 2821 Macintosh file type code(s): n/a 2823 Person & email address to contact for further information: See 2824 "Authors' Addresses" section. 2826 Intended usage: COMMON 2828 Restrictions on usage: n/a 2830 Author: See "Authors' Addresses" section. 2832 Change controller: See "Authors' Addresses" section. 2834 11.2. ALTO Cost Type Registry 2836 This document requests the creation of an ALTO Cost Type registry to 2837 be maintained by IANA. 2839 This registry serves two purposes. First, it ensures uniqueness of 2840 identifiers referring to ALTO Cost Types. Second, it provides 2841 references to particular semantics of allocated Cost Types to be 2842 applied by both ALTO Servers and applications utilizing ALTO Clients. 2844 New ALTO Cost Types are assigned after Expert Review [RFC5226]. The 2845 Expert Reviewer will generally consult the ALTO Working Group or its 2846 successor. Expert Review is used to ensure that proper documentation 2847 regarding ALTO Cost Type semantics and security considerations has 2848 been provided. The provided documentation should be detailed enough 2849 to provide guidance to both ALTO Service Providers and applications 2850 utilizing ALTO Clients as to how values of the registered ALTO Cost 2851 Type should be interpreted. Updates and deletions of ALTO Cost Types 2852 follow the same procedure. 2854 Registered ALTO Cost Type identifiers MUST conform to the syntatical 2855 requirements specified in Section 7.5.4. Identifiers are to be 2856 recorded and displayed as ASCII strings. 2858 Identifiers prefixed with 'priv:' are reserved for Private Use. 2859 Identifiers prefixed with 'exp:' are reserved for Experimental use. 2861 Requests to add a new value to the registry MUST include the 2862 following information: 2864 o Identifier: The name of the desired ALTO Cost Type. 2866 o Intended Semantics: ALTO Costs carry with them semantics to guide 2867 their usage by ALTO Clients. For example, if a value refers to a 2868 measurement, the measurement units must be documented. For proper 2869 implementation of the ordinal Cost Mode (e.g., by a third-party 2870 service), it should be documented whether higher or lower values 2871 of the cost are more preferred. 2873 o Security Considerations: ALTO Costs expose information to ALTO 2874 Clients. As such, proper usage of a particular Cost Type may 2875 require certain information to be exposed by an ALTO Service 2876 Provider. Since network information is frequently regarded as 2877 proprietary or confidential, ALTO Service Providers should be made 2878 aware of the security ramifications related to usage of a Cost 2879 Type. 2881 This specification requests registration of the identifier 2882 'routingcost'. Semantics for the this Cost Type are documented in 2883 Section 5.1.1.1, and security considerations are documented in 2884 Section 12.1. 2886 11.3. ALTO Endpoint Property Registry 2888 This document requests the creation of an ALTO Endpoint Property 2889 registry to be maintained by IANA. 2891 This registry serves two purposes. First, it ensures uniqueness of 2892 identifiers referring to ALTO Endpoint Properties. Second, it 2893 provides references to particular semantics of allocated Endpoint 2894 Properties to be applied by both ALTO Servers and applications 2895 utilizing ALTO Clients. 2897 New ALTO Endpoint Properties are assigned after Expert Review 2898 [RFC5226]. The Expert Reviewer will generally consult the ALTO 2899 Working Group or its successor. Expert Review is used to ensure that 2900 proper documentation regarding ALTO Endpoint Property semantics and 2901 security considerations has been provided. The provided 2902 documentation should be detailed enough to provide guidance to both 2903 ALTO Service Providers and applications utilizing ALTO Clients as to 2904 how values of the registered ALTO Endpoint Properties should be 2905 interpreted. Updates and deletions of ALTO Endpoint Properties 2906 follow the same procedure. 2908 Registered ALTO Endpoint Property identifiers MUST conform to the 2909 syntatical requirements specified in Section 7.5.5. Identifiers are 2910 to be recorded and displayed as ASCII strings. 2912 Identifiers prefixed with 'priv:' are reserved for Private Use. 2913 Identifiers prefixed with 'exp:' are reserved for Experimental use. 2915 Requests to add a new value to the registry MUST include the 2916 following information: 2918 o Identifier: The name of the desired ALTO Endpoint Property. 2920 o Intended Semantics: ALTO Endpoint Properties carry with them 2921 semantics to guide their usage by ALTO Clients. For example, if a 2922 value refers to a measurement, the measurement units must be 2923 documented. For proper implementation of the ordinal Cost Mode 2924 (e.g., by a third-party service), it should be documented whether 2925 higher or lower values of the cost are more preferred. 2927 o Security Considerations: ALTO Endpoint Properties expose 2928 information to ALTO Clients. As such, proper usage of a 2929 particular Endpoint Properties may require certain information to 2930 be exposed by an ALTO Service Provider. Since network information 2931 is frequently regarded as proprietary or confidential, ALTO 2932 Service Providers should be made aware of the security 2933 ramifications related to usage of an Endpoint Property. 2935 This specification requests registration of the identifier 'pid'. 2936 Semantics for the this Endpoint Property are documented in 2937 Section 4.1, and security considerations are documented in 2938 Section 12.1. 2940 12. Security Considerations 2942 12.1. Privacy Considerations for ISPs 2944 ISPs must be cognizant of the network topology and provisioning 2945 information provided through ALTO Interfaces. ISPs should evaluate 2946 how much information is revealed and the associated risks. On the 2947 one hand, providing overly fine-grained information may make it 2948 easier for attackers to infer network topology. In particular, 2949 attackers may try to infer details regarding ISPs' operational 2950 policies or inter-ISP business relationships by intentionally posting 2951 a multitude of selective queries to an ALTO server and analyzing the 2952 responses. Such sophisticated attacks may reveal more information 2953 than an ISP hosting an ALTO server intends to disclose. On the other 2954 hand, revealing overly coarse-grained information may not provide 2955 benefits to network efficiency or performance improvements to ALTO 2956 Clients. 2958 12.2. ALTO Clients 2960 Applications using the information must be cognizant of the 2961 possibility that the information is malformed or incorrect. Even if 2962 an ALTO Server has been properly authenticated by the ALTO Client, 2963 the information provided may be malicious because the ALTO Server and 2964 its credentials have been compromised (e.g., through malware). Other 2965 considerations (e.g., relating to application performance) can be 2966 found in Section 6 of [RFC5693]. 2968 ALTO Clients should also be cognizant of revealing Network Location 2969 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, 2970 as doing so may allow the ALTO Server to infer communication 2971 patterns. One possibility is for the ALTO Client to only rely on 2972 Network Map for PIDs and Cost Map amongst PIDs to avoid passing IP 2973 addresses of their peers to the ALTO Server. 2975 In addition, ALTO clients should be cautious not to unintentionally 2976 or indirectly disclose the resource identifier (of which they try to 2977 improve the retrieval through ALTO-guidance), e.g., the name/ 2978 identifier of a certain video stream in P2P live streaming, to the 2979 ALTO server. Note that the ALTO Protocol specified in this document 2980 does not explicitly reveal any resource identifier to the ALTO 2981 Server. However, for instance, depending on the popularity or other 2982 specifics (such as language) of the resource, an ALTO server could 2983 potentially deduce information about the desired resource from 2984 information such as the Network Locations the client sends as part of 2985 its request to the server. 2987 12.3. Authentication, Integrity Protection, and Encryption 2989 SSL/TLS can provide encryption of transmitted messages as well as 2990 authentication of the ALTO Client and Server. HTTP Basic or Digest 2991 authentication can provide authentication of the client (combined 2992 with SSL/TLS, it can additionally provide encryption and 2993 authentication of the server). 2995 An ALTO Server may optionally use authentication (and potentially 2996 encryption) to protect ALTO information it provides. This can be 2997 achieved by digitally signing a hash of the ALTO information itself 2998 and attaching the signature to the ALTO information. There may be 2999 special use cases where encryption of ALTO information is desirable. 3000 In many cases, however, information sent out by an ALTO Server may be 3001 regarded as non-confidential information. 3003 ISPs should be cognizant that encryption only protects ALTO 3004 information until it is decrypted by the intended ALTO Client. 3005 Digital Rights Management (DRM) techniques and legal agreements 3006 protecting ALTO information are outside of the scope of this 3007 document. 3009 12.4. ALTO Information Redistribution 3011 It is possible for applications to redistribute ALTO information to 3012 improve scalability. Even with such a distribution scheme, ALTO 3013 Clients obtaining ALTO information must be able to validate the 3014 received ALTO information to ensure that it was generated by an 3015 appropriate ALTO Server. Further, to prevent the ALTO Server from 3016 being a target of attack, the verification scheme must not require 3017 ALTO Clients to contact the ALTO Server to validate every set of 3018 information. Contacting an ALTO server for information validation 3019 would also undermine the intended effect of redistribution and is 3020 therefore not desirable. 3022 Note that the redistribution scheme must additionally handle details 3023 such as ensuring ALTO Clients retrieve ALTO information from the 3024 correct ALTO Server. See [I-D.gu-alto-redistribution] for further 3025 discussion. Details of a particular redistribution scheme are 3026 outside the scope of this document. 3028 To fulfill these requirements, ALTO Information meant to be 3029 redistributable contains a digital signature which includes a hash of 3030 the ALTO information signed by the ALTO Server with its private key. 3031 The corresponding public key is included in the Server Information 3032 resource Section 7.7.1.1, along with the certificate chain to a Root 3033 Certificate generated by the ALTO Service Provider. To prevent man- 3034 in-the-middle attacks, an ALTO Client SHOULD perform the Server 3035 Information resource request over SSL/TLS and verify the server 3036 identity according to [RFC6125]. 3038 The signature verification algorithm is detailed in Section 8.1.3.3. 3040 12.5. Denial of Service 3042 ISPs should be cognizant of the workload at the ALTO Server generated 3043 by certain ALTO Queries, such as certain queries to the Map Filtering 3044 Service and Ranking Service. In particular, queries which can be 3045 generated with low effort but result in expensive workloads at the 3046 ALTO Server could be exploited for Denial-of-Service attacks. For 3047 instance, a simple ALTO query with n Source Network Locations and m 3048 Destination Network Locations can be generated fairly easily but 3049 results in the computation of n*m Path Costs between pairs by the 3050 ALTO Server (see Section 5.2). One way to limit Denial-of-Service 3051 attacks is to employ access control to the ALTO server. Another 3052 possible mechanism for an ALTO Server to protect itself against a 3053 multitude of computationally expensive bogus requests is to demand 3054 that each ALTO Client to solve a computational puzzle first before 3055 allocating resources for answering a request (see, e.g., 3056 [I-D.jennings-sip-hashcash]). The current specification does not use 3057 such computational puzzles, and discussion regarding tradeoffs of 3058 such an approach would be needed before including such a technique in 3059 the ALTO Protocol. 3061 ISPs should also leverage the fact that the the Map Service allows 3062 ALTO Servers to pre-generate maps that can be useful to many ALTO 3063 Clients. 3065 12.6. ALTO Server Access Control 3067 In order to limit access to an ALTO server (e.g., for an ISP to only 3068 allow its users to access its ALTO server, or to prevent Denial-of- 3069 Service attacks by arbitrary hosts from the Internet), an ALTO server 3070 may employ access control policies. Depending on the use-case and 3071 scenario, an ALTO server may restrict access to its services more 3072 strictly or rather openly (see [I-D.stiemerling-alto-deployments] for 3073 a more detailed discussion on this issue). 3075 13. References 3077 13.1. Normative References 3079 [IEEE.754.2008] 3080 Institute of Electrical and Electronics Engineers, 3081 "Standard for Binary Floating-Point Arithmetic", IEEE 3082 Standard 754, August 2008. 3084 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 3085 Extensions (MIME) Part Two: Media Types", RFC 2046, 3086 November 1996. 3088 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3089 Requirement Levels", BCP 14, RFC 2119, March 1997. 3091 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3092 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3093 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3095 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 3096 Internet: Timestamps", RFC 3339, July 2002. 3098 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3099 Resource Identifier (URI): Generic Syntax", STD 66, 3100 RFC 3986, January 2005. 3102 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 3103 Unique IDentifier (UUID) URN Namespace", RFC 4122, 3104 July 2005. 3106 [RFC4627] Crockford, D., "The application/json Media Type for 3107 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 3109 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 3110 (CIDR): The Internet Address Assignment and Aggregation 3111 Plan", BCP 122, RFC 4632, August 2006. 3113 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3114 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3115 May 2008. 3117 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3118 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3119 October 2008. 3121 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 3122 Address Text Representation", RFC 5952, August 2010. 3124 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3125 Verification of Domain-Based Application Service Identity 3126 within Internet Public Key Infrastructure Using X.509 3127 (PKIX) Certificates in the Context of Transport Layer 3128 Security (TLS)", RFC 6125, March 2011. 3130 13.2. Informative References 3132 [BitTorrent] 3133 "Bittorrent Protocol Specification v1.0", 3134 . 3136 [I-D.akonjang-alto-proxidor] 3137 Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 3138 Saucez, "The PROXIDOR Service", 3139 draft-akonjang-alto-proxidor-00 (work in progress), 3140 March 2009. 3142 [I-D.gu-alto-redistribution] 3143 Yingjie, G., Alimi, R., and R. Even, "ALTO Information 3144 Redistribution", draft-gu-alto-redistribution-03 (work in 3145 progress), July 2010. 3147 [I-D.ietf-alto-reqs] 3148 Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, 3149 "Application-Layer Traffic Optimization (ALTO) 3150 Requirements", draft-ietf-alto-reqs-08 (work in progress), 3151 March 2011. 3153 [I-D.ietf-alto-server-discovery] 3154 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 3155 S. Yongchao, "ALTO Server Discovery", 3156 draft-ietf-alto-server-discovery-00 (work in progress), 3157 May 2011. 3159 [I-D.jennings-sip-hashcash] 3160 Jennings, C., "Computational Puzzles for SPAM Reduction in 3161 SIP", draft-jennings-sip-hashcash-06 (work in progress), 3162 July 2007. 3164 [I-D.mrw-nat66] 3165 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 3166 Translation", draft-mrw-nat66-16 (work in progress), 3167 April 2011. 3169 [I-D.p4p-framework] 3170 Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, 3171 "P4P: Provider Portal for P2P Applications", 3172 draft-p4p-framework-00 (work in progress), November 2008. 3174 [I-D.saumitra-alto-multi-ps] 3175 Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 3176 Dimensional Peer Selection Problem", 3177 draft-saumitra-alto-multi-ps-00 (work in progress), 3178 October 2008. 3180 [I-D.saumitra-alto-queryresponse] 3181 Das, S. and V. Narayanan, "A Client to Service Query 3182 Response Protocol for ALTO", 3183 draft-saumitra-alto-queryresponse-00 (work in progress), 3184 March 2009. 3186 [I-D.shalunov-alto-infoexport] 3187 Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 3188 Export Service", draft-shalunov-alto-infoexport-00 (work 3189 in progress), October 2008. 3191 [I-D.stiemerling-alto-deployments] 3192 Stiemerling, M. and S. Kiesel, "ALTO Deployment 3193 Considerations", draft-stiemerling-alto-deployments-06 3194 (work in progress), January 2011. 3196 [I-D.wang-alto-p4p-specification] 3197 Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, 3198 "P4P Protocol Specification", 3199 draft-wang-alto-p4p-specification-00 (work in progress), 3200 March 2009. 3202 [P4P-SIGCOMM08] 3203 Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A. 3204 Silberschatz, "P4P: Provider Portal for (P2P) 3205 Applications", SIGCOMM 2008, August 2008. 3207 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 3208 Optimization (ALTO) Problem Statement", RFC 5693, 3209 October 2009. 3211 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 3212 IPv4/IPv6 Translation", RFC 6144, April 2011. 3214 Appendix A. Acknowledgments 3216 Thank you to Jan Seedorf for contributions to the Security 3217 Considerations section. We would like to thank Yingjie Gu and Roni 3218 Even for helpful input and design concerning ALTO Information 3219 redistribution. 3221 We would like to thank the following people whose input and 3222 involvement was indispensable in achieving this merged proposal: 3224 Obi Akonjang (DT Labs/TU Berlin), 3226 Saumitra M. Das (Qualcomm Inc.), 3228 Syon Ding (China Telecom), 3230 Doug Pasko (Verizon), 3232 Laird Popkin (Pando Networks), 3234 Satish Raghunath (Juniper Networks), 3236 Albert Tian (Ericsson/Redback), 3238 Yu-Shun Wang (Microsoft), 3240 David Zhang (PPLive), 3242 Yunfei Zhang (China Mobile). 3244 We would also like to thank the following additional people who were 3245 involved in the projects that contributed to this merged document: 3246 Alex Gerber (AT&T), Chris Griffiths (Comcast), Ramit Hora (Pando 3247 Networks), Arvind Krishnamurthy (University of Washington), Marty 3248 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 3249 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T), 3250 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 3251 Damien Saucez (UCL) Thomas Scholl (AT&T), Emilio Sepulveda 3252 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 3253 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 3254 (Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia 3255 Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University), 3256 Haiyong Xie (Yale University). 3258 Appendix B. Authors 3260 [[CmtAuthors: RFC Editor: Please move information in this section to 3261 the Authors' Addresses section at publication time.]] 3263 Stefano Previdi 3264 Cisco 3266 Email: sprevidi@cisco.com 3268 Stanislav Shalunov 3269 BitTorrent 3271 Email: shalunov@bittorrent.com 3273 Richard Woundy 3274 Comcast 3276 Richard_Woundy@cable.comcast.com 3278 Authors' Addresses 3280 Richard Alimi (editor) 3281 Google 3282 1600 Amphitheatre Parkway 3283 Mountain View CA 3284 USA 3286 Email: ralimi@google.com 3287 Reinaldo Penno (editor) 3288 Juniper Networks 3289 1194 N Mathilda Avenue 3290 Sunnyvale CA 3291 USA 3293 Email: rpenno@juniper.net 3295 Y. Richard Yang (editor) 3296 Yale University 3297 51 Prospect St 3298 New Haven CT 3299 USA 3301 Email: yry@cs.yale.edu