idnits 2.17.1 draft-ietf-alto-protocol-20.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 1055 has weird spacing: '... meta meta-...' == Line 1302 has weird spacing: '...ilities capa...' == Line 1793 has weird spacing: '...ostMode cost...' == Line 2217 has weird spacing: '...ostType cost...' == Line 2219 has weird spacing: '...DFilter pids;...' == (2 more instances...) -- The document date (October 2, 2013) is 3856 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 3290, but not defined == Missing Reference: 'I-D.jennings-sip-hashcash' is mentioned on line 3327, but not defined == Missing Reference: 'ATTP' is mentioned on line 3717, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.2008' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 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-07 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-24 Summary: 9 errors (**), 0 flaws (~~), 12 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: April 5, 2014 Cisco Systems 6 Y. Yang, Ed. 7 Yale University 8 October 2, 2013 10 ALTO Protocol 11 draft-ietf-alto-protocol-20.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 network 19 application clients. What is missing is knowledge of the underlying 20 network topologies from the point of view of ISPs. In other words, 21 what an 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 April 5, 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 . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . 17 108 6.2. Cost Map Structure . . . . . . . . . . . . . . . . . . . . 18 109 6.3. Network Map and Cost Map Dependency . . . . . . . . . . . 18 110 6.4. Cost Map Update . . . . . . . . . . . . . . . . . . . . . 19 111 7. Endpoint Properties . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . . . 20 117 8.3. Basic Operations . . . . . . . . . . . . . . . . . . . . . 21 118 8.3.1. Client Discovering Information Resources . . . . . . . 21 119 8.3.2. Client Requesting Information Resources . . . . . . . 21 120 8.3.3. Server Responding to IR Request . . . . . . . . . . . 22 121 8.3.4. Client Handling Server Response . . . . . . . . . . . 22 122 8.3.5. Authentication and Encryption . . . . . . . . . . . . 23 123 8.3.6. Information Refreshing . . . . . . . . . . . . . . . . 23 124 8.3.7. HTTP Cookies . . . . . . . . . . . . . . . . . . . . . 23 125 8.3.8. Parsing of Unknown Fields . . . . . . . . . . . . . . 24 127 8.4. Server Response Encoding . . . . . . . . . . . . . . . . . 24 128 8.4.1. Meta Information . . . . . . . . . . . . . . . . . . . 24 129 8.4.2. Data Information . . . . . . . . . . . . . . . . . . . 24 130 8.5. Protocol Errors . . . . . . . . . . . . . . . . . . . . . 25 131 8.5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 25 132 8.5.2. Response Format and Error Codes . . . . . . . . . . . 25 133 8.5.3. Overload Conditions and Server Unavailability . . . . 26 134 9. Protocol Specification: Information Resource Directory . . . . 27 135 9.1. Information Resource Attributes . . . . . . . . . . . . . 27 136 9.1.1. Resource ID . . . . . . . . . . . . . . . . . . . . . 27 137 9.1.2. Media Type . . . . . . . . . . . . . . . . . . . . . . 27 138 9.1.3. Capabilities . . . . . . . . . . . . . . . . . . . . . 28 139 9.1.4. Accepts Input Parameters . . . . . . . . . . . . . . . 28 140 9.1.5. Dependent Resources . . . . . . . . . . . . . . . . . 28 141 9.2. Information Resource Directory (IRD) . . . . . . . . . . . 28 142 9.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 28 143 9.2.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . 29 144 9.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 31 145 9.2.4. Delegation using IRD . . . . . . . . . . . . . . . . . 33 146 9.2.5. Considerations of Using IRD . . . . . . . . . . . . . 35 147 10. Protocol Specification: Basic Data Types . . . . . . . . . . . 36 148 10.1. PID Name . . . . . . . . . . . . . . . . . . . . . . . . . 36 149 10.2. Resource ID . . . . . . . . . . . . . . . . . . . . . . . 36 150 10.3. Version Tag . . . . . . . . . . . . . . . . . . . . . . . 36 151 10.4. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 37 152 10.4.1. Address Type . . . . . . . . . . . . . . . . . . . . . 37 153 10.4.2. Endpoint Address . . . . . . . . . . . . . . . . . . . 37 154 10.4.3. Endpoint Prefixes . . . . . . . . . . . . . . . . . . 38 155 10.4.4. Endpoint Address Group . . . . . . . . . . . . . . . . 38 156 10.5. Cost Mode . . . . . . . . . . . . . . . . . . . . . . . . 39 157 10.6. Cost Metric . . . . . . . . . . . . . . . . . . . . . . . 39 158 10.7. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . 40 159 10.8. Endpoint Property . . . . . . . . . . . . . . . . . . . . 40 160 10.8.1. Resource Specific Endpoint Properties . . . . . . . . 40 161 10.8.2. Global Endpoint Properties . . . . . . . . . . . . . . 41 162 11. Protocol Specification: Service Information Resources . . . . 41 163 11.1. Meta Information . . . . . . . . . . . . . . . . . . . . . 41 164 11.2. Map Service . . . . . . . . . . . . . . . . . . . . . . . 41 165 11.2.1. Network Map . . . . . . . . . . . . . . . . . . . . . 41 166 11.2.2. Cost Map . . . . . . . . . . . . . . . . . . . . . . . 44 167 11.3. Map Filtering Service . . . . . . . . . . . . . . . . . . 46 168 11.3.1. Filtered Network Map . . . . . . . . . . . . . . . . . 47 169 11.3.2. Filtered Cost Map . . . . . . . . . . . . . . . . . . 49 170 11.4. Endpoint Property Service . . . . . . . . . . . . . . . . 53 171 11.4.1. Endpoint Property . . . . . . . . . . . . . . . . . . 54 172 11.5. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 57 173 11.5.1. Endpoint Cost . . . . . . . . . . . . . . . . . . . . 57 174 12. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 60 175 12.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 61 176 12.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 62 177 12.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 63 178 13. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 64 179 13.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 64 180 13.2. Hosts with Multiple Endpoint Addresses . . . . . . . . . . 65 181 13.3. Network Address Translation Considerations . . . . . . . . 65 182 13.4. Endpoint and Path Properties . . . . . . . . . . . . . . . 66 183 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 184 14.1. application/alto-* Media Types . . . . . . . . . . . . . . 66 185 14.2. ALTO Cost Metric Registry . . . . . . . . . . . . . . . . 67 186 14.3. ALTO Endpoint Property Type Registry . . . . . . . . . . . 69 187 14.4. ALTO Address Type Registry . . . . . . . . . . . . . . . . 69 188 14.5. ALTO Error Code Registry . . . . . . . . . . . . . . . . . 70 189 15. Security Considerations . . . . . . . . . . . . . . . . . . . 71 190 15.1. Authenticity and Integrity of ALTO Information . . . . . . 71 191 15.1.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 71 192 15.1.2. Protection Strategies . . . . . . . . . . . . . . . . 71 193 15.1.3. Limitations . . . . . . . . . . . . . . . . . . . . . 72 194 15.2. Potential Undesirable Guidance from Authenticated ALTO 195 Information . . . . . . . . . . . . . . . . . . . . . . . 72 196 15.2.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 72 197 15.2.2. Protection Strategies . . . . . . . . . . . . . . . . 72 198 15.3. Confidentiality of ALTO Information . . . . . . . . . . . 73 199 15.3.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 73 200 15.3.2. Protection Strategies . . . . . . . . . . . . . . . . 73 201 15.3.3. Limitations . . . . . . . . . . . . . . . . . . . . . 74 202 15.4. Privacy for ALTO Users . . . . . . . . . . . . . . . . . . 74 203 15.4.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 74 204 15.4.2. Protection Strategies . . . . . . . . . . . . . . . . 74 205 15.5. Availability of ALTO Service . . . . . . . . . . . . . . . 75 206 15.5.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 75 207 15.5.2. Protection Strategies . . . . . . . . . . . . . . . . 75 208 16. Manageability Considerations . . . . . . . . . . . . . . . . . 75 209 16.1. Operations . . . . . . . . . . . . . . . . . . . . . . . . 75 210 16.1.1. Installation and Initial Setup . . . . . . . . . . . . 76 211 16.1.2. Migration Path . . . . . . . . . . . . . . . . . . . . 76 212 16.1.3. Requirements on Other Protocols and Functional 213 Components . . . . . . . . . . . . . . . . . . . . . . 76 214 16.1.4. Impact and Observation on Network Operation . . . . . 77 215 16.2. Management . . . . . . . . . . . . . . . . . . . . . . . . 77 216 16.2.1. Management Interoperability . . . . . . . . . . . . . 77 217 16.2.2. Management Information . . . . . . . . . . . . . . . . 78 218 16.2.3. Fault Management . . . . . . . . . . . . . . . . . . . 78 219 16.2.4. Configuration Management . . . . . . . . . . . . . . . 78 220 16.2.5. Performance Management . . . . . . . . . . . . . . . . 78 221 16.2.6. Security Management . . . . . . . . . . . . . . . . . 79 222 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 223 17.1. Normative References . . . . . . . . . . . . . . . . . . . 79 224 17.2. Informative References . . . . . . . . . . . . . . . . . . 80 225 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 82 226 Appendix B. Design History and Merged Proposals . . . . . . . . . 83 227 Appendix C. Authors . . . . . . . . . . . . . . . . . . . . . . . 84 228 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84 230 1. Introduction 232 1.1. Problem Statement 234 This document defines the ALTO Protocol, which provides a solution 235 for the problem stated in [RFC5693]. Specifically, in today's 236 networks, network information such as network topologies, link 237 availability, routing policies, and path costs are hidden from the 238 application layer, and many applications benefited from such hiding 239 of network complexity. However, new applications, such as 240 application-layer overlays, can benefit from information about the 241 underlying network infrastructure. In particular, these modern 242 network applications can be adaptive, and hence become more network- 243 efficient (e.g., reduce network resource consumption) and achieve 244 better application performance (e.g., accelerated download rate), by 245 leveraging network-provided information. 247 At a high level, the ALTO Protocol specified in this document is a 248 unidirectional interface that allows a network to publish its network 249 information such as network locations, costs between them at 250 configurable granularities, and endhost properties to network 251 applications. The information published by the ALTO Protocol should 252 benefit both the network and the applications (i.e., the consumers of 253 the information). Either the operator of the network or a third- 254 party (e.g., an information aggregator) can retrieve or derive 255 related information of the network and publish it using the ALTO 256 Protocol. When a network provides information through the ALTO 257 Protocol, we say that the network provides the ALTO Service. 259 To better understand the goal of the ALTO Protocol, we provide a 260 short, non-normative overview of the benefits of ALTO to both 261 networks and applications: 263 o A network that provides an ALTO Service can achieve better 264 utilization of its networking infrastructure. For example, by 265 using ALTO as a tool to interact with applications, a network is 266 able to provide network information to applications so that the 267 applications can better manage traffic on more expensive or 268 difficult-to-provision links such as long distance, transit or 269 backup links. During the interaction, the network can choose to 270 protect its sensitive and confidential network state information, 271 by abstracting real metric values into non-real numerical scores 272 or ordinal ranking. 274 o An application that uses an ALTO Service can benefit from better 275 knowledge of the network to avoid network bottlenecks. For 276 example, an overlay application can use information provided by 277 the ALTO Service to avoid selecting peers connected via high-delay 278 links (e.g., some intercontinental links). Using ALTO to 279 initialize each node with promising ("better-than-random") peers, 280 an adaptive peer-to-peer overlay may achieve faster, better 281 convergence. 283 1.2. Design Overview 285 The ALTO Protocol specified in this document meets the ALTO 286 requirements specified in [RFC5693], and unifies multiple protocols 287 previously designed with similar intentions. See Appendix A for a 288 list of people and Appendix B for a list of proposals that have made 289 significant contributions to this effort. 291 The ALTO Protocol uses a REST-ful design [Fielding-Thesis], and 292 encodes its requests and responses using JSON [RFC4627]. These 293 designs are chosen because of their flexibility and extensibility. 294 In addition, these designs make it possible for ALTO to be deployed 295 at scale by leveraging existing HTTP [RFC2616] implementations, 296 infrastructures and deployment experience. 298 2. Terminology 300 We use the following terms defined in [RFC5693]: Application, Overlay 301 Network, Peer, Resource, Resource Identifier, Resource Provider, 302 Resource Consumer, Resource Directory, Transport Address, Host 303 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 304 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 305 Transit Traffic. 307 We also use the following additional terms: Endpoint Address, Network 308 Location, ALTO Information, ALTO Information Base, and ALTO Service. 310 2.1. Endpoint 312 An Endpoint is an application or host that is capable of 313 communicating (sending and/or receiving messages) on a network. 315 An Endpoint is typically either a Resource Provider or Resource 316 Consumer. 318 2.2. Endpoint Address 320 An Endpoint Address represents the communication address of an 321 endpoint. Common forms of Endpoint Addresses include IP address, MAC 322 address, overlay ID, and phone number. An Endpoint Address can be 323 network-attachment based (e.g., IP address) or network-attachment 324 agnostic (e.g., MAC address). 326 Each Endpoint Address has an associated Address Type, which indicates 327 both its syntax and semantics. 329 2.3. Network Location 331 Network Location is a generic term denoting a single Endpoint or a 332 group of Endpoints. For instance, it can be a single IPv4 or IPv6 333 address, an IPv4 or IPv6 prefix, or a set of prefixes. 335 2.4. ALTO Information 337 ALTO Information is a generic term referring to the network 338 information sent by an ALTO Server. 340 2.5. ALTO Information Base 342 We use the term ALTO Information Base to refer to the internal 343 representation of ALTO Information maintained by an ALTO Server. 344 Note that the structure of this internal representation is not 345 defined by this document. 347 2.6. ALTO Service 349 A network that provides ALTO Information through the ALTO Protocol is 350 said to provide the ALTO Service. 352 3. Architecture 354 We now define the ALTO architecture and the ALTO Protocol's place in 355 the overall architecture. 357 3.1. ALTO Service and Protocol Scope 359 Each network region in the global Internet can provide its ALTO 360 Service, which conveys network information from the perspective of 361 that network region. A network region in this context can be an 362 Autonomous System (AS), an ISP, a region smaller than an AS or ISP, 363 or a set of ISPs. The specific network region that an ALTO Service 364 represents will depend on the ALTO deployment scenario and ALTO 365 service discovery mechanism. 367 The ALTO Service specified in this document defines network Endpoints 368 (and aggregations thereof) and generic costs amongst them from the 369 region's perspective. The network Endpoints may include all 370 Endpoints in the global Internet. Hence, we say that the network 371 information provided by the ALTO Service of a network region 372 represents the "my-Internet view" of the network region. One may 373 note that the "my-Internet view" defined in this document does not 374 specify the internal topology of a network, and hence, we say that it 375 provides a "single-switch" abstraction. Extensions to this document 376 may provide topology details in "my-Internet view". 378 To better understand the ALTO Service and the role of the ALTO 379 Protocol, we show in Figure 1 the overall ALTO system architecture. 380 In this architecture, an ALTO Server prepares ALTO Information; an 381 ALTO Client uses ALTO Service Discovery to identify an appropriate 382 ALTO Server; and the ALTO Client requests available ALTO Information 383 from the ALTO Server using the ALTO Protocol. 385 The ALTO Information provided by the ALTO Server can be updated 386 dynamically based on network conditions, or can be seen as a policy 387 which is updated at a larger time-scale. 389 +-------------------------------------------------------------------+ 390 | Network Region | 391 | | 392 | +-----------+ | 393 | | Routing | | 394 | +--------------+ | Protocols | | 395 | | Provisioning | +-----------+ | 396 | | Policy | | | 397 | +--------------+\ | | 398 | \ | | 399 | \ | | 400 | +-----------+ \+---------+ +--------+ | 401 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 402 | |Network |.......| Server | ==================== | Client | | 403 | |Information| +---------+ +--------+ | 404 | +-----------+ / / | 405 | / ALTO SD Query/Response / | 406 | / / | 407 | +----------+ +----------------+ | 408 | | External | | ALTO Service | | 409 | | Interface| | Discovery (SD) | | 410 | +----------+ +----------------+ | 411 | | | 412 +-------------------------------------------------------------------+ 413 | 414 +------------------+ 415 | Third Parties | 416 | | 417 | Content Providers| 418 +------------------+ 420 Figure 1: Basic ALTO Architecture. 422 Figure 1 illustrates that the ALTO Information provided by an ALTO 423 Server may be influenced (at the service provider's discretion) by 424 other systems. In particular, the ALTO Server can aggregate 425 information from multiple systems to provide an abstract and unified 426 view that can be more useful to applications. Examples of other 427 systems include (but are not limited to) static network configuration 428 databases, dynamic network information, routing protocols, 429 provisioning policies, and interfaces to outside parties. These 430 components are shown in the figure for completeness but are outside 431 the scope of this specification. Recall that while the ALTO Protocol 432 may convey dynamic network information, it is not intended to replace 433 near-real-time congestion control protocols. 435 It may also be possible for an ALTO Server to exchange network 436 information with other ALTO Servers (either within the same 437 administrative domain or another administrative domain with the 438 consent of both parties) in order to adjust exported ALTO 439 Information. Such a protocol is also outside the scope of this 440 specification. 442 3.2. ALTO Information Reuse and Redistribution 444 ALTO Information may be useful to a large number of applications and 445 users. At the same time, distributing ALTO Information must be 446 efficient and not become a bottleneck. 448 The design of the ALTO Protocol allows integration with the existing 449 HTTP caching infrastructure to redistribute ALTO Information. If 450 caching or redistribution is used, the response message to an ALTO 451 Client may be returned from a third-party. 453 Application-dependent mechanisms, such as P2P DHTs or P2P file- 454 sharing, may be used to cache and redistribute ALTO Information. 455 This document does not define particular mechanisms for such 456 redistribution. 458 Additional protocol mechanisms (e.g., expiration times and digital 459 signatures for returned ALTO information) are left for future 460 investigation. 462 4. ALTO Information Service Framework 464 The ALTO Protocol conveys network information through services, where 465 each service defines a set of related functionalities. An ALTO 466 Client can request each service individually. All of the services 467 defined in ALTO are said to form the ALTO service framework and are 468 provided through a common transport protocol, messaging structure and 469 encoding, and transaction model. Functionalities offered in 470 different services can overlap. 472 The goals of the services defined in this document are to convey (1) 473 Network Locations, which denote the locations of Endpoints at a 474 network, (2) provider-defined costs for paths between pairs of 475 Network Locations, and (3) network related properties of endhosts. 476 The aforementioned goals are achieved by defining the Map Service, 477 which provides the core ALTO information to clients, and three 478 additional services: the Map Filtering Service, Endpoint Property 479 Service, and Endpoint Cost Service. Additional services can be 480 defined in companion documents. Below we give an overview of the 481 services. Details of the services will be presented in the following 482 sections. 484 .-----------------------------------------. 485 | ALTO Information Services | 486 | .-----------. .----------. .----------. | 487 | | Map | | Endpoint | | Endpoint | | 488 | | Filtering | | Property | | Cost | | 489 | | Service | | Service | | Service | | 490 | `-----------' `----------' `----------' | 491 | .-------------------------------------. | 492 | | Map Service | | 493 | | .-------------. .--------------. | | 494 | | | Network Map | | Cost Map | | | 495 | | `-------------' `--------------' | | 496 | `-------------------------------------' | 497 `-----------------------------------------' 499 Figure 2: ALTO Service Framework. 501 4.1. ALTO Information Services 503 4.1.1. Map Service 505 The Map Service provides batch information to ALTO Clients in the 506 form of Network Map and Cost Map. A Network Map (See Section 5) 507 provides a full set of Network Location groupings defined by the ALTO 508 Server and the Endpoints contained within each grouping. A Cost Map 509 (see Section 6) provides costs between a defined groupings. 511 These two maps can be thought of (and implemented as) as simple files 512 with appropriate encoding provided by the ALTO Server. 514 4.1.2. Map Filtering Service 516 Resource constrained ALTO Clients may benefit from filtering of query 517 results at the ALTO Server. This avoids that an ALTO Client first 518 spends network bandwidth and CPU cycles to collect results and then 519 performs client-side filtering. The Map Filtering Service allows 520 ALTO Clients to query an ALTO Server on Network Map and Cost Map 521 based on additional parameters. 523 4.1.3. Endpoint Property Service 525 This service allows ALTO Clients to look up properties for individual 526 Endpoints. An example property of an Endpoint is its Network 527 Location (i.e., its grouping defined by the ALTO Server). Another 528 example property is its connectivity type such as ADSL (Asymmetric 529 Digital Subscriber Line), Cable, or FTTH (Fiber To The Home). 531 4.1.4. Endpoint Cost Service 533 Some ALTO Clients may also benefit from querying for costs and 534 rankings based on Endpoints. The Endpoint Cost Service allows an 535 ALTO Server to return either numerical costs or ordinal costs 536 (rankings) directly amongst Endpoints. 538 5. Network Map 540 An ALTO Network Map defines a grouping of network endpoints. In this 541 document, we use Network Map to refer to the syntax and semantics of 542 how an ALTO Server distributes the grouping. This document does not 543 discuss the internal representation of this data structure within the 544 ALTO Server. 546 The definition of Network Map is based on the observation that in 547 reality, many endpoints are close by to one another in terms of 548 network connectivity. By treating a group of close-by endpoints 549 together as a single entity, an ALTO Server indicates aggregation of 550 these endpoints due to their proximity. This aggregation can also 551 lead to greater scalability without losing critical information when 552 conveying other network information (e.g., when defining Cost Map). 554 5.1. Provider-defined Identifier (PID) 556 One issue is that proximity varies depending on the granularity of 557 the ALTO information configured by the provider. In one deployment, 558 endpoints on the same subnet may be considered close; while in 559 another deployment, endpoints connected to the same Point of Presence 560 (PoP) may be considered close. 562 ALTO introduces provider-defined Network Location identifiers called 563 Provider-defined Identifiers (PIDs) to provide an indirect and 564 network-agnostic way to specify an aggregation of network endpoints 565 that may be treated similarly, based on network topology, type, or 566 other properties. Specifically, a PID is a US-ASCII string of type 567 PIDName (see Section 10.1) and its associated set of Endpoint 568 Addresses. As we discussed above, there can be many different ways 569 of grouping the endpoints and assigning PIDs. For example, a PID may 570 denote a subnet, a set of subnets, a metropolitan area, a PoP, an 571 autonomous system, or a set of autonomous systems. Interpreting the 572 PIDs defined in a Network Map using the "single-switch" abstraction, 573 one can consider that each PID represents an abstract port (PoP) that 574 connects a set of endpoints. 576 A key use case of PIDs is to specify network preferences (costs) 577 between PIDs instead of individual endpoints. This allows cost 578 information to be more compactly represented and updated at a faster 579 time scale than the network aggregations themselves. For example, an 580 ISP may prefer that endpoints associated with the same PoP (Point-of- 581 Presence) in a P2P application communicate locally instead of 582 communicating with endpoints in other PoPs. The ISP may aggregate 583 endhosts within a PoP into a single PID in the Network Map. The cost 584 may be encoded to indicate that Network Locations within the same PID 585 are preferred; for example, cost(PID_i, PID_i) == c and cost(PID_i, 586 PID_j) > c for i != j. Section 6 provides further details on using 587 PIDs to represent costs in an ALTO Cost Map. 589 5.2. Endpoint Addresses 591 The endpoints aggregated into a PID are denoted by endpoint 592 addresses. There are many types of addresses, such as IP addresses, 593 MAC addresses, or overlay IDs. This specification only considers IP 594 addresses. 596 5.2.1. IP Addresses 598 When either an ALTO Client or an ALTO Server needs to determine which 599 PID in a Network Map contains a particular IP address, longest-prefix 600 matching MUST be used. 602 A Network Map MUST define a PID for each possible address in the IP 603 address space for all of the address types contained in the map. A 604 RECOMMENDED way to satisfy this property is to define a PID with the 605 shortest enclosing prefix of the addresses provided in the map. For 606 a map with full IPv4 reachability, this would mean including the 607 0.0.0.0/0 prefix in a PID; for full IPv6 reachability, this would be 608 the ::/0 prefix. 610 Each endpoint MUST map into exactly one PID. Since longest-prefix 611 matching is used to map an endpoint to a PID, this can be 612 accomplished by ensuring that no two PIDs contain an identical IP 613 prefix. 615 5.3. Example Network Map 617 Figure 3 illustrates an example Network Map. PIDs are used to 618 identify network-agnostic aggregations. 620 .-----------------------------------------------------------. 621 | An ALTO Network Map | 622 | | 623 | .-----------------------------------. .---------------. | 624 | | NetLoc: PID-1 | | NetLoc: PID-2 | | 625 | | .------------------------------. | | ... | | 626 | | | 192.0.2.0/24 | | `---------------` | 627 | | | .--------------------------. | | | 628 | | | | Endpoint: 192.0.2.34 | | | .---------------. | 629 | | | `--------------------------` | | | NetLoc: PID-3 | | 630 | | `------------------------------` | | ... | | 631 | | .------------------------------. | `---------------` | 632 | | | 198.51.100.0/25 | | | 633 | | | .--------------------------. | | .---------------. | 634 | | | | Endpoint: 198.51.100.100 | | | | NetLoc: PID-4 | | 635 | | | `--------------------------` | | | ... | | 636 | | `------------------------------` | `---------------` | 637 | `-----------------------------------` | 638 | | 639 `-----------------------------------------------------------` 641 Figure 3: Example Network Map. 643 6. Cost Map 645 An ALTO Server indicates preferences amongst network locations in the 646 form of Path Costs. Path Costs are generic costs and can be 647 internally computed by a network provider according to its own 648 policy. 650 For a given Network Map, an ALTO Cost Map defines Path Costs pairwise 651 amongst sets of source and destination Network Locations defined by 652 PIDs defined in the Network Map. Each Path Cost is the end-to-end 653 cost when a unit of traffic goes from the source to the destination. 655 Since cost is directional from the source to the destination, an 656 application, when using ALTO Information, may independently determine 657 how the Resource Consumer and Resource Provider are designated as the 658 source or destination in an ALTO query, and hence how to utilize the 659 Path Cost provided by ALTO Information. For example, if the cost is 660 expected to be correlated with throughput, a typical application 661 concerned with bulk data retrieval may use the Resource Provider as 662 the source, and Resource Consumer as the destination. 664 One advantage of separating ALTO information into a Network Map and a 665 Cost Map is that the two components can be updated at different time 666 scales. For example, Network Maps may be stable for a longer time 667 while Cost Maps may be updated to reflect dynamic network conditions. 669 As used in this document, a Cost Map refers to the syntax and 670 semantics of the information distributed by the ALTO Server. This 671 document does not discuss the internal representation of this data 672 structure within the ALTO Server. 674 6.1. Cost Types 676 Path Costs have attributes: 678 o Metric: identifies what the costs represent; 680 o Mode: identifies how the costs should be interpreted. 682 The combination of a metric and a mode defines a Cost Type. Certain 683 queries for Cost Maps allow the ALTO Client to indicate the desired 684 Cost Type. For a given ALTO Server, the combination of Cost Type and 685 Network Map defines a key. In other words, an ALTO Server MUST NOT 686 define two Cost Maps with the same Cost Type, Network Map pair. 688 6.1.1. Cost Metric 690 The Metric attribute indicates what the cost represents. For 691 example, an ALTO Server could define costs representing air-miles, 692 hop-counts, or generic routing costs. 694 Cost metrics are indicated in protocol messages as strings. 696 6.1.1.1. Cost Metric: routingcost 698 An ALTO Server MUST offer the 'routingcost' Cost Metric. 700 This Cost Metric conveys a generic measure for the cost of routing 701 traffic from a source to a destination. A lower value indicates a 702 higher preference for traffic to be sent from a source to a 703 destination. 705 Note that an ISP may internally compute routing cost using any method 706 that it chooses (e.g., air-miles or hop-count) as long as it conforms 707 to these semantics. 709 6.1.2. Cost Mode 711 The Mode attribute indicates how costs should be interpreted. 712 Specifically, the Mode attribute indicates whether returned costs 713 should be interpreted as numerical values or ordinal rankings. 715 It is important to communicate such information to ALTO Clients, as 716 certain operations may not be valid on certain costs returned by an 717 ALTO Server. For example, it is possible for an ALTO Server to 718 return a set of IP addresses with costs indicating a ranking of the 719 IP addresses. Arithmetic operations that would make sense for 720 numerical values, do not make sense for ordinal rankings. ALTO 721 Clients may handle such costs differently. 723 Cost Modes are indicated in protocol messages as strings. 725 An ALTO Server MUST support at least one of 'numerical' and 'ordinal' 726 modes. An ALTO Client SHOULD be cognizant of operations when a 727 desired Cost Mode is not supported. For example, an ALTO Client 728 desiring numerical costs may adjust its behaviors if only the ordinal 729 Cost Mode is available. Alternatively, an ALTO Client desiring 730 ordinal costs may construct ordinal costs from retrieved numerical 731 values, if only the numerical Cost Mode is available. 733 6.1.2.1. Cost Mode: numerical 735 This Cost Mode is indicated by the string 'numerical'. This mode 736 indicates that it is safe to perform numerical operations (e.g. 737 normalization or computing ratios for weighted load-balancing) on the 738 returned costs. The values are floating-point numbers. 740 6.1.2.2. Cost Mode: ordinal 742 This Cost Mode is indicated by the string 'ordinal'. This mode 743 indicates that the costs values in a Cost Map are a ranking (relative 744 to all other values in a Cost Map), with a lower value indicating a 745 higher preference. The values are non-negative integers. Ordinal 746 cost values in a Cost Map need not be unique nor contiguous. In 747 particular, it is possible that two entries in a map have an 748 identical rank (ordinal cost value). This document does not specify 749 any behavior by an ALTO Client in this case; an ALTO Client may 750 decide to break ties by random selection, other application 751 knowledge, or some other means. 753 It is important to note that the values in the Cost Map provided with 754 the ordinal Cost Mode are not necessarily the actual costs known to 755 the ALTO Server. 757 6.2. Cost Map Structure 759 A request for a Cost Map either explicitly or implicitly includes a 760 list of Source Network Locations and a list of Destination Network 761 Locations. (Recall that a Network Location can be an endpoint 762 address or a PID.) 764 Specifically, assume that a request specifies a list of multiple 765 Source Network Locations, say [Src_1, Src_2, ..., Src_m], and a list 766 of multiple Destination Network Locations, say [Dst_1, Dst_2, ..., 767 Dst_n]. 769 The ALTO Server will return the Path Cost for each of the m*n 770 communicating pairs (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., 771 Src_m -> Dst_1, ..., Src_m -> Dst_n). If the ALTO Server does not 772 define a Path Cost for a particular pair, it may be omitted. We 773 refer to this structure as a Cost Map. 775 If the Cost Mode is 'ordinal', the Path Cost of each communicating 776 pair is relative to the m*n entries. 778 6.3. Network Map and Cost Map Dependency 780 If a Cost Map contains PIDs in the list of Source Network Locations 781 or the list of Destination Network Locations, the Path Costs are 782 generated based on a particular Network Map (which defines the PIDs). 783 Version Tags are introduced to ensure that ALTO Clients are able to 784 use consistent information even though the information is provided in 785 two maps. 787 A Version Tag is a tuple of (1) an ID for the resource (e.g., a 788 Network Map), and (2) a tag (an opaque string) associated with the 789 version of that resource. A Network Map distributed by an ALTO 790 Server includes its Version Tag. A Cost Map referring to PIDs also 791 includes Version Tag for the Network Map on which it is based. 793 Two Network Maps are the same if they have the same Version Tag. 794 Whenever the content of the Network Map maintained by an ALTO Server 795 changes, tag MUST also be changed. Possibilities of setting the tag 796 component include the last-modified timestamp for the Network Map, or 797 a hash of its contents, where the collision probability is considered 798 zero in practical deployment scenarios. 800 6.4. Cost Map Update 802 An ALTO Server can update a Cost Map at any time. Hence, the same 803 Cost Map retrieved from the same ALTO Server but from different 804 requests can be inconsistent. 806 7. Endpoint Properties 808 An endpoint property defines a network-aware property of an endpoint. 810 7.1. Endpoint Property Type 812 For each endpoint and an endpoint property type, there can be a value 813 for the property. The type of an Endpoint property is indicated in 814 protocol messages as a string. The value depends on the specific 815 property. For example, for a property such as whether an endpoint is 816 metered, the value is a true or false value. 818 7.1.1. Endpoint Property Type: pid 820 An ALTO Server MUST define the 'pid' Endpoint Property Type for each 821 Network Map that it provides. 823 8. Protocol Specification: General Processing 825 This section first specifies general client and server processing. 826 The details of specific services will be covered in the following 827 sections. 829 8.1. Overall Design 831 The ALTO Protocol uses a REST-ful design. There are two primary 832 components to this design: 834 o Information Resources: An ALTO Server provides a set of network 835 information resources. Each information resource has a media type 836 [RFC2046]. An ALTO Client may construct an HTTP request for a 837 particular information resource (including any parameters, if 838 necessary), and the ALTO Server returns the requested information 839 resource in an HTTP response. 841 o Information Resource Directory (IRD): An ALTO Server provides to 842 ALTO Clients a list of available information resources and the URI 843 at which each is provided. This document refers to this list as 844 the Information Resource Directory. ALTO Clients consult the 845 directory to determine the services provided by an ALTO Server. 847 8.2. Notation 849 This document uses 'JSONString', 'JSONNumber', 'JSONBool' to indicate 850 the JSON string, number, and boolean types, respectively. The type 851 'JSONValue' indicates a JSON value, as specified in Section 2.1 of 852 [RFC4627]. 854 We use an adaptation of the C-style struct notation to define the 855 fields (names/values) of JSON objects. An optional field is enclosed 856 by [ ], and an array is indicated by two numbers in angle brackets, 857 , where m indicates the minimal number of values, and n is the 858 maximum. When we write * for n, it means no upper bound. In the 859 definitions, the JSON names of the fields are case sensitive. 861 For example, the definition below defines a new type Type4, with 862 three field members (or fields for short) named "name1", "name2", and 863 "name3" respectively. The field named "name3" is optional, and the 864 field named "name2" is an array of at least one value. 866 object { 867 Type1 name1; 868 Type2 name2<1..*>; 869 [Type3 name3;] 870 } Type4; 872 We also define dictionary maps (or maps for short) from strings to 873 JSON values. For example, the definition below defines a Type3 874 object as a map. Type1 must be defined as string, and Type2 can be 875 defined as any type. 877 object-map { 878 Type1 -> Type2; 879 } Type3; 881 We use subtyping to denote that one type is derived from another 882 type. The example below denotes that TypeDerived is derived from 883 TypeBase. TypeDerived includes all fields defined in TypeBase. If 884 TypeBase does not have a field named "name1", TypeDerived will have a 885 new field named "name1". If TypeBase already has a field named 886 "name1" but with a different type, TypeDerived will have a field 887 named "name1" with the type defined in TypeDerived (i.e., Type1 in 888 the example). 890 object { 891 Type1 name1; 892 } TypeDerived : TypeBase; 894 Note that despite the notation, no standard, machine-readable 895 interface definition or schema is provided in this document. 896 Extension documents may document these as necessary. 898 8.3. Basic Operations 900 The ALTO Protocol employs standard HTTP [RFC2616]. It is used for 901 discovering available Information Resources at an ALTO Server and 902 retrieving Information Resources. ALTO Clients and ALTO Servers use 903 HTTP requests and responses carrying ALTO-specific content with 904 encoding as specified in this document, and MUST be compliant with 905 [RFC2616]. 907 8.3.1. Client Discovering Information Resources 909 To discover available Information Resources, an ALTO Client requests 910 Information Resource Directories. Informally, an Information 911 Resource Directory enumerates URIs at which an ALTO Server offers 912 Information Resources. 914 Specifically, using the ALTO Discovery protocol, an ALTO Client 915 obtains a URI through which it can request an Information Resource 916 Directory (IRD). We refer to this IRD as the Root IRD of the ALTO 917 Client. Each entry in an IRD indicates a URI at which an ALTO Server 918 accepts requests, and returns either an Information Resource or an 919 Information Resource Directory that references additional Information 920 Resources. Beginning with its Root IRD and following links to IRDs 921 recursively, an ALTO Client can discover all Information Resources 922 available to it. We refer to this set of Information Resources as 923 the Information Resource Closure of the ALTO Client. By inspecting 924 its Information Resource Closure, an ALTO Client can determine 925 whether an ALTO Server supports the desired Information Resource, and 926 if it is supported, the URI at which it is available. 928 See Section 9.2 for a detailed specification on IRDs. 930 8.3.2. Client Requesting Information Resources 932 Where possible, the ALTO Protocol uses the HTTP GET method to request 933 resources. However, some ALTO services provide Information Resources 934 that are the function of one or more input parameters. Input 935 parameters are encoded in the HTTP request's entity body, and the 936 ALTO Client MUST use the HTTP POST method to send the parameters. 938 When requesting an ALTO Information Resource that requires input 939 parameters specified in a HTTP POST request, an ALTO Client MUST set 940 the Content-Type HTTP header to the media type corresponding to the 941 format of the supplied input parameters. 943 8.3.3. Server Responding to IR Request 945 Upon receiving a request for an Information Resource that the ALTO 946 Server can provide, the ALTO Server MUST return the requested 947 Information Resource. In other cases, to be more informative 948 ([I-D.ietf-httpbis-p2-semantics]), the ALTO Server MAY provide the 949 ALTO Client with an Information Resource Directory indicating how to 950 reach the desired information resource, or return an ALTO error 951 object; see Section 8.5 for more details on ALTO error handling. 953 It is possible for an ALTO Server to leverage caching HTTP 954 intermediaries to respond to both GET and POST requests by including 955 explicit freshness information (see Section 14 of [RFC2616]). 956 Caching of POST requests is not widely implemented by HTTP 957 intermediaries, however an alternative approach is for an ALTO 958 Server, in response to POST requests, to return an HTTP 303 status 959 code ("See Other") indicating to the ALTO Client that the resulting 960 Information Resource is available via a GET request to an alternate 961 URL. HTTP intermediaries that do not support caching of POST 962 requests could then cache the response to the GET request from the 963 ALTO Client following the alternate URL in the 303 response if the 964 response to the subsequent GET request contains explicit freshness 965 information. 967 The ALTO Server MUST indicate the type of its response using a media 968 type (i.e., the Content-Type HTTP header of the response). 970 8.3.4. Client Handling Server Response 972 8.3.4.1. Using Information Resources 974 This specification does not indicate any required actions taken by 975 ALTO Clients upon successfully receiving an Information Resource from 976 an ALTO Server. Although ALTO Clients are suggested to interpret the 977 received ALTO Information and adapt application behavior, ALTO 978 Clients are not required to do so. 980 8.3.4.2. Handling Server Response and IRD 982 After receiving an Information Resource Directory, the Client can 983 consult it to determine if any of the offered URIs contain the 984 desired Information Resource. However, an ALTO Client MUST NOT 985 assume that the media type returned by the ALTO Server for a request 986 to a URI is the media type advertised in the IRD or specified in its 987 request (i.e., the client must still check the Content-Type header). 988 The expectation is that the media type returned should normally be 989 the media type advertised and requested, but in some cases it may 990 legitimately not be so. 992 In particular, it is possible for an ALTO Client to receive an 993 Information Resource Directory from an ALTO Server as a response to 994 its request for a specific Information Resource. In this case, the 995 ALTO Client may ignore the response or still parse the response. To 996 indicate that an ALTO Client will always check if a response is an 997 Information Resource Directory, the ALTO Client can indicate in the 998 "Accept" header of a HTTP request that it can accept Information 999 Resource Directory; see Section 9.2 for the media type. 1001 8.3.4.3. Handling Error Conditions 1003 If an ALTO Client does not successfully receive a desired Information 1004 Resource from a particular ALTO Server (i.e., server response 1005 indicates error or there is no response), the Client can either 1006 choose another server (if one is available) or fall back to a default 1007 behavior (e.g., perform peer selection without the use of ALTO 1008 information, when used in a peer-to-peer system). 1010 8.3.5. Authentication and Encryption 1012 When server and/or client authentication, encryption, and/or 1013 integrity protection are required, an ALTO Server MUST support SSL/ 1014 TLS [RFC5246] as a mechanism. For cases such as a public ALTO 1015 service or deployment scenarios where there is an implicit trust 1016 relationship between the client and the server and the network 1017 infrastructure connecting them is secure, SSL/TLS may not be 1018 necessary. See [RFC6125] for considerations regarding verification 1019 of server identity. 1021 8.3.6. Information Refreshing 1023 An ALTO Client MAY determine the frequency at which ALTO Information 1024 is refreshed based on information made available via HTTP. 1026 8.3.7. HTTP Cookies 1028 If cookies are included in an HTTP request received by an ALTO 1029 Server, they MUST be ignored. 1031 8.3.8. Parsing of Unknown Fields 1033 This document only details object fields used by this specification. 1034 Extensions may include additional fields within JSON objects defined 1035 in this document. ALTO implementations MUST ignore unknown fields 1036 when processing ALTO messages. 1038 8.4. Server Response Encoding 1040 Though each type of ALTO Server response (i.e., an Information 1041 Resource Directory, an individual Information Resource, or an error 1042 message) has its distinct syntax and hence its unique Media Type, 1043 they are designed to have a similar structure: a meta field providing 1044 meta definitions, and another field containing the data, if needed. 1046 Specifically, we define the base type of each ALTO Server response as 1047 ResponseEntityBase: 1049 object { 1050 ResponseMeta meta; 1051 } ResponseEntityBase; 1053 with field: 1055 meta meta-information pertaining to the response. 1057 8.4.1. Meta Information 1059 Meta information is encoded as a map object for flexibility. 1060 Specifically, ResponseMeta is defined as: 1062 object-map { 1063 JSONString -> JSONValue 1064 } ResponseMeta; 1066 8.4.2. Data Information 1068 The data component of the response encodes the response-specific 1069 data. In this document, we derive five types from ResponseEntityBase 1070 to add different types of data component: InforResourceDirectory 1071 (Section 9.2.2), InfoResourceNetworkMap (Section 11.2.1.6), 1072 InfoResourceCostMap (Section 11.2.2.6), 1073 InfoResourceEndpointProperties (Section 11.4.1.6), and 1074 InfoResourceEndpointCostMap (Section 11.5.1.6). 1076 8.5. Protocol Errors 1078 If there is an error processing a request, an ALTO Server SHOULD 1079 return additional ALTO-layer information, if it is available, in the 1080 form of an ALTO Error Resource encoded in the HTTP response' entity 1081 body. If no ALTO-layer information is available, an ALTO Server may 1082 omit an ALTO Error resource from the response. 1084 With or without additional ALTO-layer error information, an ALTO 1085 Server MUST set an appropriate HTTP status code. It is important to 1086 note that the HTTP Status Code and ALTO Error Resource have distinct 1087 roles. An ALTO Error Resource provides detailed information about 1088 why a particular request for an ALTO Resource was not successful. 1089 The HTTP status code indicates to HTTP processing elements (e.g., 1090 intermediaries and clients) how the response should be treated. 1092 8.5.1. Media Type 1094 The media type for an ALTO Error Response is "application/ 1095 alto-error+json". 1097 8.5.2. Response Format and Error Codes 1099 An ALTO Error Response MUST include the "code" key in the "meta" 1100 field of the response. The value of "code" MUST be an ALTO Error 1101 Code defined in Table 1. Note that the ALTO Error Codes defined in 1102 Table 1 are limited to support the error conditions needed for 1103 purposes of this document. Additional status codes may be defined in 1104 companion or extension documents. 1106 +-----------------------+-------------------------------------------+ 1107 | ALTO Error Code | Description | 1108 +-----------------------+-------------------------------------------+ 1109 | E_SYNTAX | Parsing error in request (including | 1110 | | identifiers) | 1111 | E_MISSING_FIELD | A required JSON field is missing | 1112 | E_INVALID_FIELD_TYPE | The type of the value of a JSON field is | 1113 | | invalid | 1114 | E_INVALID_FIELD_VALUE | The value of a JSON field is invalid | 1115 +-----------------------+-------------------------------------------+ 1117 Table 1: Defined ALTO Error Codes. 1119 After an ALTO Server receives a request, it needs to verify the 1120 syntactic and semantic validity of the request. The following 1121 paragraphs in this section are intended to illustrate the usage of 1122 the error codes defined above during the verification. An individual 1123 implementation may define its message processing in a different 1124 order. 1126 In the first step after an ALTO Server receives a request, it checks 1127 the syntax of the request body (i.e., whether the JSON structure can 1128 be parsed), and indicates a syntax error using the error code 1129 E_SYNTAX. 1131 A request without syntax errors may still be invalid. An error case 1132 is that the request misses a required field. The server indicates 1133 such an error using the error code E_MISSING_FIELD. This document 1134 defines required fields for Network Map Filtering (Section 11.3.1.3), 1135 Cost Map Filtering (Section 11.3.2.3), Endpoint Properties 1136 (Section 11.4.1.3), and Endpoint Cost (Section 11.5.1.3). For an 1137 E_MISSING_FIELD error, the server may include the optional "field" 1138 key in the "meta" field of the response, to indicate the missing 1139 field. 1141 A request with the correct fields might use a wrong type for the 1142 value of a field. For example, the value of a field could be a 1143 JSONString when a JSONNumber is expected. The server indicates such 1144 an error using the error code E_INVALID_FIELD_TYPE. The server may 1145 include the optional "field" key in the "meta" field of the response, 1146 to indicate the field that contains the wrong type. 1148 A request with the correct fields and types of values for the fields 1149 may specify a wrong value for a field. For example, a cost map 1150 filtering request may specify a wrong value of CostMode in the "cost- 1151 type" field (Section 11.3.2.3). The server indicates such an error 1152 with the error code E_INVALID_FIELD_VALUE. For an 1153 E_INVALID_FIELD_VALUE error, the server may include the optional 1154 "field" key in the "meta" field of the response, to indicate the 1155 field that contains the wrong value. The server may also include the 1156 optional "value" key in the "meta" field of the response to indicate 1157 the wrong value that triggered the error. 1159 If multiple errors are present in a single request (e.g., a request 1160 uses a JSONString when a JSONNumber is expected and a required field 1161 is missing), then the ALTO Server MUST return exactly one of the 1162 detected errors. However, the reported error is implementation 1163 defined, since specifying a particular order for message processing 1164 encroaches needlessly on implementation techniques. 1166 8.5.3. Overload Conditions and Server Unavailability 1168 If an ALTO Server detects that it cannot handle a request from an 1169 ALTO Client due to excessive load, technical problems, or system 1170 maintenance, it SHOULD do one of the following: 1172 o Return an HTTP 503 ("Service Unavailable") status code to the ALTO 1173 Client. As indicated by [RFC2616], a the Retry-After HTTP header 1174 may be used to indicate when the ALTO Client should retry the 1175 request. 1177 o Return an HTTP 307 ("Temporary Redirect") status code indicating 1178 an alternate ALTO Server that may be able to satisfy the request. 1180 The ALTO Server MAY also terminate the connection with the ALTO 1181 Client. 1183 The particular policy applied by an ALTO Server to determine that it 1184 cannot service a request is outside of the scope of this document. 1186 9. Protocol Specification: Information Resource Directory 1188 As we discussed, an ALTO Client starts by retrieving an Information 1189 Resource Directory, which specifies the attributes of individual 1190 Information Resources that an ALTO Server provides. 1192 9.1. Information Resource Attributes 1194 In this document, each Information Resource has five attributes 1195 associated with it, including its assigned ID, its response format, 1196 its capabilities, its accepted input parameters, and other resources 1197 that it may depend on. The function of an Information Resource 1198 Directory is to publishes these attributes. 1200 9.1.1. Resource ID 1202 Each Information Resource that an ALTO Client can request MUST be 1203 assigned an ID that is unique amongst all Information Resources in 1204 the Information Resource Closure of the client. The ID SHOULD remain 1205 stable even when the data provided by that resource changes. For 1206 example, even though the number of PIDs in a Network Map may be 1207 adjusted, its Resource ID should remain the same. Similarly, if the 1208 entries in a Cost Map are updated, its Resource ID should remain the 1209 same. IDs SHOULD NOT be re-used for different resources over time. 1211 9.1.2. Media Type 1213 ALTO uses Media Type [RFC2046] to uniquely indicate the data format 1214 used to encode the content to be transmitted between an ALTO Server 1215 and an ALTO Client in the HTTP entity body. 1217 9.1.3. Capabilities 1219 The Capabilities attribute of an Information Resource indicates 1220 specific capabilities that the server can provide. For example, if 1221 an ALTO Server allows an ALTO Client to specify cost constraints when 1222 the Client requests a Cost Map Information Resource, then the Server 1223 advertises the cost-constraints capability of the Cost Map 1224 Information Resource. 1226 9.1.4. Accepts Input Parameters 1228 An ALTO Server may allow an ALTO Client to supply input parameters 1229 when requesting certain Information Resources. The associated 1230 accepts attribute of an Information Resource is a Media Type, which 1231 indicates how the Client specifies the input parameters as contained 1232 in the entity body of the HTTP POST request. 1234 9.1.5. Dependent Resources 1236 The information provided in an Information Resource may use 1237 information provided in some other resources (e.g., a Cost Map uses 1238 the PIDs defined in a Network Map). The uses attribute conveys such 1239 information. 1241 9.2. Information Resource Directory (IRD) 1243 An ALTO Server uses Information Resource Directory to publish 1244 available Information Resources and their aforementioned attributes. 1245 Since resource selection happens after consumption of the Information 1246 Resource Directory, the format of the Information Resource Directory 1247 is designed to be simple with the intention of future ALTO Protocol 1248 versions maintaining backwards compatibility. Future extensions or 1249 versions of the ALTO Protocol SHOULD be accomplished by extending 1250 existing media types or adding new media types, but retaining the 1251 same format for the Information Resource Directory. 1253 An ALTO Server MUST make an Information Resource Directory available 1254 via the HTTP GET method to a URI discoverable by an ALTO Client. 1255 Discovery of this URI is out of scope of this document, but could be 1256 accomplished by manual configuration or by returning the URI of an 1257 Information Resource Directory from the ALTO Discovery Protocol 1258 [I-D.ietf-alto-server-discovery]. For recommendations on how the URI 1259 may look like, see [I-D.ietf-alto-server-discovery]. 1261 9.2.1. Media Type 1263 The media type to indicate an information directory is "application/ 1264 alto-directory+json". 1266 9.2.2. Encoding 1268 An Information Resource Directory response may include in "meta" the 1269 "cost-types" key, whose value is of type IRDMetaCostTypes defined 1270 below, where CostType is defined in Section 10.7: 1272 object-map { 1273 JSONString -> CostType; 1274 } IRDMetaCostTypes; 1276 The function of "cost-types" is to assign names to a set of CostTypes 1277 that can be used in one or more "resources" entries in the IRD to 1278 simplify specification. The names defined in "cost-types" in an IRD 1279 are local to the IRD. 1281 For a Root IRD, "meta" MUST include the "default-alto-network-map" 1282 key, which specifies the Resource ID of a Network Map. When there are 1283 multiple Network Maps defined in an IRD (e.g., with different levels 1284 of granularity), the "default-alto-network-map" key provides a 1285 guideline to simple clients that use only one Network Map. 1287 The data component of an Information Resource Directory response is 1288 named "resources", which is a JSON object of type IRDResourceEntries: 1290 object { 1291 IRDResourceEntries resources; 1292 } InfoResourceDirectory : ResponseEntityBase; 1294 object-map { 1295 ResourceID -> IRDResourceEntry; 1296 } IRDResourceEntries; 1298 object { 1299 JSONString uri; 1300 JSONString media-type; 1301 [JSONString accepts;] 1302 [Capabilities capabilities;] 1303 [ResourceID uses<0..*>;] 1304 } IRDResourceEntry; 1306 object { 1307 ... 1309 } Capabilities; 1311 An IRDResourceEntries object is a dictionary map keyed by 1312 ResourceIDs, where ResourceID is defined in Section 10.2. The value 1313 of each entry specifies: 1315 uri A URI at which the ALTO Server provides one or more Information 1316 Resources, or an Information Resource Directory indicating 1317 additional Information Resources. URIs can be relative to the URI 1318 of the IRD and MUST be resolved according to Section 5 of 1319 [RFC3986]. 1321 media-type The media type of Information Resource (see 1322 Section 9.1.2) available via GET or POST requests to the 1323 corresponding URI or "application/alto-directory+json", which 1324 indicates that the response for a request to the URI will be an 1325 Information Resource Directory for URIs discoverable via the URI. 1327 accepts The media type of input parameters (see Section 9.1.4) 1328 accepted by POST requests to the corresponding URI. If this field 1329 is not present, it MUST be assumed to be empty. 1331 capabilities A JSON Object enumerating capabilities of an ALTO 1332 Server in providing the Information Resource at the corresponding 1333 URI and Information Resources discoverable via the URI. If this 1334 field is not present, it MUST be assumed to be an empty object. 1335 If a capability for one of the offered Information Resources is 1336 not explicitly listed here, an ALTO Client may either issue an 1337 OPTIONS HTTP request to the corresponding URI to determine if the 1338 capability is supported, or assume its default value documented in 1339 this specification or an extension document describing the 1340 capability. 1342 uses A list of Resource IDs, defined in the same IRD, that define 1343 the resources on which this resource directly depends. An ALTO 1344 Server SHOULD include in this list any resources that the ALTO 1345 Client would need to retrieve in order to interpret the contents 1346 of this resource. For example, a Cost Map resource should include 1347 in this list the Network Map on which it depends. ALTO Clients 1348 may wish to consult this list in order to pre-fetch necessary 1349 resources. 1351 If an entry has an empty list for "accepts", then the corresponding 1352 URI MUST support GET requests. If an entry has a non-empty 1353 "accepts", then the corresponding URI MUST support POST requests. If 1354 an ALTO Server wishes to support both GET and POST on a single URI, 1355 it MUST specify two entries in the Information Resource Directory. 1357 9.2.3. Example 1359 The following is an example Information Resource Directory returned 1360 by an ALTO Server to an ALTO Client. Assume it is the Root IRD of 1361 the Client. 1363 GET /directory HTTP/1.1 1364 Host: alto.example.com 1365 Accept: application/alto-directory+json,application/alto-error+json 1367 HTTP/1.1 200 OK 1368 Content-Length: TBA 1369 Content-Type: application/alto-directory+json 1371 { 1372 "meta" : { 1373 "cost-types": { 1374 "num-routing": { 1375 "cost-mode" : "numerical", 1376 "cost-metric": "routingcost", 1377 "description": "My default" 1378 }, 1379 "num-hop": { 1380 "cost-mode" : "numerical", 1381 "cost-metric": "hopcount" 1382 }, 1383 "ord-routing": { 1384 "cost-mode" : "ordinal", 1385 "cost-metric": "routingcost" 1386 }, 1387 "ord-hop": { 1388 "cost-mode" : "ordinal", 1389 "cost-metric": "hopcount" 1390 } 1391 }, 1392 "default-alto-network-map" : "my-default-network-map" 1393 }, 1394 "resources" : { 1395 "my-default-network-map" : { 1396 "uri" : "http://alto.example.com/networkmap", 1397 "media-type" : "application/alto-networkmap+json" 1398 }, 1399 "numerical-routing-cost-map" : { 1400 "uri" : "http://alto.example.com/costmap/num/routingcost", 1401 "media-type" : "application/alto-costmap+json", 1402 "capabilities" : { 1403 "cost-type-names" : [ "num-routing" ] 1404 }, 1405 "uses": [ "my-default-network-map" ] 1406 }, 1407 "numerical-hopcount-cost-map" : { 1408 "uri" : "http://alto.example.com/costmap/num/hopcount", 1409 "media-type" : "application/alto-costmap+json", 1410 "capabilities" : { 1411 "cost-type-names" : [ "num-hop" ] 1412 }, 1413 "uses": [ "my-default-network-map" ] 1414 }, 1415 "custom-maps-resources" : { 1416 "uri" : "http://custom.alto.example.com/maps", 1417 "media-type" : "application/alto-directory+json" 1418 }, 1419 "endpoint-property" : { 1420 "uri" : "http://alto.example.com/endpointprop/lookup", 1421 "media-type" : "application/alto-endpointprop+json", 1422 "accepts" : "application/alto-endpointpropparams+json", 1423 "capabilities" : { 1424 "prop-types" : [ "my-default-network-map.pid", 1425 "priv:ietf-example-prop" ] 1426 }, 1427 }, 1428 "endpoint-cost" : { 1429 "uri" : "http://alto.example.com/endpointcost/lookup", 1430 "media-type" : "application/alto-endpointcost+json", 1431 "accepts" : "application/alto-endpointcostparams+json", 1432 "capabilities" : { 1433 "cost-constraints" : true, 1434 "cost-type-names" : [ "num-routing", "num-hop", 1435 "ord-routing", "ord-hop"] 1436 } 1437 } 1438 } 1439 } 1441 Specifically, the "cost-types" key of "meta" of the example IRD 1442 defines names for four cost types in this IRD. For example, "num- 1443 routing" in the example is the name that refers to a Cost Type with 1444 Cost Mode being "numerical" and Cost Metric being "routingcost". 1445 This name is used in the second entry of "resources", which defines a 1446 Cost Map. In particular, the "cost-type-names" of its "capabilities" 1447 specifies that this resource supports a Cost Type named as "num- 1448 routing". The ALTO Client looks up the name "num-routing" in "cost- 1449 types" of the IRD to obtain the Cost Type named as "num-routing". 1450 The last entry of "resources" uses all four names defined in "cost- 1451 types". 1453 Another key defined in "meta" of the example IRD is "default-alto- 1454 network-map", which has value "my-default-network-map", which is the 1455 Resource ID of a Network Map that will be defined in "resources". 1457 The "resources" field of the example IRD defines six Information 1458 Resources. For example, the second entry, which is assigned a 1459 Resource ID "numerical-routing-cost-map", provides a Cost Map, as 1460 indicated by the media-type "application/alto-costmap+json". The 1461 Cost Map is based on the Network Map defined with Resource ID "my- 1462 default-network-map". As another example, the last entry, which is 1463 assigned Resource ID "endpoint-cost", provides the Endpoint Cost 1464 Service, which is indicated by the media-type "application/ 1465 alto-endpointcost+json". An ALTO Client should use uri 1466 "http://alto.example.com/endpointcost/lookup" to access the service. 1467 The ALTO Client should format its request body to be the 1468 "application/alto-endpointcostparams+json" media type, as specified 1469 by the "accepts" attribute of the Information Resource. The "cost- 1470 type-names" field of the "capabilities" attribute of the Information 1471 Resource includes four defined cost types specified in the "cost- 1472 types" key of "meta" of the IRD. Hence, one can verify that the 1473 Endpoint Cost Information Resource supports both Cost Metrics 1474 'routingcost' and 'hopcount', each available for both 'numerical' and 1475 'ordinal'. When requesting the Information Resource, an ALTO Client 1476 can specify cost constraints, as indicated by the "cost-constraints" 1477 field of the "capabilities" attribute. 1479 9.2.4. Delegation using IRD 1481 ALTO Information Resource Directory provides flexibility to provide 1482 ALTO Service (e.g., delegation to another domain). Consider the 1483 preceding example. Assume that the ALTO Server running at 1484 alto.example.com wants to delegate some Information Resources to a 1485 separate subdomain: "custom.alto.example.com". In particular, assume 1486 that the maps available via this subdomain are filtered Network Maps, 1487 filtered Cost Maps, and some pre-generated maps for the "hopcount" 1488 and "routingcost" Cost Metrics in the "ordinal" Cost Mode. The 1489 fourth entry of "resources" in the preceding example IRD implements 1490 the delegation. The entry has a media-type of "application/ 1491 alto-directory+json", and an ALTO Client can discover the Information 1492 Resources available at "custom.alto.example.com" if its request to 1493 "http://custom.alto.example.com/maps" is successful: 1495 GET /maps HTTP/1.1 1496 Host: custom.alto.example.com 1497 Accept: application/alto-directory+json,application/alto-error+json 1499 HTTP/1.1 200 OK 1500 Content-Length: TBA 1501 Content-Type: application/alto-directory+json 1503 { 1504 "meta" : { 1505 "cost-types": { 1506 "num-routing": { 1507 "cost-mode" : "numerical", 1508 "cost-metric": "routingcost", 1509 "description": "My default" 1510 }, 1511 "num-hop": { 1512 "cost-mode" : "numerical", 1513 "cost-metric": "hopcount" 1514 }, 1515 "ord-routing": { 1516 "cost-mode" : "ordinal", 1517 "cost-metric": "routingcost" 1518 }, 1519 "ord-hop": { 1520 "cost-mode" : "ordinal", 1521 "cost-metric": "hopcount" 1522 } 1523 } 1524 }, 1525 "resources" : { 1526 "filtered-network-map" : { 1527 "uri" : "http://custom.alto.example.com/networkmap/filtered", 1528 "media-type" : "application/alto-networkmap+json", 1529 "accepts" : "application/alto-networkmapfilter+json", 1530 "uses": [ "my-default-network-map" ] 1531 }, 1532 "filtered-cost-map" : { 1533 "uri" : "http://custom.alto.example.com/costmap/filtered", 1534 "media-type" : "application/alto-costmap+json", 1535 "accepts" : "application/alto-costmapfilter+json", 1536 "capabilities" : { 1537 "cost-constraints" : true, 1538 "cost-type-names" : [ "num-routing", "num-hop", 1539 "ord-routing", "ord-hop" ] 1541 }, 1542 "uses": [ "my-default-network-map" ] 1543 }, 1544 "ordinal-routing-cost-map" : { 1545 "uri" : "http://custom.alto.example.com/ord/routingcost", 1546 "media-type" : "application/alto-costmap+json", 1547 "capabilities" : { 1548 "cost-type-names" : [ "ord-routing" ] 1549 }, 1550 "uses": [ "my-default-network-map" ] 1551 }, 1552 "ordinal-hopcount-cost-map" : { 1553 "uri" : "http://custom.alto.example.com/ord/hopcount", 1554 "media-type" : "application/alto-costmap+json", 1555 "capabilities" : { 1556 "cost-type-names" : [ "ord-hop" ], 1557 }, 1558 "uses": [ "my-default-network-map" ] 1559 } 1560 } 1561 } 1563 Note that the subdomain does not define Network Map, and uses the 1564 Network Map with Resource ID "my-default-network-map" defined in the 1565 Root IRD. 1567 9.2.5. Considerations of Using IRD 1569 9.2.5.1. ALTO Client 1571 This document specifies no requirements or constraints on ALTO 1572 Clients with regards to how they process an Information Resource 1573 Directory to identify the URI corresponding to a desired Information 1574 Resource. However, some advice is provided for implementors. 1576 It is possible that multiple entries in the directory match a desired 1577 Information Resource. For instance, in the example in Section 9.2.3, 1578 a full Cost Map with "numerical" Cost Mode and "routingcost" Cost 1579 Metric could be retrieved via a GET request to 1580 "http://alto.example.com/costmap/num/routingcost", or via a POST 1581 request to "http://custom.alto.example.com/costmap/filtered". 1583 In general, it is preferred for ALTO Clients to use GET requests 1584 where appropriate, since it is more likely for responses to be 1585 cachable. However, an ALTO Client may need to use POST, for example, 1586 to get ALTO costs or properties that are for a restricted set of PIDs 1587 or Endpoints, or to update cached information previously acquired via 1588 GET requests." 1590 9.2.5.2. ALTO Server 1592 This document indicates that an ALTO Server may or may not provide 1593 the Information Resources specified in the Map Filtering Service. If 1594 these resources are not provided, it is indicated to an ALTO Client 1595 by the absence of a Network Map or Cost Map with any media types 1596 listed under "accepts". 1598 10. Protocol Specification: Basic Data Types 1600 This section details the format of basic data types. 1602 10.1. PID Name 1604 A PID Name is encoded as a US-ASCII string. The string MUST be no 1605 more than 64 characters, and MUST NOT contain characters other than 1606 alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, and 0x61- 1607 0x7A), the hyphen ('-', code point 0x2D), the colon (':', code point 1608 0x3A), the at ('@', code point 0x40), the underline ('_', code point 1609 0x5F), or the '.' separator (code point 0x2E). The '.' separator is 1610 reserved for future use and MUST NOT be used unless specifically 1611 indicated in this document, or an extension document. 1613 The type 'PIDName' is used in this document to indicate a string of 1614 this format. 1616 10.2. Resource ID 1618 A Resource ID uniquely identifies an particular resource (e.g., a 1619 Network Map) within an ALTO Server (see Section 9.2). 1621 A Resource ID is encoded as a US-ASCII string with the same format as 1622 that of PIDName. 1624 The type 'ResourceID' is used in this document to indicate a string 1625 of this format. 1627 10.3. Version Tag 1629 A Version Tag is defined as: 1631 object { 1632 ResourceID resource-id; 1633 JSONString tag; 1635 } VersionTag; 1637 The 'resource-id' attribute is the Resource ID of a resource (e.g., a 1638 Network Map) defined in the Information Resource Directory, and 'tag' 1639 is a case-sensitive US-ASCII string. The 'tag' string MUST be no 1640 more than 64 characters, and MUST NOT contain any ASCII character 1641 below 0x21 or above 0x7E. 1643 Two values of the VersionTag are equal if and only if both the the 1644 'resource-id' attributes are byte-for-byte equal and the 'tag' 1645 attributes are byte-for-byte equal. 1647 10.4. Endpoints 1649 This section defines formats used to encode addresses for Endpoints. 1650 In a case that multiple textual representations encode the same 1651 Endpoint address or prefix (within the guidelines outlined in this 1652 document), the ALTO Protocol does not require ALTO Clients or ALTO 1653 Servers to use a particular textual representation, nor does it 1654 require that ALTO Servers reply to requests using the same textual 1655 representation used by requesting ALTO Clients. ALTO Clients must be 1656 cognizant of this. 1658 10.4.1. Address Type 1660 Address Types are encoded as US-ASCII strings consisting of only 1661 alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, and 0x61- 1662 0x7A). This document defines the address type 'ipv4' to refer to 1663 IPv4 addresses, and 'ipv6' to refer to IPv6 addresses. All Address 1664 Type identifiers appearing in an HTTP request or response with an 1665 'application/alto-*' media type MUST be registered in the ALTO 1666 Address Type registry (see Section 14.4). 1668 The type 'AddressType' is used in this document to indicate a string 1669 of this format. 1671 10.4.2. Endpoint Address 1673 Endpoint Addresses are encoded as US-ASCII strings. The exact 1674 characters and format depend on the type of endpoint address. 1676 The type 'EndpointAddr' is used in this document to indicate a string 1677 of this format. 1679 10.4.2.1. IPv4 1681 IPv4 Endpoint Addresses are encoded as specified by the 'IPv4address' 1682 rule in Section 3.2.2 of [RFC3986]. 1684 10.4.2.2. IPv6 1686 IPv6 Endpoint Addresses are encoded as specified in Section 4 of 1687 [RFC5952]. 1689 10.4.2.3. Typed Endpoint Addresses 1691 When an Endpoint Address is used, an ALTO implementation must be able 1692 to determine its type. For this purpose, the ALTO Protocol allows 1693 endpoint addresses to also explicitly indicate their type. 1695 Typed Endpoint Addresses are encoded as US-ASCII strings of the 1696 format 'AddressType:EndpointAddr' (with the ':' character as a 1697 separator). The type 'TypedEndpointAddr' is used to indicate a 1698 string of this format. 1700 10.4.3. Endpoint Prefixes 1702 For efficiency, it is useful to denote a set of Endpoint Addresses 1703 using a special notation (if one exists). This specification makes 1704 use of the prefix notations for both IPv4 and IPv6 for this purpose. 1706 Endpoint Prefixes are encoded as US-ASCII strings. The exact 1707 characters and format depend on the type of endpoint address. 1709 The type 'EndpointPrefix' is used in this document to indicate a 1710 string of this format. 1712 10.4.3.1. IPv4 1714 IPv4 Endpoint Prefixes are encoded as specified in Section 3.1 of 1715 [RFC4632]. 1717 10.4.3.2. IPv6 1719 IPv6 Endpoint Prefixes are encoded as specified in Section 7 of 1720 [RFC5952]. 1722 10.4.4. Endpoint Address Group 1724 The ALTO Protocol includes messages that specify potentially large 1725 sets of endpoint addresses. Endpoint Address Groups provide a more 1726 efficient way to encode such sets, even when the set contains 1727 endpoint addresses of different types. 1729 An Endpoint Address Group is defined as: 1731 object-map { 1732 AddressType -> EndpointPrefix<0..*>; 1733 } EndpointAddrGroup; 1735 In particular, an Endpoint Address Group is a JSON object 1736 representing a map, where each key is the string corresponding to an 1737 address type, and the corresponding value is an array listing 1738 prefixes of addresses of that type. 1740 The following is an example with both IPv4 and IPv6 endpoint 1741 addresses: 1743 { 1744 "ipv4": [ 1745 "192.0.2.0/24", 1746 "198.51.100.0/25" 1747 ], 1748 "ipv6": [ 1749 "2001:db8:0:1::/64", 1750 "2001:db8:0:2::/64" 1751 ] 1752 } 1754 10.5. Cost Mode 1756 A Cost Mode is encoded as a US-ASCII string. The string MUST either 1757 have the value 'numerical' or 'ordinal'. 1759 The type 'CostMode' is used in this document to indicate a string of 1760 this format. 1762 10.6. Cost Metric 1764 A Cost Metric is encoded as a US-ASCII string. The string MUST be no 1765 more than 32 characters, and MUST NOT contain characters other than 1766 alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, and 0x61- 1767 0x7A), the hyphen ('-', code point 0x2D), the colon (':', code point 1768 0x3A), the underline ('_', code point 0x5F), or the '.' separator 1769 (0x2E). The '.' separator is reserved for future use and MUST NOT be 1770 used unless specifically indicated by a companion or extension 1771 document. 1773 Identifiers prefixed with 'priv:' are reserved for Private Use 1774 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for 1775 Experimental use. For an identifier with the 'priv:' or 'exp:' 1776 prefix, an additional string (e.g., company identifier or random 1777 string) MUST follow to reduce potential collisions. For example, a 1778 short string after 'exp:' to indicate the starting time of a specific 1779 experiment is recommended. All other identifiers that appear in an 1780 HTTP request or response with an 'application/alto-*' media type and 1781 indicate Cost Metrics MUST be registered in the ALTO Cost Metrics 1782 registry Section 14.2. 1784 The type 'CostMetric' is used in this document to indicate a string 1785 of this format. 1787 10.7. Cost Type 1789 The combination of a CostMetric and a CostMode defines a CostType: 1791 object { 1792 CostMetric cost-metric; 1793 CostMode cost-mode; 1794 [JSONString description;] 1795 } CostType; 1797 'description', if present, MUST contain a US-ASCII string with a 1798 human-readable description of the cost-metric and cost-mode. An ALTO 1799 Client MAY present this string to a developer, as part of a discovery 1800 process. But the field SHOULD NOT be interpreted by an ALTO Client. 1802 10.8. Endpoint Property 1804 We distinguish two types of Endpoint Properties: Resource Specific 1805 Endpoint Properties and Global Endpoint Properties. The type 1806 'EndpointPropertyType' is used in this document to indicate a US- 1807 ASCII string denoting either a Resource Specific Endpoint Property or 1808 a Global Endpoint Property. 1810 10.8.1. Resource Specific Endpoint Properties 1812 We define only one Resource Specific Endpoint Property in this 1813 document: pid. It has the following format: a Resource ID, followed 1814 by the '.' separator (0x2E), followed by "pid". An example is "my- 1815 default-networkmap.pid". 1817 10.8.2. Global Endpoint Properties 1819 An Global Endpoint Property is encoded as a US-ASCII string. The 1820 string MUST be no more than 32 characters, and MUST NOT contain 1821 characters other than alphanumeric characters (code points 0x30-0x39, 1822 0x41-0x5A, and 0x61-0x7A), the hyphen ('-', code point 0x2D), the 1823 colon (':', code point 0x3A), or the underline ('_', code point 1824 0x5F). Note that the '.' separator is not allowed so that there is 1825 no ambiguity on whether an endpoint property is global or resource 1826 specific. 1828 Identifiers prefixed with 'priv:' are reserved for Private Use 1829 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for 1830 Experimental use. For an identifier with the 'priv:' or 'exp:' 1831 prefix, an additional string (e.g., company identifier or random 1832 string) MUST follow to reduce potential collisions. For example, a 1833 short string after 'exp:' to indicate the starting time of a specific 1834 experiment is recommended. All other identifiers for Endpoint 1835 Properties appearing in an HTTP request or response with an 1836 'application/alto-*' media type MUST be registered in the ALTO 1837 Endpoint Property registry Section 14.3. 1839 11. Protocol Specification: Service Information Resources 1841 This section documents the individual Information Resources defined 1842 to provide the services defined in this document. 1844 11.1. Meta Information 1846 For the "meta" field of the response to an individual Information 1847 Resource, we define two generic keys: "vtag", which is the Version 1848 Tag of the current Information Resource; and "dependent-vtags", which 1849 is an array of Version Tags, to indicate the Version Tags of the 1850 resources that this resource depends on. 1852 11.2. Map Service 1854 The Map Service provides batch information to ALTO Clients in the 1855 form of two types of maps: a Network Map and Cost Map. 1857 11.2.1. Network Map 1859 A Network Map Information Resource defines a set of PIDs, and for 1860 each PID, lists the network locations (endpoints) within the PID. An 1861 ALTO Server MUST provide at least one Network Map. 1863 11.2.1.1. Media Type 1865 The media type of Network Map is "application/alto-networkmap+json". 1867 11.2.1.2. HTTP Method 1869 A Network Map resource is requested using the HTTP GET method. 1871 11.2.1.3. Accept Input Parameters 1873 None. 1875 11.2.1.4. Capabilities 1877 None. 1879 11.2.1.5. Uses 1881 None. 1883 11.2.1.6. Response 1885 The "meta" field of a Network Map response MUST include "vtag", which 1886 is the Version Tag of the retrieved Network Map. 1888 The data component of a Network Map response is named "network-map", 1889 which is a JSON object of type NetworkMapData: 1891 object { 1892 NetworkMapData network-map; 1893 } InfoResourceNetworkMap : ResponseEntityBase; 1895 object-map { 1896 PIDName -> EndpointAddrGroup; 1897 } NetworkMapData; 1899 Specifically, a NetworkMapData object is a dictionary map keyed by 1900 PIDs, and each value representing the associated set of endpoint 1901 addresses of a PID. 1903 The returned Network Map MUST include all PIDs known to the ALTO 1904 Server. 1906 11.2.1.7. Example 1908 GET /networkmap HTTP/1.1 1909 Host: alto.example.com 1910 Accept: application/alto-networkmap+json,application/alto-error+json 1912 HTTP/1.1 200 OK 1913 Content-Length: TBA 1914 Content-Type: application/alto-networkmap+json 1916 { 1917 "meta" : { 1918 "vtag": [ 1919 {"resource-id": "my-default-network-map", 1920 "tag": "1266506139" 1921 } 1922 ] 1923 }, 1924 "network-map" : { 1925 "PID1" : { 1926 "ipv4" : [ 1927 "192.0.2.0/24", 1928 "198.51.100.0/25" 1929 ] 1930 }, 1931 "PID2" : { 1932 "ipv4" : [ 1933 "198.51.100.128/25" 1934 ] 1935 }, 1936 "PID3" : { 1937 "ipv4" : [ 1938 "0.0.0.0/0" 1939 ], 1940 "ipv6" : [ 1941 "::/0" 1942 ] 1943 } 1944 } 1945 } 1947 Note that the encoding of a Network Map response was chosen for 1948 readability and compactness. If lookup efficiency at runtime is 1949 crucial, then the returned Network Map can be transformed into data 1950 structures offering more efficient lookup. For example, one may 1951 store the Network Map as a trie-based data structure, which may allow 1952 efficient longest-prefix matching of IP addresses. 1954 11.2.2. Cost Map 1956 A Cost Map resource lists the Path Cost for each pair of source/ 1957 destination PID defined by the ALTO Server for a given Cost Metric 1958 and Cost Mode. This resource MUST be provided for at least the 1959 'routingcost' Cost Metric. 1961 11.2.2.1. Media Type 1963 The media type of Cost Map is "application/alto-costmap+json". 1965 11.2.2.2. HTTP Method 1967 A Cost Map resource is requested using the HTTP GET method. 1969 11.2.2.3. Accept Input Parameters 1971 None. 1973 11.2.2.4. Capabilities 1975 The capabilities of an ALTO Server URI providing an unfiltered cost 1976 map is a JSON Object of type CostMapCapabilities: 1978 object { 1979 JSONString cost-type-names<1..1>; 1980 } CostMapCapabilities; 1982 with field: 1984 cost-type-names Note that the array MUST include a single CostType 1985 name defined by key "cost-types" in "meta" of the IRD. This is 1986 because an unfiltered Cost Map (accept == "") is requested via an 1987 HTTP GET that accepts no input parameters. As a contrast, for 1988 filtered cost maps (see Section 11.3.2), the array can have 1989 multiple elements. 1991 11.2.2.5. Uses 1993 The Resource ID of the Network Map based on which the Cost Map will 1994 be defined. Recall (Section 6) that the combination of a Network Map 1995 and a CostType defines a key. In other words, an ALTO Server MUST 1996 NOT define two Cost Maps with the same Cost Type, Network Map pair. 1998 11.2.2.6. Response 2000 The "meta" field of a Cost Map response MUST include the "dependent- 2001 vtags" key, whose value is a single-element array to indicate the 2002 Version Tag of the Network Map used, where the Network Map is 2003 specified in "uses" of the IRD. The "meta" MUST also include "cost- 2004 type", to indicate the Cost Type (Section 10.7) of the Cost Map. 2006 The data component of a Cost Map response is named "cost-map", which 2007 is a JSON object of type CostMapData: 2009 object { 2010 CostMapData cost-map; 2011 } InfoResourceCostMap : ResponseEntityBase; 2013 object-map { 2014 PIDName -> DstCosts; 2015 } CostMapData; 2017 object-map { 2018 PIDName -> JSONValue; 2019 } DstCosts; 2021 Specifically, a CostMapData object is a dictionary map object, with 2022 each key being the PIDName string identifying the corresponding 2023 Source PID, and value being a type of DstCosts, which denotes the 2024 associated costs from the Source PID to a set of destination PIDs ( 2025 Section 6.2). An implementation of the protocol in this document 2026 SHOULD assume that the cost is a JSONNumber and fail to parse if it 2027 is not, unless the implementation is using an extension to this 2028 document that indicates when and how costs of other data types are 2029 signaled. 2031 The returned Cost Map MUST include the Path Cost for each (Source 2032 PID, Destination PID) pair for which a Path Cost is defined. An ALTO 2033 Server MAY omit entries for which a Path Cost is not defined (e.g., 2034 both the Source and Destination PIDs contain addresses outside of the 2035 Network Provider's administrative domain). 2037 Similar to Network Map, the encoding of Cost Map was chosen for 2038 readability and compactness. If lookup efficiency at runtime is 2039 crucial, then the returned Cost Map can be transformed into data 2040 structures offering more efficient lookup. For example, one may 2041 store a Cost Map as a matrix. 2043 11.2.2.7. Example 2045 GET /costmap/num/routingcost HTTP/1.1 2046 Host: alto.example.com 2047 Accept: application/alto-costmap+json,application/alto-error+json 2049 HTTP/1.1 200 OK 2050 Content-Length: TBA 2051 Content-Type: application/alto-costmap+json 2053 { 2054 "meta" : { 2055 "dependent-vtags" : [ 2056 {"resource-id": "my-default-network-map", 2057 "tag": "1266506139" 2058 } 2059 ], 2060 "cost-type" : {"cost-mode" : "numerical", 2061 "cost-metric": "routingcost" 2062 } 2063 }, 2064 "cost-map" : { 2065 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 2066 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 2067 "PID3": { "PID1": 20, "PID2": 15 } 2068 } 2069 } 2071 Similar to the Network Map case, we considered array-based encoding 2072 for "map", but chose the current encoding for clarity. 2074 11.3. Map Filtering Service 2076 The Map Filtering Service allows ALTO Clients to specify filtering 2077 criteria to return a subset of the full maps available in the Map 2078 Service. 2080 11.3.1. Filtered Network Map 2082 A Filtered Network Map is a Network Map Information Resource 2083 (Section 11.2.1) for which an ALTO Client may supply a list of PIDs 2084 to be included. A Filtered Network Map MAY be provided by an ALTO 2085 Server. 2087 11.3.1.1. Media Type 2089 Since a Filtered Network Map is still a Network Map, it uses the 2090 media type defined for Network Map at Section 11.2.1.1. 2092 11.3.1.2. HTTP Method 2094 A Filtered Network Map is requested using the HTTP POST method. 2096 11.3.1.3. Accept Input Parameters 2098 An ALTO Client supplies filtering parameters by specifying media type 2099 "application/alto-networkmapfilter+json" with HTTP POST body 2100 containing a JSON Object of type ReqFilteredNetworkMap, where: 2102 object { 2103 PIDName pids<0..*>; 2104 [AddressType address-types<0..*>;] 2105 } ReqFilteredNetworkMap; 2107 with fields: 2109 pids Specifies list of PIDs to be included in the returned Filtered 2110 Network Map. If the list of PIDs is empty, the ALTO Server MUST 2111 interpret the list as if it contained a list of all currently- 2112 defined PIDs. The ALTO Server MUST interpret entries appearing 2113 multiple times as if they appeared only once. 2115 address-types Specifies list of address types to be included in the 2116 returned Filtered Network Map. If the "address-types" field is not 2117 specified, or the list of address types is empty, the ALTO Server 2118 MUST interpret the list as if it contained a list of all address 2119 types known to the ALTO Server. The ALTO Server MUST interpret 2120 entries appearing multiple times as if they appeared only once. 2122 11.3.1.4. Capabilities 2124 None. 2126 11.3.1.5. Uses 2128 The Resource ID of the Network Map based on which the filtering is 2129 performed. 2131 11.3.1.6. Response 2133 The format is the same as unfiltered Network Map. See 2134 Section 11.2.1.6 for the format. 2136 The ALTO Server MUST only include PIDs in the response that were 2137 specified (implicitly or explicitly) in the request. If the input 2138 parameters contain a PID name that is not currently defined by the 2139 ALTO Server, the ALTO Server MUST behave as if the PID did not appear 2140 in the input parameters. Similarly, the ALTO Server MUST only 2141 enumerate addresses within each PID that have types which were 2142 specified (implicitly or explicitly) in the request. If the input 2143 parameters contain an address type that is not currently known to the 2144 ALTO Server, the ALTO Server MUST behave as if the address type did 2145 not appear in the input parameters. 2147 The Version Tag included in the "vtag" of the response MUST 2148 correspond to the full (unfiltered) Network Map Information Resource 2149 from which the filtered information is provided. This ensures that a 2150 single, canonical Version Tag is used independent of any filtering 2151 that is requested by an ALTO Client. 2153 11.3.1.7. Example 2155 POST /networkmap/filtered HTTP/1.1 2156 Host: custom.alto.example.com 2157 Content-Length: TBA 2158 Content-Type: application/alto-networkmapfilter+json 2159 Accept: application/alto-networkmap+json,application/alto-error+json 2161 { 2162 "pids": [ "PID1", "PID2" ] 2163 } 2165 HTTP/1.1 200 OK 2166 Content-Length: TBA 2167 Content-Type: application/alto-networkmap+json 2169 { 2170 "meta" : { 2171 "vtag" : [ 2172 {"resource-id": "my-default-network-map", 2173 "tag": "1266506139" 2174 } 2175 ] 2176 }, 2177 "network-map" : { 2178 "PID1" : { 2179 "ipv4" : [ 2180 "192.0.2.0/24", 2181 "198.51.100.0/24" 2182 ] 2183 }, 2184 "PID2" : { 2185 "ipv4": [ 2186 "198.51.100.128/24" 2187 ] 2188 } 2189 } 2190 } 2192 11.3.2. Filtered Cost Map 2194 A Filtered Cost Map is a Cost Map Information Resource 2195 (Section 11.2.2) for which an ALTO Client may supply additional 2196 parameters limiting the scope of the resulting Cost Map. A Filtered 2197 Cost Map MAY be provided by an ALTO Server. 2199 11.3.2.1. Media Type 2201 Since a Filtered Cost Map is still a Cost Map, it uses the media type 2202 defined for Cost Map at Section 11.2.2.1. 2204 11.3.2.2. HTTP Method 2206 A Filtered Cost Map is requested using the HTTP POST method. 2208 11.3.2.3. Accept Input Parameters 2210 The input parameters for a Filtered Map are supplied in the entity 2211 body of the POST request. This document specifies the input 2212 parameters with a data format indicated by the media type 2213 "application/alto-costmapfilter+json", which is a JSON Object of type 2214 ReqFilteredCostMap, where: 2216 object { 2217 CostType cost-type; 2218 [JSONString constraints<0..*>;] 2219 [PIDFilter pids;] 2220 } ReqFilteredCostMap; 2222 object { 2223 PIDName srcs<0..*>; 2224 PIDName dsts<0..*>; 2225 } PIDFilter; 2227 with fields: 2229 cost-type The CostType (Section 10.7) for the returned costs. The 2230 cost-metric and cost-mode fields MUST match one of the supported 2231 Cost Types indicated in this resource's capabilities 2232 (Section 11.3.2.4). The ALTO Client SHOULD omit the description 2233 field, and if present, the ALTO Server MUST ignore the description 2234 field. 2236 constraints Defines a list of additional constraints on which 2237 elements of the Cost Map are returned. This parameter MUST NOT be 2238 specified if this resource's capabilities ( Section 11.3.2.4) 2239 indicate that constraint support is not available. A constraint 2240 contains two entities separated by whitespace: (1) an operator, 2241 'gt' for greater than, 'lt' for less than, 'ge' for greater than 2242 or equal to, 'le' for less than or equal to, or 'eq' for equal to; 2243 (2) a target cost value. The cost value is a number that MUST be 2244 defined in the same units as the Cost Metric indicated by the 2245 cost-metric parameter. ALTO Servers SHOULD use at least IEEE 754 2246 double-precision floating point [IEEE.754.2008] to store the cost 2247 value, and SHOULD perform internal computations using double- 2248 precision floating-point arithmetic. If multiple 'constraint' 2249 parameters are specified, they are interpreted as being related to 2250 each other with a logical AND. 2252 pids A list of Source PIDs and a list of Destination PIDs for which 2253 Path Costs are to be returned. If a list is empty, the ALTO 2254 Server MUST interpret it as the full set of currently-defined 2255 PIDs. The ALTO Server MUST interpret entries appearing in a list 2256 multiple times as if they appeared only once. If the "pids" field 2257 is not present, both lists MUST be interpreted by the ALTO Server 2258 as containing the full set of currently-defined PIDs. 2260 11.3.2.4. Capabilities 2262 The URI providing this resource supports all capabilities documented 2263 in Section 11.2.2.4 (with identical semantics), plus additional 2264 capabilities. In particular, the capabilities are defined by a JSON 2265 object of type FilteredCostMapCapabilities: 2267 object { 2268 JSONString cost-type-names<1..*>; 2269 JSONBool cost-constraints; 2270 } FilteredCostMapCapabilities; 2272 with fields: 2274 cost-type-names See Section 11.2.2.4 and note that the array can 2275 have 1 to many cost types. 2277 cost-constraints If true, then the ALTO Server allows cost 2278 constraints to be included in requests to the corresponding URI. 2279 If not present, this field MUST be interpreted as if it specified 2280 false. ALTO Clients should be aware that constraints may not have 2281 the intended effect for cost maps with the 'ordinal' Cost Mode 2282 since ordinal costs are not restricted to being sequential 2283 integers. 2285 11.3.2.5. Uses 2287 The Resource ID of the Network Map based on which the Cost Map will 2288 be filtered. 2290 11.3.2.6. Response 2292 The format is the same as an unfiltered Cost Map. See 2293 Section 11.2.2.6 for the format. 2295 The "dependent-vtags" key in the "meta" field specifies a single 2296 element, which is the Version Tag of the Network Map used in 2297 filtering. ALTO Clients should verify that the Version Tag included 2298 in the response is consistent with the Version Tag of the Network Map 2299 used to generate the request (if applicable). If it is not, the ALTO 2300 Client may wish to request an updated Network Map, identify changes, 2301 and consider requesting a new Filtered Cost Map. 2303 The returned Cost Map MUST contain only source/destination pairs that 2304 have been indicated (implicitly or explicitly) in the input 2305 parameters. If the input parameters contain a PID name that is not 2306 currently defined by the ALTO Server, the ALTO Server MUST behave as 2307 if the PID did not appear in the input parameters. 2309 If any constraints are specified, Source/Destination pairs for which 2310 the Path Costs do not meet the constraints MUST NOT be included in 2311 the returned Cost Map. If no constraints were specified, then all 2312 Path Costs are assumed to meet the constraints. 2314 11.3.2.7. Example 2316 POST /costmap/filtered HTTP/1.1 2317 Host: custom.alto.example.com 2318 Content-Type: application/alto-costmapfilter+json 2319 Accept: application/alto-costmap+json,application/alto-error+json 2321 { 2322 "cost-type" : {"cost-mode": "numerical", 2323 "cost-metric": "routingcost" 2324 }, 2325 "pids" : { 2326 "srcs" : [ "PID1" ], 2327 "dsts" : [ "PID1", "PID2", "PID3" ] 2328 } 2329 } 2331 HTTP/1.1 200 OK 2332 Content-Length: TBA 2333 Content-Type: application/alto-costmap+json 2335 { 2336 "meta" : { 2337 "dependent-vtags" : [ 2338 {"resource-id": "my-default-network-map", 2339 "tag": "1266506139" 2340 } 2341 ], 2342 "cost-type": {"cost-mode" : "numerical", 2343 "cost-metric" : "routingcost" 2344 } 2345 }, 2346 "cost-map" : { 2347 "PID1": { "PID1": 0, "PID2": 1, "PID3": 2 } 2348 } 2349 } 2351 11.4. Endpoint Property Service 2353 The Endpoint Property Service provides information about Endpoint 2354 properties to ALTO Clients. 2356 11.4.1. Endpoint Property 2358 An Endpoint Property resource provides information about properties 2359 for individual endpoints. It MAY be provided by an ALTO Server. 2361 11.4.1.1. Media Type 2363 The media type of Endpoint Property is "application/ 2364 alto-endpointprop+json". 2366 11.4.1.2. HTTP Method 2368 The Endpoint Property resource is requested using the HTTP POST 2369 method. 2371 11.4.1.3. Accept Input Parameters 2373 An ALTO Client supplies the endpoint properties to be queried through 2374 a media type "application/alto-endpointpropparams+json", and 2375 specifies in the HTTP POST entity body a JSON Object of type 2376 ReqEndpointProp: 2378 object { 2379 EndpointPropertyType properties<1..*>; 2380 TypedEndpointAddr endpoints<1..*>; 2381 } ReqEndpointProp; 2383 with fields: 2385 properties List of endpoint properties to be returned for each 2386 endpoint. Each specified property MUST be included in the list of 2387 supported properties indicated by this resource's capabilities 2388 (Section 11.4.1.4). The ALTO Server MUST interpret entries 2389 appearing multiple times as if they appeared only once. 2391 endpoints List of endpoint addresses for which the specified 2392 properties are to be returned. The ALTO Server MUST interpret 2393 entries appearing multiple times as if they appeared only once. 2395 11.4.1.4. Capabilities 2397 This resource may be defined across multiple types of endpoint 2398 properties. The capabilities of an ALTO Server URI providing 2399 Endpoint Properties are defined by a JSON Object of type 2400 EndpointPropertyCapabilities: 2402 object { 2403 EndpointPropertyType prop-types<1..*>; 2404 } EndpointPropertyCapabilities; 2406 with field: 2408 prop-types The Endpoint Properties (see Section 10.8) supported by 2409 the corresponding URI. 2411 In particular, the Information Resource Closure MUST provide the look 2412 up of pid for every Network Map defined. 2414 11.4.1.5. Uses 2416 None. 2418 11.4.1.6. Response 2420 The "dependent-vtags" key in the "meta" field of the response MUST 2421 include the Version Tags of all Network Maps whose 'pid' is queried. 2423 The data component of an Endpoint Properties response is named 2424 "endpoint-properties", which is a JSON object of type 2425 EndpointPropertyMapData, where: 2427 object { 2428 EndpointPropertyMapData endpoint-properties; 2429 } InfoResourceEndpointProperties : ResponseEntityBase; 2431 object-map { 2432 TypedEndpointAddr -> EndpointProps; 2433 } EndpointPropertyMapData; 2435 object { 2436 EndpointPropertyType -> JSONValue; 2437 } EndpointProps; 2439 Specifically, an EndpointPropertyMapData object has one member for 2440 each endpoint indicated in the input parameters (with the name being 2441 the endpoint encoded as a TypedEndpointAddr). The requested 2442 properties for each endpoint are encoded in a corresponding 2443 EndpointProps object, which encodes one name/value pair for each 2444 requested property, where the property names are encoded as strings 2445 of type EndpointPropertyType. An implementation of the protocol in 2446 this document SHOULD assume that the property value is a JSONString 2447 and fail to parse if it is not, unless the implementation is using an 2448 extension to this document that indicates when and how property 2449 values of other data types are signaled. 2451 The ALTO Server returns the value for each of the requested endpoint 2452 properties for each of the endpoints listed in the input parameters. 2454 If the ALTO Server does not define a requested property's value for a 2455 particular endpoint, then it MUST omit that property from the 2456 response for only that endpoint. 2458 11.4.1.7. Example 2460 POST /endpointprop/lookup HTTP/1.1 2461 Host: alto.example.com 2462 Content-Length: TBA 2463 Content-Type: application/alto-endpointpropparams+json 2464 Accept: application/alto-endpointprop+json,application/alto-error+json 2466 { 2467 "properties" : [ "my-default-networkmap.pid", 2468 "priv:ietf-example-prop" ], 2469 "endpoints" : [ "ipv4:192.0.2.34", 2470 "ipv4:203.0.113.129" ] 2471 } 2473 HTTP/1.1 200 OK 2474 Content-Length: TBA 2475 Content-Type: application/alto-endpointprop+json 2477 { 2478 "meta" : { 2479 "dependent-vtags" : [ 2480 {"resource-id": "my-default-network-map", 2481 "tag": "1266506139" 2482 } 2483 ] 2484 }, 2485 "endpoint-properties": { 2486 "ipv4:192.0.2.34" : { "my-default-network-map.pid": "PID1", 2487 "priv:ietf-example-prop": "1" }, 2488 "ipv4:203.0.113.129" : { "my-default-network-map.pid": "PID3" } 2489 } 2490 } 2492 11.5. Endpoint Cost Service 2494 The Endpoint Cost Service provides information about costs between 2495 individual endpoints. 2497 In particular, this service allows lists of Endpoint prefixes (and 2498 addresses, as a special case) to be ranked (ordered) by an ALTO 2499 Server. 2501 11.5.1. Endpoint Cost 2503 An Endpoint Cost resource provides information about costs between 2504 individual endpoints. It MAY be provided by an ALTO Server. 2506 It is important to note that although this resource allows an ALTO 2507 Server to reveal costs between individual endpoints, an ALTO Server 2508 is not required to do so. A simple alternative would be to compute 2509 the cost between two endpoints as the cost between the PIDs 2510 corresponding to the endpoints. See Section 15.3 for additional 2511 details. 2513 11.5.1.1. Media Type 2515 The media type of Endpoint Cost is "application/ 2516 alto-endpointcost+json". 2518 11.5.1.2. HTTP Method 2520 The Endpoint Cost resource is requested using the HTTP POST method. 2522 11.5.1.3. Accept Input Parameters 2524 An ALTO Client supplies the endpoint cost parameters through a media 2525 type "application/alto-endpointcostparams+json", with an HTTP POST 2526 entity body of a JSON Object of type ReqEndpointCostMap: 2528 object { 2529 CostType cost-type; 2530 [JSONString constraints<0..*>;] 2531 EndpointFilter endpoints; 2532 } ReqEndpointCostMap; 2534 object { 2535 [TypedEndpointAddr srcs<0..*>;] 2536 [TypedEndpointAddr dsts<0..*>;] 2537 } EndpointFilter; 2538 with fields: 2540 cost-type The Cost Type (Section 10.7) to use for returned costs. 2541 The cost-metric and cost-mode fields MUST match one of the 2542 supported Cost Types indicated in this resource's capabilities ( 2543 Section 11.5.1.4). The ALTO Client SHOULD omit the description 2544 field, and if present, the ALTO Server MUST ignore the description 2545 field. 2547 constraints Defined equivalently to the "constraints" input 2548 parameter of a Filtered Cost Map (see Section 11.3.2). 2550 endpoints A list of Source Endpoints and Destination Endpoints for 2551 which Path Costs are to be returned. If the list of Source or 2552 Destination Endpoints is empty (or not included), the ALTO Server 2553 MUST interpret it as if it contained the Endpoint Address 2554 corresponding to the client IP address from the incoming 2555 connection (see Section 13.3 for discussion and considerations 2556 regarding this mode). The Source and Destination Endpoint lists 2557 MUST NOT be both empty. The ALTO Server MUST interpret entries 2558 appearing multiple times in a list as if they appeared only once. 2560 11.5.1.4. Capabilities 2562 In this document, we define EndpointCostCapabilities the same as 2563 FilteredCostMapCapabilities. See Section 11.3.2.4. 2565 11.5.1.5. Uses 2567 It is important to note that although this resource allows an ALTO 2568 Server to reveal costs between individual endpoints, an ALTO Server 2569 is not required to do so. A simple implementation of an ECS resource 2570 may compute the cost between two endpoints as the cost between the 2571 PIDs corresponding to the endpoints, using one of the exposed network 2572 and cost maps defined by the server. However, to preserve 2573 flexibility, the ECS resource MAY omit declaring in the "uses" 2574 attribute the network map and/or cost map on which it depends. 2576 11.5.1.6. Response 2578 The "meta" field of an Endpoint Cost response MUST include the "cost- 2579 type" key, to indicate the Cost Type used. 2581 The data component of an Endpoint Cost response is named "endpoint- 2582 cost-map", which is a JSON object of type EndpointCostMapData: 2584 object { 2585 EndpointCostMapData endpoint-cost-map; 2586 } InfoResourceEndpointCostMap : ResponseEntityBase; 2588 object-map { 2589 TypedEndpointAddr -> EndpointDstCosts; 2590 } EndpointCostMapData; 2592 object-map { 2593 TypedEndpointAddr -> JSONValue; 2594 } EndpointDstCosts; 2596 Specifically, an EndpointCostMapData object is a dictionary map with 2597 each key representing a TypedEndpointAddr string identifying the 2598 Source Endpoint specified in the input parameters. For each Source 2599 Endpoint, a EndpointDstCosts dictionary map object denotes the 2600 associated cost to each Destination Endpoint specified in input 2601 parameters. An implementation of the protocol in this document 2602 SHOULD assume that the cost value is a JSONNumber and fail to parse 2603 if it is not, unless the implementation is using an extension to this 2604 document that indicates when and how costs of other data types are 2605 signaled. If the ALTO Server does not define a cost value from a 2606 Source Endpoint to a particular Destination Endpoint, it MAY be 2607 omitted from the response. 2609 11.5.1.7. Example 2611 POST /endpointcost/lookup HTTP/1.1 2612 Host: alto.example.com 2613 Content-Length: TBA 2614 Content-Type: application/alto-endpointcostparams+json 2615 Accept: application/alto-endpointcost+json,application/alto-error+json 2617 { 2618 "cost-type": {"cost-mode" : "ordinal", 2619 "cost-metric" : "routingcost"}, 2620 "endpoints" : { 2621 "srcs": [ "ipv4:192.0.2.2" ], 2622 "dsts": [ 2623 "ipv4:192.0.2.89", 2624 "ipv4:198.51.100.34", 2625 "ipv4:203.0.113.45" 2626 ] 2627 } 2628 } 2630 HTTP/1.1 200 OK 2631 Content-Length: TBA 2632 Content-Type: application/alto-endpointcost+json 2634 { 2635 "meta" : { 2636 "cost-type": {"cost-mode" : "ordinal", 2637 "cost-metric" : "routingcost" 2638 } 2639 }, 2640 "endpoint-cost-map" : { 2641 "ipv4:192.0.2.2": { 2642 "ipv4:192.0.2.89" : 1, 2643 "ipv4:198.51.100.34" : 2, 2644 "ipv4:203.0.113.45" : 3 2645 } 2646 } 2647 } 2649 12. Use Cases 2651 The sections below depict typical use cases. While these use cases 2652 focus on peer-to-peer applications, ALTO can be applied to other 2653 environments such as CDNs [I-D.jenkins-alto-cdn-use-cases]. 2655 12.1. ALTO Client Embedded in P2P Tracker 2657 Many currently-deployed P2P systems use a Tracker to manage swarms 2658 and perform peer selection. Such a P2P Tracker can already use a 2659 variety of information to perform peer selection to meet application- 2660 specific goals. By acting as an ALTO Client, the P2P Tracker can use 2661 ALTO information as an additional information source to enable more 2662 network-efficient traffic patterns and improve application 2663 performance. 2665 A particular requirement of many P2P trackers is that they must 2666 handle a large number of P2P clients. A P2P tracker can obtain and 2667 locally store ALTO information (the Network Map and Cost Map) from 2668 the ISPs containing the P2P clients, and benefit from the same 2669 aggregation of network locations done by ALTO Servers. 2671 .---------. (1) Get Network Map .---------------. 2672 | | <----------------------> | | 2673 | ALTO | | P2P Tracker | 2674 | Server | (2) Get Cost Map | (ALTO Client) | 2675 | | <----------------------> | | 2676 `---------' `---------------' 2677 ^ | 2678 (3) Get Peers | | (4) Selected Peer 2679 | v List 2680 .---------. .-----------. 2681 | Peer 1 | <-------------- | P2P | 2682 `---------' | Client | 2683 . (5) Connect to `-----------' 2684 . Selected Peers / 2685 .---------. / 2686 | Peer 50 | <------------------ 2687 `---------' 2689 Figure 4: ALTO Client Embedded in P2P Tracker 2691 Figure 4 shows an example use case where a P2P tracker is an ALTO 2692 Client and applies ALTO information when selecting peers for its P2P 2693 clients. The example proceeds as follows: 2695 1. The P2P Tracker requests from the ALTO Server using the Network 2696 Map query the Network Map covering all PIDs. The Network Map 2697 includes the IP prefixes contained in each PID, allowing the P2P 2698 tracker to locally map P2P clients into PIDs. 2700 2. The P2P Tracker requests from the ALTO Server the Cost Map 2701 amongst all PIDs identified in the preceding step. 2703 3. A P2P Client joins the swarm, and requests a peer list from the 2704 P2P Tracker. 2706 4. The P2P Tracker returns a peer list to the P2P client. The 2707 returned peer list is computed based on the Network Map and Cost 2708 Map returned by the ALTO Server, and possibly other information 2709 sources. Note that it is possible that a tracker may use only 2710 the Network Map to implement hierarchical peer selection by 2711 preferring peers within the same PID and ISP. 2713 5. The P2P Client connects to the selected peers. 2715 Note that the P2P tracker may provide peer lists to P2P clients 2716 distributed across multiple ISPs. In such a case, the P2P tracker 2717 may communicate with multiple ALTO Servers. 2719 12.2. ALTO Client Embedded in P2P Client: Numerical Costs 2721 P2P clients may also utilize ALTO information themselves when 2722 selecting from available peers. It is important to note that not all 2723 P2P systems use a P2P tracker for peer discovery and selection. 2724 Furthermore, even when a P2P tracker is used, the P2P clients may 2725 rely on other sources, such as peer exchange and DHTs, to discover 2726 peers. 2728 When an P2P Client uses ALTO information, it typically queries only 2729 the ALTO Server servicing its own ISP. The my-Internet view provided 2730 by its ISP's ALTO Server can include preferences to all potential 2731 peers. 2733 .---------. (1) Get Network Map .---------------. 2734 | | <----------------------> | | 2735 | ALTO | | P2P Client | 2736 | Server | (2) Get Cost Map | (ALTO Client) | 2737 | | <----------------------> | | .---------. 2738 `---------' `---------------' <- | P2P | 2739 .---------. / | ^ ^ | Tracker | 2740 | Peer 1 | <-------------- | | \ `---------' 2741 `---------' | (3) Gather Peers 2742 . (4) Select Peers | | \ 2743 . and Connect / .--------. .--------. 2744 .---------. / | P2P | | DHT | 2745 | Peer 50 | <---------------- | Client | `--------' 2746 `---------' | (PEX) | 2747 `--------' 2749 Figure 5: ALTO Client Embedded in P2P Client 2751 Figure 5 shows an example use case where a P2P Client locally applies 2752 ALTO information to select peers. The use case proceeds as follows: 2754 1. The P2P Client requests the Network Map covering all PIDs from 2755 the ALTO Server servicing its own ISP. 2757 2. The P2P Client requests the Cost Map amongst all PIDs from the 2758 ALTO Server. The Cost Map by default specifies numerical costs. 2760 3. The P2P Client discovers peers from sources such as Peer Exchange 2761 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2762 P2P Trackers. 2764 4. The P2P Client uses ALTO information as part of the algorithm for 2765 selecting new peers, and connects to the selected peers. 2767 12.3. ALTO Client Embedded in P2P Client: Ranking 2769 It is also possible for a P2P Client to offload the selection and 2770 ranking process to an ALTO Server. In this use case, the ALTO Client 2771 gathers a list of known peers in the swarm, and asks the ALTO Server 2772 to rank them. 2774 As in the use case using numerical costs, the P2P Client typically 2775 only queries the ALTO Server servicing its own ISP. 2777 .---------. .---------------. 2778 | | | | 2779 | ALTO | (2) Get Endpoint Ranking | P2P Client | 2780 | Server | <----------------------> | (ALTO Client) | 2781 | | | | .---------. 2782 `---------' `---------------' <- | P2P | 2783 .---------. / | ^ ^ | Tracker | 2784 | Peer 1 | <-------------- | | \ `---------' 2785 `---------' | (1) Gather Peers 2786 . (3) Connect to | | \ 2787 . Selected Peers / .--------. .--------. 2788 .---------. / | P2P | | DHT | 2789 | Peer 50 | <---------------- | Client | `--------' 2790 `---------' | (PEX) | 2791 `--------' 2793 Figure 6: ALTO Client Embedded in P2P Client: Ranking 2795 Figure 6 shows an example of this scenario. The use case proceeds as 2796 follows: 2798 1. The P2P Client discovers peers from sources such as Peer Exchange 2799 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2800 P2P Trackers. 2802 2. The P2P Client queries the ALTO Server's Ranking Service, 2803 including discovered peers as the set of Destination Endpoints, 2804 and indicates the 'ordinal' Cost Mode. The response indicates 2805 the ranking of the candidate peers. 2807 3. The P2P Client connects to the peers in the order specified in 2808 the ranking. 2810 13. Discussions 2812 13.1. Discovery 2814 The discovery mechanism by which an ALTO Client locates an 2815 appropriate ALTO Server is out of scope for this document. This 2816 document assumes that an ALTO Client can discover an appropriate ALTO 2817 Server. Once it has done so, the ALTO Client may use the Information 2818 Resource Directory (see Section 9.2) to locate an Information 2819 Resource with the desired ALTO Information. 2821 13.2. Hosts with Multiple Endpoint Addresses 2823 In practical deployments, a particular host can be reachable using 2824 multiple addresses (e.g., a wireless IPv4 connection, a wireline IPv4 2825 connection, and a wireline IPv6 connection). In general, the 2826 particular network path followed when sending packets to the host 2827 will depend on the address that is used. Network providers may 2828 prefer one path over another. An additional consideration may be how 2829 to handle private address spaces (e.g., behind carrier-grade NATs). 2831 To support such behavior, this document allows multiple endpoint 2832 addresses and address types. With this support, the ALTO Protocol 2833 allows an ALTO Service Provider the flexibility to indicate 2834 preferences for paths from an endpoint address of one type to an 2835 endpoint address of a different type. 2837 13.3. Network Address Translation Considerations 2839 At this day and age of NAT v4<->v4, v4<->v6 [RFC6144], and possibly 2840 v6<->v6[I-D.mrw-nat66], a protocol should strive to be NAT friendly 2841 and minimize carrying IP addresses in the payload, or provide a mode 2842 of operation where the source IP address provide the information 2843 necessary to the server. 2845 The protocol specified in this document provides a mode of operation 2846 where the source network location is computed by the ALTO Server 2847 (i.e., the the Endpoint Cost Service) from the source IP address 2848 found in the ALTO Client query packets. This is similar to how some 2849 P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS 2850 Protocol" in [BitTorrent]) operate. 2852 There may be cases where an ALTO Client needs to determine its own IP 2853 address, such as when specifying a source Endpoint Address in the 2854 Endpoint Cost Service. It is possible that an ALTO Client has 2855 multiple network interface addresses, and that some or all of them 2856 may require NAT for connectivity to the public Internet. 2858 If a public IP address is required for a network interface, the ALTO 2859 Client SHOULD use the Session Traversal Utilities for NAT (STUN) 2860 [RFC5389]. If using this method, the host MUST use the "Binding 2861 Request" message and the resulting "XOR-MAPPED-ADDRESS" parameter 2862 that is returned in the response. Using STUN requires cooperation 2863 from a publicly accessible STUN server. Thus, the ALTO Client also 2864 requires configuration information that identifies the STUN server, 2865 or a domain name that can be used for STUN server discovery. To be 2866 selected for this purpose, the STUN server needs to provide the 2867 public reflexive transport address of the host. 2869 ALTO Clients should be cognizant that the network path between 2870 Endpoints can depend on multiple factors, e.g., source address, and 2871 destination address used for communication. An ALTO Server provides 2872 information based on Endpoint Addresses (more generally, Network 2873 Locations), but the mechanisms used for determining existence of 2874 connectivity or usage of NAT between Endpoints are out of scope of 2875 this document. 2877 13.4. Endpoint and Path Properties 2879 An ALTO Server could make available many properties about Endpoints 2880 beyond their network location or grouping. For example, connection 2881 type, geographical location, and others may be useful to 2882 applications. This specification focuses on network location and 2883 grouping, but the protocol may be extended to handle other Endpoint 2884 properties. 2886 14. IANA Considerations 2888 14.1. application/alto-* Media Types 2890 This document requests the registration of multiple media types, 2891 listed in Table 2. 2893 +-------------+------------------------------+----------------+ 2894 | Type | Subtype | Specification | 2895 +-------------+------------------------------+----------------+ 2896 | application | alto-directory+json | Section 9.2 | 2897 | application | alto-networkmap+json | Section 11.2.1 | 2898 | application | alto-networkmapfilter+json | Section 11.3.1 | 2899 | application | alto-costmap+json | Section 11.2.2 | 2900 | application | alto-costmapfilter+json | Section 11.3.2 | 2901 | application | alto-endpointprop+json | Section 11.4.1 | 2902 | application | alto-endpointpropparams+json | Section 11.4.1 | 2903 | application | alto-endpointcost+json | Section 11.5.1 | 2904 | application | alto-endpointcostparams+json | Section 11.5.1 | 2905 | application | alto-error+json | Section 8.5 | 2906 +-------------+------------------------------+----------------+ 2908 Table 2: ALTO Protocol Media Types. 2910 Type name: application 2912 Subtype name: This documents requests the registration of multiple 2913 subtypes, as listed in Table 2. 2915 Required parameters: n/a 2917 Optional parameters: n/a 2919 Encoding considerations: Encoding considerations are identical to 2920 those specified for the 'application/json' media type. See 2921 [RFC4627]. 2923 Security considerations: Security considerations relating to the 2924 generation and consumption of ALTO Protocol messages are discussed 2925 in Section 15. 2927 Interoperability considerations: This document specifies format of 2928 conforming messages and the interpretation thereof. 2930 Published specification: This document is the specification for 2931 these media types; see Table 2 for the section documenting each 2932 media type. 2934 Applications that use this media type: ALTO Servers and ALTO Clients 2935 either standalone or embedded within other applications. 2937 Additional information: 2939 Magic number(s): n/a 2941 File extension(s): This document uses the mime type to refer to 2942 protocol messages and thus does not require a file extension. 2944 Macintosh file type code(s): n/a 2946 Person & email address to contact for further information: See 2947 "Authors' Addresses" section. 2949 Intended usage: COMMON 2951 Restrictions on usage: n/a 2953 Author: See "Authors' Addresses" section. 2955 Change controller: Internet Engineering Task Force 2956 (mailto:iesg@ietf.org). 2958 14.2. ALTO Cost Metric Registry 2960 This document requests the creation of an ALTO Cost Metric registry, 2961 listed in Table 3, to be maintained by IANA. 2963 +-------------+---------------------+ 2964 | Identifier | Intended Semantics | 2965 +-------------+---------------------+ 2966 | routingcost | See Section 6.1.1.1 | 2967 | priv: | Private use | 2968 | exp: | Experimental use | 2969 +-------------+---------------------+ 2971 Table 3: ALTO Cost Metrics. 2973 This registry serves two purposes. First, it ensures uniqueness of 2974 identifiers referring to ALTO Cost Metrics. Second, it provides 2975 references to particular semantics of allocated Cost Metrics to be 2976 applied by both ALTO Servers and applications utilizing ALTO Clients. 2978 New ALTO Cost Metrics are assigned after Expert Review [RFC5226]. 2979 The Expert Reviewer will generally consult the ALTO Working Group or 2980 its successor. Expert Review is used to ensure that proper 2981 documentation regarding ALTO Cost Metric semantics and security 2982 considerations has been provided. The provided documentation should 2983 be detailed enough to provide guidance to both ALTO Service Providers 2984 and applications utilizing ALTO Clients as to how values of the 2985 registered ALTO Cost Metric should be interpreted. Updates and 2986 deletions of ALTO Cost Metrics follow the same procedure. 2988 Registered ALTO Cost Metric identifiers MUST conform to the 2989 syntactical requirements specified in Section 10.6. Identifiers are 2990 to be recorded and displayed as ASCII strings. 2992 Identifiers prefixed with 'priv:' are reserved for Private Use. 2993 Identifiers prefixed with 'exp:' are reserved for Experimental use. 2995 Requests to add a new value to the registry MUST include the 2996 following information: 2998 o Identifier: The name of the desired ALTO Cost Metric. 3000 o Intended Semantics: ALTO Costs carry with them semantics to guide 3001 their usage by ALTO Clients. For example, if a value refers to a 3002 measurement, the measurement units must be documented. For proper 3003 implementation of the ordinal Cost Mode (e.g., by a third-party 3004 service), it should be documented whether higher or lower values 3005 of the cost are more preferred. 3007 o Security Considerations: ALTO Costs expose information to ALTO 3008 Clients. As such, proper usage of a particular Cost Metric may 3009 require certain information to be exposed by an ALTO Service 3010 Provider. Since network information is frequently regarded as 3011 proprietary or confidential, ALTO Service Providers should be made 3012 aware of the security ramifications related to usage of a Cost 3013 Metric. 3015 This specification requests registration of the identifier 3016 'routingcost'. Semantics for the this Cost Metric are documented in 3017 Section 6.1.1.1, and security considerations are documented in 3018 Section 15.3. 3020 14.3. ALTO Endpoint Property Type Registry 3022 This document requests the creation of an ALTO Endpoint Property 3023 Types registry, listed in Table 4, to be maintained by IANA. 3025 +------------+--------------------+ 3026 | Identifier | Intended Semantics | 3027 +------------+--------------------+ 3028 | pid | See Section 7.1.1 | 3029 | priv: | Private use | 3030 | exp: | Experimental use | 3031 +------------+--------------------+ 3033 Table 4: ALTO Endpoint Property Types. 3035 The maintenance of this registry is similar to that of the preceding 3036 ALTO Cost Metrics. 3038 14.4. ALTO Address Type Registry 3040 This document requests the creation of an ALTO Address Type registry, 3041 listed in Table 5, to be maintained by IANA. 3043 +------------+-----------------+-----------------+------------------+ 3044 | Identifier | Address | Prefix Encoding | Mapping to/from | 3045 | | Encoding | | IPv4/v6 | 3046 +------------+-----------------+-----------------+------------------+ 3047 | ipv4 | See | See | Direct mapping | 3048 | | Section 10.4.2 | Section 10.4.3 | to IPv4 | 3049 | ipv6 | See | See | Direct mapping | 3050 | | Section 10.4.2 | Section 10.4.3 | to IPv6 | 3051 +------------+-----------------+-----------------+------------------+ 3053 Table 5: ALTO Address Types. 3055 This registry serves two purposes. First, it ensures uniqueness of 3056 identifiers referring to ALTO Address Types. Second, it states the 3057 requirements for allocated Address Type identifiers. 3059 New ALTO Address Types are assigned after Expert Review [RFC5226]. 3060 The Expert Reviewer will generally consult the ALTO Working Group or 3061 its successor. Expert Review is used to ensure that proper 3062 documentation regarding the new ALTO Address Types and their security 3063 considerations has been provided. The provided documentation should 3064 indicate how an address of a registered type is encoded as an 3065 EndpointAddr and, if possible, a compact method (e.g., IPv4 and IPv6 3066 prefixes) for encoding a set of addresses as an EndpointPrefix. 3067 Updates and deletions of ALTO Address Types follow the same 3068 procedure. 3070 Registered ALTO Address Type identifiers MUST conform to the 3071 syntactical requirements specified in Section 10.4.1. Identifiers 3072 are to be recorded and displayed as ASCII strings. 3074 Requests to add a new value to the registry MUST include the 3075 following information: 3077 o Identifier: The name of the desired ALTO Address Type. 3079 o Endpoint Address Encoding: The procedure for encoding an address 3080 of the registered type as an EndpointAddr (see Section 10.4.2). 3082 o Endpoint Prefix Encoding: The procedure for encoding a set of 3083 addresses of the registered type as an EndpointPrefix (see 3084 Section 10.4.3). If no such compact encoding is available, the 3085 same encoding used for a singular address may be used. In such a 3086 case, it must be documented that sets of addresses of this type 3087 always have exactly one element. 3089 o Mapping to/from IPv4/IPv6 Addresses: If possible, a mechanism to 3090 map addresses of the registered type to and from IPv4 or IPv6 3091 addresses should be specified. 3093 o Security Considerations: In some usage scenarios, Endpoint 3094 Addresses carried in ALTO Protocol messages may reveal information 3095 about an ALTO Client or an ALTO Service Provider. Applications 3096 and ALTO Service Providers using addresses of the registered type 3097 should be made aware of how (or if) the addressing scheme relates 3098 to private information and network proximity. 3100 This specification requests registration of the identifiers 'ipv4' 3101 and 'ipv6', as shown in Table 5. 3103 14.5. ALTO Error Code Registry 3105 This document requests the creation of an ALTO Error Code registry, 3106 listed in Table 1, to be maintained by IANA. 3108 15. Security Considerations 3110 Some environments and use cases of ALTO require consideration of 3111 security attacks on ALTO Servers and Clients. In order to support 3112 those environments interoperably, the ALTO requirements document 3113 [RFC6708] outlines minimum-to-implement authentication and other 3114 security requirements. Below we consider the threats and protection 3115 strategies. 3117 15.1. Authenticity and Integrity of ALTO Information 3119 15.1.1. Risk Scenarios 3121 An attacker may want to provide false or modified ALTO Information 3122 Resources or Information Resource Directory to ALTO Clients to 3123 achieve certain malicious goals. As an example, an attacker may 3124 provide false endpoint properties. For example, suppose that a 3125 network supports an endpoint property named "hasQuota" which reports 3126 if the endpoint has usage quota. An attacker may want to generate a 3127 false reply to lead to unexpected charges to the endpoint. An attack 3128 may also want to provide false Cost Map. For example, by faking a 3129 Cost Map that highly prefers a small address range or a single 3130 address, the attacker may be able to turn a distributed application 3131 into a Distributed Denial of Service (DDoS) tool. 3133 Depending on the network scenario, an attacker can attack 3134 authenticity and integrity of ALTO Information Resources using 3135 various techniques, including, but not limited to, sending forged 3136 DHCP replies in an Ethernet, DNS poisoning, and installing a 3137 transparent HTTP proxy that does some modifications. 3139 15.1.2. Protection Strategies 3141 ALTO protects the authenticity and integrity of ALTO Information 3142 (both Information Directory and individual Information Resources) by 3143 leveraging the authenticity and integrity mechanisms in TLS. In 3144 particular, the ALTO Protocol requires that HTTP over TLS [RFC2818] 3145 MUST be supported, when protecting the authenticity and integrity of 3146 ALTO Information is required. The rules in [RFC2818] for a client to 3147 verify server identity using server certificates MUST be supported. 3148 ALTO Providers who request server certificates and certification 3149 authorities who issue ALTO-specific certificates SHOULD consider the 3150 recommendations and guidelines defined in [RFC6125] 3152 Software engineers developing and service providers deploying ALTO 3153 should make themselves familiar with up-to-date Best Current 3154 Practices on configuring HTTP over TLS. 3156 15.1.3. Limitations 3158 The protection of HTTP over TLS for ALTO depends on that the domain 3159 name in the URI for the Information Resources is not comprised. This 3160 will depend on the protection implemented by service discovery. 3162 A deployment scenario may require redistribution of ALTO information 3163 to improve scalability. When authenticity and integrity of ALTO 3164 information are still required, then ALTO Clients obtaining ALTO 3165 information through redistribution must be able to validate the 3166 received ALTO information. Support for this validation is not 3167 provided in this document, but may be provided by extension 3168 documents. 3170 15.2. Potential Undesirable Guidance from Authenticated ALTO 3171 Information 3173 15.2.1. Risk Scenarios 3175 The ALTO Service makes it possible for an ALTO Provider to influence 3176 the behavior of network applications. An ALTO Provider may be 3177 hostile to some applications and hence try to use ALTO Information 3178 Resources to achieve certain goals [RFC5693]: "redirecting 3179 applications to corrupted mediators providing malicious content, or 3180 applying policies in computing Cost Map based on criteria other than 3181 network efficiency." See [I-D.ietf-alto-deployments] for additional 3182 discussions on faked ALTO Guidance. 3184 A related scenario is that an ALTO Server could unintentionally give 3185 "bad" guidance. For example, if many ALTO Clients follow the Cost 3186 Map or Endpoint Cost guidance without doing additional sanity checks 3187 or adaptation, more preferable hosts and/or links could get 3188 overloaded while less preferable ones remain idle; see AR-14 of 3189 [RFC6708] for related application considerations. 3191 15.2.2. Protection Strategies 3193 To protect applications from undesirable ALTO Information Resources, 3194 it is important to note that there is no protocol mechanism to 3195 require conforming behaviors on how applications use ALTO Information 3196 Resources. An application using ALTO may consider including a 3197 mechanism to detect misleading or undesirable results from using ALTO 3198 Information Resources. For example, if throughput measurements do 3199 not show "better-than-random" results when using the Cost Map to 3200 select resource providers, the application may want to disable ALTO 3201 usage or switch to an external ALTO Server provided by an 3202 "independent organization" (see AR-20 and AR-21 in [RFC 6708]). If 3203 the first ALTO Server is provided by the access network service 3204 provider and the access network service provider tries to redirect 3205 access to the external ALTO Server back to the provider's ALTO Server 3206 or try to tamper with the responses, the preceding authentication and 3207 integrity protection can detect such a behavior. 3209 15.3. Confidentiality of ALTO Information 3211 15.3.1. Risk Scenarios 3213 Although in many cases ALTO Information Resources may be regarded as 3214 non-confidential information, there are deployment cases where ALTO 3215 Information Resources can be sensitive information that can pose 3216 risks if exposed to unauthorized parties. We discuss the risks and 3217 protection strategies for such deployment scenarios. 3219 For example, an attacker may infer details regarding the topology, 3220 status, and operational policies of a network through the Network and 3221 Cost Maps. As a result, a sophisticated attacker may be able to 3222 infer more fine-graind topology information than an ISP hosting an 3223 ALTO Server intends to disclose. The attacker can leverage the 3224 information to mount effective attacks such as focusing on high-cost 3225 links. 3227 Revealing some endpoint properties may also reveal additional 3228 information than the Provider intended. For example, when adding the 3229 line bitrate as one endpoint property, such information may be 3230 potentially linked to the income of the habitants at the network 3231 location of an endpoint. 3233 In [RFC6708] Section 5.2.1, three types of risks associated with the 3234 confidentiality of ALTO Information Resources are identified: risk 3235 type (1) Excess disclosure of the ALTO service provider's data to an 3236 authorized ALTO Client; risk type (2) Disclosure of the ALTO service 3237 provider's data (e.g., network topology information) to an 3238 unauthorized third party; and risk type (3) Excess retrieval of the 3239 ALTO service provider's data by collaborating ALTO Clients. Section 3240 10 of [I-D.ietf-alto-deployments] also discusses information leakage 3241 from ALTO. 3243 15.3.2. Protection Strategies 3245 To address risk types (1) and (3), the Provider of an ALTO Server 3246 must be cognizant that the network topology and provisioning 3247 information provided through ALTO may lead to attacks. ALTO does not 3248 require any particular level of details of information disclosure, 3249 and hence the Provider should evaluate how much information is 3250 revealed and the associated risks. 3252 To address risk type (2), the ALTO Protocol need confidentiality. 3253 Since ALTO requires that HTTP over TLS MUST be supported, the 3254 confidentiality mechanism is provided by HTTP over TLS. 3256 For deployment scenarios where client authentication is desired to 3257 address risk type (2), ALTO requires that HTTP Digestion 3258 Authentication MUST be supported to achieve ALTO Client 3259 Authentication to limit the number of parties with whom ALTO 3260 information is directly shared. Depending on the use-case and 3261 scenario, an ALTO Server may apply other access control techniques to 3262 restrict access to its services. Access control can also help to 3263 prevent Denial-of-Service attacks by arbitrary hosts from the 3264 Internet. See [I-D.ietf-alto-deployments] for a more detailed 3265 discussion on this issue. 3267 15.3.3. Limitations 3269 ALTO Information Providers should be cognizant that encryption only 3270 protects ALTO information until it is decrypted by the intended ALTO 3271 Client. Digital Rights Management (DRM) techniques and legal 3272 agreements protecting ALTO information are outside of the scope of 3273 this document. 3275 15.4. Privacy for ALTO Users 3277 15.4.1. Risk Scenarios 3279 The ALTO Protocol provides mechanisms in which the ALTO Client 3280 serving a user can send messages containing Network Location 3281 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server. 3282 This is particularly true for the Endpoint Property, Endpoint Cost, 3283 and fine-grained Filtered Map services. The ALTO Server or a third- 3284 party who is able to intercept such messages can store and process 3285 obtained information in order to analyze user behaviors and 3286 communication patterns. The analysis may correlate information 3287 collected from multiple clients to deduce additional application/ 3288 content information. Such analysis can lead to privacy risks. For a 3289 more comprehensive classification of related risk scenarios, see 3290 cases 4, 5, and 6 in [RFC 6708], Section 5.2. 3292 15.4.2. Protection Strategies 3294 To protect user privacy, an ALTO Client should be cognizant about 3295 potential ALTO Server tracking through client queries. An ALTO 3296 Client may consider the possibility of relying only on Network Map 3297 for PIDs and Cost Map amongst PIDs to avoid passing IP addresses of 3298 other endpoints (e.g., peers) to the ALTO Server. When specific IP 3299 addresses are needed (e.g., when using the Endpoint Cost Service), an 3300 ALTO Client may consider obfuscation techniques such as specifying a 3301 broader address range (i.e., a shorter prefix length) or by zeroing 3302 out or randomizing the last few bits of IP addresses. Note that 3303 obfuscation may yield less accurate results. 3305 15.5. Availability of ALTO Service 3307 15.5.1. Risk Scenarios 3309 An attacker may want to disable ALTO Service as a way to disable 3310 network guidance to large scale applications.In particular, queries 3311 which can be generated with low effort but result in expensive 3312 workloads at the ALTO Server could be exploited for Denial-of-Service 3313 attacks. For instance, a simple ALTO query with n Source Network 3314 Locations and m Destination Network Locations can be generated fairly 3315 easily but results in the computation of n*m Path Costs between pairs 3316 by the ALTO Server (see Section 5.2). 3318 15.5.2. Protection Strategies 3320 ALTO Provider should be cognizant of the workload at the ALTO Server 3321 generated by certain ALTO Queries, such as certain queries to the Map 3322 Service, the Map Filtering Service and the Endpoint Cost (Ranking) 3323 Service. One way to limit Denial-of-Service attacks is to employ 3324 access control to the ALTO Server. The ALTO Server can also indicate 3325 overload and reject repeated requests that can cause availability 3326 problems. More advanced protection schemes such as computational 3327 puzzles [I-D.jennings-sip-hashcash] may be considered in an extension 3328 document. 3330 An ALTO Provider should also leverage the fact that the Map Service 3331 allows ALTO Servers to pre-generate maps that can be distributed to 3332 many ALTO Clients. 3334 16. Manageability Considerations 3336 This section details operations and management considerations based 3337 on existing deployments and discussions during protocol development. 3338 It also indicates where extension documents are expected to provide 3339 appropriate functionality discussed in [RFC5706] as additional 3340 deployment experience becomes available. 3342 16.1. Operations 3343 16.1.1. Installation and Initial Setup 3345 The ALTO Protocol is based on HTTP. Thus, configuring an ALTO Server 3346 may require configuring the underlying HTTP server implementation to 3347 define appropriate security policies, caching policies, performance 3348 settings, etc. 3350 Additionally, an ALTO Service Provider will need to configure the 3351 ALTO information to be provided by the ALTO Server. The granularity 3352 of the topological map and the cost map is left to the specific 3353 policies of the ALTO Service Provider. However, a reasonable default 3354 may include two PIDs, one to hold the endpoints in the provider's 3355 network and the second PID to represent full IPv4 and IPv6 3356 reachability (see Section 5.2.1), with the cost between each source/ 3357 destination PID set to 1. Another operational issue that the ALTO 3358 Service Provider needs to consider is that the filtering service can 3359 degenerate into a full map service when the filtering input is empty. 3360 Although this choice as the degeneration behavior provides 3361 continuity, the operational impact should be considered. 3363 Implementers employing an ALTO Client should attempt to automatically 3364 discover an appropriate ALTO Server. Manual configuration of the 3365 ALTO Server location may be used where automatic discovery is not 3366 appropriate. Methods for automatic discovery and manual 3367 configuration are discussed in [I-D.ietf-alto-server-discovery]. 3369 Specifications for underlying protocols (e.g., TCP, HTTP, SSL/TLS) 3370 should be consulted for their available settings and proposed default 3371 configurations. 3373 16.1.2. Migration Path 3375 This document does not detail a migration path for ALTO Servers since 3376 there is no previous standard protocol providing the similar 3377 functionality. 3379 There are existing applications making use of network information 3380 discovered from other entities such as whois, geo-location databases, 3381 or round-trip time measurements, etc. Such applications should 3382 consider using ALTO as an additional source of information; ALTO need 3383 not be the sole source of network information. 3385 16.1.3. Requirements on Other Protocols and Functional Components 3387 The ALTO Protocol assumes that HTTP client and server implementations 3388 exist. It also assumes that JSON encoder and decoder implementations 3389 exist. 3391 An ALTO Server assumes that it can gather sufficient information to 3392 populate Network and Cost maps. "Sufficient information" is 3393 dependent on the information being exposed, but likely includes 3394 information gathered from protocols such as IGP and EGP Routing 3395 Information Bases (see Figure 1). Specific mechanisms have been 3396 proposed (e.g., [I-D.medved-alto-svr-apis]) and are expected to be 3397 provided in extension documents. 3399 16.1.4. Impact and Observation on Network Operation 3401 ALTO presents a new opportunity for managing network traffic by 3402 providing additional information to clients. The potential impact to 3403 network operation is large. 3405 Deployment of an ALTO Server may shift network traffic patterns. 3406 Thus, an ALTO Service Provider should consider impacts on (or 3407 integration with) traffic engineering and the deployment of a 3408 monitoring service to observe the effects of ALTO operations. Note 3409 that ALTO-specific monitoring and metrics are discussed in 6.3 of 3410 [I-D.ietf-alto-deployments] and future versions of that document. In 3411 particular, an ALTO Service Provider may observe that ALTO Clients 3412 are not bound to ALTO Server guidance as ALTO is only one source of 3413 information. 3415 An ALTO Service Provider should ensure that appropriate information 3416 is being exposed. Privacy implications for ISPs are discussed in 3417 Section 15.3. Both ALTO Service Providers and those using ALTO 3418 Clients should be aware of the impact of incorrect or faked guidance 3419 (see Section 10.3 of [I-D.ietf-alto-deployments] and future versions 3420 of that document). 3422 16.2. Management 3424 16.2.1. Management Interoperability 3426 A common management API would be desirable given that ALTO Servers 3427 may typically be configured with dynamic data from various sources, 3428 and ALTO Servers are intended to scale horizontally for fault- 3429 tolerance and reliability. A specific API or protocol is outside the 3430 scope of this document, but may be provided by an extension document. 3432 Logging is an important functionality for ALTO Servers and, depending 3433 on the deployment, ALTO Clients. Logging should be done via syslog 3434 [RFC5424]. 3436 16.2.2. Management Information 3438 A Management Information Model (see Section 3.2 of [RFC5706] is not 3439 provided by this document, but should be included or referenced by 3440 any extension documenting an ALTO-related management API or protocol. 3442 16.2.3. Fault Management 3444 Monitoring ALTO Servers and Clients is described in Section 6.3 of 3445 [I-D.ietf-alto-deployments] and future versions of that document. 3447 16.2.4. Configuration Management 3449 Standardized approaches and protocols to configuration management for 3450 ALTO are outside the scope of this document, but this document does 3451 outline high-level principles suggested for future standardization 3452 efforts. 3454 An ALTO Server requires at least the following logical inputs: 3456 o Data sources from which ALTO Information is derived. This can 3457 either be raw network information (e.g., from routing elements) or 3458 pre-processed ALTO-level information in the form of a Network Map, 3459 Cost Map, etc. 3461 o Algorithms for computing the ALTO information returned to clients. 3462 These could either return information from a database, or 3463 information customized for each client. 3465 o Security policies mapping potential clients to the information 3466 that they have privilege to access. 3468 Multiple ALTO Servers can be deployed for scalability. A centralized 3469 configuration database may be used to ensure they are providing the 3470 desired ALTO information with appropriate security controls. The 3471 ALTO information (e.g., Network Maps and Cost Maps) being served by 3472 each ALTO Server, as well as security policies (HTTP authentication, 3473 SSL/TLS client and server authentication, SSL/TLS encryption 3474 parameters) intended to serve the same information should be 3475 monitored for consistency. 3477 16.2.5. Performance Management 3479 An exhaustive list of desirable performance information from a ALTO 3480 Servers and ALTO Clients are outside of the scope of this document. 3481 The following is a list of suggested ALTO-specific to be monitored 3482 based on the existing deployment and protocol development experience: 3484 o Requests and responses for each service listed in a Information 3485 Directory (total counts and size in bytes). 3487 o CPU and memory utilization 3489 o ALTO map updates 3491 o Number of PIDs 3493 o ALTO map sizes (in-memory size, encoded size, number of entries) 3495 16.2.6. Security Management 3497 Section 15 documents ALTO-specific security considerations. 3498 Operators should configure security policies with those in mind. 3499 Readers should refer to HTTP [RFC2616] and SSL/TLS [RFC5246] and 3500 related documents for mechanisms available for configuring security 3501 policies. Other appropriate security mechanisms (e.g., physical 3502 security, firewalls, etc) should also be considered. 3504 17. References 3506 17.1. Normative References 3508 [IEEE.754.2008] 3509 Institute of Electrical and Electronics Engineers, 3510 "Standard for Binary Floating-Point Arithmetic", IEEE 3511 Standard 754, August 2008. 3513 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 3514 Extensions (MIME) Part Two: Media Types", RFC 2046, 3515 November 1996. 3517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3518 Requirement Levels", BCP 14, RFC 2119, March 1997. 3520 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3521 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3522 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3524 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3526 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3527 Resource Identifier (URI): Generic Syntax", STD 66, 3528 RFC 3986, January 2005. 3530 [RFC4627] Crockford, D., "The application/json Media Type for 3531 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 3533 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 3534 (CIDR): The Internet Address Assignment and Aggregation 3535 Plan", BCP 122, RFC 4632, August 2006. 3537 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3538 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3539 May 2008. 3541 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3542 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 3544 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3545 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3546 October 2008. 3548 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 3550 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 3551 Optimization (ALTO) Problem Statement", RFC 5693, 3552 October 2009. 3554 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 3555 Address Text Representation", RFC 5952, August 2010. 3557 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3558 Verification of Domain-Based Application Service Identity 3559 within Internet Public Key Infrastructure Using X.509 3560 (PKIX) Certificates in the Context of Transport Layer 3561 Security (TLS)", RFC 6125, March 2011. 3563 [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 3564 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 3565 Requirements", RFC 6708, September 2012. 3567 17.2. Informative References 3569 [BitTorrent] 3570 "Bittorrent Protocol Specification v1.0", 3571 . 3573 [Fielding-Thesis] 3574 Fielding, R., "Architectural Styles and the Design of 3575 Network-based Software Architectures", University of 3576 California, Irvine, Dissertation 2000, 2000. 3578 [I-D.akonjang-alto-proxidor] 3579 Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 3580 Saucez, "The PROXIDOR Service", 3581 draft-akonjang-alto-proxidor-00 (work in progress), 3582 March 2009. 3584 [I-D.ietf-alto-deployments] 3585 Stiemerling, M., Kiesel, S., Previdi, S., and M. Scharf, 3586 "ALTO Deployment Considerations", 3587 draft-ietf-alto-deployments-07 (work in progress), 3588 July 2013. 3590 [I-D.ietf-alto-server-discovery] 3591 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 3592 S. Yongchao, "ALTO Server Discovery", 3593 draft-ietf-alto-server-discovery-10 (work in progress), 3594 September 2013. 3596 [I-D.ietf-httpbis-p2-semantics] 3597 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 3598 (HTTP/1.1): Semantics and Content", 3599 draft-ietf-httpbis-p2-semantics-24 (work in progress), 3600 September 2013. 3602 [I-D.jenkins-alto-cdn-use-cases] 3603 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 3604 S. Previdi, "Use Cases for ALTO within CDNs", 3605 draft-jenkins-alto-cdn-use-cases-03 (work in progress), 3606 June 2012. 3608 [I-D.medved-alto-svr-apis] 3609 Medved, J., Ward, D., Peterson, J., Woundy, R., and D. 3610 McDysan, "ALTO Network-Server and Server-Server APIs", 3611 draft-medved-alto-svr-apis-00 (work in progress), 3612 March 2011. 3614 [I-D.mrw-nat66] 3615 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 3616 Translation", draft-mrw-nat66-16 (work in progress), 3617 April 2011. 3619 [I-D.p4p-framework] 3620 Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, 3621 "P4P: Provider Portal for P2P Applications", 3622 draft-p4p-framework-00 (work in progress), November 2008. 3624 [I-D.saumitra-alto-multi-ps] 3625 Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 3626 Dimensional Peer Selection Problem", 3627 draft-saumitra-alto-multi-ps-00 (work in progress), 3628 October 2008. 3630 [I-D.saumitra-alto-queryresponse] 3631 Das, S. and V. Narayanan, "A Client to Service Query 3632 Response Protocol for ALTO", 3633 draft-saumitra-alto-queryresponse-00 (work in progress), 3634 March 2009. 3636 [I-D.shalunov-alto-infoexport] 3637 Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 3638 Export Service", draft-shalunov-alto-infoexport-00 (work 3639 in progress), October 2008. 3641 [I-D.wang-alto-p4p-specification] 3642 Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, 3643 "P4P Protocol Specification", 3644 draft-wang-alto-p4p-specification-00 (work in progress), 3645 March 2009. 3647 [P4P-SIGCOMM08] 3648 Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A. 3649 Silberschatz, "P4P: Provider Portal for (P2P) 3650 Applications", SIGCOMM 2008, August 2008. 3652 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 3653 Management of New Protocols and Protocol Extensions", 3654 RFC 5706, November 2009. 3656 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 3657 IPv4/IPv6 Translation", RFC 6144, April 2011. 3659 Appendix A. Acknowledgments 3661 Thank you to Sebastian Kiesel (University of Stuttgart) and Jan 3662 Seedorf (NEC) for substantial contributions to the Security 3663 Considerations section. Ben Niven-Jenkins (Velocix), Michael Scharf 3664 and Sabine Randriamasy (Alcatel-Lucent) gave substantial feedback and 3665 suggestions on the protocol design. We are particularly grateful to 3666 the substantial contributions of Wendy Roome (Alcatel-Lucent). 3668 We would like to thank the following people whose input and 3669 involvement was indispensable in achieving this merged proposal: 3671 Obi Akonjang (DT Labs/TU Berlin), 3672 Saumitra M. Das (Qualcomm Inc.), 3674 Syon Ding (China Telecom), 3676 Doug Pasko (Verizon), 3678 Laird Popkin (Pando Networks), 3680 Satish Raghunath (Juniper Networks), 3682 Albert Tian (Ericsson/Redback), 3684 Yu-Shun Wang (Microsoft), 3686 David Zhang (PPLive), 3688 Yunfei Zhang (China Mobile). 3690 We would also like to thank the following additional people who were 3691 involved in the projects that contributed to this merged document: 3692 Alex Gerber (ATT), Chris Griffiths (Comcast), Ramit Hora (Pando 3693 Networks), Arvind Krishnamurthy (University of Washington), Marty 3694 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 3695 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (ATT), 3696 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 3697 Damien Saucez (UCL) Thomas Scholl (ATT), Emilio Sepulveda 3698 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 3699 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 3700 (Huawei), Oliver Spatscheck (ATT), See-Mong Tang (Microsoft), Jia 3701 Wang (ATT), Hao Wang (Yale University), Ye Wang (Yale University), 3702 Haiyong Xie (Yale University). 3704 Appendix B. Design History and Merged Proposals 3706 The ALTO Protocol specified in this document consists of 3707 contributions from 3709 o P4P [I-D.p4p-framework], [P4P-SIGCOMM08], 3710 [I-D.wang-alto-p4p-specification]; 3712 o ALTO Info-Export [I-D.shalunov-alto-infoexport]; 3714 o Query/Response [I-D.saumitra-alto-queryresponse], 3715 [I-D.saumitra-alto-multi-ps]; 3717 o ATTP [ATTP]; and 3718 o Proxidor [I-D.akonjang-alto-proxidor]. 3720 Appendix C. Authors 3722 [[CmtAuthors: RFC Editor: Please move information in this section to 3723 the Authors' Addresses section at publication time.]] 3725 Stefano Previdi 3726 Cisco 3728 Email: sprevidi@cisco.com 3730 Stanislav Shalunov 3731 BitTorrent 3733 Email: shalunov@bittorrent.com 3735 Richard Woundy 3736 Comcast 3738 Richard_Woundy@cable.comcast.com 3740 Authors' Addresses 3742 Richard Alimi (editor) 3743 Google 3744 1600 Amphitheatre Parkway 3745 Mountain View CA 3746 USA 3748 Email: ralimi@google.com 3750 Reinaldo Penno (editor) 3751 Cisco Systems 3752 170 West Tasman Dr 3753 San Jose CA 3754 USA 3756 Email: repenno@cisco.com 3757 Y. Richard Yang (editor) 3758 Yale University 3759 51 Prospect St 3760 New Haven CT 3761 USA 3763 Email: yry@cs.yale.edu