idnits 2.17.1 draft-ietf-alto-protocol-10.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 962 has weird spacing: '...etaData meta...' == Line 968 has weird spacing: '... meta meta-...' == Line 970 has weird spacing: '... data the d...' == Line 1298 has weird spacing: '...NString uri;...' == Line 1299 has weird spacing: '...NString medi...' == (12 more instances...) -- The document date (October 31, 2011) is 4554 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 233, but not defined == Missing Reference: 'InfoResourceDataType' is mentioned on line 963, but not defined == Missing Reference: 'OPTIONAL' is mentioned on line 2192, but not defined == Missing Reference: 'TODO' is mentioned on line 2285, but not defined == Missing Reference: 'PIDName' is mentioned on line 1715, but not defined == Missing Reference: 'EndpointProperty' is mentioned on line 2092, but not defined == Missing Reference: 'TypedEndpointAddr' is mentioned on line 2229, 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-02 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: May 3, 2012 Juniper Networks 6 Y. Yang, Ed. 7 Yale University 8 October 31, 2011 10 ALTO Protocol 11 draft-ietf-alto-protocol-10.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 network information (e.g., basic network 25 location structure, preferences of network paths) with the goal of 26 modifying network resource consumption patterns while maintaining or 27 improving application performance. The basic information of ALTO is 28 based on abstract maps of a network. These maps provide simplified, 29 yet enough information of a network for applications to effectively 30 utilize. Additional services are built on top the maps. 32 This document describes a protocol implementing the ALTO Service. 33 Although the ALTO service would primarily be provided by the network 34 (i.e., the ISP), content providers and third parties could also 35 operate this service. Applications that could use this service are 36 those that have a choice in connection endpoints. Examples of such 37 applications are peer-to-peer (P2P) and content delivery networks. 39 Requirements Language 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC 2119 [RFC2119]. 45 Status of this Memo 47 This Internet-Draft is submitted to IETF in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF), its areas, and its working groups. Note that 52 other groups may also distribute working documents as Internet- 53 Drafts. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 The list of current Internet-Drafts can be accessed at 61 http://www.ietf.org/ietf/1id-abstracts.txt. 63 The list of Internet-Draft Shadow Directories can be accessed at 64 http://www.ietf.org/shadow.html. 66 This Internet-Draft will expire on May 3, 2012. 68 Copyright Notice 70 Copyright (c) 2011 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 1.1. Background and Problem Statement . . . . . . . . . . . . . 6 87 1.2. Design History and Merged Proposals . . . . . . . . . . . 6 88 1.3. Solution Benefits . . . . . . . . . . . . . . . . . . . . 7 89 1.3.1. Service Providers . . . . . . . . . . . . . . . . . . 7 90 1.3.2. Applications . . . . . . . . . . . . . . . . . . . . . 7 91 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7 92 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 93 2.1.1. Endpoint Address . . . . . . . . . . . . . . . . . . . 8 94 2.1.2. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 8 95 2.1.3. Network Location . . . . . . . . . . . . . . . . . . . 8 96 2.1.4. ALTO Information . . . . . . . . . . . . . . . . . . . 8 97 2.1.5. ALTO Information Base . . . . . . . . . . . . . . . . 8 98 2.2. ALTO Service and Protocol Scope . . . . . . . . . . . . . 8 99 3. Protocol Structure . . . . . . . . . . . . . . . . . . . . . . 10 100 3.1. Server Information Service . . . . . . . . . . . . . . . . 11 101 3.2. ALTO Information Services . . . . . . . . . . . . . . . . 11 102 3.2.1. Map Service . . . . . . . . . . . . . . . . . . . . . 12 103 3.2.2. Map Filtering Service . . . . . . . . . . . . . . . . 12 104 3.2.3. Endpoint Property Service . . . . . . . . . . . . . . 12 105 3.2.4. Endpoint Cost Service . . . . . . . . . . . . . . . . 12 106 4. Network Map . . . . . . . . . . . . . . . . . . . . . . . . . 12 107 4.1. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 108 4.2. Endpoint Addresses . . . . . . . . . . . . . . . . . . . . 13 109 4.2.1. IP Addresses . . . . . . . . . . . . . . . . . . . . . 14 110 4.3. Example Network Map . . . . . . . . . . . . . . . . . . . 14 111 5. Cost Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 112 5.1. Cost Attributes . . . . . . . . . . . . . . . . . . . . . 15 113 5.1.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . 15 114 5.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 16 115 5.2. Cost Map Structure . . . . . . . . . . . . . . . . . . . . 17 116 5.3. Network Map and Cost Map Dependency . . . . . . . . . . . 17 117 6. Protocol Design Overview . . . . . . . . . . . . . . . . . . . 18 118 6.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 18 119 6.1.1. Existing Infrastructure . . . . . . . . . . . . . . . 18 120 6.1.2. ALTO Information Reuse and Redistribution . . . . . . 18 121 6.2. Protocol Design . . . . . . . . . . . . . . . . . . . . . 19 122 7. Protocol Specification . . . . . . . . . . . . . . . . . . . . 19 123 7.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 19 124 7.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 19 125 7.2.1. Discovering Information Resources . . . . . . . . . . 20 126 7.2.2. Requesting Information Resources . . . . . . . . . . . 20 127 7.2.3. Response . . . . . . . . . . . . . . . . . . . . . . . 20 128 7.2.4. Client Behavior . . . . . . . . . . . . . . . . . . . 21 129 7.2.5. Authentication and Encryption . . . . . . . . . . . . 21 130 7.2.6. HTTP Cookies . . . . . . . . . . . . . . . . . . . . . 21 131 7.2.7. Parsing . . . . . . . . . . . . . . . . . . . . . . . 21 132 7.3. Information Resource . . . . . . . . . . . . . . . . . . . 22 133 7.3.1. Capabilities . . . . . . . . . . . . . . . . . . . . . 22 134 7.3.2. Input Parameters Media Type . . . . . . . . . . . . . 22 135 7.3.3. Media Type . . . . . . . . . . . . . . . . . . . . . . 22 136 7.3.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . 22 137 7.4. ALTO Errors . . . . . . . . . . . . . . . . . . . . . . . 24 138 7.4.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 24 139 7.4.2. Resource Format . . . . . . . . . . . . . . . . . . . 24 140 7.4.3. Error Codes . . . . . . . . . . . . . . . . . . . . . 25 141 7.5. ALTO Types . . . . . . . . . . . . . . . . . . . . . . . . 25 142 7.5.1. PID Name . . . . . . . . . . . . . . . . . . . . . . . 26 143 7.5.2. Version Tag . . . . . . . . . . . . . . . . . . . . . 26 144 7.5.3. Endpoints . . . . . . . . . . . . . . . . . . . . . . 26 145 7.5.4. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 28 146 7.5.5. Cost Type . . . . . . . . . . . . . . . . . . . . . . 28 147 7.5.6. Endpoint Property . . . . . . . . . . . . . . . . . . 29 148 7.6. Information Resource Directory . . . . . . . . . . . . . . 29 149 7.6.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 29 150 7.6.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . 30 151 7.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 31 152 7.6.4. Usage Considerations . . . . . . . . . . . . . . . . . 34 153 7.7. Information Resources . . . . . . . . . . . . . . . . . . 34 154 7.7.1. Server Information Service . . . . . . . . . . . . . . 34 155 7.7.2. Map Service . . . . . . . . . . . . . . . . . . . . . 36 156 7.7.3. Map Filtering Service . . . . . . . . . . . . . . . . 41 157 7.7.4. Endpoint Property Service . . . . . . . . . . . . . . 47 158 7.7.5. Endpoint Cost Service . . . . . . . . . . . . . . . . 49 159 8. Redistributable Responses . . . . . . . . . . . . . . . . . . 53 160 8.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 54 161 8.1.1. Service ID . . . . . . . . . . . . . . . . . . . . . . 54 162 8.1.2. Expiration Time . . . . . . . . . . . . . . . . . . . 55 163 8.1.3. Signature . . . . . . . . . . . . . . . . . . . . . . 55 164 8.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 57 165 8.2.1. Response Redistribution Descriptor Fields . . . . . . 58 166 8.2.2. Signature . . . . . . . . . . . . . . . . . . . . . . 58 167 9. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 59 168 9.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 59 169 9.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 61 170 9.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 62 171 10. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 62 172 10.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 63 173 10.2. Hosts with Multiple Endpoint Addresses . . . . . . . . . . 63 174 10.3. Network Address Translation Considerations . . . . . . . . 63 175 10.4. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . 64 176 10.5. Endpoint and Path Properties . . . . . . . . . . . . . . . 64 177 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 178 11.1. application/alto-* Media Types . . . . . . . . . . . . . . 64 179 11.2. ALTO Cost Type Registry . . . . . . . . . . . . . . . . . 66 180 11.3. ALTO Endpoint Property Registry . . . . . . . . . . . . . 67 181 12. Security Considerations . . . . . . . . . . . . . . . . . . . 68 182 12.1. Privacy Considerations for ISPs . . . . . . . . . . . . . 68 183 12.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 69 184 12.3. Authentication, Integrity Protection, and Encryption . . . 69 185 12.4. ALTO Information Redistribution . . . . . . . . . . . . . 70 186 12.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 70 187 12.6. ALTO Server Access Control . . . . . . . . . . . . . . . . 71 188 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71 189 13.1. Normative References . . . . . . . . . . . . . . . . . . . 71 190 13.2. Informative References . . . . . . . . . . . . . . . . . . 72 191 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 74 192 Appendix B. Authors . . . . . . . . . . . . . . . . . . . . . . . 75 193 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 195 1. Introduction 197 1.1. Background and Problem Statement 199 Today, network information available to applications is mostly from 200 the view of endhosts. There is no clear mechanism to convey 201 information about the network (e.g., preferences) to applications. 202 On the other hand, modern network applications can be adaptive, with 203 the potential to become more network-efficient (e.g., reduce network 204 resource consumption) and achieve better application performance 205 (e.g., accelerated download rate), by leveraging better network- 206 provided information. 208 The ALTO Service intends to provide a simple mechanism to convey 209 network information to applications. Its objective is to provide 210 basic, abstract but useful network information to applications. The 211 mechanism should include abstractions to achieve concise, flexible 212 network information expression. 214 The goal of this document is to specify a simple and unified protocol 215 that meets the ALTO requirements [I-D.ietf-alto-reqs] while providing 216 a migration path for Internet Service Providers (ISP), Content 217 Providers, and clients that have deployed protocols with similar 218 intentions (see below). This document is a work in progress and will 219 be updated with further developments. 221 1.2. Design History and Merged Proposals 223 The protocol specified here consists of contributions from 225 o P4P [I-D.p4p-framework], [P4P-SIGCOMM08], 226 [I-D.wang-alto-p4p-specification]; 228 o ALTO Info-Export [I-D.shalunov-alto-infoexport]; 230 o Query/Response [I-D.saumitra-alto-queryresponse], 231 [I-D.saumitra-alto-multi-ps]; 233 o ATTP [ATTP]; 235 o Proxidor [I-D.akonjang-alto-proxidor]. 237 See Appendix A for a list of people that have contributed 238 significantly to this effort and the projects and proposals listed 239 above. 241 1.3. Solution Benefits 243 The ALTO Service offers many benefits to both end-users (consumers of 244 the service) and Internet Service Providers (providers of the 245 service). 247 1.3.1. Service Providers 249 The ALTO Service enables ISPs to influence the peer selection process 250 in distributed applications in order to increase locality of traffic, 251 improve user-experience, amongst others. It also helps ISPs to 252 efficiently manage traffic that traverses more expensive links such 253 as transit and backup links, thus allowing a better provisioning of 254 the networking infrastructure. 256 1.3.2. Applications 258 Applications that use the ALTO Service can benefit in multiple ways. 259 For example, they may no longer need to infer topology information, 260 and some applications can reduce reliance on measuring path 261 performance metrics themselves. They can take advantage of the ISP's 262 knowledge to avoid bottlenecks and boost performance. 264 An example type of application is a Peer-to-Peer overlay where peer 265 selection can be improved by including ALTO information in the 266 selection process. 268 2. Architecture 270 Two key design objectives of the ALTO Protocol are simplicity and 271 extensibility. At the same time, it introduces additional techniques 272 to address potential scalability and privacy issues. This section 273 first introduces the terminology, and then defines the ALTO 274 architecture and the ALTO Protocol's place in the overall 275 architecture. 277 2.1. Terminology 279 We use the following terms defined in [RFC5693]: Application, Overlay 280 Network, Peer, Resource, Resource Identifier, Resource Provider, 281 Resource Consumer, Resource Directory, Transport Address, Host 282 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 283 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 284 Transit Traffic. 286 We also use the following additional terms: Endpoint Address, 287 Autonomous System Number (ASN), and Network Location. 289 2.1.1. Endpoint Address 291 An endpoint address represents the communication address of an 292 endpoint. An endpoint address can be network-attachment based (IP 293 address) or network-attachment agnostic. Common forms of endpoint 294 addresses include IP address, MAC address, overlay ID, and phone 295 number. 297 Each Endpoint Address has an associated Address Type, which indicates 298 both its syntax and semantics. 300 2.1.2. ASN 302 An Autonomous System Number. 304 2.1.3. Network Location 306 Network Location is a generic term denoting a single endpoint or 307 group of endpoints. 309 2.1.4. ALTO Information 311 ALTO Information is a generic term referring to the network 312 information sent by an ALTO Server. 314 2.1.5. ALTO Information Base 316 Internal representation of the ALTO Information maintained by the 317 ALTO Server. Note that the structure of this internal representation 318 is not defined by this document. 320 2.2. ALTO Service and Protocol Scope 322 An ALTO Server conveys the network information from the perspective 323 of a network region; the ALTO Server presents its "my-Internet View" 324 of the network region. In particular, an ALTO Server defines network 325 Endpoints (and aggregations thereof) and generic costs amongst them, 326 both from the network region's own perspective. A network region in 327 this context can be an Autonomous System, an ISP, or perhaps a 328 smaller region or set of ISPs; the details depend on the deployment 329 scenario and discovery mechanism. 331 To better understand the ALTO Service and the role of the ALTO 332 Protocol, we show in Figure 1 the overall system architecture. In 333 this architecture, an ALTO Server prepares ALTO Information; an ALTO 334 Client uses ALTO Service Discovery to identify an appropriate ALTO 335 Server; and the ALTO Client requests available ALTO Information from 336 the ALTO Server using the ALTO Protocol. 338 The ALTO Information provided by the ALTO Server can be updated 339 dynamically based on network conditions, or can be seen as a policy 340 which is updated at a larger time-scale. 342 More specifically, the ALTO Information provided by an ALTO Server 343 may be influenced (at the operator's discretion) by other systems. 344 The ALTO Server aggregates information from multiple systems to 345 provide an abstract, unified, useful network view to applications. 346 Examples of other systems include (but are not limited to) static 347 network configuration databases, dynamic network information, routing 348 protocols, provisioning policies, and interfaces to outside parties. 349 These components are shown in the figure for completeness but outside 350 the scope of this specification. 352 Note that it may also be possible for ALTO Servers to exchange 353 network information with other ALTO Servers (either within the same 354 administrative domain or another administrative domain with the 355 consent of both parties) in order to adjust exported ALTO 356 Information. Such a protocol is also outside the scope of this 357 specification. 359 +-------------------------------------------------------------------+ 360 | ISP | 361 | | 362 | +-----------+ | 363 | | Routing | | 364 | +--------------+ | Protocols | | 365 | | Provisioning | +-----------+ | 366 | | Policy | | | 367 | +--------------+\ | | 368 | \ | | 369 | \ | | 370 | +-----------+ \+---------+ +--------+ | 371 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 372 | |Network |.......| Server | -------------------- | Client | | 373 | |Information| +---------+ +--------+ | 374 | +-----------+ / / | 375 | / ALTO SD Query/Response / | 376 | / / | 377 | +----------+ +--------------+ | 378 | | External | | ALTO Service | | 379 | | Interface| | Discovery | | 380 | +----------+ +--------------+ | 381 | | | 382 +-------------------------------------------------------------------+ 383 | 384 +------------------+ 385 | Third Parties | 386 | | 387 | Content Providers| 388 +------------------+ 390 Figure 1: Basic ALTO Architecture. 392 3. Protocol Structure 394 The ALTO Protocol uses a simple extensible framework to convey 395 network information. In the general framework, the ALTO protocol 396 will convey properties on both Network Locations and the paths 397 between Network Locations. 399 In this document, we focus on a particular Endpoint property to 400 denote the location of an endpoint, and provider-defined costs for 401 paths between pairs of Network Locations. 403 The ALTO Protocol is built on a common transport protocol, messaging 404 structure and encoding, and transaction model. The protocol is 405 subdivided into services of related functionality. ALTO-Core 406 provides the Server Information Service and the Map Service to 407 provide ALTO Information. Other ALTO Information services can 408 provide additional functionality. There are three such services 409 defined in this document: the Map Filtering Service, Endpoint 410 Property Service, and Endpoint Cost Service. Additional services may 411 be defined in companion documents. Note that functionality offered 412 in different services are not totally non-overlapping (e.g., the Map 413 Service and Map Filtering Service). 415 .------------------------------------------------------------. 416 | | 417 | .----------. .-----------------------------------------. | 418 | | | | ALTO Info Services | | 419 | | | | .-----------. .----------. .----------. | | 420 | | | | | Map | | Endpoint | | Endpoint | | | 421 | | | | | Filtering | | Property | | Cost | | | 422 | | | | | Service | | Service | | Service | | | 423 | | Server | | `-----------' `----------' `----------' | | 424 | | Info. | | .-------------------------------------. | | 425 | | Service | | | Map Service | | | 426 | | | | | .-------------. .--------------. | | | 427 | | | | | | Network Map | | Cost Map | | | | 428 | | | | | `-------------' `--------------' | | | 429 | | | | `-------------------------------------' | | 430 | `----------' `-----------------------------------------' | 431 | | 432 `------------------------------------------------------------' 434 Figure 2: ALTO Protocol Structure 436 3.1. Server Information Service 438 The Server Information Service lists the details on the information 439 that can be provided by an ALTO Server and perhaps other ALTO Servers 440 maintained by the network provider. The configuration includes, for 441 example, details about the operations and cost metrics supported by 442 the ALTO Server and other related ALTO Servers that may be usable by 443 an ALTO Client. 445 3.2. ALTO Information Services 447 Multiple, distinct services are defined to allow ALTO Clients to 448 query ALTO Information from an ALTO Server. The ALTO Server 449 internally maintains an ALTO Information Base that encodes the 450 network provider's preferences. The ALTO Information Base encodes 451 the Network Locations defined by the ALTO Server (and their 452 corresponding properties), as well as the provider-defined costs 453 between pairs of Network Locations. 455 3.2.1. Map Service 457 The Map Service provides batch information to ALTO Clients in the 458 form of Network Map and Cost Map. The Network Map (See Section 4) 459 provides the full set of Network Location groupings defined by the 460 ALTO Server and the endpoints contained with each grouping. The Cost 461 Map (see Section 5) provides costs between the defined groupings. 463 These two maps can be thought of (and implemented as) as simple files 464 with appropriate encoding provided by the ALTO Server. 466 3.2.2. Map Filtering Service 468 Resource constrained ALTO Clients may benefit from query results 469 being filtered at the ALTO Server. This avoids an ALTO Client 470 spending network bandwidth or CPU collecting results and performing 471 client-side filtering. The Map Filtering Service allows ALTO Clients 472 to query for the ALTO Server Network Map and Cost Map based on 473 additional parameters. 475 3.2.3. Endpoint Property Service 477 This service allows ALTO Clients to look up properties for individual 478 endpoints. An example endpoint property is its Network Location (its 479 grouping defined by the ALTO Server) or connectivity type (e.g., 480 ADSL, Cable, or FTTH). 482 3.2.4. Endpoint Cost Service 484 Some ALTO Clients may also benefit from querying for costs and 485 rankings based on endpoints. The Endpoint Cost Service allows an 486 ALTO Server to return either numerical costs or ordinal costs 487 (rankings) directly amongst Endpoints. 489 4. Network Map 491 In reality, many endpoints are very close to one another in terms of 492 network connectivity, for example, endpoints on the same site of an 493 enterprise. By treating a group of endpoints together as a single 494 entity in ALTO, we can achieve much greater scalability without 495 losing critical information. 497 The Network Location endpoint property allows an ALTO Server to group 498 endpoints together to indicate their proximity. The resulting set of 499 groupings is called the ALTO Network Map. 501 The definition of proximity varies depending on the granularity of 502 the ALTO information configured by the provider. In one deployment, 503 endpoints on the same subnet may be considered close; while in 504 another deployment, endpoints connected to the same PoP may be 505 considered close. 507 As used in this document, the Network Map refers to the syntax and 508 semantics of the information distributed by the ALTO Server. This 509 document does not discuss the internal representation of this data 510 structure within the ALTO Server. 512 4.1. PID 514 Each group of Endpoints is identified by a provider-defined Network 515 Location identifier called a PID. There can be many different ways 516 of grouping the endpoints and assigning PIDs. 518 A PID is an identifier that provides an indirect and network-agnostic 519 way to specify an aggregation of network endpoints that may be 520 treated similarly, based on network topology, type, or other 521 properties. For example, a PID may be defined by the ALTO service 522 provider to denote a subnet, a set of subnets, a metropolitan area, a 523 PoP, an autonomous system, or a set of autonomous systems. 524 Aggregation of endpoints into PIDs can indicate proximity and can 525 improve scalability. In particular, network preferences (costs) may 526 be specified between PIDs, allowing cost information to be more 527 compactly represented and updated at a faster time scale than the 528 network aggregations themselves. 530 Using PIDs, the Network Map may also be used to communicate simple 531 preferences with only minimal information from the Cost Map. For 532 example, an ISP may prefer that endpoints associated with the same 533 PoP (Point-of-Presence) in a P2P application communicate locally 534 instead of communicating with endpoints in other PoPs. The ISP may 535 aggregate endhosts within a PoP into a single PID in the Network Map. 536 The Cost Map may be encoded to indicate that peering within the same 537 PID is preferred; for example, cost(PID_i, PID_i) == c* and 538 cost(PID_i, PID_j) > c* for i != j. Section 5 provides further 539 details about Cost Map structure. 541 4.2. Endpoint Addresses 543 Communicating endpoints may have many types of addresses, such as IP 544 addresses, MAC addresses, or overlay IDs. The current specification 545 only considers IP addresses. 547 4.2.1. IP Addresses 549 The endpoints aggregated into a PID are denoted by a list of IP 550 prefixes. When either an ALTO Client or ALTO Server needs to 551 determine which PID in a Network Map contains a particular IP 552 address, longest-prefix matching MUST be used. 554 A Network Map MUST define a PID for each possible address in the IP 555 address space for all of the address types contained in the map. A 556 RECOMMENDED way to satisfy this property is to define a PID that 557 contains the 0.0.0.0/0 prefix for IPv4 or ::/0 (for IPv6). 559 Each endpoint MUST map into exactly one PID. Since longest-prefix 560 matching is used to map an endpoint to a PID, this can be 561 accomplished by ensuring that no two PIDs contain an identical IP 562 prefix. 564 4.3. Example Network Map 566 Figure 3 illustrates an example Network Map. PIDs are used to 567 identify network-agnostic aggregations. 569 .-----------------------------------------------------------. 570 | ALTO Network Map | 571 | | 572 | .-----------------------------------. .---------------. | 573 | | NetLoc: PID-1 | | NetLoc: PID-2 | | 574 | | .------------------------------. | | ... | | 575 | | | 192.0.2.0/24 | | `---------------` | 576 | | | .--------------------------. | | | 577 | | | | Endpoint: 192.0.2.34 | | | .---------------. | 578 | | | `--------------------------` | | | NetLoc: PID-3 | | 579 | | `------------------------------` | | ... | | 580 | | .------------------------------. | `---------------` | 581 | | | 198.51.100.0/25 | | | 582 | | | .--------------------------. | | .---------------. | 583 | | | | Endpoint: 198.51.100.100 | | | | NetLoc: PID-4 | | 584 | | | `--------------------------` | | | ... | | 585 | | `------------------------------` | `---------------` | 586 | `-----------------------------------` | 587 | | 588 `-----------------------------------------------------------` 590 Figure 3: Example Network Map 592 5. Cost Map 594 An ALTO Server indicates preferences amongst network locations in the 595 form of Path Costs. Path Costs are generic costs and can be 596 internally computed by a network provider according to its own needs. 598 An ALTO Cost Map defines Path Costs pairwise amongst sets of source 599 and destination Network Locations. 601 One advantage of separating ALTO information into a Network Map and a 602 Cost Map is that the two components can be updated at different time 603 scales. For example, Network Maps may be stable for a longer time 604 while Cost Maps may be updated to reflect dynamic network conditions. 606 As used in this document, the Cost Map refers to the syntax and 607 semantics of the information distributed by the ALTO Server. This 608 document does not discuss the internal representation of this data 609 structure within the ALTO Server. 611 5.1. Cost Attributes 613 Path Costs have attributes: 615 o Type: identifies what the costs represent; 617 o Mode: identifies how the costs should be interpreted. 619 Certain queries for Cost Maps allow the ALTO Client to indicate the 620 desired Type and Mode. 622 5.1.1. Cost Type 624 The Type attribute indicates what the cost represents. For example, 625 an ALTO Server could define costs representing air-miles, hop-counts, 626 or generic routing costs. 628 Cost types are indicated in protocol messages as strings. 630 5.1.1.1. Cost Type: routingcost 632 An ALTO Server MUST define the 'routingcost' Cost Type. 634 This Cost Type conveys a generic measure for the cost of routing 635 traffic from a source to a destination. Lower values indicate a 636 higher preference for traffic to be sent from a source to a 637 destination. 639 Note that an ISP may internally compute routing cost using any method 640 it chooses (e.g., air-miles or hop-count) as long as it conforms to 641 these semantics. 643 5.1.2. Cost Mode 645 The Mode attribute indicates how costs should be interpreted. 646 Specifically, the Mode attribute indicates whether returned costs 647 should be interpreted as numerical values or ordinal rankings. 649 It is important to communicate such information to ALTO Clients, as 650 certain operations may not be valid on certain costs returned by an 651 ALTO Server. For example, it is possible for an ALTO Server to 652 return a set of IP addresses with costs indicating a ranking of the 653 IP addresses. Arithmetic operations that would make sense for 654 numerical values, do not make sense for ordinal rankings. ALTO 655 Clients may handle such costs differently. 657 Cost Modes are indicated in protocol messages as strings. 659 An ALTO Server MUST support at least one of 'numerical' and 'ordinal' 660 costs. ALTO Clients SHOULD be cognizant of operations when a desired 661 cost mode is not supported. For example, an ALTO Client desiring 662 numerical costs may adjust behavior if only the ordinal Cost Mode is 663 available. Alternatively, an ALTO Client desiring ordinal costs may 664 construct ordinal costs given numerical values if only the numerical 665 Cost Mode is available. 667 5.1.2.1. Cost Mode: numerical 669 This Cost Mode is indicated by the string 'numerical'. This mode 670 indicates that it is safe to perform numerical operations (e.g. 671 normalization) on the returned costs. 673 5.1.2.2. Cost Mode: ordinal 675 This Cost Mode is indicated by the string 'ordinal'. This mode 676 indicates that the costs values to a set of Destination Network 677 Locations from a particular Source Network Location are a ranking, 678 with lower values indicating a higher preference. The values are 679 non-negative integers. Ordinal cost values from a particular Source 680 Network Location to a set of Destination Network Locations need not 681 be unique nor contiguous. In particular, from the perspective of a 682 particular Source Network Location, two Destination Network Locations 683 may have an identical rank (ordinal cost value). This document does 684 not specify any behavior by an ALTO Client in this case; an ALTO 685 Client may decide to break ties by random selection, other 686 application knowledge, or some other means. 688 It is important to note that the values in the Cost Map provided with 689 the ordinal Cost Mode are not necessarily the actual cost known to 690 the ALTO Server. 692 5.2. Cost Map Structure 694 A query for a Cost Map either explicitly or implicitly includes a 695 list of Source Network Locations and a list of Destination Network 696 Locations. (Recall that a Network Location can be an endpoint 697 address or a PID.) 699 Specifically, assume that a query has a list of multiple Source 700 Network Locations, say [Src_1, Src_2, ..., Src_m], and a list of 701 multiple Destination Network Locations, say [Dst_1, Dst_2, ..., 702 Dst_n]. 704 The ALTO Server will return the Path Cost for each communicating pair 705 (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., Src_m -> Dst_1, ..., 706 Src_m -> Dst_n). If the ALTO Server does not define a Path Cost for 707 a particular pair, it may be omitted. We refer to this structure as 708 a Cost Map. 710 If the Cost Mode is 'ordinal', the Path Cost of each communicating 711 pair is relative to the m*n entries. 713 5.3. Network Map and Cost Map Dependency 715 If a Cost Map contains PIDs in the list of Source Network Locations 716 or the list of Destination Network Locations, the Path Costs are 717 generated based on a particular Network Map (which defines the PIDs). 718 Version Tags are introduced to ensure that ALTO Clients are able to 719 use consistent information even though the information is provided in 720 two maps. 722 A Version Tag is an opaque string associated with a Network Map 723 maintained by the ALTO Server. When the Network Map changes, the 724 Version Tag MUST also be changed. (Thus, the Version Tag is defined 725 similarly to HTTP's Entity Tags; see Section 3.11 of [RFC2616].) 726 Possibilities for generating a Version Tag include the last-modified 727 timestamp for the Network Map, or a hash of its contents. 729 A Network Map distributed by the ALTO Server includes its Version 730 Tag. A Cost Map referring to PIDs also includes the Version Tag of 731 the Network Map on which it is based. 733 6. Protocol Design Overview 735 The ALTO Protocol design uses a REST-ful design with the goal of 736 leveraging current HTTP [RFC2616] implementations and infrastructure. 737 The REST-ful design supports flexible deployment strategies and 738 provides extensibility. ALTO requests and responses are encoded with 739 JSON [RFC4627]. 741 6.1. Benefits 743 Benefits enabled by these design choices include easier understanding 744 and debugging, mature libraries, tools, infrastructure, and caching 745 and redistribution of ALTO information for increased scalability. 747 6.1.1. Existing Infrastructure 749 HTTP is a natural choice for integration with existing applications 750 and infrastructure. In particular, the ALTO Protocol design 751 leverages: 753 o the huge installed base of infrastructure, including HTTP caches, 755 o mature software implementations, 757 o the fact that many P2P clients already have an embedded HTTP 758 client, and 760 o authentication and encryption mechanisms in HTTP and SSL/TLS. 762 6.1.2. ALTO Information Reuse and Redistribution 764 ALTO information may be useful to a large number of applications and 765 users. For example, an identical Network Map may be used by all ALTO 766 Clients querying a particular ALTO Server. At the same time, 767 distributing ALTO information must be efficient and not become a 768 bottleneck. 770 Beyond integration with existing HTTP caching infrastructure, ALTO 771 information may also be cached or redistributed using application- 772 dependent mechanisms, such as P2P DHTs or P2P file-sharing. This 773 document does not define particular mechanisms for such 774 redistribution, but it does define the primitives (e.g., digital 775 signatures) needed to support such a mechanism. See 776 [I-D.gu-alto-redistribution] for further discussion. 778 Note that if caching or redistribution is used, the response message 779 may be returned from another (possibly third-party) entity. Reuse 780 and Redistribution is further discussed in Section 12.4. Protocol 781 support for redistribution is specified in Section 8. 783 6.2. Protocol Design 785 The ALTO Protocol uses a REST-ful design. There are two primary 786 components to this design: 788 o Information Resources: Each service provides network information 789 as a set of resources, which are distinguished by their media 790 types [RFC2046]. An ALTO Client may construct an HTTP request for 791 a particular resource (including any parameters, if necessary), 792 and an ALTO Server returns the requested resource in an HTTP 793 response. 795 o Information Resource Directory: An ALTO Server provides to ALTO 796 Clients a list of available resources and the URI at which each is 797 provided. This document refers to this list as the Information 798 Resource Directory. This directory is the single entry point to 799 an ALTO Service. ALTO Clients consult the directory to determine 800 the services provided by an ALTO Server. 802 7. Protocol Specification 804 This section first specifies general client and server processing, 805 followed by a detailed specification for each ALTO Information 806 Resource. 808 7.1. Notation 810 This document uses an adaptation of the C-style struct notation to 811 define the required and optional members of JSON objects. Unless 812 explicitly noted, each member of a struct is REQUIRED. 814 The types 'JSONString', 'JSONNumber', 'JSONBool' indicate the JSON 815 string, number, and boolean types, respectively. 817 Note that no standard, machine-readable interface definition or 818 schema is provided. Extension documents may document these as 819 necessary. 821 7.2. Basic Operation 823 The ALTO Protocol employs standard HTTP [RFC2616]. It is used for 824 discovering available Information Resources at an ALTO Server and 825 retrieving Information Resources. ALTO Clients and ALTO Servers use 826 HTTP requests and responses carrying ALTO-specific content with 827 encoding as specified in this document, and MUST be compliant with 829 [RFC2616]. 831 7.2.1. Discovering Information Resources 833 To discover available resources, an ALTO Client may request the 834 Information Resource Directory, which an ALTO Server provides at the 835 URI found by the ALTO Discovery protocol. 837 Informally, an Information Resource Directory enumerates URIs at 838 which an ALTO Server offers Information Resources. Each entry in the 839 directory indicates a URI at which an ALTO Server accepts requests, 840 and returns either the requested Information Resource or an 841 Information Resource Directory that references additional Information 842 Resources. See Section 7.6 for a detailed specification. 844 7.2.2. Requesting Information Resources 846 Through the retrieved Information Resource Directories, an ALTO 847 Client can determine whether an ALTO Server supports the desired 848 Information Resource, and if it is supported, the URI at which it is 849 available. 851 Where possible, the ALTO Protocol uses the HTTP GET method to request 852 resources. However, some ALTO services provide Information Resources 853 that are the function of one or more input parameters. Input 854 parameters are encoded in the HTTP request's entity body, and the 855 request uses the HTTP POST method. 857 Note that it is possible for an ALTO Server to employ caching for the 858 response to a POST request. This can be accomplished by returning an 859 HTTP 303 status code ("See Other") indicating to the ALTO Client that 860 the resulting Cost Map is available via a GET request to an alternate 861 URL (which may be cached). 863 When requesting an ALTO Information Resource that requires input 864 parameters specified in a HTTP POST request, an ALTO Client MUST set 865 the Content-Type HTTP header to the media type corresponding to the 866 format of the supplied input parameters. 868 7.2.3. Response 870 Upon receiving a request, an ALTO server either returns the requested 871 resource, provides the ALTO Client an Information Resource Directory 872 indicating how to reach the desired resource, or returns an error. 874 The type of response MUST be indicated by the media type attached to 875 the response (the Content-Type HTTP header). If an ALTO Client 876 receives an Information Resource Directory, it can consult the 877 received directory to determine if any of the offered URIs contain 878 the desired Information Resource. 880 The generic encoding for an Information Resource is specified in 881 Section 7.3. 883 Errors are indicated via either ALTO-level error codes, or via HTTP 884 status codes; see Section 7.4. 886 7.2.4. Client Behavior 888 7.2.4.1. Using Information Resources 890 This specification does not indicate any required actions taken by 891 ALTO Clients upon successfully receiving an Information Resource from 892 an ALTO Server. Although ALTO Clients are suggested to interpret the 893 received ALTO Information and adapt application behavior, ALTO 894 Clients are not required to do so. 896 7.2.4.2. Error Conditions 898 If an ALTO Client does not successfully receive a desired Information 899 Resource from a particular ALTO Server, it can either choose another 900 server (if one is available) or fall back to a default behavior 901 (e.g., perform peer selection without the use of ALTO information). 902 An ALTO Client may also retry the request at a later time. 904 7.2.5. Authentication and Encryption 906 An ALTO Server MAY support SSL/TLS to implement server and/or client 907 authentication, as well as encryption. See [RFC6125] for 908 considerations regarding verification of server identity. 910 7.2.6. HTTP Cookies 912 If cookies are included in an HTTP request received by an ALTO 913 Server, they MUST be ignored. 915 7.2.7. Parsing 917 This document only details object members used by this specification. 918 Extensions may include additional members within JSON objects defined 919 in this document. ALTO implementations MUST ignore such unknown 920 fields when processing ALTO messages. 922 7.3. Information Resource 924 An Information Resource is an HTTP entity body received by an ALTO 925 Server that encodes the ALTO Information desired by an ALTO Client. 927 This document specifies multiple Information Resources that can be 928 provided by an ALTO Server. Each Information Resource has certain 929 attributes associated with it, indicating its data format, the input 930 parameters it supports, and format of the input parameters. 932 7.3.1. Capabilities 934 An ALTO Server may advertise to an ALTO Client that it supports 935 certain capabilities in requests for an Information Resource. For 936 example, if an ALTO Server allows requests for a Cost Map to include 937 constraints, it may advertise that it supports this capability. 939 7.3.2. Input Parameters Media Type 941 An ALTO Server may allow an ALTO Client to supply input parameters 942 when requesting certain Information Resources. The format of the 943 input parameters (i.e., as contained in the entity body of the HTTP 944 POST request) is indicated by the media type [RFC2046]. 946 7.3.3. Media Type 948 The media type [RFC2046] uniquely indicates the data format of the 949 Information Resource as returned by an ALTO Server in the HTTP entity 950 body. 952 7.3.4. Encoding 954 Though each Information Resource may have a distinct syntax, they are 955 designed to have a common structure containing generic ALTO-layer 956 metadata about the resource, as well as data itself. 958 An Information Resource has a single top-level JSON object of type 959 InfoResourceEntity: 961 object { 962 InfoResourceMetaData meta; 963 [InfoResourceDataType] data; 964 } InfoResourceEntity; 966 with members: 968 meta meta-information pertaining to the Information Resource 970 data the data contained in the Information Resource 972 7.3.4.1. Meta Information 974 Meta information is encoded as a JSON object with type 975 InfoResourceMetaData: 977 object { 978 InfoResourceRedistDesc redistribution; [OPTIONAL] 979 } InfoResourceMetaData; 981 with members: 983 redistribution Additional data for use in Information Resources that 984 may be redistributed amongst ALTO Clients. See Section 8. 986 7.3.4.2. ALTO Information 988 The "data" member of the InfoResourceEntity encodes the resource- 989 specific data; the structure of this member is detailed later in this 990 section for each particular Information Resource. 992 7.3.4.3. Signature 994 An ALTO Server MAY additionally supply a signature asserting that it 995 generated a particular response. See Section 8.2.2. 997 7.3.4.4. Example 999 The following is an example of the encoding for an Information 1000 Resource: 1002 HTTP/1.1 200 OK 1003 Content-Length: [TODO] 1004 Content-Type: application/alto-costmap+json 1006 { 1007 "meta" : { 1008 "redistribution" : { ... } 1009 }, 1010 "data" : { 1011 ... 1012 } 1014 } 1016 7.4. ALTO Errors 1018 If there is an error processing a request, an ALTO Server SHOULD 1019 return additional ALTO-layer information, if it is available, in the 1020 form of an ALTO Error Resource encoded in the HTTP response's entity 1021 body. 1023 If no ALTO-layer information is available, an ALTO Server may omit an 1024 ALTO Error resource from the response. An appropriate HTTP status 1025 code MUST be set. 1027 It is important to note that the HTTP Status Code and ALTO Error Code 1028 have distinct roles. An ALTO Error Code provides detailed 1029 information about the why a particular request for an ALTO Resource 1030 was not successful. The HTTP status code indicates to HTTP 1031 processing elements (e.g., intermediaries and clients) how the 1032 response should be treated. 1034 7.4.1. Media Type 1036 The media type for an Error Resource is "application/ 1037 alto-error+json". 1039 7.4.2. Resource Format 1041 An Error Resource has the format: 1043 object { 1044 JSONString code; 1045 JSONString reason; [OPTIONAL] 1046 } ErrorResourceEntity; 1048 where: 1050 code An ALTO Error Code defined in Table 1 1052 reason A (free-form) human-readable explanation of the particular 1053 error 1055 7.4.3. Error Codes 1057 This document defines ALTO Error Codes to support the error 1058 conditions needed for purposes of this document. Additional status 1059 codes may be defined in companion or extension documents. 1061 The HTTP status codes corresponding to each ALTO Error Code are 1062 defined to provide correct behavior with HTTP intermediaries and 1063 clients. When an ALTO Server returns a particular ALTO Error Code, 1064 it MUST indicate one of the corresponding HTTP status codes in 1065 Table 1in the HTTP response. 1067 If multiple errors are present in a single request (e.g., a request 1068 uses a JSONString when a JSONInteger is expected and a required field 1069 is missing), then the ALTO Server MUST return exactly one of the 1070 detected errors. However, the reported error is implementation 1071 defined, since specifying a particular order for message processing 1072 encroaches needlessly on implementation technique. 1074 +-------------------------+-------------+---------------------------+ 1075 | ALTO Error Code | HTTP Status | Description | 1076 | | Code(s) | | 1077 +-------------------------+-------------+---------------------------+ 1078 | E_SYNTAX | 400 | Parsing error in request | 1079 | | | (including identifiers) | 1080 | | | | 1081 | E_JSON_FIELD_MISSING | 400 | Required field missing | 1082 | | | | 1083 | E_JSON_VALUE_TYPE | 400 | JSON Value of unexpected | 1084 | | | type | 1085 | | | | 1086 | E_INVALID_COST_MODE | 400 | Invalid cost mode | 1087 | | | | 1088 | E_INVALID_COST_TYPE | 400 | Invalid cost type | 1089 | | | | 1090 | E_INVALID_PROPERTY_TYPE | 400 | Invalid property type | 1091 +-------------------------+-------------+---------------------------+ 1093 Table 1: Defined ALTO Error Codes 1095 7.5. ALTO Types 1097 This section details the format for particular data values used in 1098 the ALTO Protocol. 1100 7.5.1. PID Name 1102 A PID Name is encoded as a US-ASCII string. The string MUST be no 1103 more than 64 characters, and MUST NOT contain any ASCII character 1104 below 0x21 or above 0x7E or the '.' separator. The '.' separator is 1105 reserved for future use and MUST NOT be used unless specifically 1106 indicated by a companion or extension document. 1108 The type 'PIDName' is used in this document to indicate a string of 1109 this format. 1111 7.5.2. Version Tag 1113 A Version Tag is encoded as a US-ASCII string. The string MUST be no 1114 more than 64 characters, and MUST NOT contain any ASCII character 1115 below 0x21 or above 0x7E. 1117 The type 'VersionTag' is used in this document to indicate a string 1118 of this type. 1120 7.5.3. Endpoints 1122 This section defines formats used to encode addresses for Endpoints. 1123 In a case that multiple textual representations encode the same 1124 Endpoint address or prefix (within the guidelines outlined in this 1125 document), the ALTO Protocol does not require ALTO Clients or ALTO 1126 Servers to use a particular textual representation, nor does it 1127 require that ALTO Servers reply to requests using the same textual 1128 representation used by requesting ALTO Clients. ALTO Clients must be 1129 cognizant of this. 1131 7.5.3.1. Address Type 1133 Address Types are encoded as US-ASCII strings consisting of only 1134 alphanumeric characters. This document defines the address type 1135 "ipv4" to refer to IPv4 addresses, and "ipv6" to refer to IPv6 1136 addresses. Extension documents may define additional Address Types. 1138 The type 'AddressType' is used in this document to indicate a string 1139 of this format. 1141 7.5.3.2. Endpoint Address 1143 Endpoint Addresses are encoded as US-ASCII strings. The exact 1144 characters and format depend on the type of endpoint address. 1146 The type 'EndpointAddr' is used in this document to indicate a string 1147 of this format. 1149 7.5.3.2.1. IPv4 1151 IPv4 Endpoint Addresses are encoded as specified by the 'IPv4address' 1152 rule in Section 3.2.2 of [RFC3986]. 1154 7.5.3.2.2. IPv6 1156 IPv6 Endpoint Addresses are encoded as specified in Section 4 of 1157 [RFC5952]. 1159 7.5.3.2.3. Typed Endpoint Addresses 1161 When an Endpoint Address is used, an ALTO implementation must be able 1162 to determine its type. For this purpose, the ALTO Protocol allows 1163 endpoint addresses to also explicitly indicate their type. 1165 Typed Endpoint Addresses are encoded as US-ASCII strings of the 1166 format 'AddressType:EndpointAddr' (with the ':' character as a 1167 separator). The type 'TypedEndpointAddr' is used to indicate a 1168 string of this format. 1170 7.5.3.3. Endpoint Prefixes 1172 For efficiency, it is useful to denote a set of Endpoint Addresses 1173 using a special notation (if one exists). This specification makes 1174 use of the prefix notations for both IPv4 and IPv6 for this purpose. 1176 Endpoint Prefixes are encoded as US-ASCII strings. The exact 1177 characters and format depend on the type of endpoint address. 1179 The type 'EndpointPrefix' is used in this document to indicate a 1180 string of this format. 1182 7.5.3.3.1. IPv4 1184 IPv4 Endpoint Prefixes are encoded as specified in Section 3.1 of 1185 [RFC4632]. 1187 7.5.3.3.2. IPv6 1189 IPv6 Endpoint Prefixes are encoded as specified in Section 7 of 1190 [RFC5952]. 1192 7.5.3.4. Endpoint Address Group 1194 The ALTO Protocol includes messages that specify potentially large 1195 sets of endpoint addresses. Endpoint Address Groups provide a more 1196 efficient way to encode such sets, even when the set contains 1197 endpoint addresses of different types. 1199 An Endpoint Address Group is defined as: 1201 object { 1202 EndpointPrefix [AddressType]<0..*>; 1203 ... 1204 } EndpointAddrGroup; 1206 In particular, an Endpoint Address Group is a JSON object with the 1207 name of each member being the string corresponding to the address 1208 type, and the member's corresponding value being a list of prefixes 1209 of addresses of that type. 1211 The following is an example with both IPv4 and IPv6 endpoint 1212 addresses: 1214 { 1215 "ipv4": [ 1216 "192.0.2.0/24", 1217 "198.51.100.0/25" 1218 ], 1219 "ipv6": [ 1220 "2001:db8:0:1::/64", 1221 "2001:db8:0:2::/64" 1222 ] 1223 } 1225 7.5.4. Cost Mode 1227 A Cost Mode is encoded as a US-ASCII string. The string MUST either 1228 have the value 'numerical' or 'ordinal'. 1230 The type 'CostMode' is used in this document to indicate a string of 1231 this format. 1233 7.5.5. Cost Type 1235 A Cost Type is encoded as a US-ASCII string. The string MUST be no 1236 more than 32 characters, and MUST NOT contain characters other than 1237 alphanumeric characters, the hyphen ('-'), or the ':' separator. 1239 Identifiers prefixed with 'priv:' are reserved for Private Use 1240 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for 1241 Experimental use. All other identifiers appearing in an HTTP request 1242 or response with an 'application/alto-*' media type MUST be 1243 registered in the ALTO Cost Types registry Section 11.2. 1245 The type 'CostType' is used in this document to indicate a string of 1246 this format. 1248 7.5.6. Endpoint Property 1250 An Endpoint Property is encoded as a US-ASCII string. The string 1251 MUST be no more than 32 characters, and MUST NOT contain characters 1252 other than alphanumeric characters, the hyphen ('-'), or the ':' 1253 separator. 1255 Identifiers prefixed with 'priv:' are reserved for Private Use 1256 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for 1257 Experimental use. All other identifiers appearing in an HTTP request 1258 or response with an 'application/alto-*' media type MUST be 1259 registered in the ALTO Endpoint Property registry Section 11.3. 1261 The type 'EndpointProperty' is used in this document to indicate a 1262 string of this format. 1264 7.6. Information Resource Directory 1266 An Information Resource Directory indicates to ALTO Clients which 1267 Information Resources are made available by an ALTO Server. 1269 Since resource selection happens after consumption of the Information 1270 Resource Directory, the format of the Information Resource Directory 1271 is designed to be simple with the intention of future ALTO Protocol 1272 versions maintaining backwards compatibility. Future extensions or 1273 versions of the ALTO Protocol SHOULD be accomplished by extending 1274 existing media types or adding new media types, but retaining the 1275 same format for the Information Resource Directory. 1277 An ALTO Server MUST make an Information Resource Directory available 1278 via the HTTP GET method to a URI discoverable by an ALTO Client. 1279 Discovery of this URI is out of scope of this document, but could be 1280 accomplished by manual configuration or by returning the URI of an 1281 Information Resource Directory from the ALTO Discovery Protocol 1282 [I-D.ietf-alto-server-discovery]. 1284 7.6.1. Media Type 1286 The media type is "application/alto-directory+json". 1288 7.6.2. Encoding 1290 An Information Resource Directory is a JSON object of type 1291 InfoResourceDirectory: 1293 object { 1294 ... 1295 } Capabilities; 1297 object { 1298 JSONString uri; 1299 JSONString media-types<1..*>; 1300 JSONString accepts<0..*>; [OPTIONAL] 1301 Capabilities capabilities; [OPTIONAL] 1302 } ResourceEntry; 1304 object { 1305 ResourceEntry resources<0..*>; 1306 } InfoResourceDirectory; 1308 where the "resources" array indicates a list of Information Resources 1309 provided by an ALTO Server. Note that the list of available 1310 resources is enclosed in a JSON object for extensibility; future 1311 protocol versions may specify additional members in the 1312 InfoResourceDirectory object. 1314 Any URI endpoint indicated in an Information Resource Directory MAY 1315 provide a response to an OPTIONS request that is in the format of an 1316 Information Resource Directory. This provides ALTO Clients a means 1317 to discover resources and capabilities offered by that URI endpoint. 1318 ALTO Servers that reply with an HTTP 300 status code ("Multiple 1319 Choices") SHOULD use the Information Resource Directory format in the 1320 reply. 1322 Each entry in the directory specifies: 1324 uri A URI at which the ALTO Server provides one or more Information 1325 Resources, or an Information Resource Directory indicating 1326 additional Information Resources. 1328 media-types The list of all media types of Information Resources 1329 (see Section 7.3.3) available via GET or POST requests to the 1330 corresponding URI or URIs discoverable via the URI. 1332 accepts The list of all media types of input parameters (see 1333 Section 7.3.2) accepted by POST requests to the corresponding URI 1334 or URIs discoverable via the URI. If this member is not present, 1335 it MUST be assumed to be an empty array. 1337 capabilities A JSON Object enumerating capabilities of an ALTO 1338 Server in providing the Information Resource at the corresponding 1339 URI and Information Resources discoverable via the URI. If this 1340 member is not present, it MUST be assumed to be an empty array. 1341 If a capability for one of the offered Information Resources is 1342 not explicitly listed here, an ALTO Client may either issue an 1343 OPTIONS HTTP request to the corresponding URI to determine if the 1344 capability is supported, or assume its default value. 1346 If an entry has an empty list for "accepts", then the corresponding 1347 URI MUST support GET requests. If an entry has a non-empty list for 1348 "accepts", then the corresponding URI MUST support POST requests. If 1349 an ALTO Server wishes to support both GET and POST on a single URI, 1350 it MUST specify two entries in the Information Resource Directory. 1352 7.6.3. Example 1354 The following is an example Information Resource Directory returned 1355 by an ALTO Server. In this example, the ALTO Server provides 1356 additional Network and Cost Maps via a separate subdomain, 1357 "custom.alto.example.com". The maps available via this subdomain are 1358 Filtered Network and Cost Maps as well as pre-generated maps for the 1359 "hopcount" and "routingcost" Cost Types in the "ordinal" Cost Mode. 1361 An ALTO Client can discover the maps available by 1362 "custom.alto.example.com" by successfully performing an OPTIONS 1363 request to "http://custom.alto.example.com/maps". 1365 GET /directory HTTP/1.1 1366 Host: alto.example.com 1367 Accept: application/alto-directory+json,application/alto-error+json 1369 HTTP/1.1 200 OK 1370 Content-Length: [TODO] 1371 Content-Type: application/alto-directory+json 1373 { 1374 "resources" : [ 1375 { 1376 "uri" : "http://alto.example.com/serverinfo", 1377 "media-types" : [ "application/alto-serverinfo+json" ] 1378 }, { 1379 "uri" : "http://alto.example.com/networkmap", 1380 "media-types" : [ "application/alto-networkmap+json" ] 1381 }, { 1382 "uri" : "http://alto.example.com/costmap/num/routingcost", 1383 "media-types" : [ "application/alto-costmap+json" ], 1384 "capabilities" : { 1385 "cost-modes" : [ "numerical" ], 1386 "cost-types" : [ "routingcost" ] 1387 } 1388 }, { 1389 "uri" : "http://alto.example.com/costmap/num/hopcount", 1390 "media-types" : [ "application/alto-costmap+json" ], 1391 "capabilities" : { 1392 "cost-modes" : [ "numerical" ], 1393 "cost-types" : [ "hopcount" ] 1394 } 1395 }, { 1396 "uri" : "http://custom.alto.example.com/maps", 1397 "media-types" : [ 1398 "application/alto-networkmap+json", 1399 "application/alto-costmap+json" 1400 ], 1401 "accepts" : [ 1402 "application/alto-networkmapfilter+json", 1403 "application/alto-costmapfilter+json" 1404 ] 1405 }, { 1406 "uri" : "http://alto.example.com/endpointprop/lookup", 1407 "media-types" : [ "application/alto-endpointprop+json" ], 1408 "accepts" : [ "application/alto-endpointpropparams+json" ], 1409 "capabilities" : { 1410 "prop-types" : [ "pid" ] 1411 } 1412 }, { 1413 "uri" : "http://alto.example.com/endpointcost/lookup", 1414 "media-types" : [ "application/alto-endpointcost+json" ], 1415 "accepts" : [ "application/alto-endpointcostparams+json" ], 1416 "capabilities" : { 1417 "cost-constraints" : true, 1418 "cost-modes" : [ "ordinal", "numerical" ], 1419 "cost-types" : [ "routingcost", "hopcount" ] 1420 } 1421 } 1422 ] 1423 } 1424 OPTIONS /maps HTTP/1.1 1425 Host: custom.alto.example.com 1426 Accept: application/alto-directory+json,application/alto-error+json 1428 HTTP/1.1 200 OK 1429 Content-Length: [TODO] 1430 Content-Type: application/alto-directory+json 1432 { 1433 "resources" : [ 1434 { 1435 "uri" : "http://custom.alto.example.com/networkmap/filtered", 1436 "media-types" : [ "application/alto-networkmap+json" ], 1437 "accepts" : [ "application/alto-networkmapfilter+json" ] 1438 }, { 1439 "uri" : "http://custom.alto.example.com/costmap/filtered", 1440 "media-types" : [ "application/alto-costmap+json" ], 1441 "accepts" : [ "application/alto-costmapfilter+json" ], 1442 "capabilities" : { 1443 "cost-constraints" : true, 1444 "cost-modes" : [ "ordinal", "numerical" ], 1445 "cost-types" : [ "routingcost", "hopcount" ] 1446 } 1447 }, { 1448 "uri" : "http://custom.alto.example.com/ord/routingcost", 1449 "media-types" : [ "application/alto-costmap+json" ], 1450 "capabilities" : { 1451 "cost-modes" : [ "ordinal" ], 1452 "cost-types" : [ "routingcost" ] 1453 } 1454 }, { 1455 "uri" : "http://custom.alto.example.com/ord/hopcount", 1456 "media-types" : [ "application/alto-costmap+json" ], 1457 "capabilities" : { 1458 "cost-modes" : [ "ordinal" ], 1459 "cost-types" : [ "hopcount" ] 1460 } 1461 } 1462 ] 1463 } 1465 7.6.4. Usage Considerations 1467 7.6.4.1. ALTO Client 1469 This document specifies no requirements or constraints on ALTO 1470 Clients with regards to how they process an Information Resource 1471 Directory to identify the URI corresponding to a desired Information 1472 Resource. However, some advice is provided for implementors. 1474 It is possible that multiple entries in the directory match a desired 1475 Information Resource. For instance, in the example in Section 7.6.3, 1476 a full Cost Map with "numerical" Cost Mode and "routingcost" Cost 1477 Type could be retrieved via a GET request to 1478 "http://alto.example.com/costmap/num/routingcost", or via a POST 1479 request to "http://custom.alto.example.com/costmap/filtered". 1481 In general, it is preferred for ALTO Clients to use GET requests 1482 where appropriate, since it is more likely for responses to be 1483 cacheable. 1485 7.6.4.2. ALTO Server 1487 This document indicates that an ALTO Server may or may not provide 1488 the Information Resources specified in the Map Filtering Service. If 1489 these resources are not provided, it is indicated to an ALTO Client 1490 by the absence of a Network Map or Cost Map with any media types 1491 listed under "accepts". 1493 7.7. Information Resources 1495 This section documents the individual Information Resources defined 1496 in the ALTO Protocol. 1498 7.7.1. Server Information Service 1500 The Server Information Service provides generic information about an 1501 ALTO Server. 1503 7.7.1.1. Server Info 1505 This Information Resource MUST be provided by an ALTO Server. 1507 7.7.1.1.1. Media Type 1509 The media type is "application/alto-serverinfo+json". 1511 7.7.1.1.2. HTTP Method 1513 This resource is requested using the HTTP GET method. 1515 7.7.1.1.3. Input Parameters 1517 None. 1519 7.7.1.1.4. Capabilities 1521 None. 1523 7.7.1.1.5. Response 1525 The returned InfoResourceEntity object has "data" member of type 1526 InfoResourceServerInfo: 1528 object { 1529 JSONString service-id; [OPTIONAL] 1530 JSONString certificates<0..*>; [OPTIONAL] 1531 } InfoResourceServerInfo; 1533 which has members: 1535 service-id UUID [RFC4122] indicating an one or more ALTO Servers 1536 serving equivalent ALTO Information. 1538 certificates List of PEM-encoded X.509 certificates used by the ALTO 1539 Server in the signing of responses. 1541 If an ALTO Server has the possibility of marking any response as 1542 redistributable, the 'service-id' and 'certificates' fields are 1543 REQUIRED instead of OPTIONAL. See Section 8&$160;for detailed 1544 specification. 1546 7.7.1.1.6. Example 1548 GET /serverinfo HTTP/1.1 1549 Host: alto.example.com 1550 Accept: application/alto-serverinfo+json,application/alto-error+json 1551 HTTP/1.1 200 OK 1552 Content-Length: [TODO] 1553 Content-Type: application/alto-serverinfo+json 1555 { 1556 "meta" : {}, 1557 "data" : { 1558 "service-id" : "c89ca72f-dead-41b5-9e2b-b65455ace1ee", 1559 "certificates" : [ ... ] 1560 } 1561 } 1563 7.7.2. Map Service 1565 The Map Service provides batch information to ALTO Clients in the 1566 form of two types of maps: a Network Map and Cost Map. 1568 7.7.2.1. Network Map 1570 The Network Map Information Resource lists for each PID, the network 1571 locations (endpoints) within the PID. It MUST be provided by an ALTO 1572 Server. 1574 7.7.2.1.1. Media Type 1576 The media type is "application/alto-networkmap+json". 1578 7.7.2.1.2. HTTP Method 1580 This resource is requested using the HTTP GET method. 1582 7.7.2.1.3. Input Parameters 1584 None. 1586 7.7.2.1.4. Capabilities 1588 None. 1590 7.7.2.1.5. Response 1592 The returned InfoResourceEntity object "data" member of type 1593 InfoResourceNetworkMap: 1595 object { 1596 EndpointAddrGroup [pidname]<0..*>; 1597 ... 1598 } NetworkMapData; 1600 object { 1601 VersionTag map-vtag; 1602 NetworkMapData map; 1603 } InfoResourceNetworkMap; 1605 with members: 1607 map-vtag The Version Tag (Section 5.3) of the Network Map. 1609 map The Network Map data itself. 1611 NetworkMapData is a JSON object with each member representing a 1612 single PID and its associated set of endpoint addresses. A member's 1613 name is a string of type PIDName. 1615 The returned Network Map MUST include all PIDs known to the ALTO 1616 Server. 1618 7.7.2.1.6. Example 1620 GET /networkmap HTTP/1.1 1621 Host: alto.example.com 1622 Accept: application/alto-networkmap+json,application/alto-error+json 1623 HTTP/1.1 200 OK 1624 Content-Length: [TODO] 1625 Content-Type: application/alto-networkmap+json 1627 { 1628 "meta" : {}, 1629 "data" : { 1630 "map-vtag" : "1266506139", 1631 "map" : { 1632 "PID1" : { 1633 "ipv4" : [ 1634 "192.0.2.0/24", 1635 "198.51.100.0/25" 1636 ] 1637 }, 1638 "PID2" : { 1639 "ipv4" : [ 1640 "198.51.100.128/25" 1641 ] 1642 }, 1643 "PID3" : { 1644 "ipv4" : [ 1645 "0.0.0.0/0" 1646 ], 1647 "ipv6" : [ 1648 "::/0" 1649 ] 1650 } 1651 } 1652 } 1653 } 1655 7.7.2.2. Cost Map 1657 The Cost Map resource lists the Path Cost for each pair of source/ 1658 destination PID defined by the ALTO Server for a given Cost Type and 1659 Cost Mode. This resource MUST be provided for at least the 1660 'routingcost' Cost Type and 'numerical' Cost Mode. 1662 Note that since this resource, an unfiltered Cost Map requested by an 1663 HTTP GET, does not indicate the desired Cost Mode or Cost Type as 1664 input parameters, an ALTO Server MUST indicate in an Information 1665 Resource Directory a unfiltered Cost Map Information Resource by 1666 specifying the capabilities (Section 7.7.2.2.4) with "cost-types" and 1667 "cost-modes" members each having a single element. This technique 1668 will allow an ALTO Client to determine a URI for an unfiltered Cost 1669 Map of the desired Cost Mode and Cost Type. 1671 7.7.2.2.1. Media Type 1673 The media type is "application/alto-costmap+json". 1675 7.7.2.2.2. HTTP Method 1677 This resource is requested using the HTTP GET method. 1679 7.7.2.2.3. Input Parameters 1681 None. 1683 7.7.2.2.4. Capabilities 1685 This resource may be defined for across multiple Cost Types and Cost 1686 Modes. The capabilities of an ALTO Server URI providing this 1687 resource are defined by a JSON Object of type CostMapCapability: 1689 object { 1690 CostMode cost-modes<0..*>; 1691 CostType cost-types<0..*>; 1692 } CostMapCapability; 1694 with members: 1696 cost-modes The Cost Modes ( Section 5.1.2) supported by the 1697 corresponding URI. If not present, this member MUST be 1698 interpreted as an empty array. 1700 cost-types The Cost Types ( Section 5.1.1) supported by the 1701 corresponding URI. If not present, this member MUST be 1702 interpreted as an empty array. 1704 An ALTO Server MUST support all of the Cost Types listed here for 1705 each of the listed Cost Modes. Note that an ALTO Server may provide 1706 multiple Cost Map Information Resources, each with different 1707 capabilities. 1709 7.7.2.2.5. Response 1711 The returned InfoResourceEntity object has "data" member of type 1712 InfoResourceCostMap: 1714 object DstCosts { 1715 JSONNumber [PIDName]; 1716 ... 1717 }; 1719 object { 1720 DstCosts [PIDName]<0..*>; 1721 ... 1722 } CostMapData; 1724 object { 1725 CostMode cost-mode; 1726 CostType cost-type; 1727 VersionTag map-vtag; 1728 CostMapData map; 1729 } InfoResourceCostMap; 1731 with members: 1733 cost-mode Cost Mode (Section 5.1.2) used in the Cost Map. 1735 cost-type Cost Type (Section 5.1.1) used in the Cost Map. 1737 map-vtag The Version Tag (Section 5.3) of the Network Map used to 1738 generate the Cost Map. 1740 map The Cost Map data itself. 1742 CostMapData is a JSON object with each member representing a single 1743 Source PID; the name for a member is the PIDName string identifying 1744 the corresponding Source PID. For each Source PID, a DstCosts object 1745 denotes the associated cost to a set of destination PIDs ( 1746 Section 5.2); the name for each member in the object is the PIDName 1747 string identifying the corresponding Destination PID. 1749 The returned Cost Map MUST include the Path Cost for each (Source 1750 PID, Destination PID) pair for which a Path Cost is defined. An ALTO 1751 Server MAY omit entries for which a Path Cost is not defined (e.g., 1752 both the Source and Destination PIDs contain addresses outside of the 1753 Network Provider's administrative domain). 1755 7.7.2.2.6. Example 1757 GET /costmap/num/routingcost HTTP/1.1 1758 Host: alto.example.com 1759 Accept: application/alto-costmap+json,application/alto-error+json 1760 HTTP/1.1 200 OK 1761 Content-Length: [TODO] 1762 Content-Type: application/alto-costmap+json 1764 { 1765 "meta" : {}, 1766 "data" : { 1767 "cost-mode" : "numerical", 1768 "cost-type" : "routingcost", 1769 "map-vtag" : "1266506139", 1770 "map" : { 1771 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 1772 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 1773 "PID3": { "PID1": 20, "PID2": 15 } 1774 } 1775 } 1776 } 1778 7.7.3. Map Filtering Service 1780 The Map Filtering Service allows ALTO Clients to specify filtering 1781 criteria to return a subset of the full maps available in the Map 1782 Service. 1784 7.7.3.1. Filtered Network Map 1786 A Filtered Network Map is a Network Map Information Resource 1787 (Section 7.7.2.1) for which an ALTO Client may supply a list of PIDs 1788 to be included. A Filtered Network Map MAY be provided by an ALTO 1789 Server. 1791 7.7.3.1.1. Media Type 1793 See Section 7.7.2.1.1. 1795 7.7.3.1.2. HTTP Method 1797 This resource is requested using the HTTP POST method. 1799 7.7.3.1.3. Input Parameters 1801 Input parameters are supplied in the entity body of the POST request. 1802 This document specifies the input parameters with a data format 1803 indicated by the media type "application/alto-networkmapfilter+json", 1804 which is a JSON Object of type ReqFilteredNetworkMap, where: 1806 object { 1807 PIDName pids<0..*>; 1808 AddressType address-types<0..*>; 1809 } ReqFilteredNetworkMap; 1811 with members: 1813 pids Specifies list of PIDs to be included in the returned Filtered 1814 Network Map. If the list of PIDs is empty, the ALTO Server MUST 1815 interpret the list as if it contained a list of all currently- 1816 defined PIDs. The ALTO Server MUST interpret entries appearing 1817 multiple times as if they appeared only once. 1819 address-types Specifies list of address types to be included in the 1820 returned Filtered Network Map. If the list of address types is 1821 empty, the ALTO Server MUST interpret the list as if it contained 1822 a list of all address types known to the ALTO Server. The ALTO 1823 Server MUST interpret entries appearing multiple times as if they 1824 appeared only once. 1826 7.7.3.1.4. Capabilities 1828 None. 1830 7.7.3.1.5. Response 1832 See Section 7.7.2.1.5 for the format. 1834 The ALTO Server MUST only include PIDs in the response that were 1835 specified (implicitly or explicitly) in the request. If the input 1836 parameters contain a PID name that is not currently defined by the 1837 ALTO Server, the ALTO Server MUST behave as if the PID did not appear 1838 in the input parameters. Similarly, the ALTO Server MUST only 1839 enumerate addresses within each PID that have types which were 1840 specified (implicitly or explicitly) in the request. If the input 1841 parameters contain an address type that is not currently known to the 1842 ALTO Server, the ALTO Server MUST behave as if the address type did 1843 not appear in the input parameters. 1845 7.7.3.1.6. Example 1847 POST /networkmap/filtered HTTP/1.1 1848 Host: custom.alto.example.com 1849 Content-Length: [TODO] 1850 Content-Type: application/alto-networkmapfilter+json 1851 Accept: application/alto-networkmap+json,application/alto-error+json 1853 { 1854 "pids": [ "PID1", "PID2" ] 1855 } 1857 HTTP/1.1 200 OK 1858 Content-Length: [TODO] 1859 Content-Type: application/alto-networkmap+json 1861 { 1862 "meta" : {}, 1863 "data" : { 1864 "map-vtag" : "1266506139", 1865 "map" : { 1866 "PID1" : { 1867 "ipv4" : [ 1868 "192.0.2.0/24", 1869 "198.51.100.0/24" 1870 ] 1871 }, 1872 "PID2" : { 1873 "ipv4": [ 1874 "198.51.100.128/24" 1875 ] 1876 } 1877 } 1878 } 1879 } 1881 7.7.3.2. Filtered Cost Map 1883 A Filtered Cost Map is a Cost Map Information Resource 1884 (Section 7.7.2.2) for which an ALTO Client may supply additional 1885 parameters limiting the scope of the resulting Cost Map. A Filtered 1886 Cost Map MAY be provided by an ALTO Server. 1888 7.7.3.2.1. Media Type 1890 See Section 7.7.2.2.1. 1892 7.7.3.2.2. HTTP Method 1894 This resource is requested using the HTTP POST method. 1896 7.7.3.2.3. Input Parameters 1898 Input parameters are supplied in the entity body of the POST request. 1899 This document specifies the input parameters with a data format 1900 indicated by the media type "application/alto-costmapfilter+json", 1901 which is a JSON Object of type ReqFilteredCostMap, where: 1903 object { 1904 PIDName srcs<0..*>; 1905 PIDName dsts<0..*>; 1906 } PIDFilter; 1908 object { 1909 CostMode cost-mode; 1910 CostType cost-type; 1911 JSONString constraints<0..*>; [OPTIONAL] 1912 PIDFilter pids; [OPTIONAL] 1913 } ReqFilteredCostMap; 1915 with members: 1917 cost-type The Cost Type ( Section 5.1.1) for the returned costs. 1918 This MUST be one of the supported Cost Types indicated in this 1919 resource's capabilities ( Section 7.7.3.2.4). 1921 cost-mode The Cost Mode ( Section 5.1.2) for the returned costs. 1922 This MUST be one of the supported Cost Modes indicated in this 1923 resource's capabilities ( Section 7.7.3.2.4). 1925 constraints Defines a list of additional constraints on which 1926 elements of the Cost Map are returned. This parameter MUST NOT be 1927 specified if this resource's capabilities ( Section 7.7.3.2.4) 1928 indicate that constraint support is not available. A constraint 1929 contains two entities separated by whitespace: (1) an operator 1930 either 'gt' for greater than or 'lt' for less than (2) a target 1931 numerical cost. The numerical cost is a number that MUST be 1932 defined in the same units as the Cost Type indicated by the cost- 1933 type parameter. ALTO Servers SHOULD use at least IEEE 754 double- 1934 precision floating point [IEEE.754.2008] to store the numerical 1935 cost, and SHOULD perform internal computations using double- 1936 precision floating-point arithmetic. If multiple 'constraint' 1937 parameters are specified, they are interpreted as being related to 1938 each other with a logical AND. 1940 pids A list of Source PIDs and a list of Destination PIDs for which 1941 Path Costs are to be returned. If a list is empty, the ALTO 1942 Server MUST interpret it as the full set of currently-defined 1943 PIDs. The ALTO Server MUST interpret entries appearing in a list 1944 multiple times as if they appeared only once. If the "pids" 1945 member is not present, both lists MUST be interpreted by the ALTO 1946 Server as containing the full set of currently-defined PIDs. 1948 7.7.3.2.4. Capabilities 1950 The URI providing this resource supports all capabilities documented 1951 in Section 7.7.2.2.4 (with identical semantics), plus additional 1952 capabilities. In particular, the capabilities are defined by a JSON 1953 object of type FilteredCostMapCapability: 1955 object { 1956 CostMode cost-modes<0..*>; 1957 CostType cost-types<0..*>; 1958 JSONBool cost-constraints; 1959 } FilteredCostMapCapability; 1961 with members: 1963 cost-modes See Section 7.7.2.2.4. 1965 cost-types See Section 7.7.2.2.4. 1967 cost-constraints If true, then the ALTO Server allows cost 1968 constraints to be included in requests to the corresponding URI. 1969 If not present, this member MUST be interpreted as if it specified 1970 false. 1972 7.7.3.2.5. Response 1974 See Section 7.7.2.2.5 for the format. 1976 The returned Cost Map MUST NOT contain any source/destination pair 1977 that was not indicated (implicitly or explicitly) in the input 1978 parameters. If the input parameters contain a PID name that is not 1979 currently defined by the ALTO Server, the ALTO Server MUST behave as 1980 if the PID did not appear in the input parameters. 1982 If any constraints are specified, Source/Destination pairs for which 1983 the Path Costs do not meet the constraints MUST NOT be included in 1984 the returned Cost Map. If no constraints were specified, then all 1985 Path Costs are assumed to meet the constraints. 1987 Note that ALTO Clients should verify that the Version Tag included in 1988 the response is consistent with the Version Tag of the Network Map 1989 used to generate the request (if applicable). If it is not, the ALTO 1990 Client may wish to request an updated Network Map, identify changes, 1991 and consider requesting a new Filtered Cost Map. 1993 7.7.3.2.6. Example 1995 POST /costmap/filtered HTTP/1.1 1996 Host: custom.alto.example.com 1997 Content-Type: application/alto-costmapfilter+json 1998 Accept: application/alto-costmap+json,application/alto-error+json 2000 { 2001 "cost-mode" : "numerical", 2002 "cost-type" : "routingcost", 2003 "pids" : { 2004 "srcs" : [ "PID1" ], 2005 "dsts" : [ "PID1", "PID2", "PID3" ] 2006 } 2007 } 2009 HTTP/1.1 200 OK 2010 Content-Length: [TODO] 2011 Content-Type: application/alto-costmap+json 2013 { 2014 "meta" : {}, 2015 "data" : { 2016 "cost-mode" : "numerical", 2017 "cost-type" : "routingcost", 2018 "map-vtag" : "1266506139", 2019 "map" : { 2020 "PID1": { "PID1": 0, "PID2": 1, "PID3": 2 } 2021 } 2022 } 2023 } 2025 7.7.4. Endpoint Property Service 2027 The Endpoint Property Service provides information about Endpoint 2028 properties to ALTO Clients. 2030 7.7.4.1. Endpoint Property 2032 The Endpoint Property resource provides information about properties 2033 for individual endpoints. It MAY be provided by an ALTO Server. If 2034 an ALTO Server provides the Endpoint Property resource, it MUST 2035 provide and define at least the 'pid' property for each Endpoint. 2037 7.7.4.1.1. Media Type 2039 The media type is "application/alto-endpointprop+json". 2041 7.7.4.1.2. HTTP Method 2043 This resource is requested using the HTTP POST method. 2045 7.7.4.1.3. Input Parameters 2047 Input parameters are supplied in the entity body of the POST request. 2048 This document specifies the data format of input parameteres with the 2049 media type "application/alto-endpointpropparams+json", which is a 2050 JSON Object of type ReqEndpointProp: 2052 object { 2053 EndpointProperty properties<1..*>; 2054 TypedEndpointAddr endpoints<1..*>; 2055 } ReqEndpointProp; 2057 with members: 2059 properties List of endpoint properties to returned for each 2060 endpoint. Each specified property MUST be included in the list of 2061 supported properties indicated by this resource's capabilities ( 2062 Section 7.7.4.1.4). The ALTO Server MUST interpret entries 2063 appearing multiple times as if they appeared only once. 2065 endpoints List of endpoint addresses for which the specified 2066 properties are to be returned. The ALTO Server MUST interpret 2067 entries appearing multiple times as if they appeared only once. 2069 7.7.4.1.4. Capabilities 2071 This resource may be defined across multiple types of endpoint 2072 properties. The capabilities of an ALTO Server URI providing 2073 Endpoint Properties are defined by a JSON Object of type 2074 EndpointPropertyCapability: 2076 object { 2077 EndpointProperty prop-types<0..*>; 2078 } EndpointPropertyCapability; 2080 with members: 2082 prop-types The Endpoint Property Types ( Section 3.2.3) supported by 2083 the corresponding URI. If not present, this member MUST be 2084 interpreted as an empty array. 2086 7.7.4.1.5. Response 2088 The returned InfoResourceEntity object has "data" member of type 2089 InfoResourceEndpointProperty, where: 2091 object { 2092 JSONString [EndpointProperty]; 2093 ... 2094 } EndpointProps; 2096 object { 2097 VersionTag map-vtag; [OPTIONAL] 2098 EndpointProps [TypedEndpointAddr]<0..*>; 2099 ... 2100 } InfoResourceEndpointProperty; 2102 InfoResourceEndpointProperty has one member for each endpoint 2103 indicated in the input parameters (with the name being the endpoint 2104 encoded as a TypedEndpointAddr). The requested properties for each 2105 endpoint are encoded in a corresponding EndpointProps object, which 2106 encodes one name/value pair for each requested property, where the 2107 property names are encoded as strings of type EndpointProperty and 2108 the property values encoded as JSON Strings. 2110 The ALTO Server returns the value for each of the requested endpoint 2111 properties for each of the endpoints listed in the input parameters. 2113 If the ALTO Server does not define a requested property for a 2114 particular endpoint, then it MUST omit it from the response for only 2115 that endpoint. 2117 The ALTO Server MAY include the Version Tag (Section 5.3) of the 2118 Network Map used to generate the response (if desired and applicable) 2119 as the 'map-vtag' member in the response. If the 'pid' property is 2120 returned for any endpoints in the response, the 'map-vtag' member is 2121 REQUIRED instead of OPTIONAL. 2123 7.7.4.1.6. Example 2125 POST /endpointprop/lookup HTTP/1.1 2126 Host: alto.example.com 2127 Content-Length: [TODO] 2128 Content-Type: application/alto-endpointpropparams+json 2129 Accept: application/alto-endpointprop+json,application/alto-error+json 2131 { 2132 "properties" : [ "pid" ], 2133 "endpoints" : [ "ipv4:192.0.2.34", "ipv4:203.0.113.129" ] 2134 } 2136 HTTP/1.1 200 OK 2137 Content-Length: [TODO] 2138 Content-Type: application/alto-endpointprop+json 2140 { 2141 "meta" : {}, 2142 "data": { 2143 "ipv4:192.0.2.34" : { "pid": "PID1" }, 2144 "ipv4:203.0.113.129" : { "pid": "PID3" } 2145 } 2146 } 2148 7.7.5. Endpoint Cost Service 2150 The Endpoint Cost Service provides information about costs between 2151 individual endpoints. 2153 In particular, this service allows lists of Endpoint prefixes (and 2154 addresses, as a special case) to be ranked (ordered) by an ALTO 2155 Server. 2157 7.7.5.1. Endpoint Cost 2159 The Endpoint Cost resource provides information about costs between 2160 individual endpoints. It MAY be provided by an ALTO Server. 2162 It is important to note that although this resource allows an ALTO 2163 Server to reveal costs between individual endpoints, an ALTO Server 2164 is not required to do so. A simple alternative would be to compute 2165 the cost between two endpoints as the cost between the PIDs 2166 corresponding to the endpoints. See Section 12.1 for additional 2167 details. 2169 7.7.5.1.1. Media Type 2171 The media type is "application/alto-endpointcost+json". 2173 7.7.5.1.2. HTTP Method 2175 This resource is requested using the HTTP POST method. 2177 7.7.5.1.3. Input Parameters 2179 Input parameters are supplied in the entity body of the POST request. 2180 This document specifies input parameters with a data format indicated 2181 by media type "application/alto-endpointcostparams+json", which is a 2182 JSON Object of type ReqEndpointCostMap: 2184 object { 2185 TypedEndpointAddr srcs<0..*>; [OPTIONAL] 2186 TypedEndpointAddr dsts<1..*>; 2187 } EndpointFilter; 2189 object { 2190 CostMode cost-mode; 2191 CostType cost-type; 2192 JSONString constraints; [OPTIONAL] 2193 EndpointFilter endpoints; 2194 } ReqEndpointCostMap; 2196 with members: 2198 cost-mode The Cost Mode ( Section 5.1.2) to use for returned costs. 2199 This MUST be one of the Cost Modes indicated in this resource's 2200 capabilities ( Section 7.7.5.1.4). 2202 cost-type The Cost Type ( Section 5.1.1) to use for returned costs. 2203 This MUST be one of the Cost Types indicated in this resource's 2204 capabilities ( Section 7.7.5.1.4). 2206 constraints Defined equivalently to the "constraints" input 2207 parameter of a Filtered Cost Map (see Section 7.7.3.2). 2209 endpoints A list of Source Endpoints and Destination Endpoints for 2210 which Path Costs are to be returned. If the list of Source 2211 Endpoints is empty (or not included), the ALTO Server MUST 2212 interpret it as if it contained the Endpoint Address corresponding 2213 to the client IP address from the incoming connection (see 2214 Section 10.3 for discussion and considerations regarding this 2215 mode). The list of destination Endpoints MUST NOT be empty. The 2216 ALTO Server MUST interpret entries appearing multiple times in a 2217 list as if they appeared only once. 2219 7.7.5.1.4. Capabilities 2221 See Section 7.7.3.2.4. 2223 7.7.5.1.5. Response 2225 The returned InfoResourceEntity object has "data" member equal to 2226 InfoResourceEndpointCostMap, where: 2228 object EndpointDstCosts { 2229 JSONNumber [TypedEndpointAddr]; 2230 ... 2231 }; 2233 object { 2234 EndpointDstCosts [TypedEndpointAddr]<0..*>; 2235 ... 2236 } EndpointCostMapData; 2238 object { 2239 CostMode cost-mode; 2240 CostType cost-type; 2241 EndpointCostMapData map; 2242 } InfoResourceEndpointCostMap; 2244 InfoResourceEndpointCostMap has members: 2246 cost-mode The Cost Mode used in the returned Cost Map. 2248 cost-type The Cost Type used in the returned Cost Map. 2250 map The Endpoint Cost Map data itself. 2252 EndpointCostMapData is a JSON object with each member representing a 2253 single Source Endpoint specified in the input parameters; the name 2254 for a member is the TypedEndpointAddr string identifying the 2255 corresponding Source Endpoint. For each Source Endpoint, a 2256 EndpointDstCosts object denotes the associated cost to each 2257 Destination Endpoint specified in the input parameters; the name for 2258 each member in the object is the TypedEndpointAddr string identifying 2259 the corresponding Destination Endpoint. If the ALTO Server does not 2260 define a cost from a Source Endpoint to a particular Destination 2261 Endpoint, it MAY be omitted from the response. 2263 7.7.5.1.6. Example 2265 POST /endpointcost/lookup HTTP/1.1 2266 Host: alto.example.com 2267 Content-Length: [TODO] 2268 Content-Type: application/alto-endpointcostparams+json 2269 Accept: application/alto-endpointcost+json,application/alto-error+json 2271 { 2272 "cost-mode" : "ordinal", 2273 "cost-type" : "routingcost", 2274 "endpoints" : { 2275 "srcs": [ "ipv4:192.0.2.2" ], 2276 "dsts": [ 2277 "ipv4:192.0.2.89", 2278 "ipv4:198.51.100.34", 2279 "ipv4:203.0.113.45" 2280 ] 2281 } 2282 } 2284 HTTP/1.1 200 OK 2285 Content-Length: [TODO] 2286 Content-Type: application/alto-endpointcost+json 2288 { 2289 "meta" : {}, 2290 "data" : { 2291 "cost-mode" : "ordinal", 2292 "cost-type" : "routingcost", 2293 "map" : { 2294 "ipv4:192.0.2.2": { 2295 "ipv4:192.0.2.89" : 1, 2296 "ipv4:198.51.100.34" : 2, 2297 "ipv4:203.0.113.45" : 3 2298 } 2299 } 2300 } 2301 } 2303 8. Redistributable Responses 2305 This section defines how an ALTO Server enables certain Information 2306 Resources to be redistributed by ALTO Clients. Concepts are first 2307 introduced, followed by the protocol specification. 2309 8.1. Concepts 2311 8.1.1. Service ID 2313 The Service ID is a UUID that identifies a set of ALTO Servers that 2314 would provide semantically-identical Information Resources for any 2315 request for any ALTO Client. Each ALTO Server within such a set is 2316 configured with an identical Service ID. 2318 If a pair of ALTO Servers would provide an identical Information 2319 Resource (same information sources, configuration, internal 2320 computations, update timescales, etc) in response to any particular 2321 ALTO Client request, then the pair of ALTO Servers MAY have the same 2322 Service ID. If this condition is not true, the pair of ALTO Servers 2323 MUST have a different Service ID. 2325 8.1.1.1. Rationale 2327 For scalability and fault tolerance, multiple ALTO Servers may be 2328 deployed to serve equivalent ALTO Information. In such a scenario, 2329 Information Resources from any such redundant server should be seen 2330 as equivalent for the purposes of redistribution. For example, if 2331 two ALTO Servers A and B are deployed by the service provider to 2332 distribute equivalent ALTO Information, then clients contacting 2333 Server A should be able to redistribute Information Resources to 2334 clients contacting Server B. 2336 To accomplish this behavior, ALTO Clients must be able to determine 2337 that Server A and Server B serve identical ALTO Information. One 2338 technique would be to rely on the ALTO Server's DNS name. However, 2339 such an approach would mandate that all ALTO Servers resolved by a 2340 particular DNS name would need to provide equivalent ALTO 2341 information, which may be unnecessarily restrictive. Another 2342 technique would be to rely on the server's IP address. However, this 2343 suffers similar problems as the DNS name in deployment scenarios 2344 using IP Anycast. 2346 To avoid such restrictions, the ALTO Protocol allows an ALTO Service 2347 Provider to explicitly denote ALTO Servers that provide equivalent 2348 ALTO Information by giving them identical Service IDs. Service IDs 2349 decouple the identification of equivalent ALTO Servers from the 2350 discovery process. 2352 8.1.1.2. Server Information Resource 2354 If an ALTO Server generates redistributable responses, the Server 2355 Information resource's 'service-id' field MUST be set to the ALTO 2356 Server's Service ID. 2358 8.1.1.3. Configuration 2360 To help prevent ALTO Servers from mistakenly claiming to distribute 2361 equivalent ALTO Information, ALTO Server implementations SHOULD by 2362 default generate a new UUID at installation time or startup if one 2363 has not explicitly been configured. 2365 8.1.2. Expiration Time 2367 Information Resources marked as redistributable should indicate a 2368 time after which the information is considered stale and should be 2369 refreshed from the ALTO Server (or possibly another ALTO Client). 2371 If an expiration time is present, the ALTO Server SHOULD ensure that 2372 it is reasonably consistent with the expiration time that would be 2373 computed by HTTP header fields. This specification makes no 2374 recommendation on which expiration time takes precedence, but 2375 implementers should be cognizant that HTTP intermediaries will obey 2376 only the HTTP header fields. 2378 8.1.3. Signature 2380 Information Resources marked as redistributable include a signature 2381 used to assert that the ALTO Server Provider generated the ALTO 2382 Information. 2384 8.1.3.1. Rationale 2386 Verification of the signature requires the ALTO Client to retrieve 2387 the ALTO Server's public key. To reduce requirements on the 2388 underlying transport (i.e., requiring SSL/TLS), an ALTO Client 2389 retrieves the public key as part of an X.509 certificate from the 2390 ALTO Server's Server Information resource. 2392 8.1.3.2. Certificates 2394 8.1.3.2.1. Local Certificate 2396 The ALTO Server's public key is encoded within an X.509 certificate. 2397 The corresponding private key MUST be used to sign redistributable 2398 responses. This certificate is termed the Local Certificate for an 2399 ALTO Server. 2401 8.1.3.2.2. Certificate Chain 2403 To ease key provisioning, the ALTO Protocol is designed such that 2404 each ALTO Server with an identical Service ID may have a unique 2405 private key (and hence certificate). 2407 The ALTO Service Provider may configure a certificate chain at each 2408 such ALTO Server. The Local Certificate for a single ALTO Server is 2409 the bottom-most certificate in the chain. The Certificate Chains of 2410 each ALTO Server with an identical Service ID MUST share a common 2411 Root Certificate. 2413 Note that there are two simple deployment scenarios: 2415 o One-Level Certificate Chain (Local Certificate Only): In this 2416 deployment scenario, each ALTO Server with an identical Service ID 2417 may provisioned with an identical Local Certificate. 2419 o Two-Level Certificate Chain: In this deployment scenario, a Root 2420 Certificate is maintained for a set of ALTO Servers with the same 2421 Service ID. A unique Local Certificate signed by this CA is 2422 provisioned to each ALTO Server. 2424 There are advantages to using a Certificate Chain instead of 2425 deploying the same Local Certificate to each ALTO Server. 2426 Specifically, it avoids storage of the CA's private key at ALTO 2427 Servers. It is possible to revoke and re-issue a key to a single 2428 ALTO Server. 2430 8.1.3.2.3. Server Information Resource 2432 If an ALTO Server generates redistributable responses, the Server 2433 Information resource's 'certificates' field MUST be populated with 2434 the ALTO Server's full certificate chain. The first element MUST be 2435 the ALTO Server's Local Certificate, followed by the remaining 2436 Certificate Chain in ascending order to the Root Certificate. 2438 8.1.3.3. Signature Verification 2440 ALTO Clients SHOULD verify the signature on any ALTO information 2441 received via redistribution before adjusting application behavior 2442 based on it. 2444 An ALTO Client SHOULD cache its ALTO Server's Service ID and 2445 corresponding Certificate Chain included in the Server Information 2446 resource. Recall that the last certificate in this chain is the Root 2447 Certificate. The retrieval of the Service ID and certificates SHOULD 2448 be secured using HTTPS with proper validation of the server endpoint 2449 of the SSL/TLS connection [RFC6125]. 2451 An Information Resource received via redistribution from Service ID S 2452 is declared valid if an ALTO Client can construct a transitive 2453 certificate chain from the certificate (public key) used to sign the 2454 Information Resource to the Root Certificate corresponding to Service 2455 ID S obtained by the ALTO Client in a Server Information resource. 2457 To properly construct the chain and complete this validation, an ALTO 2458 Client may need to request additional certificates from other ALTO 2459 Clients. A simple mechanism is to request the certificate chain from 2460 the ALTO Client that received the Information Resource. Note that 2461 these additional received certificates may be cached locally by an 2462 ALTO Client. 2464 ALTO Clients SHOULD verify Information Resources received via 2465 redistribution. 2467 8.1.3.4. Redistribution by ALTO Clients 2469 ALTO Clients SHOULD pass the ALTO Server Certificate, Signature, and 2470 Signature Algorithm along with the Information Resource. The 2471 mechanism for redistributing such information is not specified by the 2472 ALTO Protocol, but one possibility is to add additional messages or 2473 fields to the application's native protocol. 2475 8.2. Protocol 2477 An ALTO Server MAY indicate that a response is suitable for 2478 redistribution by including the "redistribution" member in the 2479 RspMetaData JSON object of an Information Resource. This additional 2480 member, called the Response Redistribution Descriptor, has type 2481 InfoResourceRedistDesc: 2483 object { 2484 JSONString service-id; 2485 JSONString request-uri; 2486 JSONValue request-body; 2487 JSONString media-type; 2488 JSONString expires; 2489 } InfoResourceRedistDesc; 2491 The fields encoded in the Response Redistribution Descriptor allows 2492 an ALTO Client receiving redistributed ALTO Information to understand 2493 the context of the query (the ALTO Service generating the response 2494 and any input parameters) and to interpret the results. 2496 Information about ALTO Client performing the request and any HTTP 2497 Headers passed in the request are not included in the Response 2498 Redistribution Descriptor. If any such information or headers 2499 influence the response generated by the ALTO Server, the response 2500 SHOULD NOT be indicated as redistributable. 2502 8.2.1. Response Redistribution Descriptor Fields 2504 This section defines the fields of the Response Redistribution 2505 Descriptor. 2507 8.2.1.1. Service ID 2509 The 'service-id' member is REQUIRED and MUST have a value equal to 2510 the ALTO Server's Service ID. 2512 8.2.1.2. Request URI 2514 The 'request-uri' member is REQUIRED and MUST specify the HTTP 2515 Request-URI that was passed in the HTTP request. 2517 8.2.1.3. Request Body 2519 If the HTTP request's entity body was non-empty, the 'request-body' 2520 member MUST specify full JSON value passed in the HTTP request's 2521 entity body (note that whitespace may differ, as long as the JSON 2522 Value is identical). If the HTTP request was empty, then the 2523 'request-body' MUST NOT be included. 2525 8.2.1.4. Response Media Type 2527 The 'media-type' member is REQUIRED and MUST specify the same HTTP 2528 Content-Type that is used in the HTTP response. 2530 8.2.1.5. Expiration Time 2532 The 'expires' element is RECOMMENDED and, if present, MUST specify a 2533 time in UTC formatted according to [RFC3339]. 2535 8.2.2. Signature 2537 The Hash Algorithm, Signature Algorithm, and Signature are included 2538 as either HTTP Headers or Trailers. Headers may be useful if 2539 Information Resources are pre-generated, while Trailers may be useful 2540 if Information Resources are dynamically generated (e.g., to avoid 2541 buffering large responses in memory while the hash value is 2542 computed). 2544 The following HTTP Headers (the ALTO Server MAY specify them as HTTP 2545 Trailers instead) MUST be used to encode the Signature parameters for 2546 redistributable Information Resources: 2548 ALTO-HashAlgorithm: 2549 ALTO-SignatureAlgorithm: 2550 ALTO-SignatureDigest: 2552 where and are an integer values 2553 from the IANA TLS HashAlgorithm and SignatureAlgorithm registries, 2554 and is the corresponding Base64-encoded signature. 2556 9. Use Cases 2558 The sections below depict typical use cases. 2560 9.1. ALTO Client Embedded in P2P Tracker 2562 Many P2P currently-deployed P2P systems use a Tracker to manage 2563 swarms and perform peer selection. P2P trackers may currently use a 2564 variety of information to perform peer selection to meet application- 2565 specific goals. By acting as an ALTO Client, an P2P tracker can use 2566 ALTO information as an additional information source to enable more 2567 network-efficient traffic patterns and improve application 2568 performance. 2570 A particular requirement of many P2P trackers is that they must 2571 handle a large number of P2P clients. A P2P tracker can obtain and 2572 locally store ALTO information (the Network Map and Cost Map) from 2573 the ISPs containing the P2P clients, and benefit from the same 2574 aggregation of network locations done by ALTO Servers. 2576 .---------. (1) Get Network Map .---------------. 2577 | | <----------------------> | | 2578 | ALTO | | P2P Tracker | 2579 | Server | (2) Get Cost Map | (ALTO Client) | 2580 | | <----------------------> | | 2581 `---------' `---------------' 2582 ^ | 2583 (3) Get Peers | | (4) Selected Peer 2584 | v List 2585 .---------. .-----------. 2586 | Peer 1 | <-------------- | P2P | 2587 `---------' | Client | 2588 . (5) Connect to `-----------' 2589 . Selected Peers / 2590 .---------. / 2591 | Peer 50 | <------------------ 2592 `---------' 2594 Figure 4: ALTO Client Embedded in P2P Tracker 2596 Figure 4 shows an example use case where a P2P tracker is an ALTO 2597 Client and applies ALTO information when selecting peers for its P2P 2598 clients. The example proceeds as follows: 2600 1. The P2P Tracker requests the Network Map covering all PIDs from 2601 the ALTO Server using the Network Map query. The Network Map 2602 includes the IP prefixes contained in each PID, allowing the P2P 2603 tracker to locally map P2P clients into a PIDs. 2605 2. The P2P Tracker requests the Cost Map amongst all PIDs from the 2606 ALTO Server. 2608 3. A P2P Client joins the swarm, and requests a peer list from the 2609 P2P Tracker. 2611 4. The P2P Tracker returns a peer list to the P2P client. The 2612 returned peer list is computed based on the Network Map and Cost 2613 Map returned by the ALTO Server, and possibly other information 2614 sources. Note that it is possible that a tracker may use only 2615 the Network Map to implement hierarchical peer selection by 2616 preferring peers within the same PID and ISP. 2618 5. The P2P Client connects to the selected peers. 2620 Note that the P2P tracker may provide peer lists to P2P clients 2621 distributed across multiple ISPs. In such a case, the P2P tracker 2622 may communicate with multiple ALTO Servers. 2624 9.2. ALTO Client Embedded in P2P Client: Numerical Costs 2626 P2P clients may also utilize ALTO information themselves when 2627 selecting from available peers. It is important to note that not all 2628 P2P systems use a P2P tracker for peer discovery and selection. 2629 Furthermore, even when a P2P tracker is used, the P2P clients may 2630 rely on other sources, such as peer exchange and DHTs, to discover 2631 peers. 2633 When an P2P Client uses ALTO information, it typically queries only 2634 the ALTO Server servicing its own ISP. The my-Internet view provided 2635 by its ISP's ALTO Server can include preferences to all potential 2636 peers. 2638 .---------. (1) Get Network Map .---------------. 2639 | | <----------------------> | | 2640 | ALTO | | P2P Client | 2641 | Server | (2) Get Cost Map | (ALTO Client) | 2642 | | <----------------------> | | .---------. 2643 `---------' `---------------' <- | P2P | 2644 .---------. / | ^ ^ | Tracker | 2645 | Peer 1 | <-------------- | | \ `---------' 2646 `---------' | (3) Gather Peers 2647 . (4) Select Peers | | \ 2648 . and Connect / .--------. .--------. 2649 .---------. / | P2P | | DHT | 2650 | Peer 50 | <---------------- | Client | `--------' 2651 `---------' | (PEX) | 2652 `--------' 2654 Figure 5: ALTO Client Embedded in P2P Client 2656 Figure 5 shows an example use case where a P2P Client locally applies 2657 ALTO information to select peers. The use case proceeds as follows: 2659 1. The P2P Client requests the Network Map covering all PIDs from 2660 the ALTO Server servicing its own ISP. 2662 2. The P2P Client requests the Cost Map amongst all PIDs from the 2663 ALTO Server. The Cost Map by default specifies numerical costs. 2665 3. The P2P Client discovers peers from sources such as Peer Exchange 2666 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2667 P2P Trackers. 2669 4. The P2P Client uses ALTO information as part of the algorithm for 2670 selecting new peers, and connects to the selected peers. 2672 9.3. ALTO Client Embedded in P2P Client: Ranking 2674 It is also possible for a P2P Client to offload the selection and 2675 ranking process to an ALTO Server. In this use case, the ALTO Client 2676 gathers a list of known peers in the swarm, and asks the ALTO Server 2677 to rank them. 2679 As in the use case using numerical costs, the P2P Client typically 2680 only queries the ALTO Server servicing its own ISP. 2682 .---------. .---------------. 2683 | | | | 2684 | ALTO | (2) Get Endpoint Ranking | P2P Client | 2685 | Server | <----------------------> | (ALTO Client) | 2686 | | | | .---------. 2687 `---------' `---------------' <- | P2P | 2688 .---------. / | ^ ^ | Tracker | 2689 | Peer 1 | <-------------- | | \ `---------' 2690 `---------' | (1) Gather Peers 2691 . (3) Connect to | | \ 2692 . Selected Peers / .--------. .--------. 2693 .---------. / | P2P | | DHT | 2694 | Peer 50 | <---------------- | Client | `--------' 2695 `---------' | (PEX) | 2696 `--------' 2698 Figure 6: ALTO Client Embedded in P2P Client: Ranking 2700 Figure 6 shows an example of this scenario. The use case proceeds as 2701 follows: 2703 1. The P2P Client discovers peers from sources such as Peer Exchange 2704 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2705 P2P Trackers. 2707 2. The P2P Client queries the ALTO Server's Ranking Service, 2708 including discovered peers as the set of Destination Endpoints, 2709 and indicates the 'ordinal' Cost Mode. The response indicates 2710 the ranking of the candidate peers. 2712 3. The P2P Client connects to the peers in the order specified in 2713 the ranking. 2715 10. Discussions 2716 10.1. Discovery 2718 The discovery mechanism by which an ALTO Client locates an 2719 appropriate ALTO Server is out of scope for this document. This 2720 document assumes that an ALTO Client can discover an appropriate ALTO 2721 Server. Once it has done so, the ALTO Client may use the Information 2722 Resource Directory (see Section 7.6) to locate an Information 2723 Resource with the desired ALTO Information. 2725 10.2. Hosts with Multiple Endpoint Addresses 2727 In practical deployments, especially during the transition from IPv4 2728 to IPv6, a particular host may be reachable using multiple addresses. 2729 Furthermore, the particular network path followed when sending 2730 packets to the host may differ based on the address that is used. 2731 Network providers may prefer one path over another (e.g., one path my 2732 have a NAT64 middlebox). An additional consideration may be how to 2733 handle private address spaces (e.g., behind carrier-grade NATs). 2735 To support such behavior, this document allows multiple types of 2736 endpoint addresses. In supporting multiple address types, the ALTO 2737 Protocol also allows ALTO Service Provider the flexibility to 2738 indicate preferences for paths from an endpoint address of one type 2739 to an endpoint address of a different type. Note that in general, 2740 the path through the network may differ dependent on the types of 2741 addresses that are used. 2743 Note that there are limitations as to what information ALTO can 2744 provide in this regard. In particular, a particular ALTO Service 2745 provider may not be able to determine if connectivity with a 2746 particular endhost will succeed over IPv4 or IPv6, as this may depend 2747 upon information unknown to the ISP such as particular application 2748 implementations. 2750 10.3. Network Address Translation Considerations 2752 At this day and age of NAT v4<->v4, v4<->v6 [RFC6144], and possibly 2753 v6<->v6[I-D.mrw-nat66], a protocol should strive to be NAT friendly 2754 and minimize carrying IP addresses in the payload, or provide a mode 2755 of operation where the source IP address provide the information 2756 necessary to the server. 2758 The protocol specified in this document provides a mode of operation 2759 where the source network location is computed by the ALTO Server 2760 (i.e., the the Endpoint Cost Service) from the source IP address 2761 found in the ALTO Client query packets. This is similar to how some 2762 P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS 2763 Protocol" in [BitTorrent]) operate. 2765 The ALTO client SHOULD use the Session Traversal Utilities for NAT 2766 (STUN) [RFC5389] to determine a public IP address to use as a source 2767 Endpoint address. If using this method, the host MUST use the 2768 "Binding Request" message and the resulting "XOR-MAPPED-ADDRESS" 2769 parameter that is returned in the response. Using STUN requires 2770 cooperation from a publicly accessible STUN server. Thus, the ALTO 2771 client also requires configuration information that identifies the 2772 STUN server, or a domain name that can be used for STUN server 2773 discovery. To be selected for this purpose, the STUN server needs to 2774 provide the public reflexive transport address of the host. 2776 10.4. Mapping IPs to ASNs 2778 It may be desired for the ALTO Protocol to provide ALTO information 2779 including ASNs. Thus, ALTO Clients may need to identify the ASN for 2780 a Resource Provider to determine the cost to that Resource Provider. 2782 Applications can already map IPs to ASNs using information from a BGP 2783 Looking Glass. To do so, they must download a file of about 1.5MB 2784 when compressed (as of October 2008, with all information not needed 2785 for IP to ASN mapping removed) and periodically (perhaps monthly) 2786 refresh it. 2788 Alternatively, the Network Map query in the Map Filtering Service 2789 defined in this document could be extended to map ASNs into a set of 2790 IP prefixes. The mappings provided by the ISP would be both smaller 2791 and more authoritative. 2793 For simplicity of implementation, it's highly desirable that clients 2794 only have to implement exactly one mechanism of mapping IPs to ASNs. 2796 10.5. Endpoint and Path Properties 2798 An ALTO Server could make available many properties about Endpoints 2799 beyond their network location or grouping. For example, connection 2800 type, geographical location, and others may be useful to 2801 applications. This specification focuses on network location and 2802 grouping, but the protocol may be extended to handle other Endpoint 2803 properties. 2805 11. IANA Considerations 2807 11.1. application/alto-* Media Types 2809 This document requests the registration of multiple media types, 2810 listed in Table 2. 2812 +-------------+------------------------------+-----------------+ 2813 | Type | Subtype | Specification | 2814 +-------------+------------------------------+-----------------+ 2815 | application | alto-directory+json | Section 7.6 | 2816 | application | alto-serverinfo+json | Section 7.7.1.1 | 2817 | application | alto-networkmap+json | Section 7.7.2.1 | 2818 | application | alto-networkmapfilter+json | Section 7.7.3.1 | 2819 | application | alto-costmap+json | Section 7.7.2.2 | 2820 | application | alto-costmapfilter+json | Section 7.7.3.2 | 2821 | application | alto-endpointprop+json | Section 7.7.4.1 | 2822 | application | alto-endpointpropparams+json | Section 7.7.4.1 | 2823 | application | alto-endpointcost+json | Section 7.7.5.1 | 2824 | application | alto-endpointcostparams+json | Section 7.7.5.1 | 2825 | application | alto-error+json | Section 7.4 | 2826 +-------------+------------------------------+-----------------+ 2828 Table 2: ALTO Protocol Media Types 2830 Type name: application 2832 Subtype name: This documents requests the registration of multiple 2833 subtypes, as listed in Table 2. 2835 Required parameters: n/a 2837 Optional parameters: n/a 2839 Encoding considerations: Encoding considerations are identical to 2840 those specified for the 'application/json' media type. See 2841 [RFC4627]. 2843 Security considerations: Security considerations relating to the 2844 generation and consumption of ALTO protocol messages are discussed 2845 in Section 12. 2847 Interoperability considerations: This document specifies format of 2848 conforming messages and the interpretation thereof. 2850 Published specification: This document is the specification for 2851 these media types; see Table 2for the section documenting each 2852 media type. 2854 Applications that use this media type: ALTO Servers and ALTO Clients 2855 either standalone or embedded within other applications. 2857 Additional information: 2859 Magic number(s): n/a 2861 File extension(s): This document uses the mime type to refer to 2862 protocol messages and thus does not require a file extension. 2864 Macintosh file type code(s): n/a 2866 Person & email address to contact for further information: See 2867 "Authors' Addresses" section. 2869 Intended usage: COMMON 2871 Restrictions on usage: n/a 2873 Author: See "Authors' Addresses" section. 2875 Change controller: See "Authors' Addresses" section. 2877 11.2. ALTO Cost Type Registry 2879 This document requests the creation of an ALTO Cost Type registry to 2880 be maintained by IANA. 2882 This registry serves two purposes. First, it ensures uniqueness of 2883 identifiers referring to ALTO Cost Types. Second, it provides 2884 references to particular semantics of allocated Cost Types to be 2885 applied by both ALTO Servers and applications utilizing ALTO Clients. 2887 New ALTO Cost Types are assigned after Expert Review [RFC5226]. The 2888 Expert Reviewer will generally consult the ALTO Working Group or its 2889 successor. Expert Review is used to ensure that proper documentation 2890 regarding ALTO Cost Type semantics and security considerations has 2891 been provided. The provided documentation should be detailed enough 2892 to provide guidance to both ALTO Service Providers and applications 2893 utilizing ALTO Clients as to how values of the registered ALTO Cost 2894 Type should be interpreted. Updates and deletions of ALTO Cost Types 2895 follow the same procedure. 2897 Registered ALTO Cost Type identifiers MUST conform to the syntatical 2898 requirements specified in Section 7.5.5. Identifiers are to be 2899 recorded and displayed as ASCII strings. 2901 Identifiers prefixed with 'priv:' are reserved for Private Use. 2902 Identifiers prefixed with 'exp:' are reserved for Experimental use. 2904 Requests to add a new value to the registry MUST include the 2905 following information: 2907 o Identifier: The name of the desired ALTO Cost Type. 2909 o Intended Semantics: ALTO Costs carry with them semantics to guide 2910 their usage by ALTO Clients. For example, if a value refers to a 2911 measurement, the measurement units must be documented. For proper 2912 implementation of the ordinal Cost Mode (e.g., by a third-party 2913 service), it should be documented whether higher or lower values 2914 of the cost are more preferred. 2916 o Security Considerations: ALTO Costs expose information to ALTO 2917 Clients. As such, proper usage of a particular Cost Type may 2918 require certain information to be exposed by an ALTO Service 2919 Provider. Since network information is frequently regarded as 2920 proprietary or confidential, ALTO Service Providers should be made 2921 aware of the security ramifications related to usage of a Cost 2922 Type. 2924 This specification requests registration of the identifier 2925 'routingcost'. Semantics for the this Cost Type are documented in 2926 Section 5.1.1.1, and security considerations are documented in 2927 Section 12.1. 2929 11.3. ALTO Endpoint Property Registry 2931 This document requests the creation of an ALTO Endpoint Property 2932 registry to be maintained by IANA. 2934 This registry serves two purposes. First, it ensures uniqueness of 2935 identifiers referring to ALTO Endpoint Properties. Second, it 2936 provides references to particular semantics of allocated Endpoint 2937 Properties to be applied by both ALTO Servers and applications 2938 utilizing ALTO Clients. 2940 New ALTO Endpoint Properties are assigned after Expert Review 2941 [RFC5226]. The Expert Reviewer will generally consult the ALTO 2942 Working Group or its successor. Expert Review is used to ensure that 2943 proper documentation regarding ALTO Endpoint Property semantics and 2944 security considerations has been provided. The provided 2945 documentation should be detailed enough to provide guidance to both 2946 ALTO Service Providers and applications utilizing ALTO Clients as to 2947 how values of the registered ALTO Endpoint Properties should be 2948 interpreted. Updates and deletions of ALTO Endpoint Properties 2949 follow the same procedure. 2951 Registered ALTO Endpoint Property identifiers MUST conform to the 2952 syntatical requirements specified in Section 7.5.6. Identifiers are 2953 to be recorded and displayed as ASCII strings. 2955 Identifiers prefixed with 'priv:' are reserved for Private Use. 2956 Identifiers prefixed with 'exp:' are reserved for Experimental use. 2958 Requests to add a new value to the registry MUST include the 2959 following information: 2961 o Identifier: The name of the desired ALTO Endpoint Property. 2963 o Intended Semantics: ALTO Endpoint Properties carry with them 2964 semantics to guide their usage by ALTO Clients. For example, if a 2965 value refers to a measurement, the measurement units must be 2966 documented. For proper implementation of the ordinal Cost Mode 2967 (e.g., by a third-party service), it should be documented whether 2968 higher or lower values of the cost are more preferred. 2970 o Security Considerations: ALTO Endpoint Properties expose 2971 information to ALTO Clients. As such, proper usage of a 2972 particular Endpoint Properties may require certain information to 2973 be exposed by an ALTO Service Provider. Since network information 2974 is frequently regarded as proprietary or confidential, ALTO 2975 Service Providers should be made aware of the security 2976 ramifications related to usage of an Endpoint Property. 2978 This specification requests registration of the identifier 'pid'. 2979 Semantics for the this Endpoint Property are documented in 2980 Section 4.1, and security considerations are documented in 2981 Section 12.1. 2983 12. Security Considerations 2985 12.1. Privacy Considerations for ISPs 2987 ISPs must be cognizant of the network topology and provisioning 2988 information provided through ALTO Interfaces. ISPs should evaluate 2989 how much information is revealed and the associated risks. On the 2990 one hand, providing overly fine-grained information may make it 2991 easier for attackers to infer network topology. In particular, 2992 attackers may try to infer details regarding ISPs' operational 2993 policies or inter-ISP business relationships by intentionally posting 2994 a multitude of selective queries to an ALTO server and analyzing the 2995 responses. Such sophisticated attacks may reveal more information 2996 than an ISP hosting an ALTO server intends to disclose. On the other 2997 hand, revealing overly coarse-grained information may not provide 2998 benefits to network efficiency or performance improvements to ALTO 2999 Clients. 3001 12.2. ALTO Clients 3003 Applications using the information must be cognizant of the 3004 possibility that the information is malformed or incorrect. Even if 3005 an ALTO Server has been properly authenticated by the ALTO Client, 3006 the information provided may be malicious because the ALTO Server and 3007 its credentials have been compromised (e.g., through malware). Other 3008 considerations (e.g., relating to application performance) can be 3009 found in Section 6 of [RFC5693]. 3011 ALTO Clients should also be cognizant of revealing Network Location 3012 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, 3013 as doing so may allow the ALTO Server to infer communication 3014 patterns. One possibility is for the ALTO Client to only rely on 3015 Network Map for PIDs and Cost Map amongst PIDs to avoid passing IP 3016 addresses of their peers to the ALTO Server. 3018 In addition, ALTO clients should be cautious not to unintentionally 3019 or indirectly disclose the resource identifier (of which they try to 3020 improve the retrieval through ALTO-guidance), e.g., the name/ 3021 identifier of a certain video stream in P2P live streaming, to the 3022 ALTO server. Note that the ALTO Protocol specified in this document 3023 does not explicitly reveal any resource identifier to the ALTO 3024 Server. However, for instance, depending on the popularity or other 3025 specifics (such as language) of the resource, an ALTO server could 3026 potentially deduce information about the desired resource from 3027 information such as the Network Locations the client sends as part of 3028 its request to the server. 3030 12.3. Authentication, Integrity Protection, and Encryption 3032 SSL/TLS can provide encryption of transmitted messages as well as 3033 authentication of the ALTO Client and Server. HTTP Basic or Digest 3034 authentication can provide authentication of the client (combined 3035 with SSL/TLS, it can additionally provide encryption and 3036 authentication of the server). 3038 An ALTO Server may optionally use authentication (and potentially 3039 encryption) to protect ALTO information it provides. This can be 3040 achieved by digitally signing a hash of the ALTO information itself 3041 and attaching the signature to the ALTO information. There may be 3042 special use cases where encryption of ALTO information is desirable. 3043 In many cases, however, information sent out by an ALTO Server may be 3044 regarded as non-confidential information. 3046 ISPs should be cognizant that encryption only protects ALTO 3047 information until it is decrypted by the intended ALTO Client. 3048 Digital Rights Management (DRM) techniques and legal agreements 3049 protecting ALTO information are outside of the scope of this 3050 document. 3052 12.4. ALTO Information Redistribution 3054 It is possible for applications to redistribute ALTO information to 3055 improve scalability. Even with such a distribution scheme, ALTO 3056 Clients obtaining ALTO information must be able to validate the 3057 received ALTO information to ensure that it was generated by an 3058 appropriate ALTO Server. Further, to prevent the ALTO Server from 3059 being a target of attack, the verification scheme must not require 3060 ALTO Clients to contact the ALTO Server to validate every set of 3061 information. Contacting an ALTO server for information validation 3062 would also undermine the intended effect of redistribution and is 3063 therefore not desirable. 3065 Note that the redistribution scheme must additionally handle details 3066 such as ensuring ALTO Clients retrieve ALTO information from the 3067 correct ALTO Server. See [I-D.gu-alto-redistribution] for further 3068 discussion. Details of a particular redistribution scheme are 3069 outside the scope of this document. 3071 To fulfill these requirements, ALTO Information meant to be 3072 redistributable contains a digital signature which includes a hash of 3073 the ALTO information signed by the ALTO Server with its private key. 3074 The corresponding public key is included in the Server Information 3075 resource Section 7.7.1.1, along with the certificate chain to a Root 3076 Certificate generated by the ALTO Service Provider. To prevent man- 3077 in-the-middle attacks, an ALTO Client SHOULD perform the Server 3078 Information resource request over SSL/TLS and verify the server 3079 identity according to [RFC6125]. 3081 The signature verification algorithm is detailed in Section 8.1.3.3. 3083 12.5. Denial of Service 3085 ISPs should be cognizant of the workload at the ALTO Server generated 3086 by certain ALTO Queries, such as certain queries to the Map Filtering 3087 Service and Ranking Service. In particular, queries which can be 3088 generated with low effort but result in expensive workloads at the 3089 ALTO Server could be exploited for Denial-of-Service attacks. For 3090 instance, a simple ALTO query with n Source Network Locations and m 3091 Destination Network Locations can be generated fairly easily but 3092 results in the computation of n*m Path Costs between pairs by the 3093 ALTO Server (see Section 5.2). One way to limit Denial-of-Service 3094 attacks is to employ access control to the ALTO server. Another 3095 possible mechanism for an ALTO Server to protect itself against a 3096 multitude of computationally expensive bogus requests is to demand 3097 that each ALTO Client to solve a computational puzzle first before 3098 allocating resources for answering a request (see, e.g., 3099 [I-D.jennings-sip-hashcash]). The current specification does not use 3100 such computational puzzles, and discussion regarding tradeoffs of 3101 such an approach would be needed before including such a technique in 3102 the ALTO Protocol. 3104 ISPs should also leverage the fact that the the Map Service allows 3105 ALTO Servers to pre-generate maps that can be useful to many ALTO 3106 Clients. 3108 12.6. ALTO Server Access Control 3110 In order to limit access to an ALTO server (e.g., for an ISP to only 3111 allow its users to access its ALTO server, or to prevent Denial-of- 3112 Service attacks by arbitrary hosts from the Internet), an ALTO server 3113 may employ access control policies. Depending on the use-case and 3114 scenario, an ALTO server may restrict access to its services more 3115 strictly or rather openly (see [I-D.stiemerling-alto-deployments] for 3116 a more detailed discussion on this issue). 3118 13. References 3120 13.1. Normative References 3122 [IEEE.754.2008] 3123 Institute of Electrical and Electronics Engineers, 3124 "Standard for Binary Floating-Point Arithmetic", IEEE 3125 Standard 754, August 2008. 3127 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 3128 Extensions (MIME) Part Two: Media Types", RFC 2046, 3129 November 1996. 3131 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3132 Requirement Levels", BCP 14, RFC 2119, March 1997. 3134 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3135 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3136 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3138 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 3139 Internet: Timestamps", RFC 3339, July 2002. 3141 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3142 Resource Identifier (URI): Generic Syntax", STD 66, 3143 RFC 3986, January 2005. 3145 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 3146 Unique IDentifier (UUID) URN Namespace", RFC 4122, 3147 July 2005. 3149 [RFC4627] Crockford, D., "The application/json Media Type for 3150 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 3152 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 3153 (CIDR): The Internet Address Assignment and Aggregation 3154 Plan", BCP 122, RFC 4632, August 2006. 3156 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3157 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3158 May 2008. 3160 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3161 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3162 October 2008. 3164 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 3165 Address Text Representation", RFC 5952, August 2010. 3167 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3168 Verification of Domain-Based Application Service Identity 3169 within Internet Public Key Infrastructure Using X.509 3170 (PKIX) Certificates in the Context of Transport Layer 3171 Security (TLS)", RFC 6125, March 2011. 3173 13.2. Informative References 3175 [BitTorrent] 3176 "Bittorrent Protocol Specification v1.0", 3177 . 3179 [I-D.akonjang-alto-proxidor] 3180 Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 3181 Saucez, "The PROXIDOR Service", 3182 draft-akonjang-alto-proxidor-00 (work in progress), 3183 March 2009. 3185 [I-D.gu-alto-redistribution] 3186 Yingjie, G., Alimi, R., and R. Even, "ALTO Information 3187 Redistribution", draft-gu-alto-redistribution-03 (work in 3188 progress), July 2010. 3190 [I-D.ietf-alto-reqs] 3191 Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, 3192 "Application-Layer Traffic Optimization (ALTO) 3193 Requirements", draft-ietf-alto-reqs-08 (work in progress), 3194 March 2011. 3196 [I-D.ietf-alto-server-discovery] 3197 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 3198 S. Yongchao, "ALTO Server Discovery", 3199 draft-ietf-alto-server-discovery-02 (work in progress), 3200 September 2011. 3202 [I-D.jennings-sip-hashcash] 3203 Jennings, C., "Computational Puzzles for SPAM Reduction in 3204 SIP", draft-jennings-sip-hashcash-06 (work in progress), 3205 July 2007. 3207 [I-D.mrw-nat66] 3208 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 3209 Translation", draft-mrw-nat66-16 (work in progress), 3210 April 2011. 3212 [I-D.p4p-framework] 3213 Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, 3214 "P4P: Provider Portal for P2P Applications", 3215 draft-p4p-framework-00 (work in progress), November 2008. 3217 [I-D.saumitra-alto-multi-ps] 3218 Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 3219 Dimensional Peer Selection Problem", 3220 draft-saumitra-alto-multi-ps-00 (work in progress), 3221 October 2008. 3223 [I-D.saumitra-alto-queryresponse] 3224 Das, S. and V. Narayanan, "A Client to Service Query 3225 Response Protocol for ALTO", 3226 draft-saumitra-alto-queryresponse-00 (work in progress), 3227 March 2009. 3229 [I-D.shalunov-alto-infoexport] 3230 Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 3231 Export Service", draft-shalunov-alto-infoexport-00 (work 3232 in progress), October 2008. 3234 [I-D.stiemerling-alto-deployments] 3235 Stiemerling, M. and S. Kiesel, "ALTO Deployment 3236 Considerations", draft-stiemerling-alto-deployments-06 3237 (work in progress), January 2011. 3239 [I-D.wang-alto-p4p-specification] 3240 Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, 3241 "P4P Protocol Specification", 3242 draft-wang-alto-p4p-specification-00 (work in progress), 3243 March 2009. 3245 [P4P-SIGCOMM08] 3246 Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A. 3247 Silberschatz, "P4P: Provider Portal for (P2P) 3248 Applications", SIGCOMM 2008, August 2008. 3250 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 3251 Optimization (ALTO) Problem Statement", RFC 5693, 3252 October 2009. 3254 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 3255 IPv4/IPv6 Translation", RFC 6144, April 2011. 3257 Appendix A. Acknowledgments 3259 Thank you to Jan Seedorf for contributions to the Security 3260 Considerations section. We would like to thank Yingjie Gu and Roni 3261 Even for helpful input and design concerning ALTO Information 3262 redistribution. 3264 We would like to thank the following people whose input and 3265 involvement was indispensable in achieving this merged proposal: 3267 Obi Akonjang (DT Labs/TU Berlin), 3269 Saumitra M. Das (Qualcomm Inc.), 3271 Syon Ding (China Telecom), 3273 Doug Pasko (Verizon), 3275 Laird Popkin (Pando Networks), 3277 Satish Raghunath (Juniper Networks), 3279 Albert Tian (Ericsson/Redback), 3281 Yu-Shun Wang (Microsoft), 3283 David Zhang (PPLive), 3285 Yunfei Zhang (China Mobile). 3287 We would also like to thank the following additional people who were 3288 involved in the projects that contributed to this merged document: 3289 Alex Gerber (AT&T), Chris Griffiths (Comcast), Ramit Hora (Pando 3290 Networks), Arvind Krishnamurthy (University of Washington), Marty 3291 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 3292 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T), 3293 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 3294 Damien Saucez (UCL) Thomas Scholl (AT&T), Emilio Sepulveda 3295 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 3296 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 3297 (Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia 3298 Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University), 3299 Haiyong Xie (Yale University). 3301 Appendix B. Authors 3303 [[CmtAuthors: RFC Editor: Please move information in this section to 3304 the Authors' Addresses section at publication time.]] 3306 Stefano Previdi 3307 Cisco 3309 Email: sprevidi@cisco.com 3311 Stanislav Shalunov 3312 BitTorrent 3314 Email: shalunov@bittorrent.com 3316 Richard Woundy 3317 Comcast 3319 Richard_Woundy@cable.comcast.com 3321 Authors' Addresses 3323 Richard Alimi (editor) 3324 Google 3325 1600 Amphitheatre Parkway 3326 Mountain View CA 3327 USA 3329 Email: ralimi@google.com 3330 Reinaldo Penno (editor) 3331 Juniper Networks 3332 1194 N Mathilda Avenue 3333 Sunnyvale CA 3334 USA 3336 Email: rpenno@juniper.net 3338 Y. Richard Yang (editor) 3339 Yale University 3340 51 Prospect St 3341 New Haven CT 3342 USA 3344 Email: yry@cs.yale.edu