idnits 2.17.1 draft-ietf-alto-protocol-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 1096 has weird spacing: '...ilities capa...' == Line 1392 has weird spacing: '...ataType data...' == Line 1396 has weird spacing: '... meta meta-...' == Line 1398 has weird spacing: '... data the d...' == Line 1705 has weird spacing: '...ostMode cost...' == (6 more instances...) -- The document date (July 14, 2013) is 3929 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: 'RFC 6708' is mentioned on line 3146, but not defined == Missing Reference: 'I-D.jennings-sip-hashcash' is mentioned on line 3183, but not defined == Missing Reference: 'ATTP' is mentioned on line 3578, but not defined == Unused Reference: 'I-D.ietf-alto-reqs' is defined on line 3445, but no explicit reference was found in the text -- 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 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Downref: Normative reference to an Informational RFC: RFC 5693 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Downref: Normative reference to an Informational RFC: RFC 6708 == Outdated reference: A later version (-16) exists of draft-ietf-alto-deployments-06 == 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-08 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-22 Summary: 9 errors (**), 0 flaws (~~), 15 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: January 15, 2014 Cisco Systems 6 Y. Yang, Ed. 7 Yale University 8 July 14, 2013 10 ALTO Protocol 11 draft-ietf-alto-protocol-17.txt 13 Abstract 15 Applications using the Internet already have access to some topology 16 information of Internet Service Provider (ISP) networks. For 17 example, views to Internet routing tables at looking glass servers 18 are available and can be practically downloaded to many application 19 clients. What is missing is knowledge of the underlying network 20 topologies from the point of view of ISPs. In other words, what an 21 ISP prefers in terms of traffic optimization -- and a way to 22 distribute it. 24 The Application-Layer Traffic Optimization (ALTO) Service provides 25 network information (e.g., basic network location structure and 26 preferences of network paths) with the goal of modifying network 27 resource consumption patterns while maintaining or improving 28 application performance. The basic information of ALTO is based on 29 abstract maps of a network. These maps provide a simplified view, 30 yet enough information about a network for applications to 31 effectively utilize them. Additional services are built on top of 32 the maps. 34 This document describes a protocol implementing the ALTO Service. 35 Although the ALTO Service would primarily be provided by ISPs, other 36 entities such as content service providers could also operate an ALTO 37 service. Applications that could use this service are those that 38 have a choice to which end points to connect. Examples of such 39 applications are peer-to-peer (P2P) and content delivery networks. 41 Requirements Language 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC 2119 [RFC2119]. 47 Status of this Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on January 15, 2014. 63 Copyright Notice 65 Copyright (c) 2013 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 7 82 1.2. Design Overview . . . . . . . . . . . . . . . . . . . . . 8 83 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 2.2. Endpoint Address . . . . . . . . . . . . . . . . . . . . . 8 86 2.3. Network Location . . . . . . . . . . . . . . . . . . . . . 9 87 2.4. ALTO Information . . . . . . . . . . . . . . . . . . . . . 9 88 2.5. ALTO Information Base . . . . . . . . . . . . . . . . . . 9 89 2.6. ALTO Service . . . . . . . . . . . . . . . . . . . . . . . 9 90 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 3.1. ALTO Service and Protocol Scope . . . . . . . . . . . . . 9 92 3.2. ALTO Information Reuse and Redistribution . . . . . . . . 11 93 4. ALTO Information Service Framework . . . . . . . . . . . . . . 11 94 4.1. ALTO Information Services . . . . . . . . . . . . . . . . 12 95 4.1.1. Map Service . . . . . . . . . . . . . . . . . . . . . 12 96 4.1.2. Map Filtering Service . . . . . . . . . . . . . . . . 12 97 4.1.3. Endpoint Property Service . . . . . . . . . . . . . . 13 98 4.1.4. Endpoint Cost Service . . . . . . . . . . . . . . . . 13 99 5. Network Map . . . . . . . . . . . . . . . . . . . . . . . . . 13 100 5.1. Provider-defined Identifier (PID) . . . . . . . . . . . . 13 101 5.2. Endpoint Addresses . . . . . . . . . . . . . . . . . . . . 14 102 5.2.1. IP Addresses . . . . . . . . . . . . . . . . . . . . . 14 103 5.3. Example Network Map . . . . . . . . . . . . . . . . . . . 15 104 6. Cost Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 105 6.1. Cost Types . . . . . . . . . . . . . . . . . . . . . . . . 16 106 6.1.1. Cost Metric . . . . . . . . . . . . . . . . . . . . . 16 107 6.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 16 108 6.2. Cost Map Structure . . . . . . . . . . . . . . . . . . . . 17 109 6.3. Network Map and Cost Map Dependency . . . . . . . . . . . 18 110 6.4. Cost Map Update . . . . . . . . . . . . . . . . . . . . . 18 111 7. Endpoint Properties . . . . . . . . . . . . . . . . . . . . . 18 112 7.1. Endpoint Property Type . . . . . . . . . . . . . . . . . . 19 113 7.1.1. Endpoint Property Type: pid . . . . . . . . . . . . . 19 114 8. Protocol Specification: General Processing . . . . . . . . . . 19 115 8.1. Overall Design . . . . . . . . . . . . . . . . . . . . . . 19 116 8.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 19 117 8.3. Basic Operation . . . . . . . . . . . . . . . . . . . . . 20 118 8.3.1. Client Discovering Information Resources . . . . . . . 20 119 8.3.2. Client Requesting Information Resources . . . . . . . 21 120 8.3.3. Server Responding to IR Request . . . . . . . . . . . 21 121 8.3.4. Client Handling Server Response . . . . . . . . . . . 22 122 8.3.5. Authentication and Encryption . . . . . . . . . . . . 22 123 8.3.6. Information Refresh . . . . . . . . . . . . . . . . . 23 124 8.3.7. HTTP Cookies . . . . . . . . . . . . . . . . . . . . . 23 125 8.3.8. Parsing . . . . . . . . . . . . . . . . . . . . . . . 23 127 8.4. Information Resource: Attributes . . . . . . . . . . . . . 23 128 8.4.1. Resource ID . . . . . . . . . . . . . . . . . . . . . 23 129 8.4.2. Media Type . . . . . . . . . . . . . . . . . . . . . . 24 130 8.4.3. Capabilities . . . . . . . . . . . . . . . . . . . . . 24 131 8.4.4. Accepts Input Parameters . . . . . . . . . . . . . . . 24 132 8.5. Information Resource Directory . . . . . . . . . . . . . . 24 133 8.5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 24 134 8.5.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . 25 135 8.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 26 136 8.5.4. Delegation and Multiple Choices . . . . . . . . . . . 29 137 8.5.5. Usage Considerations . . . . . . . . . . . . . . . . . 31 138 8.6. Information Resource: Content Encoding . . . . . . . . . . 31 139 8.6.1. Meta Information . . . . . . . . . . . . . . . . . . . 32 140 8.6.2. Data Information . . . . . . . . . . . . . . . . . . . 32 141 8.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 32 142 8.7. Protocol Errors . . . . . . . . . . . . . . . . . . . . . 33 143 8.7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 33 144 8.7.2. Resource Format and Error Codes . . . . . . . . . . . 33 145 8.7.3. Overload Conditions and Server Unavailability . . . . 34 146 9. Protocol Specification: Basic ALTO Data Types . . . . . . . . 34 147 9.1. PID Name . . . . . . . . . . . . . . . . . . . . . . . . . 35 148 9.2. Resource ID . . . . . . . . . . . . . . . . . . . . . . . 35 149 9.3. Version Tag . . . . . . . . . . . . . . . . . . . . . . . 35 150 9.4. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 36 151 9.4.1. Address Type . . . . . . . . . . . . . . . . . . . . . 36 152 9.4.2. Endpoint Address . . . . . . . . . . . . . . . . . . . 36 153 9.4.3. Endpoint Prefixes . . . . . . . . . . . . . . . . . . 37 154 9.4.4. Endpoint Address Group . . . . . . . . . . . . . . . . 37 155 9.5. Cost Mode . . . . . . . . . . . . . . . . . . . . . . . . 38 156 9.6. Cost Metric . . . . . . . . . . . . . . . . . . . . . . . 38 157 9.7. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . 39 158 9.8. Endpoint Property . . . . . . . . . . . . . . . . . . . . 39 159 10. Protocol Specification: Service Information Resources . . . . 39 160 10.1. Map Service . . . . . . . . . . . . . . . . . . . . . . . 40 161 10.1.1. Network Map . . . . . . . . . . . . . . . . . . . . . 40 162 10.1.2. Cost Map . . . . . . . . . . . . . . . . . . . . . . . 42 163 10.2. Map Filtering Service . . . . . . . . . . . . . . . . . . 45 164 10.2.1. Filtered Network Map . . . . . . . . . . . . . . . . . 45 165 10.2.2. Filtered Cost Map . . . . . . . . . . . . . . . . . . 48 166 10.3. Endpoint Property Service . . . . . . . . . . . . . . . . 51 167 10.3.1. Endpoint Property . . . . . . . . . . . . . . . . . . 51 168 10.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 54 169 10.4.1. Endpoint Cost . . . . . . . . . . . . . . . . . . . . 55 170 11. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 58 171 11.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 59 172 11.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 60 173 11.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 61 174 12. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 62 175 12.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 62 176 12.2. Hosts with Multiple Endpoint Addresses . . . . . . . . . . 63 177 12.3. Network Address Translation Considerations . . . . . . . . 63 178 12.4. Endpoint and Path Properties . . . . . . . . . . . . . . . 64 179 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 180 13.1. application/alto-* Media Types . . . . . . . . . . . . . . 64 181 13.2. ALTO Cost Metric Registry . . . . . . . . . . . . . . . . 65 182 13.3. ALTO Endpoint Property Type Registry . . . . . . . . . . . 67 183 13.4. ALTO Address Type Registry . . . . . . . . . . . . . . . . 67 184 13.5. ALTO Error Code Registry . . . . . . . . . . . . . . . . . 68 185 14. Security Considerations . . . . . . . . . . . . . . . . . . . 69 186 14.1. Authenticity and Integrity of ALTO Information . . . . . . 69 187 14.1.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 69 188 14.1.2. Protection Strategies . . . . . . . . . . . . . . . . 69 189 14.1.3. Limitations . . . . . . . . . . . . . . . . . . . . . 70 190 14.2. Potential Undesirable Guidance from Authenticated ALTO 191 Information . . . . . . . . . . . . . . . . . . . . . . . 70 192 14.2.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 70 193 14.2.2. Protection Strategies . . . . . . . . . . . . . . . . 70 194 14.3. Confidentiality of ALTO Information . . . . . . . . . . . 71 195 14.3.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 71 196 14.3.2. Protection Strategies . . . . . . . . . . . . . . . . 71 197 14.3.3. Limitations . . . . . . . . . . . . . . . . . . . . . 72 198 14.4. Privacy for ALTO Users . . . . . . . . . . . . . . . . . . 72 199 14.4.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 72 200 14.4.2. Protection Strategies . . . . . . . . . . . . . . . . 72 201 14.5. Availability of ALTO Service . . . . . . . . . . . . . . . 73 202 14.5.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 73 203 14.5.2. Protection Strategies . . . . . . . . . . . . . . . . 73 204 15. Manageability Considerations . . . . . . . . . . . . . . . . . 73 205 15.1. Operations . . . . . . . . . . . . . . . . . . . . . . . . 73 206 15.1.1. Installation and Initial Setup . . . . . . . . . . . . 74 207 15.1.2. Migration Path . . . . . . . . . . . . . . . . . . . . 74 208 15.1.3. Requirements on Other Protocols and Functional 209 Components . . . . . . . . . . . . . . . . . . . . . . 74 210 15.1.4. Impact and Observation on Network Operation . . . . . 75 211 15.2. Management . . . . . . . . . . . . . . . . . . . . . . . . 75 212 15.2.1. Management Interoperability . . . . . . . . . . . . . 75 213 15.2.2. Management Information . . . . . . . . . . . . . . . . 76 214 15.2.3. Fault Management . . . . . . . . . . . . . . . . . . . 76 215 15.2.4. Configuration Management . . . . . . . . . . . . . . . 76 216 15.2.5. Performance Management . . . . . . . . . . . . . . . . 76 217 15.2.6. Security Management . . . . . . . . . . . . . . . . . 77 218 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 77 219 16.1. Normative References . . . . . . . . . . . . . . . . . . . 77 220 16.2. Informative References . . . . . . . . . . . . . . . . . . 78 221 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 80 222 Appendix B. Design History and Merged Proposals . . . . . . . . . 81 223 Appendix C. Authors . . . . . . . . . . . . . . . . . . . . . . . 82 224 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82 226 1. Introduction 228 1.1. Problem Statement 230 This document defines the ALTO Protocol, which provides a solution 231 for the problem stated in [RFC5693]. Specifically, in today's 232 networks, network information such as network topologies, link 233 availability, routing policies, and path costs are hidden from the 234 application layer, and many applications benefited from such hiding 235 of network complexity. However, new applications, such as 236 application-layer overlays, can benefit from information about the 237 underlying network infrastructure. In particular, these modern 238 network applications can be adaptive, and hence become more network- 239 efficient (e.g., reduce network resource consumption) and achieve 240 better application performance (e.g., accelerated download rate), by 241 leveraging network-provided information. 243 At a high level, the ALTO Protocol specified in this document is a 244 unidirectional interface that allows a network to publish its network 245 information such as network locations, costs between them at 246 configurable granularities, and endhost properties to network 247 applications. The information published by the ALTO protocol should 248 benefit both the network and the applications (consumers of the 249 information). Either the operator of the network or a third-party 250 (e.g., an information aggregator) can retrieve or derive related 251 information of the network and publish it using the ALTO Protocol. 252 When a network provides information through the ALTO Protocol, we say 253 that the network provides the ALTO Service. 255 To better understand the goal of the ALTO Protocol, we provide a 256 short, non-normative overview of the benefits of ALTO to both 257 networks and applications: 259 o A network that provides an ALTO Service can achieve better 260 utilization of its networking infrastructure. For example, by 261 using ALTO as a tool to interact with applications, a network is 262 able to provide network information to applications so that the 263 applications can better manage traffic on more expensive or 264 difficult to provision links such as long distance, transit or 265 backup links. During the interaction, the network can choose to 266 protect its sensitive and confidential network state information, 267 by abstracting real metric values into non-real numerical scores 268 or ordinal ranking. 270 o An application that uses an ALTO Service can benefit from better 271 knowledge of the network to avoid network bottlenecks. For 272 example, an overlay application can use information provided by 273 the ALTO Service to avoid selecting peers connected via high-delay 274 links (e.g., some intercontinental links). Using ALTO to 275 initialize each node with promising ("better-than-expected") 276 peers, an adaptive peer-to-peer overlay may achieve faster, better 277 convergence. 279 1.2. Design Overview 281 The ALTO Protocol specified in this document meets the ALTO 282 requirements specified in [RFC5693], and unifies multiple protocols 283 previously designed with similar intentions. See Appendix A for a 284 list of people and Appendix B for a list of proposals that have made 285 significant contributions to this effort. 287 The ALTO Protocol uses a REST-ful design [Fielding-Thesis], and 288 encodes its requests and responses using JSON [RFC4627]. These 289 designs are chosen because of their flexibility and extensibility. 290 In addition, these designs make it possible for ALTO to be deployed 291 at scale by leveraging existing HTTP [RFC2616] implementations, 292 infrastructures and deployment experience. 294 2. Terminology 296 We use the following terms defined in [RFC5693]: Application, Overlay 297 Network, Peer, Resource, Resource Identifier, Resource Provider, 298 Resource Consumer, Resource Directory, Transport Address, Host 299 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 300 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 301 Transit Traffic. 303 We also use the following additional terms: Endpoint Address, Network 304 Location, ALTO Information, ALTO Information Base, and ALTO Service. 306 2.1. Endpoint 308 An Endpoint is an application or host that is capable of 309 communicating (sending and/or receiving messages) on a network. 311 An Endpoint is typically either a Resource Provider or Resource 312 Consumer. 314 2.2. Endpoint Address 316 An Endpoint Address represents the communication address of an 317 endpoint. Common forms of Endpoint Addresses include IP address, MAC 318 address, overlay ID, and phone number. An Endpoint Address can be 319 network-attachment based (e.g., IP address) or network-attachment 320 agnostic (e.g., MAC address). 322 Each Endpoint Address has an associated Address Type, which indicates 323 both its syntax and semantics. 325 2.3. Network Location 327 Network Location is a generic term denoting a single Endpoint or a 328 group of Endpoints. For instance, it can be a single IPv4 or IPv6 329 address, an IPv4 or IPv6 prefix, or a set of prefixes. 331 2.4. ALTO Information 333 ALTO Information is a generic term referring to the network 334 information sent by an ALTO Server. 336 2.5. ALTO Information Base 338 Internal representation of the ALTO Information maintained by the 339 ALTO Server. Note that the structure of this internal representation 340 is not defined by this document. 342 2.6. ALTO Service 344 A network that provides ALTO Information through the ALTO protocol is 345 said to provide the ALTO Service. 347 3. Architecture 349 We now define the ALTO architecture and the ALTO Protocol's place in 350 the overall architecture. 352 3.1. ALTO Service and Protocol Scope 354 Each network region in the global Internet can provide its ALTO 355 Service, which conveys network information from the perspective of 356 that network region. A network region in this context can be an 357 Autonomous System (AS), an ISP, a region smaller than an AS or ISP, 358 or a set of ISPs. The specific network region that an ALTO Service 359 represents will depend on the ALTO deployment scenario and ALTO 360 service discovery mechanism. 362 Specifically, the ALTO Service of a network region defines network 363 Endpoints (and aggregations thereof) and generic costs amongst them 364 from the region's perspective. The network Endpoints may include all 365 Endpoints in the global Internet. Hence, we say that the network 366 information provided by the ALTO Service of a network region 367 represents the "my-Internet View" of the network region. 369 To better understand the ALTO Service and the role of the ALTO 370 Protocol, we show in Figure 1 the overall ALTO system architecture. 371 In this architecture, an ALTO Server prepares ALTO Information; an 372 ALTO Client uses ALTO Service Discovery to identify an appropriate 373 ALTO Server; and the ALTO Client requests available ALTO Information 374 from the ALTO Server using the ALTO Protocol. 376 The ALTO Information provided by the ALTO Server can be updated 377 dynamically based on network conditions, or can be seen as a policy 378 which is updated at a larger time-scale. 380 +-------------------------------------------------------------------+ 381 | Network Region | 382 | | 383 | +-----------+ | 384 | | Routing | | 385 | +--------------+ | Protocols | | 386 | | Provisioning | +-----------+ | 387 | | Policy | | | 388 | +--------------+\ | | 389 | \ | | 390 | \ | | 391 | +-----------+ \+---------+ +--------+ | 392 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 393 | |Network |.......| Server | ==================== | Client | | 394 | |Information| +---------+ +--------+ | 395 | +-----------+ / / | 396 | / ALTO SD Query/Response / | 397 | / / | 398 | +----------+ +----------------+ | 399 | | External | | ALTO Service | | 400 | | Interface| | Discovery (SD) | | 401 | +----------+ +----------------+ | 402 | | | 403 +-------------------------------------------------------------------+ 404 | 405 +------------------+ 406 | Third Parties | 407 | | 408 | Content Providers| 409 +------------------+ 411 Figure 1: Basic ALTO Architecture. 413 Figure 1 illustrates that the ALTO Information provided by an ALTO 414 Server may be influenced (at the service provider's discretion) by 415 other systems. In particular, the ALTO Server can aggregate 416 information from multiple systems to provide an abstract and unified 417 view that can be more useful to applications. Examples of other 418 systems include (but are not limited to) static network configuration 419 databases, dynamic network information, routing protocols, 420 provisioning policies, and interfaces to outside parties. These 421 components are shown in the figure for completeness but are outside 422 the scope of this specification. Recall that while the ALTO Protocol 423 may convey dynamic network information, it is not intended to replace 424 near-real-time congestion control protocols. 426 It may also be possible for an ALTO Server to exchange network 427 information with other ALTO Servers (either within the same 428 administrative domain or another administrative domain with the 429 consent of both parties) in order to adjust exported ALTO 430 Information. Such a protocol is also outside the scope of this 431 specification. 433 3.2. ALTO Information Reuse and Redistribution 435 ALTO Information may be useful to a large number of applications and 436 users. At the same time, distributing ALTO Information must be 437 efficient and not become a bottleneck. 439 The design of the ALTO Protocol allows integration with the existing 440 HTTP caching infrastructure to redistribute ALTO Information. If 441 caching or redistribution is used, the response message to an ALTO 442 Client may be returned from a third-party. 444 Application-dependent mechanisms, such as P2P DHTs or P2P file- 445 sharing, may be used to cache and redistribute ALTO Information. 446 This document does not define particular mechanisms for such 447 redistribution. 449 Additional protocol mechanisms (e.g., expiration times and digital 450 signatures for returned ALTO information) are left for future 451 investigation. 453 4. ALTO Information Service Framework 455 The ALTO Protocol conveys network information through services, where 456 each service defines a set of related functionalities. An ALTO 457 Client can query each service individually. All of the services 458 defined in ALTO are said to form the ALTO service framework and are 459 provided through a common transport protocol, messaging structure and 460 encoding, and transaction model. Functionalities offered in 461 different services can overlap. 463 In this document, we focus on achieving the goals of conveying (1) 464 Network Locations, which denote the locations of Endpoints at a 465 network, (2) provider-defined costs for paths between pairs of 466 Network Locations, and (3) network related properties of endhosts. 467 We achieve the goals by defining the Map Service, which provides the 468 core ALTO information to clients, and three additional services: the 469 Map Filtering Service, Endpoint Property Service, and Endpoint Cost 470 Service. Additional services can be defined in companion documents. 471 Below we give an overview of the services. Details of the services 472 will be presented in the following sections. 474 .-----------------------------------------. 475 | ALTO Information Services | 476 | .-----------. .----------. .----------. | 477 | | Map | | Endpoint | | Endpoint | | 478 | | Filtering | | Property | | Cost | | 479 | | Service | | Service | | Service | | 480 | `-----------' `----------' `----------' | 481 | .-------------------------------------. | 482 | | Map Service | | 483 | | .-------------. .--------------. | | 484 | | | Network Map | | Cost Map | | | 485 | | `-------------' `--------------' | | 486 | `-------------------------------------' | 487 `-----------------------------------------' 489 Figure 2: ALTO Service Framework. 491 4.1. ALTO Information Services 493 4.1.1. Map Service 495 The Map Service provides batch information to ALTO Clients in the 496 form of Network Map and Cost Map. The Network Map (See Section 5) 497 provides the full set of Network Location groupings defined by the 498 ALTO Server and the Endpoints contained within each grouping. The 499 Cost Map (see Section 6) provides costs between the defined 500 groupings. 502 These two maps can be thought of (and implemented as) as simple files 503 with appropriate encoding provided by the ALTO Server. 505 4.1.2. Map Filtering Service 507 Resource constrained ALTO Clients may benefit from filtering of query 508 results at the ALTO Server. This avoids that an ALTO Client first 509 spends network bandwidth and CPU cycles to collect results and then 510 performs client-side filtering. The Map Filtering Service allows 511 ALTO Clients to query an ALTO Server on Network Map and Cost Map 512 based on additional parameters. 514 4.1.3. Endpoint Property Service 516 This service allows ALTO Clients to look up properties for individual 517 Endpoints. An example property of an Endpoint is its Network 518 Location (i.e., its grouping defined by the ALTO Server). Another 519 example property is its connectivity type such as ADSL (Asymmetric 520 Digital Subscriber Line), Cable, or FTTH (Fiber To The Home). 522 4.1.4. Endpoint Cost Service 524 Some ALTO Clients may also benefit from querying for costs and 525 rankings based on Endpoints. The Endpoint Cost Service allows an 526 ALTO Server to return either numerical costs or ordinal costs 527 (rankings) directly amongst Endpoints. 529 5. Network Map 531 An ALTO Network Map defines a grouping of network endpoints. In this 532 document, we use Network Map to refer to the syntax and semantics of 533 how an ALTO Server distributes the grouping. This document does not 534 discuss the internal representation of this data structure within the 535 ALTO Server. 537 The definition of Network Map is based on the observation that in 538 reality, many endpoints are close by to one another in terms of 539 network connectivity. By treating a group of close-by endpoints 540 together as a single entity, an ALTO Server indicates aggregation of 541 these endpoints due to their proximity. This aggregation can also 542 lead to greater scalability without losing critical information when 543 conveying other network information (e.g., when defining Cost Map). 545 5.1. Provider-defined Identifier (PID) 547 One issue is that proximity varies depending on the granularity of 548 the ALTO information configured by the provider. In one deployment, 549 endpoints on the same subnet may be considered close; while in 550 another deployment, endpoints connected to the same Point of Presence 551 (PoP) may be considered close. 553 ALTO introduces provider-defined Network Location identifiers called 554 Provider-defined Identifiers (PIDs) to provide an indirect and 555 network-agnostic way to specify an aggregation of network endpoints 556 that may be treated similarly, based on network topology, type, or 557 other properties. Specifically, a PID is a US-ASCII string of type 558 PIDName (see Section 9.1) and its associated set of Endpoint 559 Addresses. As we discussed above, there can be many different ways 560 of grouping the endpoints and assigning PIDs. For example, a PID may 561 denote a subnet, a set of subnets, a metropolitan area, a PoP, an 562 autonomous system, or a set of autonomous systems. 564 A key use case of PIDs is to specify network preferences (costs) 565 between PIDs instead of individual endpoints. This allows cost 566 information to be more compactly represented and updated at a faster 567 time scale than the network aggregations themselves. For example, an 568 ISP may prefer that endpoints associated with the same PoP (Point-of- 569 Presence) in a P2P application communicate locally instead of 570 communicating with endpoints in other PoPs. The ISP may aggregate 571 endhosts within a PoP into a single PID in the Network Map. The cost 572 may be encoded to indicate that Network Locations within the same PID 573 are preferred; for example, cost(PID_i, PID_i) == c and cost(PID_i, 574 PID_j) > c for i != j. Section 6 provides further details on using 575 PIDs to represent costs in an ALTO Cost Map. 577 5.2. Endpoint Addresses 579 The endpoints aggregated into a PID are denoted by endpoint 580 addresses. There are many types of addresses, such as IP addresses, 581 MAC addresses, or overlay IDs. This specification only considers IP 582 addresses. 584 5.2.1. IP Addresses 586 When either an ALTO Client or an ALTO Server needs to determine which 587 PID in a Network Map contains a particular IP address, longest-prefix 588 matching MUST be used. 590 A Network Map MUST define a PID for each possible address in the IP 591 address space for all of the address types contained in the map. A 592 RECOMMENDED way to satisfy this property is to define a PID with the 593 shortest enclosing prefix of the addresses provided in the map. For 594 a map with full IPv4 reachability, this would mean including the 595 0.0.0.0/0 prefix in a PID; for full IPv6 reachability, this would be 596 the ::/0 prefix. 598 Each endpoint MUST map into exactly one PID. Since longest-prefix 599 matching is used to map an endpoint to a PID, this can be 600 accomplished by ensuring that no two PIDs contain an identical IP 601 prefix. 603 5.3. Example Network Map 605 Figure 3 illustrates an example Network Map. PIDs are used to 606 identify network-agnostic aggregations. 608 .-----------------------------------------------------------. 609 | ALTO Network Map | 610 | | 611 | .-----------------------------------. .---------------. | 612 | | NetLoc: PID-1 | | NetLoc: PID-2 | | 613 | | .------------------------------. | | ... | | 614 | | | 192.0.2.0/24 | | `---------------` | 615 | | | .--------------------------. | | | 616 | | | | Endpoint: 192.0.2.34 | | | .---------------. | 617 | | | `--------------------------` | | | NetLoc: PID-3 | | 618 | | `------------------------------` | | ... | | 619 | | .------------------------------. | `---------------` | 620 | | | 198.51.100.0/25 | | | 621 | | | .--------------------------. | | .---------------. | 622 | | | | Endpoint: 198.51.100.100 | | | | NetLoc: PID-4 | | 623 | | | `--------------------------` | | | ... | | 624 | | `------------------------------` | `---------------` | 625 | `-----------------------------------` | 626 | | 627 `-----------------------------------------------------------` 629 Figure 3: Example Network Map. 631 6. Cost Map 633 An ALTO Server indicates preferences amongst network locations in the 634 form of Path Costs. Path Costs are generic costs and can be 635 internally computed by a network provider according to its own needs. 637 An ALTO Cost Map defines Path Costs pairwise amongst sets of source 638 and destination Network Locations defined by PIDs. Each Path Cost is 639 the end-to-end cost when a unit of traffic goes from the source to 640 the destination. 642 As cost is directional from the source to the destination, an 643 application, when using ALTO Information, may independently determine 644 how the Resource Consumer and Resource Provider are designated as the 645 source or destination in an ALTO query, and hence how to utilize the 646 Path Cost provided by ALTO Information. For example, if the cost is 647 expected to be correlated with throughput, a typical application 648 concerned with bulk data retrieval may use the Resource Provider as 649 the source, and Resource Consumer as the destination. 651 One advantage of separating ALTO information into a Network Map and a 652 Cost Map is that the two components can be updated at different time 653 scales. For example, Network Maps may be stable for a longer time 654 while Cost Maps may be updated to reflect dynamic network conditions. 656 As used in this document, the Cost Map refers to the syntax and 657 semantics of the information distributed by the ALTO Server. This 658 document does not discuss the internal representation of this data 659 structure within the ALTO Server. 661 6.1. Cost Types 663 Path Costs have attributes: 665 o Metric: identifies what the costs represent; 667 o Mode: identifies how the costs should be interpreted. 669 The combination of a metric and a mode defines a Cost Type. Certain 670 queries for Cost Maps allow the ALTO Client to indicate the desired 671 Cost Type. 673 6.1.1. Cost Metric 675 The Metric attribute indicates what the cost represents. For 676 example, an ALTO Server could define costs representing air-miles, 677 hop-counts, or generic routing costs. 679 Cost metrics are indicated in protocol messages as strings. 681 6.1.1.1. Cost Metric: routingcost 683 An ALTO Server MUST offer the 'routingcost' Cost Metric. 685 This Cost Metric conveys a generic measure for the cost of routing 686 traffic from a source to a destination. A lower value indicates a 687 higher preference for traffic to be sent from a source to a 688 destination. 690 Note that an ISP may internally compute routing cost using any method 691 it chooses (e.g., air-miles or hop-count) as long as it conforms to 692 these semantics. 694 6.1.2. Cost Mode 696 The Mode attribute indicates how costs should be interpreted. 697 Specifically, the Mode attribute indicates whether returned costs 698 should be interpreted as numerical values or ordinal rankings. 700 It is important to communicate such information to ALTO Clients, as 701 certain operations may not be valid on certain costs returned by an 702 ALTO Server. For example, it is possible for an ALTO Server to 703 return a set of IP addresses with costs indicating a ranking of the 704 IP addresses. Arithmetic operations that would make sense for 705 numerical values, do not make sense for ordinal rankings. ALTO 706 Clients may handle such costs differently. 708 Cost Modes are indicated in protocol messages as strings. 710 An ALTO Server MUST support at least one of 'numerical' and 'ordinal' 711 modes. An ALTO Client SHOULD be cognizant of operations when a 712 desired Cost Mode is not supported. For example, an ALTO Client 713 desiring numerical costs may adjust its behaviors if only the ordinal 714 Cost Mode is available. Alternatively, an ALTO Client desiring 715 ordinal costs may construct ordinal costs from retrieved numerical 716 values, if only the numerical Cost Mode is available. 718 6.1.2.1. Cost Mode: numerical 720 This Cost Mode is indicated by the string 'numerical'. This mode 721 indicates that it is safe to perform numerical operations (e.g. 722 normalization or computing ratios for weighted load-balancing) on the 723 returned costs. The values are floating-point numbers. 725 6.1.2.2. Cost Mode: ordinal 727 This Cost Mode is indicated by the string 'ordinal'. This mode 728 indicates that the costs values in a Cost Map are a ranking (relative 729 to all other values in a Cost Map), with a lower value indicating a 730 higher preference. The values are non-negative integers. Ordinal 731 cost values in a Cost Map need not be unique nor contiguous. In 732 particular, it is possible that two entries in a map have an 733 identical rank (ordinal cost value). This document does not specify 734 any behavior by an ALTO Client in this case; an ALTO Client may 735 decide to break ties by random selection, other application 736 knowledge, or some other means. 738 It is important to note that the values in the Cost Map provided with 739 the ordinal Cost Mode are not necessarily the actual costs known to 740 the ALTO Server. 742 6.2. Cost Map Structure 744 A query for a Cost Map either explicitly or implicitly includes a 745 list of Source Network Locations and a list of Destination Network 746 Locations. (Recall that a Network Location can be an endpoint 747 address or a PID.) 748 Specifically, assume that a query has a list of multiple Source 749 Network Locations, say [Src_1, Src_2, ..., Src_m], and a list of 750 multiple Destination Network Locations, say [Dst_1, Dst_2, ..., 751 Dst_n]. 753 The ALTO Server will return the Path Cost for each of the m*n 754 communicating pairs (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., 755 Src_m -> Dst_1, ..., Src_m -> Dst_n). If the ALTO Server does not 756 define a Path Cost for a particular pair, it may be omitted. We 757 refer to this structure as a Cost Map. 759 If the Cost Mode is 'ordinal', the Path Cost of each communicating 760 pair is relative to the m*n entries. 762 6.3. Network Map and Cost Map Dependency 764 If a Cost Map contains PIDs in the list of Source Network Locations 765 or the list of Destination Network Locations, the Path Costs are 766 generated based on a particular Network Map (which defines the PIDs). 767 Version Tags are introduced to ensure that ALTO Clients are able to 768 use consistent information even though the information is provided in 769 two maps. 771 A Version Tag is a tuple of (1) an ID for the resource (e.g., a 772 Network Map), and (2) a tag (an opaque string) associated with the 773 version of that resource. A Network Map distributed by an ALTO 774 Server includes its Version Tag. A Cost Map referring to PIDs also 775 includes Version Tag for the Network Map on which it is based. 777 Two Network Maps are the same if they have the same Version Tag. 778 Whenever the content of the Network Map maintained by an ALTO Server 779 changes, tag MUST also be changed. Possibilities of setting the tag 780 component include the last-modified timestamp for the Network Map, or 781 a hash of its contents, where the collision probability is considered 782 zero in practical deployment scenarios. 784 6.4. Cost Map Update 786 An ALTO Server can update a Cost Map at any time. Hence, the same 787 Cost Map retrieved from the same ALTO Server but from different 788 requests can be inconsistent. 790 7. Endpoint Properties 792 An endpoint property defines a network-aware property of an endpoint. 794 7.1. Endpoint Property Type 796 For each endpoint and an endpoint property type, there can be a value 797 for the property. The type of an Endpoint property is indicated in 798 protocol messages as a string. The value depends on the specific 799 property. For example, for a property such as whether an endpoint is 800 metered, the value is a true or false value. 802 7.1.1. Endpoint Property Type: pid 804 An ALTO Server MUST define the 'pid' Endpoint Property Type, which 805 provides the PID of an endpoint. Since the PID of an endpoint 806 depends on the Network Map, the Version Tag of the full (unfiltered) 807 Network Map used to return the pid property MUST be included. 809 8. Protocol Specification: General Processing 811 This section first specifies general client and server processing. 812 The details of specific services will be covered in the following 813 sections. 815 8.1. Overall Design 817 The ALTO Protocol uses a REST-ful design. There are two primary 818 components to this design: 820 o Information Resources: Each service provides network information 821 as a set of information resources, which are distinguished by 822 their media types [RFC2046]. An ALTO Client may construct an HTTP 823 request for a particular information resource (including any 824 parameters, if necessary), and an ALTO Server returns the 825 requested information resource in an HTTP response. 827 o Information Resource Directory (IRD): An ALTO Server provides to 828 ALTO Clients a list of available information resources and the URI 829 at which each is provided. This document refers to this list as 830 the Information Resource Directory. ALTO Clients consult the 831 directory to determine the services provided by an ALTO Server. 833 8.2. Notation 835 This document uses 'JSONString', 'JSONNumber', 'JSONBool' to indicate 836 the JSON string, number, and boolean types, respectively. The type 837 'JSONValue' indicates a JSON value, as specified in Section 2.1 of 838 [RFC4627]. 840 We use an adaptation of the C-style struct notation to define the 841 members (names/values) of JSON objects. An optional member is 842 enclosed by [ ], and an array is indicated by two numbers in angle 843 brackets, , where m indicates the minimal number of values, and 844 n is the maximum. When we write * for n, it means no upper bound. 845 In the definitions, the JSON names of the members are case sensitive. 847 For example, the definition below defines a new type Type4, with 848 three members named "name1", "name2", and "name3" respectively. The 849 member named "name3" is optional, and the member named "name2" is an 850 array of at least one value. 852 object { 853 Type1 name1; 854 Type2 name2<1..*>; 855 [Type3 name3;] 856 } Type4; 858 We also define dictionary maps (or maps for short) from strings to 859 JSON values. For example, the definition below defines a Type3 860 object as a map. Type1 must be defined as string, and Type2 can be 861 any type. 863 object-map { 864 Type1 -> Type2; 865 } Type3; 867 Note that despite the notation, no standard, machine-readable 868 interface definition or schema is provided in this document. 869 Extension documents may document these as necessary. 871 8.3. Basic Operation 873 The ALTO Protocol employs standard HTTP [RFC2616]. It is used for 874 discovering available Information Resources at an ALTO Server and 875 retrieving Information Resources. ALTO Clients and ALTO Servers use 876 HTTP requests and responses carrying ALTO-specific content with 877 encoding as specified in this document, and MUST be compliant with 878 [RFC2616]. 880 8.3.1. Client Discovering Information Resources 882 To discover available Information Resources, an ALTO Client requests 883 the Information Resource Directory, which an ALTO Server provides at 884 the URI found by the ALTO Discovery protocol. 886 Informally, an Information Resource Directory enumerates URIs at 887 which an ALTO Server offers Information Resources. Each entry in the 888 directory indicates a URI at which an ALTO Server accepts requests, 889 and returns either the requested Information Resource or an 890 Information Resource Directory that references additional Information 891 Resources. See Section 8.5 for a detailed specification. 893 8.3.2. Client Requesting Information Resources 895 Through the retrieved Information Resource Directories, an ALTO 896 Client can determine whether an ALTO Server supports the desired 897 Information Resource, and if it is supported, the URI at which it is 898 available. 900 Where possible, the ALTO Protocol uses the HTTP GET method to request 901 resources. However, some ALTO services provide Information Resources 902 that are the function of one or more input parameters. Input 903 parameters are encoded in the HTTP request's entity body, and the 904 ALTO Client MUST use the HTTP POST method to send the parameters. 906 When requesting an ALTO Information Resource that requires input 907 parameters specified in a HTTP POST request, an ALTO Client MUST set 908 the Content-Type HTTP header to the media type corresponding to the 909 format of the supplied input parameters. 911 8.3.3. Server Responding to IR Request 913 Upon receiving a request for an Information Resource that the ALTO 914 Server can provide, the ALTO Server MUST return the requested 915 Information Resource. In other cases, to be more informative 916 ([I-D.ietf-httpbis-p2-semantics]), the ALTO Server MAY provide the 917 ALTO Client with an Information Resource Directory indicating how to 918 reach the desired information resource, or return an ALTO error 919 object; see Section 8.7 for more details on ALTO error handling. 921 It is possible for an ALTO Server to leverage caching HTTP 922 intermediaries to respond to both GET and POST requests by including 923 explicit freshness information (see Section 14 of [RFC2616]). 924 Caching of POST requests is not widely implemented by HTTP 925 intermediaries, however an alternative approach is for an ALTO 926 Server, in response to POST requests, to return an HTTP 303 status 927 code ("See Other") indicating to the ALTO Client that the resulting 928 Information Resource is available via a GET request to an alternate 929 URL. HTTP intermediaries that do not support caching of POST 930 requests could then cache the response to the GET request from the 931 ALTO Client following the alternate URL in the 303 response if the 932 response to the subsequent GET request contains explicit freshness 933 information. 935 The ALTO Server MUST indicate the type of its response using a media 936 type (i.e., the Content-Type HTTP header of the response). 938 8.3.4. Client Handling Server Response 940 8.3.4.1. Using Information Resources 942 This specification does not indicate any required actions taken by 943 ALTO Clients upon successfully receiving an Information Resource from 944 an ALTO Server. Although ALTO Clients are suggested to interpret the 945 received ALTO Information and adapt application behavior, ALTO 946 Clients are not required to do so. 948 8.3.4.2. Handling Server Response and IRD 950 After receiving an Information Resource Directory, the Client can 951 consult it to determine if any of the offered URIs contain the 952 desired Information Resource. However, an ALTO Client MUST NOT 953 assume that the media type returned by the ALTO Server for a request 954 to a URI is the media type advertised in the IRD or specified in its 955 request (i.e., the client must still check the Content-Type header). 956 The expectation is that the media type returned should normally be 957 the media type advertised and requested, but in some cases it may 958 legitimately not be so. 960 In particular, it is possible for an ALTO Client to receive an 961 Information Resource Directory from an ALTO Server as a response to 962 its request for a specific Information Resource. In this case, the 963 ALTO Client may ignore the response or still parse the response. To 964 indicate that an ALTO Client will always check if a response is an 965 Information Resource Directory, the ALTO Client can indicate in the 966 "Accept" header of a HTTP request that it can accept Information 967 Resource Directory; see Section 8.5 for the media type. 969 8.3.4.3. Handling Error Conditions 971 If an ALTO Client does not successfully receive a desired Information 972 Resource from a particular ALTO Server (i.e., server response 973 indicates error or there is no response), the Client can either 974 choose another server (if one is available) or fall back to a default 975 behavior (e.g., perform peer selection without the use of ALTO 976 information, when used in a peer-to-peer system). 978 8.3.5. Authentication and Encryption 980 When server and/or client authentication, encryption, and/or 981 integrity protection are required, an ALTO Server MUST support SSL/ 982 TLS [RFC5246] as a mechanism. For cases such as a public ALTO 983 service or deployment scenarios where there is an implicit trust 984 relationship between the client and the server and the network 985 infrastructure connecting them is secure, SSL/TLS may not be 986 necessary. See [RFC6125] for considerations regarding verification 987 of server identity. 989 8.3.6. Information Refresh 991 An ALTO Client MAY determine the frequency at which ALTO Information 992 is refreshed based information made available via HTTP. 994 8.3.7. HTTP Cookies 996 If cookies are included in an HTTP request received by an ALTO 997 Server, they MUST be ignored. 999 8.3.8. Parsing 1001 This document only details object members used by this specification. 1002 Extensions may include additional members within JSON objects defined 1003 in this document. ALTO implementations MUST ignore unknown fields 1004 when processing ALTO messages. 1006 8.4. Information Resource: Attributes 1008 An Information Resource encodes the ALTO Information desired by an 1009 ALTO Client. This document specifies multiple Information Resources 1010 that can be provided by an ALTO Server. 1012 Each Information Resource has certain attributes associated with it, 1013 including its data format, its capabilities, and its accepted input 1014 parameters. These attributes are published by an ALTO Server in its 1015 Information Resource Directory. 1017 8.4.1. Resource ID 1019 Each Information Resource MUST be given a unique ID. The ID MUST be 1020 unique amongst all resources offered by the ALTO Server, including 1021 those defined in Information Resource Directories linked from this 1022 ALTO Server. The ID SHOULD remain stable even when the data provided 1023 by that resource changes. IDs SHOULD NOT be re-used for different 1024 resources over time. For example, even though the number of PIDs in 1025 a Network Map may be adjusted, its Resource ID should remain the 1026 same. Similarly, if the entries in a Cost Map are updated, its 1027 Resource ID should remain the same. 1029 8.4.2. Media Type 1031 ALTO uses Media Type [RFC2046] to uniquely indicate the data format 1032 used to encode the content to be transmitted between an ALTO Server 1033 and an ALTO Client in the HTTP entity body. 1035 8.4.3. Capabilities 1037 The Capabilities associated with an Information Resource announced by 1038 an ALTO Server indicates specific capabilities that the server can 1039 provide. For example, if an ALTO Server allows an ALTO Client to 1040 specify cost constraints when the Client requests a Cost Map 1041 Information Resource, the Server advertises the cost-constraints 1042 capability for its Cost Map Information Resource. 1044 8.4.4. Accepts Input Parameters 1046 An ALTO Server may allow an ALTO Client to supply input parameters 1047 when requesting certain Information Resources. The associated 1048 accepts attribute of an Information Resource is a Media Type, which 1049 indicates how the Client specifies the input parameters as contained 1050 in the entity body of the HTTP POST request. 1052 8.5. Information Resource Directory 1054 An ALTO Server uses Information Resource Directory to publish 1055 available Information Resources and their aforementioned attributes. 1056 Since resource selection happens after consumption of the Information 1057 Resource Directory, the format of the Information Resource Directory 1058 is designed to be simple with the intention of future ALTO Protocol 1059 versions maintaining backwards compatibility. Future extensions or 1060 versions of the ALTO Protocol SHOULD be accomplished by extending 1061 existing media types or adding new media types, but retaining the 1062 same format for the Information Resource Directory. 1064 An ALTO Server MUST make an Information Resource Directory available 1065 via the HTTP GET method to a URI discoverable by an ALTO Client. 1066 Discovery of this URI is out of scope of this document, but could be 1067 accomplished by manual configuration or by returning the URI of an 1068 Information Resource Directory from the ALTO Discovery Protocol 1069 [I-D.ietf-alto-server-discovery]. For recommendations on how the URI 1070 may look like, see [I-D.ietf-alto-server-discovery]. 1072 8.5.1. Media Type 1074 The media type to indicate an information directory is "application/ 1075 alto-directory+json". 1077 8.5.2. Encoding 1079 An Information Resource Directory is a JSON object of type 1080 InfoResourceDirectory: 1082 object { 1083 IRDMeta meta; 1084 IRDResourceEntry resources<1..*>; 1085 } InfoResourceDirectory; 1087 object-map { 1088 JSONString -> JSONValue; 1089 } IRDMeta; 1091 object { 1092 ResourceID id; 1093 JSONString uri; 1094 JSONString media-type; 1095 [JSONString accepts;] 1096 [Capabilities capabilities;] 1097 [ResourceID uses<0..*>;] 1098 } IRDResourceEntry; 1100 object { 1101 ... 1102 } Capabilities; 1104 where the "meta" member provides definitions related with the IRD 1105 itself, or can be used when defining multiple individual Information 1106 resources; 1108 the "resources" array indicates a list of Information Resources 1109 provided by an ALTO Server. Note that the list of available 1110 resources is enclosed in a JSON object for extensibility; future 1111 protocol versions may specify additional members in the 1112 InfoResourceDirectory object. 1114 Each entry specifies: 1116 uri A URI at which the ALTO Server provides one or more Information 1117 Resources, or an Information Resource Directory indicating 1118 additional Information Resources. URIs can be relative and MUST 1119 be resolved according to Section 5 of [RFC3986]. 1121 media-type The media type of Information Resource (see 1122 Section 8.4.2) available via GET or POST requests to the 1123 corresponding URI or "application/alto-directory+json", which 1124 indicates that the response for a request to the URI will be an 1125 Information Resource Directory for URIs discoverable via the URI. 1127 accepts The media type of input parameters (see Section 8.4.4) 1128 accepted by POST requests to the corresponding URI. If this 1129 member is not present, it MUST be assumed to be empty. 1131 capabilities A JSON Object enumerating capabilities of an ALTO 1132 Server in providing the Information Resource at the corresponding 1133 URI and Information Resources discoverable via the URI. If this 1134 member is not present, it MUST be assumed to be an empty object. 1135 If a capability for one of the offered Information Resources is 1136 not explicitly listed here, an ALTO Client may either issue an 1137 OPTIONS HTTP request to the corresponding URI to determine if the 1138 capability is supported, or assume its default value documented in 1139 this specification or an extension document describing the 1140 capability. 1142 uses A list of Resource IDs corresponding to resources on which this 1143 resource directly depends. An ALTO Server SHOULD include in this 1144 list any resource that the ALTO Client would need to retrieve in 1145 order to interpret the contents of this resource. For example, a 1146 Cost Map resource should include in this list the Network Map on 1147 which it depends. Likewise, an Endpoint Property resource 1148 providing the 'pid' property should indicate the Network Map on 1149 which it is based. ALTO Clients may wish to consult this list in 1150 order to pre-fetch necessary resources. 1152 If an entry has an empty list for "accepts", then the corresponding 1153 URI MUST support GET requests. If an entry has a non-empty 1154 "accepts", then the corresponding URI MUST support POST requests. If 1155 an ALTO Server wishes to support both GET and POST on a single URI, 1156 it MUST specify two entries in the Information Resource Directory. 1158 8.5.3. Example 1160 The following is an example Information Resource Directory returned 1161 by an ALTO Server. 1163 GET /directory HTTP/1.1 1164 Host: alto.example.com 1165 Accept: application/alto-directory+json,application/alto-error+json 1166 HTTP/1.1 200 OK 1167 Content-Length: TBA 1168 Content-Type: application/alto-directory+json 1170 { 1171 "meta" : { 1172 "cost-types": { 1173 "num-routing": {"cost-mode" : "numerical", 1174 "cost-metric": "routingcost", 1175 "description": "My default"}, 1176 "num-hop": {"cost-mode" : "numerical", 1177 "cost-metric": "hopcount"} 1178 "ord-routing": {"cost-mode" : "ordinal", 1179 "cost-metric": "routingcost"}, 1180 "ord-hop": {"cost-mode" : "ordinal", 1181 "cost-metric": "hopcount"} 1182 } 1183 }, 1184 "resources" : [ 1185 { 1186 "id" : "default-network-map", 1187 "uri" : "http://alto.example.com/networkmap", 1188 "media-type" : "application/alto-networkmap+json" 1189 }, { 1190 "id" : "numerical-routing-cost-map", 1191 "uri" : "http://alto.example.com/costmap/num/routingcost", 1192 "media-type" : "application/alto-costmap+json", 1193 "capabilities" : { 1194 "cost-type-names" : [ "num-routing" ] 1195 }, 1196 "uses": [ "default-network-map" ] 1197 }, { 1198 "id" : "numerical-hopcount-cost-map", 1199 "uri" : "http://alto.example.com/costmap/num/hopcount", 1200 "media-type" : "application/alto-costmap+json", 1201 "capabilities" : { 1202 "cost-type-names" : [ "num-hop" ] 1203 }, 1204 "uses": [ "default-network-map" ] 1205 }, { 1206 "id" : "custom-maps-resources", 1207 "uri" : "http://custom.alto.example.com/maps", 1208 "media-type" : "application/alto-directory+json", 1209 }, { 1210 "id" : "endpoint-property", 1211 "uri" : "http://alto.example.com/endpointprop/lookup", 1212 "media-type" : "application/alto-endpointprop+json", 1213 "accepts" : "application/alto-endpointpropparams+json", 1214 "capabilities" : { 1215 "prop-types" : [ "pid" ] 1216 }, 1217 "uses": [ "default-network-map" ] 1218 }, { 1219 "id" : "endpoint-cost", 1220 "uri" : "http://alto.example.com/endpointcost/lookup", 1221 "media-type" : "application/alto-endpointcost+json", 1222 "accepts" : "application/alto-endpointcostparams+json", 1223 "capabilities" : { 1224 "cost-constraints" : true, 1225 "cost-type-names" : [ "num-routing", "num-hop", 1226 "ord-routing", "ord-hop"] 1227 } 1228 } 1229 ] 1230 } 1232 Specifically, the "meta" member of the example IRD defines a field 1233 named "cost-types", which defines the names of cost types for this 1234 IRD. For example, "num-routing" in the example is the name that 1235 refers to a Cost Type with Cost Mode being "numerical" and Cost 1236 Metric being "routingcost". The value of "cost-types" is of type 1237 IRDMetaCostTypes defined below; see Section 9.7 for the definition of 1238 CostType. 1240 The names defined in "cost-types" can be used in one or more 1241 "resources" entries. For example, the second entry of "resources" 1242 defines a Cost Map. The "cost-type-names" of its "capabilities" 1243 specifies that this resource supports a Cost Type named as "num- 1244 routing". The ALTO Client looks up the name "num-routing" in "cost- 1245 types" of the IRD to obtain the Cost Type named as "num-routing". 1246 The last entry of "resources" uses all four names defined in "cost- 1247 types". 1249 object-map { 1250 JSONString -> CostType; 1251 } IRDMetaCostTypes; 1253 The "resources" array of the example IRD defines six Information 1254 Resources. For example, the last entry is to provide the Endpoint 1255 Cost Service, which is indicated by the media-type "application/ 1256 alto-endpointcost+json". An ALTO Client should use uri 1257 "http://alto.example.com/endpointcost/lookup" to access the service. 1258 The ALTO Client should format its request body to be the 1259 "application/alto-endpointcostparams+json" media type, as specified 1260 by the "accepts" attribute of the Information Resource. The "cost- 1261 type-names" member of the "capabilities" attribute of the Information 1262 Resource includes 4 defined cost types from the "meta" member of the 1263 IRD. Hence, one can verify that the Endpoint Cost Information 1264 Resource supports both Cost Metrics 'routingcost' and 'hopcount', 1265 each available for both 'numerical' and 'ordinal'. When requesting 1266 the Information Resource, an ALTO Client can specify cost 1267 constraints, as indicated by the "cost-constraints" member of the 1268 "capabilities" attribute. 1270 8.5.4. Delegation and Multiple Choices 1272 ALTO Information Resource Directory provides flexibility to an ALTO 1273 Server (e.g., delegation) so that it MAY indicate multiple 1274 Information Resources using one URI endpoint. In the example above, 1275 the ALTO Server provides additional Network and Cost Maps via a 1276 separate subdomain, "custom.alto.example.com". In particular, the 1277 maps available via this subdomain are Filtered Network and Cost Maps 1278 as well as pre-generated maps for the "hopcount" and "routingcost" 1279 Cost Metrics in the "ordinal" Cost Mode. 1281 Consider the preceding example. The fourth entry of "resources" 1282 provides additional Network and Cost Maps via a separate subdomain: 1283 "custom.alto.example.com". This delegation is indicated by the 1284 media-type "application/alto-directory+json". The ALTO Client can 1285 discover the maps available at "custom.alto.example.com" by 1286 successfully performing a request to 1287 "http://custom.alto.example.com/maps": 1289 GET /maps HTTP/1.1 1290 Host: custom.alto.example.com 1291 Accept: application/alto-directory+json,application/alto-error+json 1293 HTTP/1.1 200 OK 1294 Content-Length: TBA 1295 Content-Type: application/alto-directory+json 1297 { 1298 "meta" : { 1299 "cost-types": { 1300 "num-routing": {"cost-mode" : "numerical", 1301 "cost-metric": "routingcost", 1302 "description": "My default"}, 1304 "num-hop": {"cost-mode" : "numerical", 1305 "cost-metric": "hopcount"} 1306 "ord-routing": {"cost-mode" : "ordinal", 1307 "cost-metric": "routingcost"}, 1308 "ord-hop": {"cost-mode" : "ordinal", 1309 "cost-metric": "hopcount"} 1310 } 1311 }, 1312 "resources" : [ 1313 { 1314 "id" : "filtered-network-map", 1315 "uri" : "http://custom.alto.example.com/networkmap/filtered", 1316 "media-type" : "application/alto-networkmap+json", 1317 "accepts" : "application/alto-networkmapfilter+json" 1318 }, { 1319 "id" : "filtered-cost-map", 1320 "uri" : "http://custom.alto.example.com/costmap/filtered", 1321 "media-type" : "application/alto-costmap+json", 1322 "accepts" : "application/alto-costmapfilter+json", 1323 "capabilities" : { 1324 "cost-constraints" : true, 1325 "cost-type-names" : [ "num-routing", "num-hop", 1326 "ord-routing", "ord-hop" ] 1327 }, 1328 "uses": [ "default-network-map" ] 1329 }, { 1330 "id" : "ordinal-routing-cost-map", 1331 "uri" : "http://custom.alto.example.com/ord/routingcost", 1332 "media-type" : [ "application/alto-costmap+json", 1333 "capabilities" : { 1334 "cost-type-names" : [ "ord-routing" ] 1335 }, 1336 "uses": [ "default-network-map" ] 1337 }, { 1338 "id" : "ordinal-hopcount-cost-map", 1339 "uri" : "http://custom.alto.example.com/ord/hopcount", 1340 "media-type" : "application/alto-costmap+json", 1341 "capabilities" : { 1342 "cost-type-names" : [ "ord-hop" ], 1343 }, 1344 "uses": [ "default-network-map" ] 1345 } 1346 ] 1347 } 1349 8.5.5. Usage Considerations 1351 8.5.5.1. ALTO Client 1353 This document specifies no requirements or constraints on ALTO 1354 Clients with regards to how they process an Information Resource 1355 Directory to identify the URI corresponding to a desired Information 1356 Resource. However, some advice is provided for implementors. 1358 It is possible that multiple entries in the directory match a desired 1359 Information Resource. For instance, in the example in Section 8.5.3, 1360 a full Cost Map with "numerical" Cost Mode and "routingcost" Cost 1361 Metric could be retrieved via a GET request to 1362 "http://alto.example.com/costmap/num/routingcost", or via a POST 1363 request to "http://custom.alto.example.com/costmap/filtered". 1365 In general, it is preferred for ALTO Clients to use GET requests 1366 where appropriate, since it is more likely for responses to be 1367 cachable. However, an ALTO Client may need to use POST, for example, 1368 to get ALTO costs or properties that are for a restricted set of PIDs 1369 or Endpoints, or to update cached information previously acquired via 1370 GET requests." 1372 8.5.5.2. ALTO Server 1374 This document indicates that an ALTO Server may or may not provide 1375 the Information Resources specified in the Map Filtering Service. If 1376 these resources are not provided, it is indicated to an ALTO Client 1377 by the absence of a Network Map or Cost Map with any media types 1378 listed under "accepts". 1380 8.6. Information Resource: Content Encoding 1382 Though each Information Resource may have a distinct syntax and hence 1383 its unique Media Type, they are designed to have a common structure 1384 containing generic ALTO-layer metadata about the resource, as well as 1385 data itself. 1387 Specifically, each Information Resource has a single top-level JSON 1388 object of type InfoResourceEntity: 1390 object { 1391 InfoResourceMeta meta; 1392 InfoResourceDataType data; 1393 } InfoResourceEntity; 1394 with members: 1396 meta meta-information pertaining to the Information Resource; 1398 data the data contained in the Information Resource. 1400 8.6.1. Meta Information 1402 Meta information is encoded as a JSON object. This document does not 1403 specify any members, but it is defined here as a standard container 1404 for extensibility. Specifically, InfoResourceMetaData is defined as: 1406 object-map { 1407 JSONString -> JSONValue 1408 } InfoResourceMetaData; 1410 8.6.2. Data Information 1412 The "data" member of the InfoResourceEntity encodes the resource- 1413 specific data. In this document, we define four specific 1414 InfoResourceDataType: InfoResourceNetworkMap, InfoResourceCostMap, 1415 InfoResourceEndpointProperty, and InfoResourceEndpointCostMap, whose 1416 structures will be detailed below. 1418 8.6.3. Example 1420 The following is an example of the encoding for an Information 1421 Resource: 1423 HTTP/1.1 200 OK 1424 Content-Length: 40 1425 Content-Type: application/alto-costmap+json 1427 { 1428 "meta" : {}, 1429 "data" : { 1430 ... 1431 } 1432 } 1434 8.7. Protocol Errors 1436 If there is an error processing a request, an ALTO Server SHOULD 1437 return additional ALTO-layer information, if it is available, in the 1438 form of an ALTO Error Resource encoded in the HTTP response' entity 1439 body. If no ALTO-layer information is available, an ALTO Server may 1440 omit an ALTO Error resource from the response. 1442 With or without additional ALTO-layer error information, an ALTO 1443 Server MUST set an appropriate HTTP status code. It is important to 1444 note that the HTTP Status Code and ALTO Error Resource have distinct 1445 roles. An ALTO Error Resource provides detailed information about 1446 why a particular request for an ALTO Resource was not successful. 1447 The HTTP status code indicates to HTTP processing elements (e.g., 1448 intermediaries and clients) how the response should be treated. 1450 8.7.1. Media Type 1452 The media type for an ALTO Error Resource is "application/ 1453 alto-error+json". 1455 8.7.2. Resource Format and Error Codes 1457 An ALTO Error Resource has the format: 1459 object { 1460 JSONString code; 1461 } ErrorResourceEntity; 1463 where: 1465 code An ALTO Error Code defined in Table 1. Note that the ALTO 1466 Error Codes defined in Table 1 are limited to support the error 1467 conditions needed for purposes of this document. Additional 1468 status codes may be defined in companion or extension documents. 1470 +-------------------------+-----------------------------------------+ 1471 | ALTO Error Code | Description | 1472 +-------------------------+-----------------------------------------+ 1473 | E_SYNTAX | Parsing error in request (including | 1474 | | identifiers) | 1475 | E_JSON_FIELD_MISSING | Required field missing | 1476 | E_JSON_VALUE_TYPE | JSON Value of unexpected type | 1477 | E_INVALID_COST_MODE | Invalid cost mode | 1478 | E_INVALID_COST_METRIC | Invalid cost metric | 1479 | E_INVALID_PROPERTY_TYPE | Invalid property type | 1480 +-------------------------+-----------------------------------------+ 1482 Table 1: Defined ALTO Error Codes. 1484 If multiple errors are present in a single request (e.g., a request 1485 uses a JSONString when a JSONNumber is expected and a required field 1486 is missing), then the ALTO Server MUST return exactly one of the 1487 detected errors. However, the reported error is implementation 1488 defined, since specifying a particular order for message processing 1489 encroaches needlessly on implementation technique. 1491 8.7.3. Overload Conditions and Server Unavailability 1493 If an ALTO Server detects that it cannot handle a request from an 1494 ALTO Client due to excessive load, technical problems, or system 1495 maintenance, it SHOULD do one of the following: 1497 o Return an HTTP 503 ("Service Unavailable") status code to the ALTO 1498 Client. As indicated by [RFC2616], a the Retry-After HTTP header 1499 may be used to indicate when the ALTO Client should retry the 1500 request. 1502 o Return an HTTP 307 ("Temporary Redirect") status code indicating 1503 an alternate ALTO Server that may be able to satisfy the request. 1505 The ALTO Server MAY also terminate the connection with the ALTO 1506 Client. 1508 The particular policy applied by an ALTO Server to determine that it 1509 cannot service a request is outside of the scope of this document. 1511 9. Protocol Specification: Basic ALTO Data Types 1513 This section details the format for particular data values used in 1514 the ALTO Protocol. 1516 9.1. PID Name 1518 A PID Name is encoded as a US-ASCII string. The string MUST be no 1519 more than 64 characters, and MUST NOT contain characters other than 1520 alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, and 0x61- 1521 0x7A), the hyphen ('-', code point 0x2D), the colon (':', code point 1522 0x3A), the at ('@', code point 0x40), or the '.' separator (code 1523 point 0x2E). The '.' separator is reserved for future use and MUST 1524 NOT be used unless specifically indicated by a companion or extension 1525 document. 1527 The type 'PIDName' is used in this document to indicate a string of 1528 this format. 1530 9.2. Resource ID 1532 A Resource ID uniquely identifies an particular resource (e.g., a 1533 Network Map) within an ALTO Server (see Section 8.5). 1535 A Resource ID is encoded as a US-ASCII string. The string MUST be no 1536 more than 64 characters, and MUST NOT contain any ASCII character 1537 below 0x21 or above 0x7E. 1539 The type 'ResourceID' is used in this document to indicate a string 1540 of this format. 1542 9.3. Version Tag 1544 A Version Tag is defined as: 1546 object { 1547 ResourceID resource-id; 1548 JSONString tag; 1549 } VersionTag; 1551 The 'resource-id' attribute is an ID corresponding a resource (e.g., 1552 a Network Map) in an Information Resource Directory to which the 1553 Version Tag refers, and 'tag' encoded as a case-sensitive US-ASCII 1554 string. The 'tag' string MUST be no more than 64 characters, and 1555 MUST NOT contain any ASCII character below 0x21 or above 0x7E. 1557 Two values of the VersionTag are equal if and only if both the the 1558 'resource-id' attributes are byte-for-byte equal and the 'tag' 1559 attributes are byte-for-byte equal. 1561 9.4. Endpoints 1563 This section defines formats used to encode addresses for Endpoints. 1564 In a case that multiple textual representations encode the same 1565 Endpoint address or prefix (within the guidelines outlined in this 1566 document), the ALTO Protocol does not require ALTO Clients or ALTO 1567 Servers to use a particular textual representation, nor does it 1568 require that ALTO Servers reply to requests using the same textual 1569 representation used by requesting ALTO Clients. ALTO Clients must be 1570 cognizant of this. 1572 9.4.1. Address Type 1574 Address Types are encoded as US-ASCII strings consisting of only 1575 alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, and 0x61- 1576 0x7A). This document defines the address type 'ipv4' to refer to 1577 IPv4 addresses, and 'ipv6' to refer to IPv6 addresses. All Address 1578 Type identifiers appearing in an HTTP request or response with an 1579 'application/alto-*' media type MUST be registered in the ALTO 1580 Address Type registry (see Section 13.4). 1582 The type 'AddressType' is used in this document to indicate a string 1583 of this format. 1585 9.4.2. Endpoint Address 1587 Endpoint Addresses are encoded as US-ASCII strings. The exact 1588 characters and format depend on the type of endpoint address. 1590 The type 'EndpointAddr' is used in this document to indicate a string 1591 of this format. 1593 9.4.2.1. IPv4 1595 IPv4 Endpoint Addresses are encoded as specified by the 'IPv4address' 1596 rule in Section 3.2.2 of [RFC3986]. 1598 9.4.2.2. IPv6 1600 IPv6 Endpoint Addresses are encoded as specified in Section 4 of 1601 [RFC5952]. 1603 9.4.2.3. Typed Endpoint Addresses 1605 When an Endpoint Address is used, an ALTO implementation must be able 1606 to determine its type. For this purpose, the ALTO Protocol allows 1607 endpoint addresses to also explicitly indicate their type. 1609 Typed Endpoint Addresses are encoded as US-ASCII strings of the 1610 format 'AddressType:EndpointAddr' (with the ':' character as a 1611 separator). The type 'TypedEndpointAddr' is used to indicate a 1612 string of this format. 1614 9.4.3. Endpoint Prefixes 1616 For efficiency, it is useful to denote a set of Endpoint Addresses 1617 using a special notation (if one exists). This specification makes 1618 use of the prefix notations for both IPv4 and IPv6 for this purpose. 1620 Endpoint Prefixes are encoded as US-ASCII strings. The exact 1621 characters and format depend on the type of endpoint address. 1623 The type 'EndpointPrefix' is used in this document to indicate a 1624 string of this format. 1626 9.4.3.1. IPv4 1628 IPv4 Endpoint Prefixes are encoded as specified in Section 3.1 of 1629 [RFC4632]. 1631 9.4.3.2. IPv6 1633 IPv6 Endpoint Prefixes are encoded as specified in Section 7 of 1634 [RFC5952]. 1636 9.4.4. Endpoint Address Group 1638 The ALTO Protocol includes messages that specify potentially large 1639 sets of endpoint addresses. Endpoint Address Groups provide a more 1640 efficient way to encode such sets, even when the set contains 1641 endpoint addresses of different types. 1643 An Endpoint Address Group is defined as: 1645 object-map { 1646 AddressType -> EndpointPrefix<0..*>; 1647 } EndpointAddrGroup; 1649 In particular, an Endpoint Address Group is a JSON object 1650 representing a map, where each key is the string corresponding to an 1651 address type, and the corresponding value is an array listing 1652 prefixes of addresses of that type. 1654 The following is an example with both IPv4 and IPv6 endpoint 1655 addresses: 1657 { 1658 "ipv4": [ 1659 "192.0.2.0/24", 1660 "198.51.100.0/25" 1661 ], 1662 "ipv6": [ 1663 "2001:db8:0:1::/64", 1664 "2001:db8:0:2::/64" 1665 ] 1666 } 1668 9.5. Cost Mode 1670 A Cost Mode is encoded as a US-ASCII string. The string MUST either 1671 have the value 'numerical' or 'ordinal'. 1673 The type 'CostMode' is used in this document to indicate a string of 1674 this format. 1676 9.6. Cost Metric 1678 A Cost Metric is encoded as a US-ASCII string. The string MUST be no 1679 more than 32 characters, and MUST NOT contain characters other than 1680 alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, and 0x61- 1681 0x7A), the hyphen ('-', code point 0x2D), the colon (':', code point 1682 0x3A), or the '.' separator (0x2E). The '.' separator is reserved 1683 for future use and MUST NOT be used unless specifically indicated by 1684 a companion or extension document. 1686 Identifiers prefixed with 'priv:' are reserved for Private Use 1687 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for 1688 Experimental use. For an identifier with the 'priv:' or 'exp:' 1689 prefix, an additional string (e.g., company identifier or random 1690 string) MUST follow to reduce potential collisions. For example, a 1691 short string after 'exp:' to indicate the starting time of a specific 1692 experiment is recommended. All other identifiers appearing in an 1693 HTTP request or response with an 'application/alto-*' media type MUST 1694 be registered in the ALTO Cost Metrics registry Section 13.2. 1696 The type 'CostMetric' is used in this document to indicate a string 1697 of this format. 1699 9.7. Cost Type 1701 The combination of a CostMetric and a CostMode defines a CostType: 1703 object { 1704 CostMetric cost-metric; 1705 CostMode cost-mode; 1706 [JSONString description;] 1707 } CostType; 1709 'description', if present, MUST contain a US-ASCII string with a 1710 human-readable description of the cost-metric and cost-mode. An ALTO 1711 Client MAY present this string to a developer, as part of a discovery 1712 process. But the field SHOULD NOT be interpreted by an ALTO Client. 1714 9.8. Endpoint Property 1716 An Endpoint Property is encoded as a US-ASCII string. The string 1717 MUST be no more than 32 characters, and MUST NOT contain characters 1718 other than alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, 1719 and 0x61-0x7A), the hyphen ('-', code point 0x2D), the colon (':', 1720 code point 0x3A), or the '.' separator (0x2E). The '.' separator is 1721 reserved for future use and MUST NOT be used unless specifically 1722 indicated by a companion or extension document. 1724 Identifiers prefixed with 'priv:' are reserved for Private Use 1725 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for 1726 Experimental use. For an identifier with the 'priv:' or 'exp:' 1727 prefix, an additional string (e.g., company identifier or random 1728 string) MUST follow to reduce potential collisions. For example, a 1729 short string after 'exp:' to indicate the starting time of a specific 1730 experiment is recommended. All other identifiers appearing in an 1731 HTTP request or response with an 'application/alto-*' media type MUST 1732 be registered in the ALTO Endpoint Property registry Section 13.3. 1734 The type 'EndpointPropertyType' is used in this document to indicate 1735 a string of this format. 1737 10. Protocol Specification: Service Information Resources 1739 This section documents the individual Information Resources defined 1740 to provide the services defined in this document. 1742 10.1. Map Service 1744 The Map Service provides batch information to ALTO Clients in the 1745 form of two types of maps: a Network Map and Cost Map. 1747 10.1.1. Network Map 1749 The Network Map Information Resource lists for each PID, the network 1750 locations (endpoints) within the PID. An ALTO Server MUST provide at 1751 least one Network Map. 1753 10.1.1.1. Media Type 1755 The media type of Network Map is "application/alto-networkmap+json". 1757 10.1.1.2. HTTP Method 1759 The Network Map resource is requested using the HTTP GET method. 1761 10.1.1.3. Accept Input Parameters 1763 None. 1765 10.1.1.4. Capabilities 1767 None. 1769 10.1.1.5. Response 1771 The "data" member of the returned InfoResourceEntity for a Network 1772 Map is an object of type InfoResourceNetworkMap: 1774 object { 1775 VersionTag map-vtag; 1776 NetworkMapData map; 1777 } InfoResourceNetworkMap; 1779 object-map { 1780 PIDName -> EndpointAddrGroup; 1781 } NetworkMapData; 1783 with members: 1785 map-vtag The Version Tag (Section 6.3) of the Network Map. 1787 map The Network Map data itself. 1789 NetworkMapData is a JSON object representing a dictionary map with 1790 each key representing a single PID, and the value the associated set 1791 of endpoint addresses. 1793 The returned Network Map MUST include all PIDs known to the ALTO 1794 Server. 1796 10.1.1.6. Example 1798 GET /networkmap HTTP/1.1 1799 Host: alto.example.com 1800 Accept: application/alto-networkmap+json,application/alto-error+json 1801 HTTP/1.1 200 OK 1802 Content-Length: TBA 1803 Content-Type: application/alto-networkmap+json 1805 { 1806 "meta" : {}, 1807 "data" : { 1808 "map-vtag" : { 1809 "resource-id": "default-network-map", 1810 "tag": "1266506139" 1811 }, 1812 "map" : { 1813 "PID1" : { 1814 "ipv4" : [ 1815 "192.0.2.0/24", 1816 "198.51.100.0/25" 1817 ] 1818 }, 1819 "PID2" : { 1820 "ipv4" : [ 1821 "198.51.100.128/25" 1822 ] 1823 }, 1824 "PID3" : { 1825 "ipv4" : [ 1826 "0.0.0.0/0" 1827 ], 1828 "ipv6" : [ 1829 "::/0" 1830 ] 1831 } 1832 } 1833 } 1834 } 1836 The encodings were chosen for readability and compactness. If lookup 1837 efficiency at runtime is crucial, then the returned Cost Map and 1838 Network Map can be transformed into data structures offering more 1839 efficient lookup. For example, one may store the Cost Map as a 1840 matrix, and the Network Map as a trie-based data structure, which may 1841 allow efficient longest-prefix matching of IP addresses. 1843 10.1.2. Cost Map 1845 The Cost Map resource lists the Path Cost for each pair of source/ 1846 destination PID defined by the ALTO Server for a given Cost Metric 1847 and Cost Mode. This resource MUST be provided for at least the 1848 'routingcost' Cost Metric. 1850 10.1.2.1. Media Type 1852 The media type of Cost Map is "application/alto-costmap+json". 1854 10.1.2.2. HTTP Method 1856 The Cost Map resource is requested using the HTTP GET method. 1858 10.1.2.3. Accept Input Parameters 1860 None. 1862 10.1.2.4. Capabilities 1864 The capabilities of an ALTO Server URI providing an unfiltered cost 1865 map is a JSON Object of type CostMapCapabilities: 1867 object { 1868 JSONString cost-type-names<1..*>; 1869 } CostMapCapabilities; 1871 with member: 1873 cost-type-names A sequence of CostType names defined in "cost-types" 1874 of the "meta" member of an IRD. These represent the Cost Types 1875 that are supported via the corresponding URI in the IRD. If there 1876 is more than one Cost Type in this list, then the ALTO Server 1877 SHOULD return an IRD to the client to lead it towards the URIs for 1878 the corresponding Cost Maps. Since an unfiltered Cost Map is 1879 requested via an HTTP GET that accepts no input parameters, an 1880 ALTO Client MUST be led towards a resource that has a single 1881 element in the 'cost-type-names' list. 1883 10.1.2.5. Response 1885 The "data" member of the returned InfoResourceEntity for a Cost Map 1886 is an object of type InfoResourceCostMap: 1888 object { 1889 CostType cost-type; 1890 VersionTag map-vtag; 1891 CostMapData map; 1892 } InfoResourceCostMap; 1894 object-map { 1895 PIDName -> DstCosts; 1896 } CostMapData; 1898 object-map { 1899 PIDName -> JSONValue; 1900 } DstCosts; 1902 with members: 1904 cost-type Cost Type (Section 9.7) used in the Cost Map. 1906 map-vtag The Version Tag (Section 6.3) of the full (unfiltered) 1907 Network Map used to generate the Cost Map. 1909 map The Cost Map data itself. 1911 CostMapData is a dictionary map object, with each key being the 1912 PIDName string identifying the corresponding Source PID, and value 1913 being a type of DstCosts, which denotes the associated costs from the 1914 Source PID to a set of destination PIDs ( Section 6.2). An 1915 implementation of the protocol in this document SHOULD assume that 1916 the cost is a JSONNumber and fail to parse if it is not, unless the 1917 implementation is using an extension to this document that indicates 1918 when and how costs of other data types are signaled. 1920 The returned Cost Map MUST include the Path Cost for each (Source 1921 PID, Destination PID) pair for which a Path Cost is defined. An ALTO 1922 Server MAY omit entries for which a Path Cost is not defined (e.g., 1923 both the Source and Destination PIDs contain addresses outside of the 1924 Network Provider's administrative domain). 1926 10.1.2.6. Example 1928 GET /costmap/num/routingcost HTTP/1.1 1929 Host: alto.example.com 1930 Accept: application/alto-costmap+json,application/alto-error+json 1931 HTTP/1.1 200 OK 1932 Content-Length: TBA 1933 Content-Type: application/alto-costmap+json 1935 { 1936 "meta" : {}, 1937 "data" : { 1938 "cost-type" : {"cost-mode" : "numerical", 1939 "cost-metric": "routingcost"}, 1940 "map-vtag" : { 1941 "resource-id": "default-network-map", 1942 "tag": "1266506139" 1943 }, 1944 "map" : { 1945 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 1946 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 1947 "PID3": { "PID1": 20, "PID2": 15 } 1948 } 1949 } 1950 } 1952 Similar to the Network Map case, we considered array-based encoding 1953 for "map", but chose the current encoding for clarity. 1955 10.2. Map Filtering Service 1957 The Map Filtering Service allows ALTO Clients to specify filtering 1958 criteria to return a subset of the full maps available in the Map 1959 Service. 1961 10.2.1. Filtered Network Map 1963 A Filtered Network Map is a Network Map Information Resource 1964 (Section 10.1.1) for which an ALTO Client may supply a list of PIDs 1965 to be included. A Filtered Network Map MAY be provided by an ALTO 1966 Server. 1968 10.2.1.1. Media Type 1970 As a Filtered Network Map is a Network Map, it uses the media type 1971 defined for Network Map at Section 10.1.1.1. 1973 10.2.1.2. HTTP Method 1975 A Filtered Network Map is requested using the HTTP POST method. 1977 10.2.1.3. Accept Input Parameters 1979 An ALTO Client supplies filtering parameters by specifying media type 1980 "application/alto-networkmapfilter+json" with HTTP POST body 1981 containing a JSON Object of type ReqFilteredNetworkMap, where: 1983 object { 1984 PIDName pids<0..*>; 1985 [AddressType address-types<0..*>;] 1986 } ReqFilteredNetworkMap; 1988 with members: 1990 pids Specifies list of PIDs to be included in the returned Filtered 1991 Network Map. If the list of PIDs is empty, the ALTO Server MUST 1992 interpret the list as if it contained a list of all currently- 1993 defined PIDs. The ALTO Server MUST interpret entries appearing 1994 multiple times as if they appeared only once. 1996 address-types Specifies list of address types to be included in the 1997 returned Filtered Network Map. If the "address-types" member is 1998 not specified, or the list of address types is empty, the ALTO 1999 Server MUST interpret the list as if it contained a list of all 2000 address types known to the ALTO Server. The ALTO Server MUST 2001 interpret entries appearing multiple times as if they appeared 2002 only once. 2004 10.2.1.4. Capabilities 2006 None. 2008 10.2.1.5. Response 2010 See Section 10.1.1.5 for the format. 2012 The ALTO Server MUST only include PIDs in the response that were 2013 specified (implicitly or explicitly) in the request. If the input 2014 parameters contain a PID name that is not currently defined by the 2015 ALTO Server, the ALTO Server MUST behave as if the PID did not appear 2016 in the input parameters. Similarly, the ALTO Server MUST only 2017 enumerate addresses within each PID that have types which were 2018 specified (implicitly or explicitly) in the request. If the input 2019 parameters contain an address type that is not currently known to the 2020 ALTO Server, the ALTO Server MUST behave as if the address type did 2021 not appear in the input parameters. 2023 The Version Tag included in the response MUST correspond to the full 2024 (unfiltered) Network Map Information Resource from which the filtered 2025 information is provided. This ensures that a single, canonical 2026 Version Tag is used independent of any filtering that is requested by 2027 an ALTO Client. 2029 10.2.1.6. Example 2031 POST /networkmap/filtered HTTP/1.1 2032 Host: custom.alto.example.com 2033 Content-Length: 27 2034 Content-Type: application/alto-networkmapfilter+json 2035 Accept: application/alto-networkmap+json,application/alto-error+json 2037 { 2038 "pids": [ "PID1", "PID2" ] 2039 } 2041 HTTP/1.1 200 OK 2042 Content-Length: TBA 2043 Content-Type: application/alto-networkmap+json 2045 { 2046 "meta" : {}, 2047 "data" : { 2048 "map-vtag" : { 2049 "resource-id": "default-network-map", 2050 "tag": "1266506139" 2051 }, 2052 "map" : { 2053 "PID1" : { 2054 "ipv4" : [ 2055 "192.0.2.0/24", 2056 "198.51.100.0/24" 2057 ] 2058 }, 2059 "PID2" : { 2060 "ipv4": [ 2061 "198.51.100.128/24" 2062 ] 2063 } 2064 } 2065 } 2066 } 2068 10.2.2. Filtered Cost Map 2070 A Filtered Cost Map is a Cost Map Information Resource 2071 (Section 10.1.2) for which an ALTO Client may supply additional 2072 parameters limiting the scope of the resulting Cost Map. A Filtered 2073 Cost Map MAY be provided by an ALTO Server. 2075 10.2.2.1. Media Type 2077 As a Filtered Cost Map is a Cost Map, it uses the media type defined 2078 for Cost Map at Section 10.1.2.1. 2080 10.2.2.2. HTTP Method 2082 A Filtered Cost Map is requested using the HTTP POST method. 2084 10.2.2.3. Accept Input Parameters 2086 The input parameters for a Filtered Map are supplied in the entity 2087 body of the POST request. This document specifies the input 2088 parameters with a data format indicated by the media type 2089 "application/alto-costmapfilter+json", which is a JSON Object of type 2090 ReqFilteredCostMap, where: 2092 object { 2093 CostType cost-type; 2094 [JSONString constraints<0..*>;] 2095 [PIDFilter pids;] 2096 } ReqFilteredCostMap; 2098 object { 2099 PIDName srcs<0..*>; 2100 PIDName dsts<0..*>; 2101 } PIDFilter; 2103 with members: 2105 cost-type The CostType (Section 9.7) for the returned costs. The 2106 cost-metric and cost-mode fields MUST match one of the supported 2107 Cost Types indicated in this resource's capabilities 2108 (Section 10.2.2.4). The ALTO Client SHOULD omit the description 2109 field, and if present, the ALTO Server MUST ignore the description 2110 field. 2112 constraints Defines a list of additional constraints on which 2113 elements of the Cost Map are returned. This parameter MUST NOT be 2114 specified if this resource's capabilities ( Section 10.2.2.4) 2115 indicate that constraint support is not available. A constraint 2116 contains two entities separated by whitespace: (1) an operator, 2117 'gt' for greater than, 'lt' for less than, 'ge' for greater than 2118 or equal to, 'le' for less than or equal to, or 'eq' for equal to; 2119 (2) a target cost value. The cost value is a number that MUST be 2120 defined in the same units as the Cost Metric indicated by the 2121 cost-metric parameter. ALTO Servers SHOULD use at least IEEE 754 2122 double-precision floating point [IEEE.754.2008] to store the cost 2123 value, and SHOULD perform internal computations using double- 2124 precision floating-point arithmetic. If multiple 'constraint' 2125 parameters are specified, they are interpreted as being related to 2126 each other with a logical AND. 2128 pids A list of Source PIDs and a list of Destination PIDs for which 2129 Path Costs are to be returned. If a list is empty, the ALTO 2130 Server MUST interpret it as the full set of currently-defined 2131 PIDs. The ALTO Server MUST interpret entries appearing in a list 2132 multiple times as if they appeared only once. If the "pids" 2133 member is not present, both lists MUST be interpreted by the ALTO 2134 Server as containing the full set of currently-defined PIDs. 2136 10.2.2.4. Capabilities 2138 The URI providing this resource supports all capabilities documented 2139 in Section 10.1.2.4 (with identical semantics), plus additional 2140 capabilities. In particular, the capabilities are defined by a JSON 2141 object of type FilteredCostMapCapabilities: 2143 object { 2144 JSONString cost-type-names<1..*>; 2145 JSONBool cost-constraints; 2146 } FilteredCostMapCapabilities; 2148 with members: 2150 cost-type-names See Section 10.1.2.4 and note that the array can 2151 have 1 to many cost types. 2153 cost-constraints If true, then the ALTO Server allows cost 2154 constraints to be included in requests to the corresponding URI. 2155 If not present, this member MUST be interpreted as if it specified 2156 false. ALTO Clients should be aware that constraints may not have 2157 the intended effect for cost maps with the 'ordinal' Cost Mode 2158 since ordinal costs are not restricted to being sequential 2159 integers. 2161 10.2.2.5. Response 2163 See Section 10.1.2.5 for the format. 2165 The returned Cost Map MUST contain only source/destination pairs that 2166 have been indicated (implicitly or explicitly) in the input 2167 parameters. If the input parameters contain a PID name that is not 2168 currently defined by the ALTO Server, the ALTO Server MUST behave as 2169 if the PID did not appear in the input parameters. 2171 If any constraints are specified, Source/Destination pairs for which 2172 the Path Costs do not meet the constraints MUST NOT be included in 2173 the returned Cost Map. If no constraints were specified, then all 2174 Path Costs are assumed to meet the constraints. 2176 Note that ALTO Clients should verify that the Version Tag included in 2177 the response is consistent with the Version Tag of the Network Map 2178 used to generate the request (if applicable). If it is not, the ALTO 2179 Client may wish to request an updated Network Map, identify changes, 2180 and consider requesting a new Filtered Cost Map. 2182 10.2.2.6. Example 2184 POST /costmap/filtered HTTP/1.1 2185 Host: custom.alto.example.com 2186 Content-Type: application/alto-costmapfilter+json 2187 Accept: application/alto-costmap+json,application/alto-error+json 2189 { 2190 "cost-type" : {"cost-mode": "numerical", 2191 "cost-metric": "routingcost"}, 2192 "pids" : { 2193 "srcs" : [ "PID1" ], 2194 "dsts" : [ "PID1", "PID2", "PID3" ] 2195 } 2196 } 2198 HTTP/1.1 200 OK 2199 Content-Length: TBA 2200 Content-Type: application/alto-costmap+json 2202 { 2203 "meta" : {}, 2204 "data" : { 2205 "cost-type": {"cost-mode" : "numerical", 2206 "cost-metric" : "routingcost"}, 2207 "map-vtag" : { 2208 "resource-id": "default-network-map", 2209 "tag": "1266506139" 2210 }, 2211 "map" : { 2212 "PID1": { "PID1": 0, "PID2": 1, "PID3": 2 } 2213 } 2214 } 2215 } 2217 10.3. Endpoint Property Service 2219 The Endpoint Property Service provides information about Endpoint 2220 properties to ALTO Clients. 2222 10.3.1. Endpoint Property 2224 The Endpoint Property resource provides information about properties 2225 for individual endpoints. It MAY be provided by an ALTO Server. If 2226 an ALTO Server provides one or more Endpoint Property resources, then 2227 at least one MUST provide the 'pid' property. 2229 10.3.1.1. Media Type 2231 The media type of Endpoint Property is "application/ 2232 alto-endpointprop+json". 2234 10.3.1.2. HTTP Method 2236 The Endpoint Property resource is requested using the HTTP POST 2237 method. 2239 10.3.1.3. Accept Input Parameters 2241 An ALTO Client supplies the endpoint properties to be queried through 2242 a media type "application/alto-endpointpropparams+json", and 2243 specifies in the HTTP POST entity body a JSON Object of type 2244 ReqEndpointProp: 2246 object { 2247 EndpointPropertyType properties<1..*>; 2248 TypedEndpointAddr endpoints<1..*>; 2249 } ReqEndpointProp; 2251 with members: 2253 properties List of endpoint properties to be returned for each 2254 endpoint. Each specified property MUST be included in the list of 2255 supported properties indicated by this resource's capabilities 2256 (Section 10.3.1.4). The ALTO Server MUST interpret entries 2257 appearing multiple times as if they appeared only once. 2259 endpoints List of endpoint addresses for which the specified 2260 properties are to be returned. The ALTO Server MUST interpret 2261 entries appearing multiple times as if they appeared only once. 2263 10.3.1.4. Capabilities 2265 This resource may be defined across multiple types of endpoint 2266 properties. The capabilities of an ALTO Server URI providing 2267 Endpoint Properties are defined by a JSON Object of type 2268 EndpointPropertyCapabilities: 2270 object { 2271 EndpointPropertyType prop-types<1..*>; 2273 } EndpointPropertyCapabilities; 2275 with members: 2277 prop-types The Endpoint Properties (see Section 9.8) supported by 2278 the corresponding URI. 2280 10.3.1.5. Response 2282 The returned InfoResourceEntity object has "data" member of type 2283 InfoResourceEndpointProperty, where: 2285 object { 2286 VersionTag map-vtag; [DEPEND ON PROPERTIES] 2287 EndpointPropertyMapData map; 2288 } InfoResourceEndpointProperty; 2290 object-map { 2291 TypedEndpointAddr -> EndpointProps; 2292 } EndpointPropertyMapData; 2294 object { 2295 EndpointPropertyType -> JSONValue; 2296 } EndpointProps; 2298 EndpointPropertyMapData has one member for each endpoint indicated in 2299 the input parameters (with the name being the endpoint encoded as a 2300 TypedEndpointAddr). The requested properties for each endpoint are 2301 encoded in a corresponding EndpointProps object, which encodes one 2302 name/value pair for each requested property, where the property names 2303 are encoded as strings of type EndpointPropertyType. An 2304 implementation of the protocol in this document SHOULD assume that 2305 the property value is a JSONString and fail to parse if it is not, 2306 unless the implementation is using an extension to this document that 2307 indicates when and how property values of other data types are 2308 signaled. 2310 The ALTO Server returns the value for each of the requested endpoint 2311 properties for each of the endpoints listed in the input parameters. 2313 If the ALTO Server does not define a requested property's value for a 2314 particular endpoint, then it MUST omit that property from the 2315 response for only that endpoint. 2317 The ALTO Server MAY include the Version Tag (Section 6.3) of the full 2318 (unfiltered) Network Map used to generate the response (if desired 2319 and applicable) as the 'map-vtag' member in the response. If the 2320 'pid' property is returned for any endpoints in the response, the 2321 'map-vtag' member is REQUIRED. Otherwise, it is OPTIONAL. 2323 10.3.1.6. Example 2325 POST /endpointprop/lookup HTTP/1.1 2326 Host: alto.example.com 2327 Content-Length: 96 2328 Content-Type: application/alto-endpointpropparams+json 2329 Accept: application/alto-endpointprop+json,application/alto-error+json 2331 { 2332 "properties" : [ "pid", "example-prop" ], 2333 "endpoints" : [ "ipv4:192.0.2.34", "ipv4:203.0.113.129" ] 2334 } 2336 HTTP/1.1 200 OK 2337 Content-Length: TBA 2338 Content-Type: application/alto-endpointprop+json 2340 { 2341 "meta" : {}, 2342 "data": { 2343 "map-vtag" : { 2344 "resource-id": "default-network-map", 2345 "tag": "1266506139" 2346 }, 2347 "map" : { 2348 "ipv4:192.0.2.34" : { "pid": "PID1", "example-prop": "1" }, 2349 "ipv4:203.0.113.129" : { "pid": "PID3" } 2350 } 2351 } 2352 } 2354 10.4. Endpoint Cost Service 2356 The Endpoint Cost Service provides information about costs between 2357 individual endpoints. 2359 In particular, this service allows lists of Endpoint prefixes (and 2360 addresses, as a special case) to be ranked (ordered) by an ALTO 2361 Server. 2363 10.4.1. Endpoint Cost 2365 The Endpoint Cost resource provides information about costs between 2366 individual endpoints. It MAY be provided by an ALTO Server. 2368 It is important to note that although this resource allows an ALTO 2369 Server to reveal costs between individual endpoints, an ALTO Server 2370 is not required to do so. A simple alternative would be to compute 2371 the cost between two endpoints as the cost between the PIDs 2372 corresponding to the endpoints. See Section 14.3 for additional 2373 details. 2375 10.4.1.1. Media Type 2377 The media type of Endpoint Cost is "application/ 2378 alto-endpointcost+json". 2380 10.4.1.2. HTTP Method 2382 The Endpoint Cost resource is requested using the HTTP POST method. 2384 10.4.1.3. Accept Input Parameters 2386 An ALTO Client supplies the endpoint cost parameters through a media 2387 type "application/alto-endpointcostparams+json", with an HTTP POST 2388 entity body of a JSON Object of type ReqEndpointCostMap: 2390 object { 2391 CostType cost-type; 2392 [JSONString constraints<0..*>;] 2393 EndpointFilter endpoints; 2394 } ReqEndpointCostMap; 2396 object { 2397 [TypedEndpointAddr srcs<0..*>;] 2398 [TypedEndpointAddr dsts<0..*>;] 2399 } EndpointFilter; 2401 with members: 2403 cost-type The Cost Type (Section 9.7) to use for returned costs. 2404 The cost-metric and cost-mode fields MUST match one of the 2405 supported Cost Types indicated in this resource's capabilities ( 2406 Section 10.4.1.4). The ALTO Client SHOULD omit the description 2407 field, and if present, the ALTO Server MUST ignore the description 2408 field. 2410 constraints Defined equivalently to the "constraints" input 2411 parameter of a Filtered Cost Map (see Section 10.2.2). 2413 endpoints A list of Source Endpoints and Destination Endpoints for 2414 which Path Costs are to be returned. If the list of Source or 2415 Destination Endpoints is empty (or not included), the ALTO Server 2416 MUST interpret it as if it contained the Endpoint Address 2417 corresponding to the client IP address from the incoming 2418 connection (see Section 12.3 for discussion and considerations 2419 regarding this mode). The Source and Destination Endpoint lists 2420 MUST NOT be both empty. The ALTO Server MUST interpret entries 2421 appearing multiple times in a list as if they appeared only once. 2423 10.4.1.4. Capabilities 2425 In this document, we define EndpointCostCapabilities the same as 2426 FilteredCostMapCapabilities. See Section 10.2.2.4. 2428 10.4.1.5. Response 2430 The returned InfoResourceEntity object has "data" member equal to 2431 InfoResourceEndpointCostMap, where: 2433 object { 2434 CostType cost-type; 2435 EndpointCostMapData map; 2436 } InfoResourceEndpointCostMap; 2438 object-map { 2439 TypedEndpointAddr -> EndpointDstCosts; 2440 } EndpointCostMapData; 2442 object-map { 2443 TypedEndpointAddr -> JSONValue; 2444 } EndpointDstCosts; 2446 InfoResourceEndpointCostMap has members: 2448 cost-type The Cost Type used in the returned Cost Map. 2450 map The Endpoint Cost Map data itself. 2452 EndpointCostMapData is a dictionary map object with each key 2453 representing a TypedEndpointAddr string identifying the Source 2454 Endpoint specified in the input parameters; the name for a member is. 2455 For each Source Endpoint, a EndpointDstCosts dictionary map object 2456 denotes the associated cost to each Destination Endpoint specified in 2457 input parameters. An implementation of the protocol in this document 2458 SHOULD assume that the cost value is a JSONNumber and fail to parse 2459 if it is not, unless the implementation is using an extension to this 2460 document that indicates when and how costs of other data types are 2461 signaled. If the ALTO Server does not define a cost value from a 2462 Source Endpoint to a particular Destination Endpoint, it MAY be 2463 omitted from the response. 2465 10.4.1.6. Example 2467 POST /endpointcost/lookup HTTP/1.1 2468 Host: alto.example.com 2469 Content-Length: 195 2470 Content-Type: application/alto-endpointcostparams+json 2471 Accept: application/alto-endpointcost+json,application/alto-error+json 2473 { 2474 "cost-type": {"cost-mode" : "ordinal", 2475 "cost-metric" : "routingcost"}, 2476 "endpoints" : { 2477 "srcs": [ "ipv4:192.0.2.2" ], 2478 "dsts": [ 2479 "ipv4:192.0.2.89", 2480 "ipv4:198.51.100.34", 2481 "ipv4:203.0.113.45" 2482 ] 2483 } 2484 } 2486 HTTP/1.1 200 OK 2487 Content-Length: 231 2488 Content-Type: application/alto-endpointcost+json 2490 { 2491 "meta" : {}, 2492 "data" : { 2493 "cost-type": {"cost-mode" : "ordinal", 2494 "cost-metric" : "routingcost"}, 2495 "map" : { 2496 "ipv4:192.0.2.2": { 2497 "ipv4:192.0.2.89" : 1, 2498 "ipv4:198.51.100.34" : 2, 2499 "ipv4:203.0.113.45" : 3 2500 } 2501 } 2502 } 2503 } 2505 11. Use Cases 2507 The sections below depict typical use cases. While these use cases 2508 focus on peer-to-peer applications, ALTO can be applied to other 2509 environments such as CDNs [I-D.jenkins-alto-cdn-use-cases]. 2511 11.1. ALTO Client Embedded in P2P Tracker 2513 Many currently-deployed P2P systems use a Tracker to manage swarms 2514 and perform peer selection. Such a P2P Tracker can already use a 2515 variety of information to perform peer selection to meet application- 2516 specific goals. By acting as an ALTO Client, the P2P Tracker can use 2517 ALTO information as an additional information source to enable more 2518 network-efficient traffic patterns and improve application 2519 performance. 2521 A particular requirement of many P2P trackers is that they must 2522 handle a large number of P2P clients. A P2P tracker can obtain and 2523 locally store ALTO information (the Network Map and Cost Map) from 2524 the ISPs containing the P2P clients, and benefit from the same 2525 aggregation of network locations done by ALTO Servers. 2527 .---------. (1) Get Network Map .---------------. 2528 | | <----------------------> | | 2529 | ALTO | | P2P Tracker | 2530 | Server | (2) Get Cost Map | (ALTO Client) | 2531 | | <----------------------> | | 2532 `---------' `---------------' 2533 ^ | 2534 (3) Get Peers | | (4) Selected Peer 2535 | v List 2536 .---------. .-----------. 2537 | Peer 1 | <-------------- | P2P | 2538 `---------' | Client | 2539 . (5) Connect to `-----------' 2540 . Selected Peers / 2541 .---------. / 2542 | Peer 50 | <------------------ 2543 `---------' 2545 Figure 4: ALTO Client Embedded in P2P Tracker 2547 Figure 4 shows an example use case where a P2P tracker is an ALTO 2548 Client and applies ALTO information when selecting peers for its P2P 2549 clients. The example proceeds as follows: 2551 1. The P2P Tracker requests from the ALTO Server using the Network 2552 Map query the Network Map covering all PIDs. The Network Map 2553 includes the IP prefixes contained in each PID, allowing the P2P 2554 tracker to locally map P2P clients into PIDs. 2556 2. The P2P Tracker requests from the ALTO Server the Cost Map 2557 amongst all PIDs identified in the preceding step. 2559 3. A P2P Client joins the swarm, and requests a peer list from the 2560 P2P Tracker. 2562 4. The P2P Tracker returns a peer list to the P2P client. The 2563 returned peer list is computed based on the Network Map and Cost 2564 Map returned by the ALTO Server, and possibly other information 2565 sources. Note that it is possible that a tracker may use only 2566 the Network Map to implement hierarchical peer selection by 2567 preferring peers within the same PID and ISP. 2569 5. The P2P Client connects to the selected peers. 2571 Note that the P2P tracker may provide peer lists to P2P clients 2572 distributed across multiple ISPs. In such a case, the P2P tracker 2573 may communicate with multiple ALTO Servers. 2575 11.2. ALTO Client Embedded in P2P Client: Numerical Costs 2577 P2P clients may also utilize ALTO information themselves when 2578 selecting from available peers. It is important to note that not all 2579 P2P systems use a P2P tracker for peer discovery and selection. 2580 Furthermore, even when a P2P tracker is used, the P2P clients may 2581 rely on other sources, such as peer exchange and DHTs, to discover 2582 peers. 2584 When an P2P Client uses ALTO information, it typically queries only 2585 the ALTO Server servicing its own ISP. The my-Internet view provided 2586 by its ISP's ALTO Server can include preferences to all potential 2587 peers. 2589 .---------. (1) Get Network Map .---------------. 2590 | | <----------------------> | | 2591 | ALTO | | P2P Client | 2592 | Server | (2) Get Cost Map | (ALTO Client) | 2593 | | <----------------------> | | .---------. 2594 `---------' `---------------' <- | P2P | 2595 .---------. / | ^ ^ | Tracker | 2596 | Peer 1 | <-------------- | | \ `---------' 2597 `---------' | (3) Gather Peers 2598 . (4) Select Peers | | \ 2599 . and Connect / .--------. .--------. 2600 .---------. / | P2P | | DHT | 2601 | Peer 50 | <---------------- | Client | `--------' 2602 `---------' | (PEX) | 2603 `--------' 2605 Figure 5: ALTO Client Embedded in P2P Client 2607 Figure 5 shows an example use case where a P2P Client locally applies 2608 ALTO information to select peers. The use case proceeds as follows: 2610 1. The P2P Client requests the Network Map covering all PIDs from 2611 the ALTO Server servicing its own ISP. 2613 2. The P2P Client requests the Cost Map amongst all PIDs from the 2614 ALTO Server. The Cost Map by default specifies numerical costs. 2616 3. The P2P Client discovers peers from sources such as Peer Exchange 2617 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2618 P2P Trackers. 2620 4. The P2P Client uses ALTO information as part of the algorithm for 2621 selecting new peers, and connects to the selected peers. 2623 11.3. ALTO Client Embedded in P2P Client: Ranking 2625 It is also possible for a P2P Client to offload the selection and 2626 ranking process to an ALTO Server. In this use case, the ALTO Client 2627 gathers a list of known peers in the swarm, and asks the ALTO Server 2628 to rank them. 2630 As in the use case using numerical costs, the P2P Client typically 2631 only queries the ALTO Server servicing its own ISP. 2633 .---------. .---------------. 2634 | | | | 2635 | ALTO | (2) Get Endpoint Ranking | P2P Client | 2636 | Server | <----------------------> | (ALTO Client) | 2637 | | | | .---------. 2638 `---------' `---------------' <- | P2P | 2639 .---------. / | ^ ^ | Tracker | 2640 | Peer 1 | <-------------- | | \ `---------' 2641 `---------' | (1) Gather Peers 2642 . (3) Connect to | | \ 2643 . Selected Peers / .--------. .--------. 2644 .---------. / | P2P | | DHT | 2645 | Peer 50 | <---------------- | Client | `--------' 2646 `---------' | (PEX) | 2647 `--------' 2649 Figure 6: ALTO Client Embedded in P2P Client: Ranking 2651 Figure 6 shows an example of this scenario. The use case proceeds as 2652 follows: 2654 1. The P2P Client discovers peers from sources such as Peer Exchange 2655 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2656 P2P Trackers. 2658 2. The P2P Client queries the ALTO Server's Ranking Service, 2659 including discovered peers as the set of Destination Endpoints, 2660 and indicates the 'ordinal' Cost Mode. The response indicates 2661 the ranking of the candidate peers. 2663 3. The P2P Client connects to the peers in the order specified in 2664 the ranking. 2666 12. Discussions 2668 12.1. Discovery 2670 The discovery mechanism by which an ALTO Client locates an 2671 appropriate ALTO Server is out of scope for this document. This 2672 document assumes that an ALTO Client can discover an appropriate ALTO 2673 Server. Once it has done so, the ALTO Client may use the Information 2674 Resource Directory (see Section 8.5) to locate an Information 2675 Resource with the desired ALTO Information. 2677 12.2. Hosts with Multiple Endpoint Addresses 2679 In practical deployments, a particular host can be reachable using 2680 multiple addresses (e.g., a wireless IPv4 connection, a wireline IPv4 2681 connection, and a wireline IPv6 connection). In general, the 2682 particular network path followed when sending packets to the host 2683 will depend on the address that is used. Network providers may 2684 prefer one path over another. An additional consideration may be how 2685 to handle private address spaces (e.g., behind carrier-grade NATs). 2687 To support such behavior, this document allows multiple endpoint 2688 addresses and address types. With this support, the ALTO Protocol 2689 allows an ALTO Service Provider the flexibility to indicate 2690 preferences for paths from an endpoint address of one type to an 2691 endpoint address of a different type. 2693 12.3. Network Address Translation Considerations 2695 At this day and age of NAT v4<->v4, v4<->v6 [RFC6144], and possibly 2696 v6<->v6[I-D.mrw-nat66], a protocol should strive to be NAT friendly 2697 and minimize carrying IP addresses in the payload, or provide a mode 2698 of operation where the source IP address provide the information 2699 necessary to the server. 2701 The protocol specified in this document provides a mode of operation 2702 where the source network location is computed by the ALTO Server 2703 (i.e., the the Endpoint Cost Service) from the source IP address 2704 found in the ALTO Client query packets. This is similar to how some 2705 P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS 2706 Protocol" in [BitTorrent]) operate. 2708 There may be cases where an ALTO Client needs to determine its own IP 2709 address, such as when specifying a source Endpoint Address in the 2710 Endpoint Cost Service. It is possible that an ALTO Client has 2711 multiple network interface addresses, and that some or all of them 2712 may require NAT for connectivity to the public Internet. 2714 If a public IP address is required for a network interface, the ALTO 2715 Client SHOULD use the Session Traversal Utilities for NAT (STUN) 2716 [RFC5389]. If using this method, the host MUST use the "Binding 2717 Request" message and the resulting "XOR-MAPPED-ADDRESS" parameter 2718 that is returned in the response. Using STUN requires cooperation 2719 from a publicly accessible STUN server. Thus, the ALTO Client also 2720 requires configuration information that identifies the STUN server, 2721 or a domain name that can be used for STUN server discovery. To be 2722 selected for this purpose, the STUN server needs to provide the 2723 public reflexive transport address of the host. 2725 ALTO Clients should be cognizant that the network path between 2726 Endpoints can depend on multiple factors, e.g., source address, and 2727 destination address used for communication. An ALTO Server provides 2728 information based on Endpoint Addresses (more generally, Network 2729 Locations), but the mechanisms used for determining existence of 2730 connectivity or usage of NAT between Endpoints are out of scope of 2731 this document. 2733 12.4. Endpoint and Path Properties 2735 An ALTO Server could make available many properties about Endpoints 2736 beyond their network location or grouping. For example, connection 2737 type, geographical location, and others may be useful to 2738 applications. This specification focuses on network location and 2739 grouping, but the protocol may be extended to handle other Endpoint 2740 properties. 2742 13. IANA Considerations 2744 13.1. application/alto-* Media Types 2746 This document requests the registration of multiple media types, 2747 listed in Table 2. 2749 +-------------+------------------------------+----------------+ 2750 | Type | Subtype | Specification | 2751 +-------------+------------------------------+----------------+ 2752 | application | alto-directory+json | Section 8.5 | 2753 | application | alto-networkmap+json | Section 10.1.1 | 2754 | application | alto-networkmapfilter+json | Section 10.2.1 | 2755 | application | alto-costmap+json | Section 10.1.2 | 2756 | application | alto-costmapfilter+json | Section 10.2.2 | 2757 | application | alto-endpointprop+json | Section 10.3.1 | 2758 | application | alto-endpointpropparams+json | Section 10.3.1 | 2759 | application | alto-endpointcost+json | Section 10.4.1 | 2760 | application | alto-endpointcostparams+json | Section 10.4.1 | 2761 | application | alto-error+json | Section 8.7 | 2762 +-------------+------------------------------+----------------+ 2764 Table 2: ALTO Protocol Media Types. 2766 Type name: application 2768 Subtype name: This documents requests the registration of multiple 2769 subtypes, as listed in Table 2. 2771 Required parameters: n/a 2773 Optional parameters: n/a 2775 Encoding considerations: Encoding considerations are identical to 2776 those specified for the 'application/json' media type. See 2777 [RFC4627]. 2779 Security considerations: Security considerations relating to the 2780 generation and consumption of ALTO Protocol messages are discussed 2781 in Section 14. 2783 Interoperability considerations: This document specifies format of 2784 conforming messages and the interpretation thereof. 2786 Published specification: This document is the specification for 2787 these media types; see Table 2 for the section documenting each 2788 media type. 2790 Applications that use this media type: ALTO Servers and ALTO Clients 2791 either standalone or embedded within other applications. 2793 Additional information: 2795 Magic number(s): n/a 2797 File extension(s): This document uses the mime type to refer to 2798 protocol messages and thus does not require a file extension. 2800 Macintosh file type code(s): n/a 2802 Person & email address to contact for further information: See 2803 "Authors' Addresses" section. 2805 Intended usage: COMMON 2807 Restrictions on usage: n/a 2809 Author: See "Authors' Addresses" section. 2811 Change controller: Internet Engineering Task Force 2812 (mailto:iesg@ietf.org). 2814 13.2. ALTO Cost Metric Registry 2816 This document requests the creation of an ALTO Cost Metric registry, 2817 listed in Table 3, to be maintained by IANA. 2819 +-------------+---------------------+ 2820 | Identifier | Intended Semantics | 2821 +-------------+---------------------+ 2822 | routingcost | See Section 6.1.1.1 | 2823 | priv: | Private use | 2824 | exp: | Experimental use | 2825 +-------------+---------------------+ 2827 Table 3: ALTO Cost Metrics. 2829 This registry serves two purposes. First, it ensures uniqueness of 2830 identifiers referring to ALTO Cost Metrics. Second, it provides 2831 references to particular semantics of allocated Cost Metrics to be 2832 applied by both ALTO Servers and applications utilizing ALTO Clients. 2834 New ALTO Cost Metrics are assigned after Expert Review [RFC5226]. 2835 The Expert Reviewer will generally consult the ALTO Working Group or 2836 its successor. Expert Review is used to ensure that proper 2837 documentation regarding ALTO Cost Metric semantics and security 2838 considerations has been provided. The provided documentation should 2839 be detailed enough to provide guidance to both ALTO Service Providers 2840 and applications utilizing ALTO Clients as to how values of the 2841 registered ALTO Cost Metric should be interpreted. Updates and 2842 deletions of ALTO Cost Metrics follow the same procedure. 2844 Registered ALTO Cost Metric identifiers MUST conform to the 2845 syntactical requirements specified in Section 9.6. Identifiers are 2846 to be recorded and displayed as ASCII strings. 2848 Identifiers prefixed with 'priv:' are reserved for Private Use. 2849 Identifiers prefixed with 'exp:' are reserved for Experimental use. 2851 Requests to add a new value to the registry MUST include the 2852 following information: 2854 o Identifier: The name of the desired ALTO Cost Metric. 2856 o Intended Semantics: ALTO Costs carry with them semantics to guide 2857 their usage by ALTO Clients. For example, if a value refers to a 2858 measurement, the measurement units must be documented. For proper 2859 implementation of the ordinal Cost Mode (e.g., by a third-party 2860 service), it should be documented whether higher or lower values 2861 of the cost are more preferred. 2863 o Security Considerations: ALTO Costs expose information to ALTO 2864 Clients. As such, proper usage of a particular Cost Metric may 2865 require certain information to be exposed by an ALTO Service 2866 Provider. Since network information is frequently regarded as 2867 proprietary or confidential, ALTO Service Providers should be made 2868 aware of the security ramifications related to usage of a Cost 2869 Metric. 2871 This specification requests registration of the identifier 2872 'routingcost'. Semantics for the this Cost Metric are documented in 2873 Section 6.1.1.1, and security considerations are documented in 2874 Section 14.3. 2876 13.3. ALTO Endpoint Property Type Registry 2878 This document requests the creation of an ALTO Endpoint Property 2879 Types registry, listed in Table 4, to be maintained by IANA. 2881 +------------+--------------------+ 2882 | Identifier | Intended Semantics | 2883 +------------+--------------------+ 2884 | pid | See Section 7.1.1 | 2885 | priv: | Private use | 2886 | exp: | Experimental use | 2887 +------------+--------------------+ 2889 Table 4: ALTO Endpoint Property Types. 2891 The maintenance of this registry is similar to that of the preceding 2892 ALTO Cost Metrics. 2894 13.4. ALTO Address Type Registry 2896 This document requests the creation of an ALTO Address Type registry, 2897 listed in Table 5, to be maintained by IANA. 2899 +------------+----------------+----------------+--------------------+ 2900 | Identifier | Address | Prefix | Mapping to/from | 2901 | | Encoding | Encoding | IPv4/v6 | 2902 +------------+----------------+----------------+--------------------+ 2903 | ipv4 | See | See | Direct mapping to | 2904 | | Section 9.4.2 | Section 9.4.3 | IPv4 | 2905 | ipv6 | See | See | Direct mapping to | 2906 | | Section 9.4.2 | Section 9.4.3 | IPv6 | 2907 +------------+----------------+----------------+--------------------+ 2909 Table 5: ALTO Address Types. 2911 This registry serves two purposes. First, it ensures uniqueness of 2912 identifiers referring to ALTO Address Types. Second, it states the 2913 requirements for allocated Address Type identifiers. 2915 New ALTO Address Types are assigned after Expert Review [RFC5226]. 2916 The Expert Reviewer will generally consult the ALTO Working Group or 2917 its successor. Expert Review is used to ensure that proper 2918 documentation regarding the new ALTO Address Types and their security 2919 considerations has been provided. The provided documentation should 2920 indicate how an address of a registered type is encoded as an 2921 EndpointAddr and, if possible, a compact method (e.g., IPv4 and IPv6 2922 prefixes) for encoding a set of addresses as an EndpointPrefix. 2923 Updates and deletions of ALTO Address Types follow the same 2924 procedure. 2926 Registered ALTO Address Type identifiers MUST conform to the 2927 syntactical requirements specified in Section 9.4.1. Identifiers are 2928 to be recorded and displayed as ASCII strings. 2930 Requests to add a new value to the registry MUST include the 2931 following information: 2933 o Identifier: The name of the desired ALTO Address Type. 2935 o Endpoint Address Encoding: The procedure for encoding an address 2936 of the registered type as an EndpointAddr (see Section 9.4.2). 2938 o Endpoint Prefix Encoding: The procedure for encoding a set of 2939 addresses of the registered type as an EndpointPrefix (see 2940 Section 9.4.3). If no such compact encoding is available, the 2941 same encoding used for a singular address may be used. In such a 2942 case, it must be documented that sets of addresses of this type 2943 always have exactly one element. 2945 o Mapping to/from IPv4/IPv6 Addresses: If possible, a mechanism to 2946 map addresses of the registered type to and from IPv4 or IPv6 2947 addresses should be specified. 2949 o Security Considerations: In some usage scenarios, Endpoint 2950 Addresses carried in ALTO Protocol messages may reveal information 2951 about an ALTO Client or an ALTO Service Provider. Applications 2952 and ALTO Service Providers using addresses of the registered type 2953 should be made aware of how (or if) the addressing scheme relates 2954 to private information and network proximity. 2956 This specification requests registration of the identifiers 'ipv4' 2957 and 'ipv6', as shown in Table 5. 2959 13.5. ALTO Error Code Registry 2961 This document requests the creation of an ALTO Error Code registry, 2962 listed in Table 1, to be maintained by IANA. 2964 14. Security Considerations 2966 Some environments and use cases of ALTO require consideration of 2967 security attacks on ALTO Servers and Clients. In order to support 2968 those environments interoperably, the ALTO requirements document 2969 [RFC6708] outlines minimum-to-implement authentication and other 2970 security requirements. Below we consider the threats and protection 2971 strategies. 2973 14.1. Authenticity and Integrity of ALTO Information 2975 14.1.1. Risk Scenarios 2977 An attacker may want to provide false or modified ALTO Information 2978 Resources or Information Resource Directory to ALTO Clients to 2979 achieve certain malicious goals. As an example, an attacker may 2980 provide false endpoint properties. For example, suppose that a 2981 network supports an endpoint property named "hasQuota" which reports 2982 if the endpoint has usage quota. An attacker may want to generate a 2983 false reply to lead to unexpected charges to the endpoint. An attack 2984 may also want to provide false Cost Map. For example, by faking a 2985 Cost Map that highly prefers a small address range or a single 2986 address, the attacker may be able to turn a distributed application 2987 into a Distributed Denial of Service (DDoS) tool. 2989 Depending on the network scenario, an attacker can attack 2990 authenticity and integrity of ALTO Information Resources using 2991 various techniques, including, but not limited to, sending forged 2992 DHCP replies in an Ethernet, DNS poisoning, and installing a 2993 transparent HTTP proxy that does some modifications. 2995 14.1.2. Protection Strategies 2997 ALTO protects the authenticity and integrity of ALTO Information 2998 (both Information Directory and individual Information Resources) by 2999 leveraging the authenticity and integrity mechanisms in TLS. In 3000 particular, the ALTO Protocol requires that HTTP over TLS [RFC2818] 3001 MUST be supported, when protecting the authenticity and integrity of 3002 ALTO Information is required. The rules in [RFC2818] for a client to 3003 verify server identity using server certificates MUST be supported. 3004 ALTO Providers who request server certificates and certification 3005 authorities who issue ALTO-specific certificates SHOULD consider the 3006 recommendations and guidelines defined in [RFC6125] 3008 Software engineers developing and service providers deploying ALTO 3009 should make themselves familiar with up-to-date Best Current 3010 Practices on configuring HTTP over TLS. 3012 14.1.3. Limitations 3014 The protection of HTTP over TLS for ALTO depends on that the domain 3015 name in the URI for the Information Resources is not comprised. This 3016 will depend on the protection implemented by service discovery. 3018 A deployment scenario may require redistribution of ALTO information 3019 to improve scalability. When authenticity and integrity of ALTO 3020 information are still required, then ALTO Clients obtaining ALTO 3021 information through redistribution must be able to validate the 3022 received ALTO information. Support for this validation is not 3023 provided in this document, but may be provided by extension 3024 documents. 3026 14.2. Potential Undesirable Guidance from Authenticated ALTO 3027 Information 3029 14.2.1. Risk Scenarios 3031 The ALTO Service makes it possible for an ALTO Provider to influence 3032 the behavior of network applications. An ALTO Provider may be 3033 hostile to some applications and hence try to use ALTO Information 3034 Resources to achieve certain goals [RFC5693]: "redirecting 3035 applications to corrupted mediators providing malicious content, or 3036 applying policies in computing Cost Map based on criteria other than 3037 network efficiency." See [I-D.ietf-alto-deployments] for additional 3038 discussions on faked ALTO Guidance. 3040 A related scenario is that an ALTO Server could unintentionally give 3041 "bad" guidance. For example, if many ALTO Clients follow the Cost 3042 Map or Endpoint Cost guidance without doing additional sanity checks 3043 or adaptation, more preferable hosts and/or links could get 3044 overloaded while less preferable ones remain idle; see AR-14 of 3045 [RFC6708] for related application considerations. 3047 14.2.2. Protection Strategies 3049 To protect applications from undesirable ALTO Information Resources, 3050 it is important to note that there is no protocol mechanism to 3051 require conforming behaviors on how applications use ALTO Information 3052 Resources. An application using ALTO may consider including a 3053 mechanism to detect misleading or undesirable results from using ALTO 3054 Information Resources. For example, if throughput measurements do 3055 not show "better-than-random" results when using the Cost Map to 3056 select resource providers, the application may want to disable ALTO 3057 usage or switch to an external ALTO Server provided by an 3058 "independent organization" (see AR-20 and AR-21 in [RFC 6708]). If 3059 the first ALTO Server is provided by the access network service 3060 provider and the access network service provider tries to redirect 3061 access to the external ALTO Server back to the provider's ALTO Server 3062 or try to tamper with the responses, the preceding authentication and 3063 integrity protection can detect such a behavior. 3065 14.3. Confidentiality of ALTO Information 3067 14.3.1. Risk Scenarios 3069 Although in many cases ALTO Information Resources may be regarded as 3070 non-confidential information, there are deployment cases where ALTO 3071 Information Resources can be sensitive information that can pose 3072 risks if exposed to unauthorized parties. We discuss the risks and 3073 protection strategies for such deployment scenarios. 3075 For example, an attacker may infer details regarding the topology, 3076 status, and operational policies of a network through the Network and 3077 Cost Maps. As a result, a sophisticated attacker may be able to 3078 infer more fine-graind topology information than an ISP hosting an 3079 ALTO Server intends to disclose. The attacker can leverage the 3080 information to mount effective attacks such as focusing on high-cost 3081 links. 3083 Revealing some endpoint properties may also reveal additional 3084 information than the Provider intended. For example, when adding the 3085 line bitrate as one endpoint property, such information may be 3086 potentially linked to the income of the habitants at the network 3087 location of an endpoint. 3089 In [RFC6708] Section 5.2.1, three types of risks associated with the 3090 confidentiality of ALTO Information Resources are identified: risk 3091 type (1) Excess disclosure of the ALTO service provider's data to an 3092 authorized ALTO Client; risk type (2) Disclosure of the ALTO service 3093 provider's data (e.g., network topology information) to an 3094 unauthorized third party; and risk type (3) Excess retrieval of the 3095 ALTO service provider's data by collaborating ALTO Clients. Section 3096 10 of [I-D.ietf-alto-deployments] also discusses information leakage 3097 from ALTO. 3099 14.3.2. Protection Strategies 3101 To address risk types (1) and (3), the Provider of an ALTO Server 3102 must be cognizant that the network topology and provisioning 3103 information provided through ALTO may lead to attacks. ALTO does not 3104 require any particular level of details of information disclosure, 3105 and hence the Provider should evaluate how much information is 3106 revealed and the associated risks. 3108 To address risk type (2), the ALTO Protocol need confidentiality. 3109 Since ALTO requires that HTTP over TLS MUST be supported, the 3110 confidentiality mechanism is provided by HTTP over TLS. 3112 For deployment scenarios where client authentication is desired to 3113 address risk type (2), ALTO requires that HTTP Digestion 3114 Authentication MUST be supported to achieve ALTO Client 3115 Authentication to limit the number of parties with whom ALTO 3116 information is directly shared. Depending on the use-case and 3117 scenario, an ALTO Server may apply other access control techniques to 3118 restrict access to its services. Access control can also help to 3119 prevent Denial-of-Service attacks by arbitrary hosts from the 3120 Internet. See [I-D.ietf-alto-deployments] for a more detailed 3121 discussion on this issue. 3123 14.3.3. Limitations 3125 ALTO Information Providers should be cognizant that encryption only 3126 protects ALTO information until it is decrypted by the intended ALTO 3127 Client. Digital Rights Management (DRM) techniques and legal 3128 agreements protecting ALTO information are outside of the scope of 3129 this document. 3131 14.4. Privacy for ALTO Users 3133 14.4.1. Risk Scenarios 3135 The ALTO Protocol provides mechanisms in which the ALTO Client 3136 serving a user can send messages containing Network Location 3137 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server. 3138 This is particularly true for the Endpoint Property, Endpoint Cost, 3139 and fine-grained Filtered Map services. The ALTO Server or a third- 3140 party who is able to intercept such messages can store and process 3141 obtained information in order to analyze user behaviors and 3142 communication patterns. The analysis may correlate information 3143 collected from multiple clients to deduce additional application/ 3144 content information. Such analysis can lead to privacy risks. For a 3145 more comprehensive classification of related risk scenarios, see 3146 cases 4, 5, and 6 in [RFC 6708], Section 5.2. 3148 14.4.2. Protection Strategies 3150 To protect user privacy, an ALTO Client should be cognizant about 3151 potential ALTO Server tracking through client queries. An ALTO 3152 Client may consider the possibility of relying only on Network Map 3153 for PIDs and Cost Map amongst PIDs to avoid passing IP addresses of 3154 other endpoints (e.g., peers) to the ALTO Server. When specific IP 3155 addresses are needed (e.g., when using the Endpoint Cost Service), an 3156 ALTO Client may consider obfuscation techniques such as specifying a 3157 broader address range (i.e., a shorter prefix length) or by zeroing 3158 out or randomizing the last few bits of IP addresses. Note that 3159 obfuscation may yield less accurate results. 3161 14.5. Availability of ALTO Service 3163 14.5.1. Risk Scenarios 3165 An attacker may want to disable ALTO Service as a way to disable 3166 network guidance to large scale applications.In particular, queries 3167 which can be generated with low effort but result in expensive 3168 workloads at the ALTO Server could be exploited for Denial-of-Service 3169 attacks. For instance, a simple ALTO query with n Source Network 3170 Locations and m Destination Network Locations can be generated fairly 3171 easily but results in the computation of n*m Path Costs between pairs 3172 by the ALTO Server (see Section 5.2). 3174 14.5.2. Protection Strategies 3176 ALTO Provider should be cognizant of the workload at the ALTO Server 3177 generated by certain ALTO Queries, such as certain queries to the Map 3178 Service, the Map Filtering Service and the Endpoint Cost (Ranking) 3179 Service. One way to limit Denial-of-Service attacks is to employ 3180 access control to the ALTO Server. The ALTO Server can also indicate 3181 overload and reject repeated requests that can cause availability 3182 problems. More advanced protection schemes such as computational 3183 puzzles [I-D.jennings-sip-hashcash] may be considered in an extension 3184 document. 3186 An ALTO Provider should also leverage the fact that the Map Service 3187 allows ALTO Servers to pre-generate maps that can be distributed to 3188 many ALTO Clients. 3190 15. Manageability Considerations 3192 This section details operations and management considerations based 3193 on existing deployments and discussions during protocol development. 3194 It also indicates where extension documents are expected to provide 3195 appropriate functionality discussed in [RFC5706] as additional 3196 deployment experience becomes available. 3198 15.1. Operations 3199 15.1.1. Installation and Initial Setup 3201 The ALTO Protocol is based on HTTP. Thus, configuring an ALTO Server 3202 may require configuring the underlying HTTP server implementation to 3203 define appropriate security policies, caching policies, performance 3204 settings, etc. 3206 Additionally, an ALTO Service Provider will need to configure the 3207 ALTO information to be provided by the ALTO Server. The granularity 3208 of the topological map and the cost map is left to the specific 3209 policies of the ALTO Service Provider. However, a reasonable default 3210 may include two PIDs, one to hold the endpoints in the provider's 3211 network and the second PID to represent full IPv4 and IPv6 3212 reachability (see Section 5.2.1), with the cost between each source/ 3213 destination PID set to 1. Another operational issue that the ALTO 3214 Service Provider needs to consider is that the filtering service can 3215 degenerate into a full map service when the filtering input is empty. 3216 Although this choice as the degeneration behavior provides 3217 continuity, the operational impact should be considered. 3219 Implementers employing an ALTO Client should attempt to automatically 3220 discover an appropriate ALTO Server. Manual configuration of the 3221 ALTO Server location may be used where automatic discovery is not 3222 appropriate. Methods for automatic discovery and manual 3223 configuration are discussed in [I-D.ietf-alto-server-discovery]. 3225 Specifications for underlying protocols (e.g., TCP, HTTP, SSL/TLS) 3226 should be consulted for their available settings and proposed default 3227 configurations. 3229 15.1.2. Migration Path 3231 This document does not detail a migration path for ALTO Servers since 3232 there is no previous standard protocol providing the similar 3233 functionality. 3235 There are existing applications making use of network information 3236 discovered from other entities such as whois, geo-location databases, 3237 or round-trip time measurements, etc. Such applications should 3238 consider using ALTO as an additional source of information; ALTO need 3239 not be the sole source of network information. 3241 15.1.3. Requirements on Other Protocols and Functional Components 3243 The ALTO Protocol assumes that HTTP client and server implementations 3244 exist. It also assumes that JSON encoder and decoder implementations 3245 exist. 3247 An ALTO Server assumes that it can gather sufficient information to 3248 populate Network and Cost maps. "Sufficient information" is 3249 dependent on the information being exposed, but likely includes 3250 information gathered from protocols such as IGP and EGP Routing 3251 Information Bases (see Figure 1). Specific mechanisms have been 3252 proposed (e.g., [I-D.medved-alto-svr-apis]) and are expected to be 3253 provided in extension documents. 3255 15.1.4. Impact and Observation on Network Operation 3257 ALTO presents a new opportunity for managing network traffic by 3258 providing additional information to clients. The potential impact to 3259 network operation is large. 3261 Deployment of an ALTO Server may shift network traffic patterns. 3262 Thus, an ALTO Service Provider should consider impacts on (or 3263 integration with) traffic engineering and the deployment of a 3264 monitoring service to observe the effects of ALTO operations. Note 3265 that ALTO-specific monitoring and metrics are discussed in 6.3 of 3266 [I-D.ietf-alto-deployments] and future versions of that document. In 3267 particular, an ALTO Service Provider may observe that ALTO Clients 3268 are not bound to ALTO Server guidance as ALTO is only one source of 3269 information. 3271 An ALTO Service Provider should ensure that appropriate information 3272 is being exposed. Privacy implications for ISPs are discussed in 3273 Section 14.3. Both ALTO Service Providers and those using ALTO 3274 Clients should be aware of the impact of incorrect or faked guidance 3275 (see Section 10.3 of [I-D.ietf-alto-deployments] and future versions 3276 of that document). 3278 15.2. Management 3280 15.2.1. Management Interoperability 3282 A common management API would be desirable given that ALTO Servers 3283 may typically be configured with dynamic data from various sources, 3284 and ALTO Servers are intended to scale horizontally for fault- 3285 tolerance and reliability. A specific API or protocol is outside the 3286 scope of this document, but may be provided by an extension document. 3288 Logging is an important functionality for ALTO Servers and, depending 3289 on the deployment, ALTO Clients. Logging should be done via syslog 3290 [RFC5424]. 3292 15.2.2. Management Information 3294 A Management Information Model (see Section 3.2 of [RFC5706] is not 3295 provided by this document, but should be included or referenced by 3296 any extension documenting an ALTO-related management API or protocol. 3298 15.2.3. Fault Management 3300 Monitoring ALTO Servers and Clients is described in Section 6.3 of 3301 [I-D.ietf-alto-deployments] and future versions of that document. 3303 15.2.4. Configuration Management 3305 Standardized approaches and protocols to configuration management for 3306 ALTO are outside the scope of this document, but this document does 3307 outline high-level principles suggested for future standardization 3308 efforts. 3310 An ALTO Server requires at least the following logical inputs: 3312 o Data sources from which ALTO Information is derived. This can 3313 either be raw network information (e.g., from routing elements) or 3314 pre-processed ALTO-level information in the form of a Network Map, 3315 Cost Map, etc. 3317 o Algorithms for computing the ALTO information returned to clients. 3318 These could either return information from a database, or 3319 information customized for each client. 3321 o Security policies mapping potential clients to the information 3322 that they have privilege to access. 3324 Multiple ALTO Servers can be deployed for scalability. A centralized 3325 configuration database may be used to ensure they are providing the 3326 desired ALTO information with appropriate security controls. The 3327 ALTO information (e.g., Network Maps and Cost Maps) being served by 3328 each ALTO Server, as well as security policies (HTTP authentication, 3329 SSL/TLS client and server authentication, SSL/TLS encryption 3330 parameters) intended to serve the same information should be 3331 monitored for consistency. 3333 15.2.5. Performance Management 3335 An exhaustive list of desirable performance information from a ALTO 3336 Servers and ALTO Clients are outside of the scope of this document. 3337 The following is a list of suggested ALTO-specific to be monitored 3338 based on the existing deployment and protocol development experience: 3340 o Requests and responses for each service listed in a Information 3341 Directory (total counts and size in bytes). 3343 o CPU and memory utilization 3345 o ALTO map updates 3347 o Number of PIDs 3349 o ALTO map sizes (in-memory size, encoded size, number of entries) 3351 15.2.6. Security Management 3353 Section 14 documents ALTO-specific security considerations. 3354 Operators should configure security policies with those in mind. 3355 Readers should refer to HTTP [RFC2616] and SSL/TLS [RFC5246] and 3356 related documents for mechanisms available for configuring security 3357 policies. Other appropriate security mechanisms (e.g., physical 3358 security, firewalls, etc) should also be considered. 3360 16. References 3362 16.1. Normative References 3364 [IEEE.754.2008] 3365 Institute of Electrical and Electronics Engineers, 3366 "Standard for Binary Floating-Point Arithmetic", IEEE 3367 Standard 754, August 2008. 3369 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 3370 Extensions (MIME) Part Two: Media Types", RFC 2046, 3371 November 1996. 3373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3374 Requirement Levels", BCP 14, RFC 2119, March 1997. 3376 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3377 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3378 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3380 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3382 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3383 Resource Identifier (URI): Generic Syntax", STD 66, 3384 RFC 3986, January 2005. 3386 [RFC4627] Crockford, D., "The application/json Media Type for 3387 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 3389 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 3390 (CIDR): The Internet Address Assignment and Aggregation 3391 Plan", BCP 122, RFC 4632, August 2006. 3393 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3394 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3395 May 2008. 3397 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3398 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 3400 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3401 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3402 October 2008. 3404 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 3406 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 3407 Optimization (ALTO) Problem Statement", RFC 5693, 3408 October 2009. 3410 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 3411 Address Text Representation", RFC 5952, August 2010. 3413 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3414 Verification of Domain-Based Application Service Identity 3415 within Internet Public Key Infrastructure Using X.509 3416 (PKIX) Certificates in the Context of Transport Layer 3417 Security (TLS)", RFC 6125, March 2011. 3419 [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 3420 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 3421 Requirements", RFC 6708, September 2012. 3423 16.2. Informative References 3425 [BitTorrent] 3426 "Bittorrent Protocol Specification v1.0", 3427 . 3429 [Fielding-Thesis] 3430 Fielding, R., "Architectural Styles and the Design of 3431 Network-based Software Architectures", University of 3432 California, Irvine, Dissertation 2000, 2000. 3434 [I-D.akonjang-alto-proxidor] 3435 Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 3436 Saucez, "The PROXIDOR Service", 3437 draft-akonjang-alto-proxidor-00 (work in progress), 3438 March 2009. 3440 [I-D.ietf-alto-deployments] 3441 Stiemerling, M., Kiesel, S., and S. Previdi, "ALTO 3442 Deployment Considerations", draft-ietf-alto-deployments-06 3443 (work in progress), February 2013. 3445 [I-D.ietf-alto-reqs] 3446 Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, 3447 "Application-Layer Traffic Optimization (ALTO) 3448 Requirements", draft-ietf-alto-reqs-08 (work in progress), 3449 March 2011. 3451 [I-D.ietf-alto-server-discovery] 3452 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 3453 S. Yongchao, "ALTO Server Discovery", 3454 draft-ietf-alto-server-discovery-08 (work in progress), 3455 March 2013. 3457 [I-D.ietf-httpbis-p2-semantics] 3458 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 3459 (HTTP/1.1): Semantics and Content", 3460 draft-ietf-httpbis-p2-semantics-22 (work in progress), 3461 February 2013. 3463 [I-D.jenkins-alto-cdn-use-cases] 3464 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 3465 S. Previdi, "Use Cases for ALTO within CDNs", 3466 draft-jenkins-alto-cdn-use-cases-03 (work in progress), 3467 June 2012. 3469 [I-D.medved-alto-svr-apis] 3470 Medved, J., Ward, D., Peterson, J., Woundy, R., and D. 3471 McDysan, "ALTO Network-Server and Server-Server APIs", 3472 draft-medved-alto-svr-apis-00 (work in progress), 3473 March 2011. 3475 [I-D.mrw-nat66] 3476 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 3477 Translation", draft-mrw-nat66-16 (work in progress), 3478 April 2011. 3480 [I-D.p4p-framework] 3481 Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, 3482 "P4P: Provider Portal for P2P Applications", 3483 draft-p4p-framework-00 (work in progress), November 2008. 3485 [I-D.saumitra-alto-multi-ps] 3486 Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 3487 Dimensional Peer Selection Problem", 3488 draft-saumitra-alto-multi-ps-00 (work in progress), 3489 October 2008. 3491 [I-D.saumitra-alto-queryresponse] 3492 Das, S. and V. Narayanan, "A Client to Service Query 3493 Response Protocol for ALTO", 3494 draft-saumitra-alto-queryresponse-00 (work in progress), 3495 March 2009. 3497 [I-D.shalunov-alto-infoexport] 3498 Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 3499 Export Service", draft-shalunov-alto-infoexport-00 (work 3500 in progress), October 2008. 3502 [I-D.wang-alto-p4p-specification] 3503 Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, 3504 "P4P Protocol Specification", 3505 draft-wang-alto-p4p-specification-00 (work in progress), 3506 March 2009. 3508 [P4P-SIGCOMM08] 3509 Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A. 3510 Silberschatz, "P4P: Provider Portal for (P2P) 3511 Applications", SIGCOMM 2008, August 2008. 3513 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 3514 Management of New Protocols and Protocol Extensions", 3515 RFC 5706, November 2009. 3517 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 3518 IPv4/IPv6 Translation", RFC 6144, April 2011. 3520 Appendix A. Acknowledgments 3522 Thank you to Sebastian Kiesel (University of Stuttgart) and Jan 3523 Seedorf (NEC) for substantial contributions to the Security 3524 Considerations section. Ben Niven-Jenkins (Velocix), Wendy Roome, 3525 Michael Scharf and Sabine Randriamasy (Alcatel-Lucent) gave 3526 substantial feedback and suggestions on the protocol design. 3528 We would like to thank the following people whose input and 3529 involvement was indispensable in achieving this merged proposal: 3531 Obi Akonjang (DT Labs/TU Berlin), 3533 Saumitra M. Das (Qualcomm Inc.), 3535 Syon Ding (China Telecom), 3537 Doug Pasko (Verizon), 3539 Laird Popkin (Pando Networks), 3541 Satish Raghunath (Juniper Networks), 3543 Albert Tian (Ericsson/Redback), 3545 Yu-Shun Wang (Microsoft), 3547 David Zhang (PPLive), 3549 Yunfei Zhang (China Mobile). 3551 We would also like to thank the following additional people who were 3552 involved in the projects that contributed to this merged document: 3553 Alex Gerber (ATT), Chris Griffiths (Comcast), Ramit Hora (Pando 3554 Networks), Arvind Krishnamurthy (University of Washington), Marty 3555 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 3556 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (ATT), 3557 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 3558 Damien Saucez (UCL) Thomas Scholl (ATT), Emilio Sepulveda 3559 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 3560 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 3561 (Huawei), Oliver Spatscheck (ATT), See-Mong Tang (Microsoft), Jia 3562 Wang (ATT), Hao Wang (Yale University), Ye Wang (Yale University), 3563 Haiyong Xie (Yale University). 3565 Appendix B. Design History and Merged Proposals 3567 The ALTO Protocol specified in this document consists of 3568 contributions from 3570 o P4P [I-D.p4p-framework], [P4P-SIGCOMM08], 3571 [I-D.wang-alto-p4p-specification]; 3573 o ALTO Info-Export [I-D.shalunov-alto-infoexport]; 3575 o Query/Response [I-D.saumitra-alto-queryresponse], 3576 [I-D.saumitra-alto-multi-ps]; 3578 o ATTP [ATTP]; and 3580 o Proxidor [I-D.akonjang-alto-proxidor]. 3582 Appendix C. Authors 3584 [[CmtAuthors: RFC Editor: Please move information in this section to 3585 the Authors' Addresses section at publication time.]] 3587 Stefano Previdi 3588 Cisco 3590 Email: sprevidi@cisco.com 3592 Stanislav Shalunov 3593 BitTorrent 3595 Email: shalunov@bittorrent.com 3597 Richard Woundy 3598 Comcast 3600 Richard_Woundy@cable.comcast.com 3602 Authors' Addresses 3604 Richard Alimi (editor) 3605 Google 3606 1600 Amphitheatre Parkway 3607 Mountain View CA 3608 USA 3610 Email: ralimi@google.com 3612 Reinaldo Penno (editor) 3613 Cisco Systems 3614 170 West Tasman Dr 3615 San Jose CA 3616 USA 3618 Email: repenno@cisco.com 3619 Y. Richard Yang (editor) 3620 Yale University 3621 51 Prospect St 3622 New Haven CT 3623 USA 3625 Email: yry@cs.yale.edu