idnits 2.17.1 draft-ietf-alto-protocol-15.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 1063 has weird spacing: '...ilities capa...' == Line 1318 has weird spacing: '...ataType data...' == Line 1323 has weird spacing: '... meta meta-...' == Line 1325 has weird spacing: '... data the d...' == Line 1605 has weird spacing: '...stModel cost-...' == (6 more instances...) -- The document date (May 8, 2013) is 4003 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 3014, but not defined == Missing Reference: 'I-D.jennings-sip-hashcash' is mentioned on line 3051, but not defined == Missing Reference: 'ATTP' is mentioned on line 3442, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.2008' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Downref: Normative reference to an Informational RFC: RFC 5693 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Downref: Normative reference to an Informational RFC: RFC 6708 == Outdated reference: A later version (-16) exists of draft-ietf-alto-deployments-06 == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-08 == Outdated reference: A later version (-10) exists of draft-ietf-alto-server-discovery-08 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-22 Summary: 8 errors (**), 0 flaws (~~), 14 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: November 9, 2013 Cisco Systems 6 Y. Yang, Ed. 7 Yale University 8 May 8, 2013 10 ALTO Protocol 11 draft-ietf-alto-protocol-15.txt 13 Abstract 15 Applications using the Internet already have access to topology 16 information of Internet Service Provider (ISP) networks. For 17 example, views to Internet routing tables at looking glass servers 18 are available and can be practically downloaded to many application 19 clients. What is missing is knowledge of the underlying network 20 topologies from the point of view of ISPs (henceforth referred as 21 Providers). In other words, what a Provider prefers in terms of 22 traffic optimization -- and a way to 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 the network 36 service providers (e.g., Internet service providers), content service 37 providers and third parties could also operate an ALTO service. 38 Applications that could use this service are those that have a choice 39 to which end points to connect. Examples of such applications are 40 peer-to-peer (P2P) and content delivery networks. 42 Requirements Language 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [RFC2119]. 48 Status of this Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at http://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on November 9, 2013. 64 Copyright Notice 66 Copyright (c) 2013 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 1.1. Background and Problem Statement . . . . . . . . . . . . . 6 83 1.2. Solution Benefits . . . . . . . . . . . . . . . . . . . . 6 84 1.2.1. Service Providers . . . . . . . . . . . . . . . . . . 6 85 1.2.2. Applications . . . . . . . . . . . . . . . . . . . . . 7 86 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 2.2. Endpoint Address . . . . . . . . . . . . . . . . . . . . . 7 89 2.3. ASN . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 90 2.4. Network Location . . . . . . . . . . . . . . . . . . . . . 8 91 2.5. ALTO Information . . . . . . . . . . . . . . . . . . . . . 8 92 2.6. ALTO Information Base . . . . . . . . . . . . . . . . . . 8 93 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 8 94 3.1. ALTO Service and Protocol Scope . . . . . . . . . . . . . 8 95 3.2. ALTO Information Reuse and Redistribution . . . . . . . . 10 96 4. ALTO Information Service Framework . . . . . . . . . . . . . . 10 97 4.1. ALTO Information Services . . . . . . . . . . . . . . . . 11 98 4.1.1. Map Service . . . . . . . . . . . . . . . . . . . . . 11 99 4.1.2. Map Filtering Service . . . . . . . . . . . . . . . . 11 100 4.1.3. Endpoint Property Service . . . . . . . . . . . . . . 12 101 4.1.4. Endpoint Cost Service . . . . . . . . . . . . . . . . 12 102 5. Network Map . . . . . . . . . . . . . . . . . . . . . . . . . 12 103 5.1. Provider-defined Identifier (PID) . . . . . . . . . . . . 12 104 5.2. Endpoint Addresses . . . . . . . . . . . . . . . . . . . . 13 105 5.2.1. IP Addresses . . . . . . . . . . . . . . . . . . . . . 13 106 5.3. Example Network Map . . . . . . . . . . . . . . . . . . . 13 107 6. Cost Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 108 6.1. Cost Types . . . . . . . . . . . . . . . . . . . . . . . . 15 109 6.1.1. Cost Metric . . . . . . . . . . . . . . . . . . . . . 15 110 6.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 15 111 6.2. Cost Map Structure . . . . . . . . . . . . . . . . . . . . 16 112 6.3. Network Map and Cost Map Dependency . . . . . . . . . . . 17 113 7. Endpoint Properties . . . . . . . . . . . . . . . . . . . . . 17 114 7.1. Endpoint Property Type . . . . . . . . . . . . . . . . . . 17 115 7.1.1. Endpoint Property Type: pid . . . . . . . . . . . . . 18 116 8. Protocol Specification: General Processing . . . . . . . . . . 18 117 8.1. Overall Design . . . . . . . . . . . . . . . . . . . . . . 18 118 8.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 18 119 8.3. Basic Operation . . . . . . . . . . . . . . . . . . . . . 19 120 8.3.1. Client Discovering Information Resources . . . . . . . 19 121 8.3.2. Client Requesting Information Resources . . . . . . . 20 122 8.3.3. Server Responding to IR Request . . . . . . . . . . . 20 123 8.3.4. Client Handling Server Response . . . . . . . . . . . 21 124 8.3.5. Authentication and Encryption . . . . . . . . . . . . 21 125 8.3.6. HTTP Cookies . . . . . . . . . . . . . . . . . . . . . 21 126 8.3.7. Parsing . . . . . . . . . . . . . . . . . . . . . . . 22 128 8.4. Information Resource: Attributes . . . . . . . . . . . . . 22 129 8.4.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 22 130 8.4.2. Capabilities . . . . . . . . . . . . . . . . . . . . . 22 131 8.4.3. Accepts Input Parameters . . . . . . . . . . . . . . . 22 132 8.5. Information Resource Directory . . . . . . . . . . . . . . 22 133 8.5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 23 134 8.5.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . 23 135 8.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 24 136 8.5.4. Multiple Choices and OPTIONS . . . . . . . . . . . . . 26 137 8.5.5. Usage Considerations . . . . . . . . . . . . . . . . . 29 138 8.6. Information Resource: Content Encoding . . . . . . . . . . 29 139 8.6.1. Meta Information . . . . . . . . . . . . . . . . . . . 30 140 8.6.2. Data Information . . . . . . . . . . . . . . . . . . . 30 141 8.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 30 142 8.7. Protocol Errors . . . . . . . . . . . . . . . . . . . . . 30 143 8.7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 31 144 8.7.2. Resource Format and Error Codes . . . . . . . . . . . 31 145 8.7.3. Overload Conditions and Server Unavailability . . . . 32 146 9. Protocol Specification: Basic ALTO Data Types . . . . . . . . 32 147 9.1. PID Name . . . . . . . . . . . . . . . . . . . . . . . . . 32 148 9.2. Version Tag . . . . . . . . . . . . . . . . . . . . . . . 32 149 9.3. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 33 150 9.3.1. Address Type . . . . . . . . . . . . . . . . . . . . . 33 151 9.3.2. Endpoint Address . . . . . . . . . . . . . . . . . . . 33 152 9.3.3. Endpoint Prefixes . . . . . . . . . . . . . . . . . . 34 153 9.3.4. Endpoint Address Group . . . . . . . . . . . . . . . . 34 154 9.4. Cost Mode . . . . . . . . . . . . . . . . . . . . . . . . 35 155 9.5. Cost Metric . . . . . . . . . . . . . . . . . . . . . . . 35 156 9.6. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . 36 157 9.7. Endpoint Property . . . . . . . . . . . . . . . . . . . . 36 158 10. Protocol Specification: Service Information Resources . . . . 36 159 10.1. Map Service . . . . . . . . . . . . . . . . . . . . . . . 37 160 10.1.1. Network Map . . . . . . . . . . . . . . . . . . . . . 37 161 10.1.2. Cost Map . . . . . . . . . . . . . . . . . . . . . . . 39 162 10.2. Map Filtering Service . . . . . . . . . . . . . . . . . . 42 163 10.2.1. Filtered Network Map . . . . . . . . . . . . . . . . . 42 164 10.2.2. Filtered Cost Map . . . . . . . . . . . . . . . . . . 44 165 10.3. Endpoint Property Service . . . . . . . . . . . . . . . . 48 166 10.3.1. Endpoint Property . . . . . . . . . . . . . . . . . . 48 167 10.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 51 168 10.4.1. Endpoint Cost . . . . . . . . . . . . . . . . . . . . 51 169 11. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 54 170 11.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 55 171 11.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 56 172 11.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 57 173 12. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 58 174 12.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 58 175 12.2. Hosts with Multiple Endpoint Addresses . . . . . . . . . . 59 176 12.3. Network Address Translation Considerations . . . . . . . . 59 177 12.4. Endpoint and Path Properties . . . . . . . . . . . . . . . 60 178 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 179 13.1. application/alto-* Media Types . . . . . . . . . . . . . . 60 180 13.2. ALTO Cost Metric Registry . . . . . . . . . . . . . . . . 61 181 13.3. ALTO Endpoint Property Type Registry . . . . . . . . . . . 63 182 13.4. ALTO Address Type Registry . . . . . . . . . . . . . . . . 63 183 13.5. ALTO Error Code Registry . . . . . . . . . . . . . . . . . 64 184 14. Security Considerations . . . . . . . . . . . . . . . . . . . 65 185 14.1. Authenticity and Integrity of ALTO Information . . . . . . 65 186 14.1.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 65 187 14.1.2. Protection Strategies . . . . . . . . . . . . . . . . 65 188 14.1.3. Limitations . . . . . . . . . . . . . . . . . . . . . 66 189 14.2. Potential Undesirable Guidance from Authenticated ALTO 190 Information . . . . . . . . . . . . . . . . . . . . . . . 66 191 14.2.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 66 192 14.2.2. Protection Strategies . . . . . . . . . . . . . . . . 66 193 14.3. Confidentiality of ALTO Information . . . . . . . . . . . 67 194 14.3.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 67 195 14.3.2. Protection Strategies . . . . . . . . . . . . . . . . 67 196 14.3.3. Limitations . . . . . . . . . . . . . . . . . . . . . 68 197 14.4. Privacy for ALTO Users . . . . . . . . . . . . . . . . . . 68 198 14.4.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 68 199 14.4.2. Protection Strategies . . . . . . . . . . . . . . . . 68 200 14.5. Availability of ALTO Service . . . . . . . . . . . . . . . 69 201 14.5.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 69 202 14.5.2. Protection Strategies . . . . . . . . . . . . . . . . 69 203 15. Manageability Considerations . . . . . . . . . . . . . . . . . 69 204 15.1. Operations . . . . . . . . . . . . . . . . . . . . . . . . 69 205 15.1.1. Installation and Initial Setup . . . . . . . . . . . . 70 206 15.1.2. Migration Path . . . . . . . . . . . . . . . . . . . . 70 207 15.1.3. Requirements on Other Protocols and Functional 208 Components . . . . . . . . . . . . . . . . . . . . . . 70 209 15.1.4. Impact and Observation on Network Operation . . . . . 71 210 15.2. Management . . . . . . . . . . . . . . . . . . . . . . . . 71 211 15.2.1. Management Interoperability . . . . . . . . . . . . . 71 212 15.2.2. Management Information . . . . . . . . . . . . . . . . 72 213 15.2.3. Fault Management . . . . . . . . . . . . . . . . . . . 72 214 15.2.4. Configuration Management . . . . . . . . . . . . . . . 72 215 15.2.5. Performance Management . . . . . . . . . . . . . . . . 72 216 15.2.6. Security Management . . . . . . . . . . . . . . . . . 73 217 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73 218 16.1. Normative References . . . . . . . . . . . . . . . . . . . 73 219 16.2. Informative References . . . . . . . . . . . . . . . . . . 74 220 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 76 221 Appendix B. Design History and Merged Proposals . . . . . . . . . 77 222 Appendix C. Authors . . . . . . . . . . . . . . . . . . . . . . . 78 223 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78 225 1. Introduction 227 1.1. Background and Problem Statement 229 Today, network information available to applications is mostly from 230 the view of endhosts. There is no clear mechanism for a network to 231 convey to network applications its point of view on its network 232 topological structures and path preferences, forcing applications to 233 make approximations using data sources such as BGP Looking Glass 234 and/or applications' own measurements, which can be misleading or 235 inaccurate. On the other hand, modern network applications can be 236 adaptive, and hence become more network-efficient (e.g., reduce 237 network resource consumption) and achieve better application 238 performance (e.g., accelerated download rate), by leveraging better 239 network-provided information. 241 This document defines the ALTO protocol to implement the ALTO 242 Service, which provides a simple mechanism to convey useful network 243 information such as topological and path preference information to 244 applications from the underlying network Providers' points of view. 245 The ALTO protocol meets the ALTO requirements [I-D.ietf-alto-reqs], 246 and unifies multiple protocols previously designed with similar 247 intentions. See Appendix A for a list of people and Appendix B for a 248 list of proposals that have made significant contributions to this 249 effort. 251 The ALTO protocol uses a REST-ful design [Fielding-Thesis], and 252 encodes its requests and responses using JSON [RFC4627]. These 253 designs are chosen because of their flexibility and extensibility. 254 In addition, these designs make it possible for ALTO to be deployed 255 at scale by leveraging existing HTTP [RFC2616] implementations, 256 infrastructures and deployment experience. 258 1.2. Solution Benefits 260 At a high level, the ALTO Service allows a Service Provider (e.g., an 261 ISP) to publish network information such as network locations, costs 262 between them at configurable granularities, and endhost properties. 264 A mechanism to publish such information can benefit both Service 265 Providers (providers of the information) and Applications (consumers 266 of the information). We enumerate some benefits below. 268 1.2.1. Service Providers 270 A Service Provider that provides an ALTO Service can achieve better 271 utilization of its networking infrastructure. For example, by using 272 ALTO as a tool to interact with applications, a Service Provider is 273 able to provide network information to applications so that the 274 applications can better manage traffic on more expensive or difficult 275 to provision links such as long distance, transit or backup links. 277 1.2.2. Applications 279 Applications that use an ALTO Service can benefit from better 280 knowledge of the network to avoid network bottlenecks. For example, 281 a peer-to-peer overlay application can use information provided by an 282 ALTO Service to avoid selecting peers connected with low bandwidth 283 links. By using ALTO information, applications can reduce the 284 reliance on obtaining network information through third-party 285 databases; applications relying on measuring path performance metrics 286 themselves can reduce the measurement overhead by conducting only 287 fine-tuning or fault-tolerant measurements on top of ALTO 288 information. 290 2. Terminology 292 We use the following terms defined in [RFC5693]: Application, Overlay 293 Network, Peer, Resource, Resource Identifier, Resource Provider, 294 Resource Consumer, Resource Directory, Transport Address, Host 295 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 296 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 297 Transit Traffic. 299 We also use the following additional terms: Endpoint Address, 300 Autonomous System Number (ASN), Network Location, ALTO Information, 301 and ALTO Information Base. 303 2.1. Endpoint 305 An Endpoint is an application or host that is capable of 306 communicating (sending and/or receiving messages) on a network. 308 An Endpoint is typically either a Resource Provider or Resource 309 Consumer. 311 2.2. Endpoint Address 313 An Endpoint Address represents the communication address of an 314 endpoint. Common forms of Endpoint Addresses include IP address, MAC 315 address, overlay ID, and phone number. An Endpoint Address can be 316 network-attachment based (e.g., IP address) or network-attachment 317 agnostic (e.g., MAC address). 319 Each Endpoint Address has an associated Address Type, which indicates 320 both its syntax and semantics. 322 2.3. ASN 324 An Autonomous System Number. 326 2.4. Network Location 328 Network Location is a generic term denoting a single Endpoint or a 329 group of Endpoints. For instance, it can be a single IPv4 or IPv6 330 address, an IPv4 or IPv6 prefix, or a set of prefixes. 332 2.5. ALTO Information 334 ALTO Information is a generic term referring to the network 335 information sent by an ALTO Server. 337 2.6. ALTO Information Base 339 Internal representation of the ALTO Information maintained by the 340 ALTO Server. Note that the structure of this internal representation 341 is not defined by this document. 343 3. Architecture 345 We now define the ALTO architecture and the ALTO Protocol's place in 346 the overall architecture. 348 3.1. ALTO Service and Protocol Scope 350 Each network region in the global Internet can provide its ALTO 351 Service, which conveys network information from the perspective of 352 that network region. A network region in this context can be an 353 Autonomous System (AS), an ISP, a region smaller than an AS or ISP, 354 or a set of ISPs. The specific network region that an ALTO Service 355 represents will depend on the ALTO deployment scenario and ALTO 356 service discovery mechanism. 358 Specifically, the ALTO Service of a network region defines network 359 Endpoints (and aggregations thereof) and generic costs amongst them 360 from the region's perspective. The network Endpoints may include all 361 Endpoints in the global Internet. Hence, we say that the network 362 information provided by the ALTO Service of a network region 363 represents the "my-Internet View" of the network region. 365 To better understand the ALTO Service and the role of the ALTO 366 Protocol, we show in Figure 1 the overall ALTO system architecture. 368 In this architecture, an ALTO Server prepares ALTO Information; an 369 ALTO Client uses ALTO Service Discovery to identify an appropriate 370 ALTO Server; and the ALTO Client requests available ALTO Information 371 from the ALTO Server using the ALTO Protocol. 373 The ALTO Information provided by the ALTO Server can be updated 374 dynamically based on network conditions, or can be seen as a policy 375 which is updated at a larger time-scale. 377 +-------------------------------------------------------------------+ 378 | Network Region | 379 | | 380 | +-----------+ | 381 | | Routing | | 382 | +--------------+ | Protocols | | 383 | | Provisioning | +-----------+ | 384 | | Policy | | | 385 | +--------------+\ | | 386 | \ | | 387 | \ | | 388 | +-----------+ \+---------+ +--------+ | 389 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 390 | |Network |.......| Server | ==================== | Client | | 391 | |Information| +---------+ +--------+ | 392 | +-----------+ / / | 393 | / ALTO SD Query/Response / | 394 | / / | 395 | +----------+ +----------------+ | 396 | | External | | ALTO Service | | 397 | | Interface| | Discovery (SD) | | 398 | +----------+ +----------------+ | 399 | | | 400 +-------------------------------------------------------------------+ 401 | 402 +------------------+ 403 | Third Parties | 404 | | 405 | Content Providers| 406 +------------------+ 408 Figure 1: Basic ALTO Architecture. 410 Figure 1 illustrates that the ALTO Information provided by an ALTO 411 Server may be influenced (at the service provider's discretion) by 412 other systems. In particular, the ALTO Server can aggregate 413 information from multiple systems to provide an abstract and unified 414 view that can be more useful to applications. Examples of other 415 systems include (but are not limited to) static network configuration 416 databases, dynamic network information, routing protocols, 417 provisioning policies, and interfaces to outside parties. These 418 components are shown in the figure for completeness but are outside 419 the scope of this specification. Recall that while the ALTO Protocol 420 may convey dynamic network information, it is not intended to replace 421 near-real-time congestion control protocols. 423 It may also be possible for an ALTO Server to exchange network 424 information with other ALTO Servers (either within the same 425 administrative domain or another administrative domain with the 426 consent of both parties) in order to adjust exported ALTO 427 Information. Such a protocol is also outside the scope of this 428 specification. 430 3.2. ALTO Information Reuse and Redistribution 432 ALTO Information may be useful to a large number of applications and 433 users. At the same time, distributing ALTO Information must be 434 efficient and not become a bottleneck. 436 The design of ALTO allows integration with the existing HTTP caching 437 infrastructure to redistribute ALTO Information. If caching or 438 redistribution is used, the response message to an ALTO Client may be 439 returned from a third-party. 441 Application-dependent mechanisms, such as P2P DHTs or P2P file- 442 sharing, may be used to cache and redistribute ALTO Information. 443 This document does not define particular mechanisms for such 444 redistribution. 446 Additional protocol mechanisms (e.g., expiration times and digital 447 signatures for returned ALTO information) are left for future 448 investigation. 450 4. ALTO Information Service Framework 452 The ALTO Protocol conveys network information through services, where 453 each service defines a set of related functionalities. An ALTO 454 Client can query each service individually. All of the services 455 defined in ALTO are said to form the ALTO service framework and are 456 provided through a common transport protocol, messaging structure and 457 encoding, and transaction model. Functionalities offered in 458 different services can overlap. 460 In this document, we focus on achieving the goal of conveying (1) 461 Network Locations, which denote the locations of Endpoints at a 462 network, (2) provider-defined costs for paths between pairs of 463 Network Locations, and (3) network related properties of endhosts. 464 We achieve the goal by defining the Map Service, which provides the 465 core ALTO information to clients, and three additional services: the 466 Map Filtering Service, Endpoint Property Service, and Endpoint Cost 467 Service. Additional services can be defined in companion documents. 468 Below we give an overview of the services. Details of the services 469 will be presented in the following sections. 471 .-----------------------------------------. 472 | ALTO Information Services | 473 | .-----------. .----------. .----------. | 474 | | Map | | Endpoint | | Endpoint | | 475 | | Filtering | | Property | | Cost | | 476 | | Service | | Service | | Service | | 477 | `-----------' `----------' `----------' | 478 | .-------------------------------------. | 479 | | Map Service | | 480 | | .-------------. .--------------. | | 481 | | | Network Map | | Cost Map | | | 482 | | `-------------' `--------------' | | 483 | `-------------------------------------' | 484 `-----------------------------------------' 486 Figure 2: ALTO Service Framework. 488 4.1. ALTO Information Services 490 4.1.1. Map Service 492 The Map Service provides batch information to ALTO Clients in the 493 form of Network Map and Cost Map. The Network Map (See Section 5) 494 provides the full set of Network Location groupings defined by the 495 ALTO Server and the Endpoints contained within each grouping. The 496 Cost Map (see Section 6) provides costs between the defined 497 groupings. 499 These two maps can be thought of (and implemented as) as simple files 500 with appropriate encoding provided by the ALTO Server. 502 4.1.2. Map Filtering Service 504 Resource constrained ALTO Clients may benefit from filtering of query 505 results at the ALTO Server. This avoids that an ALTO Client spends 506 network bandwidth and CPU cycles to collect results and then perform 507 client-side filtering. The Map Filtering Service allows ALTO Clients 508 to query for the ALTO Server Network Map and Cost Map based on 509 additional parameters. 511 4.1.3. Endpoint Property Service 513 This service allows ALTO Clients to look up properties for individual 514 Endpoints. An example property of an Endpoint is its Network 515 Location (i.e., its grouping defined by the ALTO Server). Another 516 example property is its connectivity type such as ADSL (Asymmetric 517 Digital Subscriber Line), Cable, or FTTH (Fiber To The Home). 519 4.1.4. Endpoint Cost Service 521 Some ALTO Clients may also benefit from querying for costs and 522 rankings based on Endpoints. The Endpoint Cost Service allows an 523 ALTO Server to return either numerical costs or ordinal costs 524 (rankings) directly amongst Endpoints. 526 5. Network Map 528 An ALTO Network Map defines a grouping of network endpoints. In this 529 document, we use Network Map to refer to the syntax and semantics of 530 how an ALTO Server distributes the grouping. This document does not 531 discuss the internal representation of this data structure within the 532 ALTO Server. 534 The definition of Network Map is based on the observation that in 535 reality, many endpoints are close by to one another in terms of 536 network connectivity. By treating a group of close-by endpoints 537 together as a single entity, an ALTO Server indicates aggregation of 538 these endpoints due to their proximity. This aggregation can also 539 lead to greater scalability without losing critical information when 540 conveying other network information (e.g., when defining Cost Map). 542 5.1. Provider-defined Identifier (PID) 544 One issue is that proximity varies depending on the granularity of 545 the ALTO information configured by the provider. In one deployment, 546 endpoints on the same subnet may be considered close; while in 547 another deployment, endpoints connected to the same Point of Presence 548 (PoP) may be considered close. 550 ALTO introduces provider-defined Network Location identifiers called 551 Provider-defined Identifiers (PIDs) to provide an indirect and 552 network-agnostic way to specify an aggregation of network endpoints 553 that may be treated similarly, based on network topology, type, or 554 other properties. Specifically, a PID is a US-ASCII string of type 555 PIDName (see Section 9.1) and its associated set of Endpoint 556 Addresses. As we discussed above, there can be many different ways 557 of grouping the endpoints and assigning PIDs. For example, a PID may 558 denote a subnet, a set of subnets, a metropolitan area, a PoP, an 559 autonomous system, or a set of autonomous systems. 561 A key use case of PIDs is to specify network preferences (costs) 562 between PIDs instead of individual endpoints. This allows cost 563 information to be more compactly represented and updated at a faster 564 time scale than the network aggregations themselves. For example, an 565 ISP may prefer that endpoints associated with the same PoP (Point-of- 566 Presence) in a P2P application communicate locally instead of 567 communicating with endpoints in other PoPs. The ISP may aggregate 568 endhosts within a PoP into a single PID in the Network Map. The cost 569 may be encoded to indicate that Network Locations within the same PID 570 are preferred; for example, cost(PID_i, PID_i) == c and cost(PID_i, 571 PID_j) > c for i != j. Section 6 provides further details on using 572 PIDs to represent costs in an ALTO Cost Map. 574 5.2. Endpoint Addresses 576 The endpoints aggregated into a PID are denoted by endpoint 577 addresses. There are many types of addresses, such as IP addresses, 578 MAC addresses, or overlay IDs. This specification only considers IP 579 addresses. 581 5.2.1. IP Addresses 583 When either an ALTO Client or ALTO Server needs to determine which 584 PID in a Network Map contains a particular IP address, longest-prefix 585 matching MUST be used. 587 A Network Map MUST define a PID for each possible address in the IP 588 address space for all of the address types contained in the map. A 589 RECOMMENDED way to satisfy this property is to define a PID with the 590 shortest enclosing prefix of the addresses provided in the map. For 591 a map with full IPv4 reachability, this would mean including the 592 0.0.0.0/0 prefix in a PID; for full IPv6 reachability, this would be 593 the ::/0 prefix. 595 Each endpoint MUST map into exactly one PID. Since longest-prefix 596 matching is used to map an endpoint to a PID, this can be 597 accomplished by ensuring that no two PIDs contain an identical IP 598 prefix. 600 5.3. Example Network Map 602 Figure 3 illustrates an example Network Map. PIDs are used to 603 identify network-agnostic aggregations. 605 .-----------------------------------------------------------. 606 | ALTO Network Map | 607 | | 608 | .-----------------------------------. .---------------. | 609 | | NetLoc: PID-1 | | NetLoc: PID-2 | | 610 | | .------------------------------. | | ... | | 611 | | | 192.0.2.0/24 | | `---------------` | 612 | | | .--------------------------. | | | 613 | | | | Endpoint: 192.0.2.34 | | | .---------------. | 614 | | | `--------------------------` | | | NetLoc: PID-3 | | 615 | | `------------------------------` | | ... | | 616 | | .------------------------------. | `---------------` | 617 | | | 198.51.100.0/25 | | | 618 | | | .--------------------------. | | .---------------. | 619 | | | | Endpoint: 198.51.100.100 | | | | NetLoc: PID-4 | | 620 | | | `--------------------------` | | | ... | | 621 | | `------------------------------` | `---------------` | 622 | `-----------------------------------` | 623 | | 624 `-----------------------------------------------------------` 626 Figure 3: Example Network Map. 628 6. Cost Map 630 An ALTO Server indicates preferences amongst network locations in the 631 form of Path Costs. Path Costs are generic costs and can be 632 internally computed by a network provider according to its own needs. 634 An ALTO Cost Map defines Path Costs pairwise amongst sets of source 635 and destination Network Locations defined by PIDs. Each Path Cost is 636 the end-to-end cost when a unit of traffic goes from the source to 637 the destination. 639 As cost is directional from the source to the destination, an 640 application, when using ALTO Information, may independently determine 641 how the Resource Consumer and Resource Provider are designated as the 642 source or destination in an ALTO query, and hence how to utilize the 643 Path Cost provided by ALTO Information. For example, if the cost is 644 expected to be correlated with throughput, a typical application 645 concerned with bulk data retrieval may use the Resource Provider as 646 the source, and Resource Consumer as the destination. 648 One advantage of separating ALTO information into a Network Map and a 649 Cost Map is that the two components can be updated at different time 650 scales. For example, Network Maps may be stable for a longer time 651 while Cost Maps may be updated to reflect dynamic network conditions. 653 As used in this document, the Cost Map refers to the syntax and 654 semantics of the information distributed by the ALTO Server. This 655 document does not discuss the internal representation of this data 656 structure within the ALTO Server. 658 6.1. Cost Types 660 Path Costs have attributes: 662 o Metric: identifies what the costs represent; 664 o Mode: identifies how the costs should be interpreted. 666 The combination of a metric and a mode defines a Cost Type. Certain 667 queries for Cost Maps allow the ALTO Client to indicate the desired 668 Cost Type. 670 6.1.1. Cost Metric 672 The Metric attribute indicates what the cost represents. For 673 example, an ALTO Server could define costs representing air-miles, 674 hop-counts, or generic routing costs. 676 Cost metrics are indicated in protocol messages as strings. 678 6.1.1.1. Cost Metric: routingcost 680 An ALTO Server MUST offer the 'routingcost' Cost Metric. 682 This Cost Metric conveys a generic measure for the cost of routing 683 traffic from a source to a destination. Lower values indicate a 684 higher preference for traffic to be sent from a source to a 685 destination. 687 Note that an ISP may internally compute routing cost using any method 688 it chooses (e.g., air-miles or hop-count) as long as it conforms to 689 these semantics. 691 6.1.2. Cost Mode 693 The Mode attribute indicates how costs should be interpreted. 694 Specifically, the Mode attribute indicates whether returned costs 695 should be interpreted as numerical values or ordinal rankings. 697 It is important to communicate such information to ALTO Clients, as 698 certain operations may not be valid on certain costs returned by an 699 ALTO Server. For example, it is possible for an ALTO Server to 700 return a set of IP addresses with costs indicating a ranking of the 701 IP addresses. Arithmetic operations that would make sense for 702 numerical values, do not make sense for ordinal rankings. ALTO 703 Clients may handle such costs differently. 705 Cost Modes are indicated in protocol messages as strings. 707 An ALTO Server MUST support at least one of 'numerical' and 'ordinal' 708 modes. An ALTO Client SHOULD be cognizant of operations when a 709 desired Cost Mode is not supported. For example, an ALTO Client 710 desiring numerical costs may adjust its behaviors if only the ordinal 711 Cost Mode is available. Alternatively, an ALTO Client desiring 712 ordinal costs may construct ordinal costs given numerical values if 713 only the numerical Cost Mode is available. 715 6.1.2.1. Cost Mode: numerical 717 This Cost Mode is indicated by the string 'numerical'. This mode 718 indicates that it is safe to perform numerical operations (e.g. 719 normalization or computing ratios for weighted load-balancing) on the 720 returned costs. The values are floating-point numbers. 722 6.1.2.2. Cost Mode: ordinal 724 This Cost Mode is indicated by the string 'ordinal'. This mode 725 indicates that the costs values in a Cost Map are a ranking (relative 726 to all other values in a Cost Map), with lower values indicating a 727 higher preference. The values are non-negative integers. Ordinal 728 cost values in a Cost Map need not be unique nor contiguous. In 729 particular, it is possible that two entries in a map have an 730 identical rank (ordinal cost value). This document does not specify 731 any behavior by an ALTO Client in this case; an ALTO Client may 732 decide to break ties by random selection, other application 733 knowledge, or some other means. 735 It is important to note that the values in the Cost Map provided with 736 the ordinal Cost Mode are not necessarily the actual cost known to 737 the ALTO Server. 739 6.2. Cost Map Structure 741 A query for a Cost Map either explicitly or implicitly includes a 742 list of Source Network Locations and a list of Destination Network 743 Locations. (Recall that a Network Location can be an endpoint 744 address or a PID.) 746 Specifically, assume that a query has a list of multiple Source 747 Network Locations, say [Src_1, Src_2, ..., Src_m], and a list of 748 multiple Destination Network Locations, say [Dst_1, Dst_2, ..., 749 Dst_n]. 751 The ALTO Server will return the Path Cost for each of the m*n 752 communicating pairs (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., 753 Src_m -> Dst_1, ..., Src_m -> Dst_n). If the ALTO Server does not 754 define a Path Cost for a particular pair, it may be omitted. We 755 refer to this structure as a Cost Map. 757 If the Cost Mode is 'ordinal', the Path Cost of each communicating 758 pair is relative to the m*n entries. 760 6.3. Network Map and Cost Map Dependency 762 If a Cost Map contains PIDs in the list of Source Network Locations 763 or the list of Destination Network Locations, the Path Costs are 764 generated based on a particular Network Map (which defines the PIDs). 765 Version Tags are introduced to ensure that ALTO Clients are able to 766 use consistent information even though the information is provided in 767 two maps. 769 A Version Tag is an opaque string associated with a Network Map 770 maintained by the ALTO Server. Two Version Tags match only if their 771 strings are the same. Whenever the content of the Network Map 772 maintained by the ALTO Server changes, the Version Tag MUST also be 773 changed. Possibilities for generating a Version Tag include the 774 last-modified timestamp for the Network Map, or a hash of its 775 contents, where the collision probability is considered zero in 776 practical deployment scenarios. 778 A Network Map distributed by the ALTO Server includes its Version 779 Tag. A Cost Map referring to PIDs also includes the Version Tag of 780 the Network Map on which it is based. 782 7. Endpoint Properties 784 An endpoint property defines a network-aware property of an endpoint. 786 7.1. Endpoint Property Type 788 For each endpoint and an endpoint property type, there can be a value 789 for the property. The type of an Endpoint property is indicated in 790 protocol messages as a string. The value depends on the specific 791 property. For example, for a property such as whether an endpoint is 792 metered, the value is a true or false value. 794 7.1.1. Endpoint Property Type: pid 796 An ALTO Server MUST define the 'pid' Endpoint Property Type, which 797 provides the PID of an endpoint. Since the PID of an endpoint 798 depends on the Network Map, Version Tag of the Network Map used to 799 return the pid property MUST be included. 801 8. Protocol Specification: General Processing 803 This section first specifies general client and server processing. 804 The details of specific services will be covered in the following 805 sections. 807 8.1. Overall Design 809 The ALTO Protocol uses a REST-ful design. There are two primary 810 components to this design: 812 o Information Resources: Each service provides network information 813 as a set of information resources, which are distinguished by 814 their media types [RFC2046]. An ALTO Client may construct an HTTP 815 request for a particular information resource (including any 816 parameters, if necessary), and an ALTO Server returns the 817 requested information resource in an HTTP response. 819 o Information Resource Directory (IRD): An ALTO Server provides to 820 ALTO Clients a list of available information resources and the URI 821 at which each is provided. This document refers to this list as 822 the Information Resource Directory. ALTO Clients consult the 823 directory to determine the services provided by an ALTO Server. 825 8.2. Notation 827 This document uses 'JSONString', 'JSONNumber', 'JSONBool' to indicate 828 the JSON string, number, and boolean types, respectively. The type 829 'JSONValue' indicates a JSON value, as specified in Section 2.1 of 830 [RFC4627]. 832 We use an adaptation of the C-style struct notation to define the 833 members (names/values) of JSON objects. An optional member is 834 enclosed by [ ], and an array is indicated by two numbers, m and n, 835 where m indicates the minimal number of values, and n is the maximum. 836 When we write .. for n, it means no upper bound. In the definitions, 837 the JSON names of the members are case sensitive. 839 For example, the definition below defines a new type Type4, with 840 three members named "name1", "name2", and "name3" respectively. The 841 member named "name3" is optional, and the member named "name2" is an 842 array of at least one value. 844 object { 845 Type1 name1; 846 Type2 name2<1..*>; 847 [Type3 name3;] 848 } Type4; 850 We also define dictionary maps (or maps for short) from strings to 851 JSON values. For example, the definition below defines a Type3 852 object as a map. Type1 must be defined as string, and Type2 can be 853 any type. 855 object-map { 856 Type1 -> Type2; 857 } Type3; 859 Note that despite the notation, no standard, machine-readable 860 interface definition or schema is provided. Extension documents may 861 document these as necessary. 863 8.3. Basic Operation 865 The ALTO Protocol employs standard HTTP [RFC2616]. It is used for 866 discovering available Information Resources at an ALTO Server and 867 retrieving Information Resources. ALTO Clients and ALTO Servers use 868 HTTP requests and responses carrying ALTO-specific content with 869 encoding as specified in this document, and MUST be compliant with 870 [RFC2616]. 872 8.3.1. Client Discovering Information Resources 874 To discover available Information Resources, an ALTO Client requests 875 the Information Resource Directory, which an ALTO Server provides at 876 the URI found by the ALTO Discovery protocol. 878 Informally, an Information Resource Directory enumerates URIs at 879 which an ALTO Server offers Information Resources. Each entry in the 880 directory indicates a URI at which an ALTO Server accepts requests, 881 and returns either the requested Information Resource or an 882 Information Resource Directory that references additional Information 883 Resources. See Section 8.5 for a detailed specification. 885 8.3.2. Client Requesting Information Resources 887 Through the retrieved Information Resource Directories, an ALTO 888 Client can determine whether an ALTO Server supports the desired 889 Information Resource, and if it is supported, the URI at which it is 890 available. 892 Where possible, the ALTO Protocol uses the HTTP GET method to request 893 resources. However, some ALTO services provide Information Resources 894 that are the function of one or more input parameters. Input 895 parameters are encoded in the HTTP request's entity body, and the 896 ALTO Client MUST use the HTTP POST method to send the parameters. 898 When requesting an ALTO Information Resource that requires input 899 parameters specified in a HTTP POST request, an ALTO Client MUST set 900 the Content-Type HTTP header to the media type corresponding to the 901 format of the supplied input parameters. 903 8.3.3. Server Responding to IR Request 905 Upon receiving a request for an Information Resource that the ALTO 906 Server can provide, the ALTO server MUST return the requested 907 Information Resource. In other cases, to be more informative 908 ([I-D.ietf-httpbis-p2-semantics]), the ALTO server MAY provide the 909 ALTO Client with an Information Resource Directory indicating how to 910 reach the desired information resource, or return an ALTO error 911 object; see Section 8.7 for more details on ALTO error handling. 913 It is possible for an ALTO Server to leverage caching HTTP 914 intermediaries to respond to both GET and POST requests by including 915 explicit freshness information (see Section 14 of [RFC2616]). 916 Caching of POST requests is not widely implemented by HTTP 917 intermediaries, however an alternative approach is for an ALTO 918 Server, in response to POST requests, to return an HTTP 303 status 919 code ("See Other") indicating to the ALTO Client that the resulting 920 Information Resource is available via a GET request to an alternate 921 URL. HTTP intermediaries that do not support caching of POST 922 requests could then cache the response to the GET request from the 923 ALTO Client following the alternate URL in the 303 response if the 924 response to the subsequent GET request contains explicit freshness 925 information. 927 The ALTO server MUST indicate the type of its response using a media 928 type (i.e., the Content-Type HTTP header of the response). 930 8.3.4. Client Handling Server Response 932 8.3.4.1. Using Information Resources 934 This specification does not indicate any required actions taken by 935 ALTO Clients upon successfully receiving an Information Resource from 936 an ALTO Server. Although ALTO Clients are suggested to interpret the 937 received ALTO Information and adapt application behavior, ALTO 938 Clients are not required to do so. 940 8.3.4.2. Handling IRD as a Response 942 After receiving an Information Resource Directory, the Client can 943 consult it to determine if any of the offered URIs contain the 944 desired Information Resource. Note that it is possible for an ALTO 945 Client to receive an Information Resource Directory from an ALTO 946 Server as a response to its request for a specific Information 947 Resource. In this case, the ALTO Client may ignore the response or 948 still parse the response. To indicate that an ALTO Client will 949 always check if a response is an Information Resource Directory, the 950 ALTO Client can indicate in the "Accept" header of a HTTP request 951 that it can accept Information Resource Directory; see Section 8.5 952 for the media type. 954 8.3.4.3. Handling Error Conditions 956 If an ALTO Client does not successfully receive a desired Information 957 Resource from a particular ALTO Server (i.e., server response 958 indicates error or there is no response), the Client can either 959 choose another server (if one is available) or fall back to a default 960 behavior (e.g., perform peer selection without the use of ALTO 961 information, when used in a peer-to-peer system). 963 8.3.5. Authentication and Encryption 965 When server and/or client authentication, encryption, and/or 966 integrity protection are required, an ALTO Server MUST support SSL/ 967 TLS [RFC5246] as a mechanism. For cases such as a public ALTO 968 service or deployment scenarios where there is an implicit trust 969 relationship between the client and the server and the network 970 infrastructure connecting them is secure, SSL/TLS may not be 971 necessary. See [RFC6125] for considerations regarding verification 972 of server identity. 974 8.3.6. HTTP Cookies 976 If cookies are included in an HTTP request received by an ALTO 977 Server, they MUST be ignored. 979 8.3.7. Parsing 981 This document only details object members used by this specification. 982 Extensions may include additional members within JSON objects defined 983 in this document. ALTO implementations MUST ignore such unknown 984 fields when processing ALTO messages. 986 8.4. Information Resource: Attributes 988 An Information Resource encodes the ALTO Information desired by an 989 ALTO Client. This document specifies multiple Information Resources 990 that can be provided by an ALTO Server. 992 Each Information Resource has certain attributes associated with it, 993 including its data format, its capabilities, and its accepted input 994 parameters. These attributes are published by an ALTO Server in its 995 Information Resource Directory. 997 8.4.1. Media Type 999 A Media Type [RFC2046] uniquely indicates a data format used to 1000 encode the content of an Information Resource that an ALTO Server 1001 returns to an ALTO Client in the HTTP entity body. 1003 8.4.2. Capabilities 1005 The Capabilities associated with an Information Resource announced by 1006 an ALTO Server indicates specific capabilities that the server can 1007 provide. For example, if an ALTO Server allows an ALTO Client to 1008 specify cost constraints when the Client requests a Cost Map 1009 Information Resource, the Server advertises the cost-constraints 1010 capability for its Cost Map Information Resource. 1012 8.4.3. Accepts Input Parameters 1014 An ALTO Server may allow an ALTO Client to supply input parameters 1015 when requesting certain Information Resources. The associated 1016 accepts attribute of an Information Resource is a Media Type, which 1017 indicates how the Client specifies the input parameters as contained 1018 in the entity body of the HTTP POST request. 1020 8.5. Information Resource Directory 1022 An ALTO Server uses Information Resource Directory to publish 1023 available Information Resources and their aforementioned attributes. 1024 Since resource selection happens after consumption of the Information 1025 Resource Directory, the format of the Information Resource Directory 1026 is designed to be simple with the intention of future ALTO Protocol 1027 versions maintaining backwards compatibility. Future extensions or 1028 versions of the ALTO Protocol SHOULD be accomplished by extending 1029 existing media types or adding new media types, but retaining the 1030 same format for the Information Resource Directory. 1032 An ALTO Server MUST make an Information Resource Directory available 1033 via the HTTP GET method to a URI discoverable by an ALTO Client. 1034 Discovery of this URI is out of scope of this document, but could be 1035 accomplished by manual configuration or by returning the URI of an 1036 Information Resource Directory from the ALTO Discovery Protocol 1037 [I-D.ietf-alto-server-discovery]. For recommendations on how the URI 1038 may look like, see [I-D.ietf-alto-server-discovery]. 1040 8.5.1. Media Type 1042 The media type to indicate an information directory is "application/ 1043 alto-directory+json". 1045 8.5.2. Encoding 1047 An Information Resource Directory is a JSON object of type 1048 InfoResourceDirectory: 1050 object { 1051 IRDMeta meta; 1052 IRDResourceEntry resources<0..*>; 1053 } InfoResourceDirectory; 1055 object-map { 1056 JSONString -> JSONValue; 1057 } IRDMeta; 1059 object { 1060 JSONString uri; 1061 JSONString media-types<1..*>; 1062 [JSONString accepts<0..*>;] 1063 [Capabilities capabilities;] 1064 } IRDResourceEntry; 1066 object { 1067 ... 1068 } Capabilities; 1070 where the "meta" member provides definitions related with the IRD 1071 itself, or can be used when defining multiple individual Information 1072 resources; 1073 the "resources" array indicates a list of Information Resources 1074 provided by an ALTO Server. Note that the list of available 1075 resources is enclosed in a JSON object for extensibility; future 1076 protocol versions may specify additional members in the 1077 InfoResourceDirectory object. 1079 Each entry specifies: 1081 uri A URI at which the ALTO Server provides one or more Information 1082 Resources, or an Information Resource Directory indicating 1083 additional Information Resources. URIs can be relative and MUST 1084 be resolved according to Section 5 of [RFC3986]. 1086 media-types The list of all media types of Information Resources 1087 (see Section 8.4.1) available via GET or POST requests to the 1088 corresponding URI or URIs discoverable via the URI. 1090 accepts The list of all media types of input parameters (see 1091 Section 8.4.3) accepted by POST requests to the corresponding URI 1092 or URIs discoverable via the URI. If this member is not present, 1093 it MUST be assumed to be an empty array. 1095 capabilities A JSON Object enumerating capabilities of an ALTO 1096 Server in providing the Information Resource at the corresponding 1097 URI and Information Resources discoverable via the URI. If this 1098 member is not present, it MUST be assumed to be an empty object. 1099 If a capability for one of the offered Information Resources is 1100 not explicitly listed here, an ALTO Client may either issue an 1101 OPTIONS HTTP request to the corresponding URI to determine if the 1102 capability is supported, or assume its default value documented in 1103 this specification or an extension document describing the 1104 capability. 1106 If an entry has an empty list for "accepts", then the corresponding 1107 URI MUST support GET requests. If an entry has a non-empty list for 1108 "accepts", then the corresponding URI MUST support POST requests. If 1109 an ALTO Server wishes to support both GET and POST on a single URI, 1110 it MUST specify two entries in the Information Resource Directory. 1112 8.5.3. Example 1114 The following is an example Information Resource Directory returned 1115 by an ALTO Server. 1117 GET /directory HTTP/1.1 1118 Host: alto.example.com 1119 Accept: application/alto-directory+json,application/alto-error+json 1120 HTTP/1.1 200 OK 1121 Content-Length: TBA 1122 Content-Type: application/alto-directory+json 1124 { 1125 "meta" : { 1126 "cost-types": { 1127 "num-routing": {"cost-mode" : "numerical", 1128 "cost-metric": "routingcost", 1129 "description": "My default"}, 1130 "num-hop": {"cost-mode" : "numerical", 1131 "cost-metric": "hopcount"} 1132 "ord-routing": {"cost-mode" : "ordinal", 1133 "cost-metric": "routingcost"}, 1134 "ord-hop": {"cost-mode" : "ordinal", 1135 "cost-metric": "hopcount"} 1136 } 1137 }, 1138 "resources" : [ 1139 { 1140 "uri" : "http://alto.example.com/networkmap", 1141 "media-types" : [ "application/alto-networkmap+json" ] 1142 }, { 1143 "uri" : "http://alto.example.com/costmap/num/routingcost", 1144 "media-types" : [ "application/alto-costmap+json" ], 1145 "capabilities" : { 1146 "cost-type-names" : [ "num-routing" ] 1147 } 1148 }, { 1149 "uri" : "http://alto.example.com/costmap/num/hopcount", 1150 "media-types" : [ "application/alto-costmap+json" ], 1151 "capabilities" : { 1152 "cost-type-names" : [ "num-hop" ] 1153 } 1154 }, { 1155 "uri" : "http://custom.alto.example.com/maps", 1156 "media-types" : [ 1157 "application/alto-networkmap+json", 1158 "application/alto-costmap+json" 1159 ], 1160 "accepts" : [ 1161 "application/alto-networkmapfilter+json", 1162 "application/alto-costmapfilter+json" 1163 ] 1164 }, { 1165 "uri" : "http://alto.example.com/endpointprop/lookup", 1166 "media-types" : [ "application/alto-endpointprop+json" ], 1167 "accepts" : [ "application/alto-endpointpropparams+json" ], 1168 "capabilities" : { 1169 "prop-types" : [ "pid" ] 1170 } 1171 }, { 1172 "uri" : "http://alto.example.com/endpointcost/lookup", 1173 "media-types" : [ "application/alto-endpointcost+json" ], 1174 "accepts" : [ "application/alto-endpointcostparams+json" ], 1175 "capabilities" : { 1176 "cost-constraints" : true, 1177 "cost-type-names" : [ "num-routing", "num-hop", 1178 "ord-routing", "ord-hop"] 1179 } 1180 } 1181 ] 1182 } 1184 Specifically, the "meta" member of the example IRD defines four cost 1185 types so that each Information Resource can use them. 1187 The "resources" array of the example IRD defines six Information 1188 Resources. For example, the last entry is to provide the Endpoint 1189 Cost Service, which is indicated by the media-type "application/ 1190 alto-endpointcost+json". An ALTO Client should use uri 1191 "http://alto.example.com/endpointcost/lookup" to access the service. 1192 The ALTO Client should format its request body to be the 1193 "application/alto-endpointcostparams+json" media type, as specified 1194 by the "accepts" attribute of the Information Resource. The "cost- 1195 type-names" member of the "capabilities" attribute of the Information 1196 Resource includes 4 defined cost types from the "meta" member of the 1197 IRD. Hence, one can verify that the Endpoint Cost Information 1198 Resource supports both Cost Metrics 'routingcost' and 'hopcount', 1199 each available for both 'numerical' and 'ordinal'. When requesting 1200 the Information Resource, an ALTO Client can specify cost 1201 constraints, as indicated by the "cost-constraints" member of the 1202 "capabilities" attribute. 1204 8.5.4. Multiple Choices and OPTIONS 1206 ALTO Information Resource Directory provides flexibility to an ALTO 1207 Server (e.g., delegation) so that it MAY indicate multiple 1208 Information Resources using one URI endpoint. In the example above, 1209 the ALTO Server provides additional Network and Cost Maps via a 1210 separate subdomain, "custom.alto.example.com". In particular, the 1211 maps available via this subdomain are Filtered Network and Cost Maps 1212 as well as pre-generated maps for the "hopcount" and "routingcost" 1213 Cost Metrics in the "ordinal" Cost Mode. 1215 If an ALTO Client requests one URI that provides multiple Information 1216 Resources, the ALTO Server replies with an HTTP 300 status code 1217 ("Multiple Choices"). The ALTO Client can discover the specific 1218 Information Resources indicated by the URI using an OPTIONS request. 1219 The ALTO Server SHOULD use the Information Resource Directory format 1220 in its reply to an OPTIONS request. 1222 Consider the preceding example. The ALTO Client can discover the 1223 maps available at "custom.alto.example.com" by successfully 1224 performing an OPTIONS request to 1225 "http://custom.alto.example.com/maps": 1227 OPTIONS /maps HTTP/1.1 1228 Host: custom.alto.example.com 1229 Accept: application/alto-directory+json,application/alto-error+json 1230 HTTP/1.1 200 OK 1231 Content-Length: TBA 1232 Content-Type: application/alto-directory+json 1234 { 1235 "meta" : { 1236 "cost-types": { 1237 "num-routing": {"cost-mode" : "numerical", 1238 "cost-metric": "routingcost", 1239 "description": "My default"}, 1240 "num-hop": {"cost-mode" : "numerical", 1241 "cost-metric": "hopcount"} 1242 "ord-routing": {"cost-mode" : "ordinal", 1243 "cost-metric": "routingcost"}, 1244 "ord-hop": {"cost-mode" : "ordinal", 1245 "cost-metric": "hopcount"} 1246 } 1247 }, 1248 "resources" : [ 1249 { 1250 "uri" : "http://custom.alto.example.com/networkmap/filtered", 1251 "media-types" : [ "application/alto-networkmap+json" ], 1252 "accepts" : [ "application/alto-networkmapfilter+json" ] 1253 }, { 1254 "uri" : "http://custom.alto.example.com/costmap/filtered", 1255 "media-types" : [ "application/alto-costmap+json" ], 1256 "accepts" : [ "application/alto-costmapfilter+json" ], 1257 "capabilities" : { 1258 "cost-constraints" : true, 1259 "cost-type-names" : [ "num-routing", "num-hop", 1260 "ord-routing", "ord-hop" ] 1261 } 1262 }, { 1263 "uri" : "http://custom.alto.example.com/ord/routingcost", 1264 "media-types" : [ "application/alto-costmap+json" ], 1265 "capabilities" : { 1266 "cost-type-names" : [ "ord-routing" ] 1267 } 1268 }, { 1269 "uri" : "http://custom.alto.example.com/ord/hopcount", 1270 "media-types" : [ "application/alto-costmap+json" ], 1271 "capabilities" : { 1272 "cost-type-names" : [ "ord-hop" ], 1273 } 1274 } 1275 ] 1276 } 1278 8.5.5. Usage Considerations 1280 8.5.5.1. ALTO Client 1282 This document specifies no requirements or constraints on ALTO 1283 Clients with regards to how they process an Information Resource 1284 Directory to identify the URI corresponding to a desired Information 1285 Resource. However, some advice is provided for implementors. 1287 It is possible that multiple entries in the directory match a desired 1288 Information Resource. For instance, in the example in Section 8.5.3, 1289 a full Cost Map with "numerical" Cost Mode and "routingcost" Cost 1290 Metric could be retrieved via a GET request to 1291 "http://alto.example.com/costmap/num/routingcost", or via a POST 1292 request to "http://custom.alto.example.com/costmap/filtered". 1294 In general, it is preferred for ALTO Clients to use GET requests 1295 where appropriate, since it is more likely for responses to be 1296 cachable. 1298 8.5.5.2. ALTO Server 1300 This document indicates that an ALTO Server may or may not provide 1301 the Information Resources specified in the Map Filtering Service. If 1302 these resources are not provided, it is indicated to an ALTO Client 1303 by the absence of a Network Map or Cost Map with any media types 1304 listed under "accepts". 1306 8.6. Information Resource: Content Encoding 1308 Though each Information Resource may have a distinct syntax and hence 1309 its unique Media Type, they are designed to have a common structure 1310 containing generic ALTO-layer metadata about the resource, as well as 1311 data itself. 1313 Specifically, each Information Resource has a single top-level JSON 1314 object of type InfoResourceEntity: 1316 object { 1317 InfoResourceMeta meta; 1318 InfoResourceDataType data; 1319 } InfoResourceEntity; 1321 with members: 1323 meta meta-information pertaining to the Information Resource; 1325 data the data contained in the Information Resource. 1327 8.6.1. Meta Information 1329 Meta information is encoded as a JSON object. This document does not 1330 specify any members, but it is defined here as a standard container 1331 for extensibility. Specifically, InfoResourceMetaData is defined as: 1333 object-map { 1334 JSONString -> JSONValue 1335 } InfoResourceMetaData; 1337 8.6.2. Data Information 1339 The "data" member of the InfoResourceEntity encodes the resource- 1340 specific data. In this document, we define four specific 1341 InfoResourceDataType: InfoResourceNetworkMap, InfoResourceCostMap, 1342 InfoResourceEndpointProperty, and InfoResourceEndpointCostMap, whose 1343 structures will be detailed below. 1345 8.6.3. Example 1347 The following is an example of the encoding for an Information 1348 Resource: 1350 HTTP/1.1 200 OK 1351 Content-Length: 40 1352 Content-Type: application/alto-costmap+json 1354 { 1355 "meta" : {}, 1356 "data" : { 1357 ... 1358 } 1359 } 1361 8.7. Protocol Errors 1363 If there is an error processing a request, an ALTO Server SHOULD 1364 return additional ALTO-layer information, if it is available, in the 1365 form of an ALTO Error Resource encoded in the HTTP response' entity 1366 body. If no ALTO-layer information is available, an ALTO Server may 1367 omit an ALTO Error resource from the response. 1369 With or without additional ALTO-layer error information, an ALTO 1370 Server MUST set an appropriate HTTP status code. It is important to 1371 note that the HTTP Status Code and ALTO Error Resource have distinct 1372 roles. An ALTO Error Resource provides detailed information about 1373 why a particular request for an ALTO Resource was not successful. 1374 The HTTP status code indicates to HTTP processing elements (e.g., 1375 intermediaries and clients) how the response should be treated. 1377 8.7.1. Media Type 1379 The media type for an ALTO Error Resource is "application/ 1380 alto-error+json". 1382 8.7.2. Resource Format and Error Codes 1384 An ALTO Error Resource has the format: 1386 object { 1387 JSONString code; 1388 } ErrorResourceEntity; 1390 where: 1392 code An ALTO Error Code defined in Table 1. Note that the ALTO 1393 Error Codes defined in Table 1 are limited to support the error 1394 conditions needed for purposes of this document. Additional 1395 status codes may be defined in companion or extension documents. 1397 +-------------------------+-----------------------------------------+ 1398 | ALTO Error Code | Description | 1399 +-------------------------+-----------------------------------------+ 1400 | E_SYNTAX | Parsing error in request (including | 1401 | | identifiers) | 1402 | E_JSON_FIELD_MISSING | Required field missing | 1403 | E_JSON_VALUE_TYPE | JSON Value of unexpected type | 1404 | E_INVALID_COST_MODE | Invalid cost mode | 1405 | E_INVALID_COST_METRIC | Invalid cost metric | 1406 | E_INVALID_PROPERTY_TYPE | Invalid property type | 1407 +-------------------------+-----------------------------------------+ 1409 Table 1: Defined ALTO Error Codes. 1411 If multiple errors are present in a single request (e.g., a request 1412 uses a JSONString when a JSONNumber is expected and a required field 1413 is missing), then the ALTO Server MUST return exactly one of the 1414 detected errors. However, the reported error is implementation 1415 defined, since specifying a particular order for message processing 1416 encroaches needlessly on implementation technique. 1418 8.7.3. Overload Conditions and Server Unavailability 1420 If an ALTO Server detects that it cannot handle a request from an 1421 ALTO Client due to excessive load, technical problems, or system 1422 maintenance, it SHOULD do one of the following: 1424 o Return an HTTP 503 ("Service Unavailable") status code to the ALTO 1425 Client. As indicated by [RFC2616], a the Retry-After HTTP header 1426 may be used to indicate when the ALTO Client should retry the 1427 request. 1429 o Return an HTTP 307 ("Temporary Redirect") status code indicating 1430 an alternate ALTO Server that may be able to satisfy the request. 1432 The ALTO Server MAY also terminate the connection with the ALTO 1433 Client. 1435 The particular policy applied by an ALTO Server to determine that it 1436 cannot service a request is outside of the scope of this document. 1438 9. Protocol Specification: Basic ALTO Data Types 1440 This section details the format for particular data values used in 1441 the ALTO Protocol. 1443 9.1. PID Name 1445 A PID Name is encoded as a US-ASCII string. The string MUST be no 1446 more than 64 characters, and MUST NOT contain any ASCII character 1447 below 0x21 or above 0x7E or the '.' separator (0x2E). The '.' 1448 separator is reserved for future use and MUST NOT be used unless 1449 specifically indicated by a companion or extension document. 1451 The type 'PIDName' is used in this document to indicate a string of 1452 this format. 1454 9.2. Version Tag 1456 A Version Tag is encoded as a case-sensitive US-ASCII string. The 1457 string MUST be no more than 64 characters, and MUST NOT contain any 1458 ASCII character below 0x21 or above 0x7E. 1460 The type 'VersionTag' is used in this document to indicate a string 1461 of this type. Two tags are the same if and only if they are byte for 1462 byte equal. 1464 9.3. Endpoints 1466 This section defines formats used to encode addresses for Endpoints. 1467 In a case that multiple textual representations encode the same 1468 Endpoint address or prefix (within the guidelines outlined in this 1469 document), the ALTO Protocol does not require ALTO Clients or ALTO 1470 Servers to use a particular textual representation, nor does it 1471 require that ALTO Servers reply to requests using the same textual 1472 representation used by requesting ALTO Clients. ALTO Clients must be 1473 cognizant of this. 1475 9.3.1. Address Type 1477 Address Types are encoded as US-ASCII strings consisting of only 1478 alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, and 0x61- 1479 0x7A). This document defines the address type 'ipv4' to refer to 1480 IPv4 addresses, and 'ipv6' to refer to IPv6 addresses. All Address 1481 Type identifiers appearing in an HTTP request or response with an 1482 'application/alto-*' media type MUST be registered in the ALTO 1483 Address Type registry (see Section 13.4). 1485 The type 'AddressType' is used in this document to indicate a string 1486 of this format. 1488 9.3.2. Endpoint Address 1490 Endpoint Addresses are encoded as US-ASCII strings. The exact 1491 characters and format depend on the type of endpoint address. 1493 The type 'EndpointAddr' is used in this document to indicate a string 1494 of this format. 1496 9.3.2.1. IPv4 1498 IPv4 Endpoint Addresses are encoded as specified by the 'IPv4address' 1499 rule in Section 3.2.2 of [RFC3986]. 1501 9.3.2.2. IPv6 1503 IPv6 Endpoint Addresses are encoded as specified in Section 4 of 1504 [RFC5952]. 1506 9.3.2.3. Typed Endpoint Addresses 1508 When an Endpoint Address is used, an ALTO implementation must be able 1509 to determine its type. For this purpose, the ALTO Protocol allows 1510 endpoint addresses to also explicitly indicate their type. 1512 Typed Endpoint Addresses are encoded as US-ASCII strings of the 1513 format 'AddressType:EndpointAddr' (with the ':' character as a 1514 separator). The type 'TypedEndpointAddr' is used to indicate a 1515 string of this format. 1517 9.3.3. Endpoint Prefixes 1519 For efficiency, it is useful to denote a set of Endpoint Addresses 1520 using a special notation (if one exists). This specification makes 1521 use of the prefix notations for both IPv4 and IPv6 for this purpose. 1523 Endpoint Prefixes are encoded as US-ASCII strings. The exact 1524 characters and format depend on the type of endpoint address. 1526 The type 'EndpointPrefix' is used in this document to indicate a 1527 string of this format. 1529 9.3.3.1. IPv4 1531 IPv4 Endpoint Prefixes are encoded as specified in Section 3.1 of 1532 [RFC4632]. 1534 9.3.3.2. IPv6 1536 IPv6 Endpoint Prefixes are encoded as specified in Section 7 of 1537 [RFC5952]. 1539 9.3.4. Endpoint Address Group 1541 The ALTO Protocol includes messages that specify potentially large 1542 sets of endpoint addresses. Endpoint Address Groups provide a more 1543 efficient way to encode such sets, even when the set contains 1544 endpoint addresses of different types. 1546 An Endpoint Address Group is defined as: 1548 object-map { 1549 AddressType -> EndpointPrefix<0..*>; 1550 } EndpointAddrGroup; 1551 In particular, an Endpoint Address Group is a JSON object 1552 representing a map, where each key is the string corresponding to an 1553 address type, and the corresponding value is an array listing 1554 prefixes of addresses of that type. 1556 The following is an example with both IPv4 and IPv6 endpoint 1557 addresses: 1559 { 1560 "ipv4": [ 1561 "192.0.2.0/24", 1562 "198.51.100.0/25" 1563 ], 1564 "ipv6": [ 1565 "2001:db8:0:1::/64", 1566 "2001:db8:0:2::/64" 1567 ] 1568 } 1570 9.4. Cost Mode 1572 A Cost Mode is encoded as a US-ASCII string. The string MUST either 1573 have the value 'numerical' or 'ordinal'. 1575 The type 'CostMode' is used in this document to indicate a string of 1576 this format. 1578 9.5. Cost Metric 1580 A Cost Metric is encoded as a US-ASCII string. The string MUST be no 1581 more than 32 characters, and MUST NOT contain characters other than 1582 alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, and 0x61- 1583 0x7A), the hyphen ('-', code point 0x2D), or the colon (':', code 1584 point 0x3A). 1586 Identifiers prefixed with 'priv:' are reserved for Private Use 1587 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for 1588 Experimental use. For an identifier with the 'priv:' or 'exp:' 1589 prefix, an additional string (e.g., company identifier or random 1590 string) MUST follow to reduce potential collisions. For example, a 1591 short string after 'exp:' to indicate the starting time of a specific 1592 experiment is recommended. All other identifiers appearing in an 1593 HTTP request or response with an 'application/alto-*' media type MUST 1594 be registered in the ALTO Cost Metrics registry Section 13.2. 1596 The type 'CostMetric' is used in this document to indicate a string 1597 of this format. 1599 9.6. Cost Type 1601 The combinaton of CostType and a CostMode defines a CostType: 1603 object { 1604 CostMetric cost-metric; 1605 CostModel cost-mode; 1606 [JSONString description;] 1607 } CostType; 1609 'description', if present, MUST contain a US-ASCII string with a 1610 human-readable description of the cost-metric and cost-mode. The 1611 field SHOULD NOT be interpreted by an ALTO Client. 1613 9.7. Endpoint Property 1615 An Endpoint Property is encoded as a US-ASCII string. The string 1616 MUST be no more than 32 characters, and MUST NOT contain characters 1617 other than alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, 1618 and 0x61-0x7A), the hyphen ('-', code point 0x2D), or the colon (':', 1619 code point 0x3A). 1621 Identifiers prefixed with 'priv:' are reserved for Private Use 1622 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for 1623 Experimental use. For an identifier with the 'priv:' or 'exp:' 1624 prefix, an additional string (e.g., company identifier or random 1625 string) MUST follow to reduce potential collisions. For example, a 1626 short string after 'exp:' to indicate the starting time of a specific 1627 experiment is recommended. All other identifiers appearing in an 1628 HTTP request or response with an 'application/alto-*' media type MUST 1629 be registered in the ALTO Endpoint Property registry Section 13.3. 1631 The type 'EndpointPropertyType' is used in this document to indicate 1632 a string of this format. 1634 10. Protocol Specification: Service Information Resources 1636 This section documents the individual Information Resources defined 1637 to provide the services define in this document. 1639 10.1. Map Service 1641 The Map Service provides batch information to ALTO Clients in the 1642 form of two types of maps: a Network Map and Cost Map. 1644 10.1.1. Network Map 1646 The Network Map Information Resource lists for each PID, the network 1647 locations (endpoints) within the PID. It MUST be provided by an ALTO 1648 Server. 1650 10.1.1.1. Media Type 1652 The media type of Network Map is "application/alto-networkmap+json". 1654 10.1.1.2. HTTP Method 1656 The Network Map resource is requested using the HTTP GET method. 1658 10.1.1.3. Accept Input Parameters 1660 None. 1662 10.1.1.4. Capabilities 1664 None. 1666 10.1.1.5. Response 1668 The "data" member of the returned InfoResourceEntity for a Network 1669 Map is an object of type InfoResourceNetworkMap: 1671 object { 1672 VersionTag map-vtag; 1673 NetworkMapData map; 1674 } InfoResourceNetworkMap; 1676 object-map { 1677 PIDName -> EndpointAddrGroup; 1678 } NetworkMapData; 1680 with members: 1682 map-vtag The Version Tag (Section 6.3) of the Network Map. 1684 map The Network Map data itself. 1686 NetworkMapData is a JSON object representing a dictionary map with 1687 each key representing a single PID, and the value the associated set 1688 of endpoint addresses. 1690 The returned Network Map MUST include all PIDs known to the ALTO 1691 Server. 1693 10.1.1.6. Example 1695 GET /networkmap HTTP/1.1 1696 Host: alto.example.com 1697 Accept: application/alto-networkmap+json,application/alto-error+json 1698 HTTP/1.1 200 OK 1699 Content-Length: 370 1700 Content-Type: application/alto-networkmap+json 1702 { 1703 "meta" : {}, 1704 "data" : { 1705 "map-vtag" : "1266506139", 1706 "map" : { 1707 "PID1" : { 1708 "ipv4" : [ 1709 "192.0.2.0/24", 1710 "198.51.100.0/25" 1711 ] 1712 }, 1713 "PID2" : { 1714 "ipv4" : [ 1715 "198.51.100.128/25" 1716 ] 1717 }, 1718 "PID3" : { 1719 "ipv4" : [ 1720 "0.0.0.0/0" 1721 ], 1722 "ipv6" : [ 1723 "::/0" 1724 ] 1725 } 1726 } 1727 } 1728 } 1730 The encodings were chosen for readability and compactness. If lookup 1731 efficiency at runtime is crucial, then the returned Network Map and 1732 Cost Map can be transformed into data structures offering more 1733 efficient lookup, such as transforming the Network Map into a IP trie 1734 for longest-prefix matching and the Cost Map into a matrix. 1736 10.1.2. Cost Map 1738 The Cost Map resource lists the Path Cost for each pair of source/ 1739 destination PID defined by the ALTO Server for a given Cost Metric 1740 and Cost Mode. This resource MUST be provided for at least the 1741 'routingcost' Cost Metric. 1743 10.1.2.1. Media Type 1745 The media type of Cost Map is "application/alto-costmap+json". 1747 10.1.2.2. HTTP Method 1749 The Cost Map resource is requested using the HTTP GET method. 1751 10.1.2.3. Accept Input Parameters 1753 None. 1755 10.1.2.4. Capabilities 1757 The capabilities of an ALTO Server URI providing an unfiltered cost 1758 map is a JSON Object of type CostMapCapabilities: 1760 object { 1761 JSONString cost-type-names<1..*>; 1762 } CostMapCapabilities; 1764 with member: 1766 cost-type-names A sequence of CostType names defined in "cost-types" 1767 of the "meta" member of an IRD. These represent the Cost Types 1768 that are supported via the corresponding URI in the IRD. If there 1769 is more than one Cost Type in this list, then the ALTO Server 1770 SHOULD return an IRD to the client to lead it towards the URIs for 1771 the corresponding Cost Maps. Since an unfiltered Cost Map is 1772 requested via an HTTP GET that accepts no input parameters, an 1773 ALTO Client MUST be led towards a resource that has a single 1774 element in the 'cost-type-names' list. 1776 10.1.2.5. Response 1778 The "data" member of the returned InfoResourceEntity for a Cost Map 1779 is an object of type InfoResourceCostMap: 1781 object { 1782 CostType cost-type; 1783 VersionTag map-vtag; 1784 CostMapData map; 1785 } InfoResourceCostMap; 1787 object-map { 1788 PIDName -> DstCosts; 1789 } CostMapData; 1791 object-map { 1792 PIDName -> JSONValue; 1793 } DstCosts; 1795 with members: 1797 cost-type Cost Type (Section 9.6) used in the Cost Map. 1799 map-vtag The Version Tag (Section 6.3) of the Network Map used to 1800 generate the Cost Map. 1802 map The Cost Map data itself. 1804 CostMapData is a dictionary map object, with each key being the 1805 PIDName string identifying the corresponding Source PID, and value 1806 being a type of DstCosts, which denotes the associated costs from the 1807 Source PID to a set of destination PIDs ( Section 6.2). An 1808 implementation of the protocol in this document SHOULD assume that 1809 the cost is a JSONNumber and fail to parse if it is not, unless the 1810 implementation is using an extension to this document that indicates 1811 when and how costs of other data types are signaled. 1813 The returned Cost Map MUST include the Path Cost for each (Source 1814 PID, Destination PID) pair for which a Path Cost is defined. An ALTO 1815 Server MAY omit entries for which a Path Cost is not defined (e.g., 1816 both the Source and Destination PIDs contain addresses outside of the 1817 Network Provider's administrative domain). 1819 10.1.2.6. Example 1821 GET /costmap/num/routingcost HTTP/1.1 1822 Host: alto.example.com 1823 Accept: application/alto-costmap+json,application/alto-error+json 1824 HTTP/1.1 200 OK 1825 Content-Length: TBA 1826 Content-Type: application/alto-costmap+json 1828 { 1829 "meta" : {}, 1830 "data" : { 1831 "cost-type" : {"cost-mode" : "numerical", 1832 "cost-metric": "routingcost"}, 1833 "map-vtag" : "1266506139", 1834 "map" : { 1835 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 1836 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 1837 "PID3": { "PID1": 20, "PID2": 15 } 1838 } 1839 } 1840 } 1842 Similar to the Network Map case, we considered array-based encoding 1843 for "map", but chose the current encoding for clarity. 1845 10.2. Map Filtering Service 1847 The Map Filtering Service allows ALTO Clients to specify filtering 1848 criteria to return a subset of the full maps available in the Map 1849 Service. 1851 10.2.1. Filtered Network Map 1853 A Filtered Network Map is a Network Map Information Resource 1854 (Section 10.1.1) for which an ALTO Client may supply a list of PIDs 1855 to be included. A Filtered Network Map MAY be provided by an ALTO 1856 Server. 1858 10.2.1.1. Media Type 1860 As a Filtered Network Map is a Network Map, it uses the media type 1861 defined for Network Map at Section 10.1.1.1. 1863 10.2.1.2. HTTP Method 1865 A Filtered Network Map is requested using the HTTP POST method. 1867 10.2.1.3. Accept Input Parameters 1869 An ALTO Client supplies filtering parameters by specifying media type 1870 "application/alto-networkmapfilter+json" with HTTP POST body 1871 containing a JSON Object of type ReqFilteredNetworkMap, where: 1873 object { 1874 PIDName pids<0..*>; 1875 AddressType address-types<0..*>; 1876 } ReqFilteredNetworkMap; 1878 with members: 1880 pids Specifies list of PIDs to be included in the returned Filtered 1881 Network Map. If the list of PIDs is empty, the ALTO Server MUST 1882 interpret the list as if it contained a list of all currently- 1883 defined PIDs. The ALTO Server MUST interpret entries appearing 1884 multiple times as if they appeared only once. 1886 address-types Specifies list of address types to be included in the 1887 returned Filtered Network Map. If the list of address types is 1888 empty, the ALTO Server MUST interpret the list as if it contained 1889 a list of all address types known to the ALTO Server. The ALTO 1890 Server MUST interpret entries appearing multiple times as if they 1891 appeared only once. 1893 10.2.1.4. Capabilities 1895 None. 1897 10.2.1.5. Response 1899 See Section 10.1.1.5 for the format. 1901 The ALTO Server MUST only include PIDs in the response that were 1902 specified (implicitly or explicitly) in the request. If the input 1903 parameters contain a PID name that is not currently defined by the 1904 ALTO Server, the ALTO Server MUST behave as if the PID did not appear 1905 in the input parameters. Similarly, the ALTO Server MUST only 1906 enumerate addresses within each PID that have types which were 1907 specified (implicitly or explicitly) in the request. If the input 1908 parameters contain an address type that is not currently known to the 1909 ALTO Server, the ALTO Server MUST behave as if the address type did 1910 not appear in the input parameters. 1912 10.2.1.6. Example 1914 POST /networkmap/filtered HTTP/1.1 1915 Host: custom.alto.example.com 1916 Content-Length: 27 1917 Content-Type: application/alto-networkmapfilter+json 1918 Accept: application/alto-networkmap+json,application/alto-error+json 1920 { 1921 "pids": [ "PID1", "PID2" ] 1922 } 1924 HTTP/1.1 200 OK 1925 Content-Length: 255 1926 Content-Type: application/alto-networkmap+json 1928 { 1929 "meta" : {}, 1930 "data" : { 1931 "map-vtag" : "1266506139", 1932 "map" : { 1933 "PID1" : { 1934 "ipv4" : [ 1935 "192.0.2.0/24", 1936 "198.51.100.0/24" 1937 ] 1938 }, 1939 "PID2" : { 1940 "ipv4": [ 1941 "198.51.100.128/24" 1942 ] 1943 } 1944 } 1945 } 1946 } 1948 10.2.2. Filtered Cost Map 1950 A Filtered Cost Map is a Cost Map Information Resource 1951 (Section 10.1.2) for which an ALTO Client may supply additional 1952 parameters limiting the scope of the resulting Cost Map. A Filtered 1953 Cost Map MAY be provided by an ALTO Server. 1955 10.2.2.1. Media Type 1957 As a Filtered Cost Map is a Cost Map, it uses the media type defined 1958 for Cost Map at Section 10.1.2.1. 1960 10.2.2.2. HTTP Method 1962 A Filtered Cost Map is requested using the HTTP POST method. 1964 10.2.2.3. Accept Input Parameters 1966 The input parameters for a Filtered Map are supplied in the entity 1967 body of the POST request. This document specifies the input 1968 parameters with a data format indicated by the media type 1969 "application/alto-costmapfilter+json", which is a JSON Object of type 1970 ReqFilteredCostMap, where: 1972 object { 1973 CostType cost-type; 1974 [JSONString constraints<0..*>;] 1975 [PIDFilter pids;] 1976 } ReqFilteredCostMap; 1978 object { 1979 PIDName srcs<0..*>; 1980 PIDName dsts<0..*>; 1981 } PIDFilter; 1983 with members: 1985 cost-type The CostType (Section 9.6) for the returned costs. This 1986 MUST be one of the supported Cost Types indicated in this 1987 resource's capabilities ( Section 10.2.2.4). 1989 constraints Defines a list of additional constraints on which 1990 elements of the Cost Map are returned. This parameter MUST NOT be 1991 specified if this resource's capabilities ( Section 10.2.2.4) 1992 indicate that constraint support is not available. A constraint 1993 contains two entities separated by whitespace: (1) an operator, 1994 'gt' for greater than, 'lt' for less than, 'ge' for greater than 1995 or equal to, 'le' for less than or equal to, or 'eq' for equal to; 1996 (2) a target cost value. The cost value is a number that MUST be 1997 defined in the same units as the Cost Metric indicated by the 1998 cost-metric parameter. ALTO Servers SHOULD use at least IEEE 754 1999 double-precision floating point [IEEE.754.2008] to store the cost 2000 value, and SHOULD perform internal computations using double- 2001 precision floating-point arithmetic. If multiple 'constraint' 2002 parameters are specified, they are interpreted as being related to 2003 each other with a logical AND. 2005 pids A list of Source PIDs and a list of Destination PIDs for which 2006 Path Costs are to be returned. If a list is empty, the ALTO 2007 Server MUST interpret it as the full set of currently-defined 2008 PIDs. The ALTO Server MUST interpret entries appearing in a list 2009 multiple times as if they appeared only once. If the "pids" 2010 member is not present, both lists MUST be interpreted by the ALTO 2011 Server as containing the full set of currently-defined PIDs. 2013 10.2.2.4. Capabilities 2015 The URI providing this resource supports all capabilities documented 2016 in Section 10.1.2.4 (with identical semantics), plus additional 2017 capabilities. In particular, the capabilities are defined by a JSON 2018 object of type FilteredCostMapCapabilities: 2020 object { 2021 JSONString cost-type-names<1..*>; 2022 JSONBool cost-constraints; 2023 } FilteredCostMapCapabilities; 2025 with members: 2027 cost-type-names See Section 10.1.2.4 and note that the array can 2028 have 1 to many cost types. 2030 cost-constraints If true, then the ALTO Server allows cost 2031 constraints to be included in requests to the corresponding URI. 2032 If not present, this member MUST be interpreted as if it specified 2033 false. ALTO Clients should be aware that constraints may not have 2034 the intended effect for cost maps with the 'ordinal' Cost Mode 2035 since ordinal costs are not restricted to being sequential 2036 integers. 2038 10.2.2.5. Response 2040 See Section 10.1.2.5 for the format. 2042 The returned Cost Map MUST contain only source/destination pairs that 2043 have been indicated (implicitly or explicitly) in the input 2044 parameters. If the input parameters contain a PID name that is not 2045 currently defined by the ALTO Server, the ALTO Server MUST behave as 2046 if the PID did not appear in the input parameters. 2048 If any constraints are specified, Source/Destination pairs for which 2049 the Path Costs do not meet the constraints MUST NOT be included in 2050 the returned Cost Map. If no constraints were specified, then all 2051 Path Costs are assumed to meet the constraints. 2053 Note that ALTO Clients should verify that the Version Tag included in 2054 the response is consistent with the Version Tag of the Network Map 2055 used to generate the request (if applicable). If it is not, the ALTO 2056 Client may wish to request an updated Network Map, identify changes, 2057 and consider requesting a new Filtered Cost Map. 2059 10.2.2.6. Example 2061 POST /costmap/filtered HTTP/1.1 2062 Host: custom.alto.example.com 2063 Content-Type: application/alto-costmapfilter+json 2064 Accept: application/alto-costmap+json,application/alto-error+json 2066 { 2067 "cost-type" : {"cost-mode": "numerical", 2068 "cost-metric": "routingcost"}, 2069 "pids" : { 2070 "srcs" : [ "PID1" ], 2071 "dsts" : [ "PID1", "PID2", "PID3" ] 2072 } 2073 } 2075 HTTP/1.1 200 OK 2076 Content-Length: 177 2077 Content-Type: application/alto-costmap+json 2079 { 2080 "meta" : {}, 2081 "data" : { 2082 "cost-type": {"cost-mode" : "numerical", 2083 "cost-metric" : "routingcost"}, 2084 "map-vtag" : "1266506139", 2085 "map" : { 2086 "PID1": { "PID1": 0, "PID2": 1, "PID3": 2 } 2087 } 2088 } 2089 } 2091 10.3. Endpoint Property Service 2093 The Endpoint Property Service provides information about Endpoint 2094 properties to ALTO Clients. 2096 10.3.1. Endpoint Property 2098 The Endpoint Property resource provides information about properties 2099 for individual endpoints. It MAY be provided by an ALTO Server. If 2100 an ALTO Server provides one or more Endpoint Property resources, then 2101 at least one MUST provide the 'pid' property. 2103 10.3.1.1. Media Type 2105 The media type of Endpoint Property is "application/ 2106 alto-endpointprop+json". 2108 10.3.1.2. HTTP Method 2110 The Endpoint Property resource is requested using the HTTP POST 2111 method. 2113 10.3.1.3. Accept Input Parameters 2115 An ALTO Client supplies the endpoint properties to be queried through 2116 a media type "application/alto-endpointpropparams+json", and 2117 specifies in the HTTP POST entity body a JSON Object of type 2118 ReqEndpointProp: 2120 object { 2121 EndpointPropertyType properties<1..*>; 2122 TypedEndpointAddr endpoints<1..*>; 2123 } ReqEndpointProp; 2125 with members: 2127 properties List of endpoint properties to be returned for each 2128 endpoint. Each specified property MUST be included in the list of 2129 supported properties indicated by this resource's capabilities 2130 (Section 10.3.1.4). The ALTO Server MUST interpret entries 2131 appearing multiple times as if they appeared only once. 2133 endpoints List of endpoint addresses for which the specified 2134 properties are to be returned. The ALTO Server MUST interpret 2135 entries appearing multiple times as if they appeared only once. 2137 10.3.1.4. Capabilities 2139 This resource may be defined across multiple types of endpoint 2140 properties. The capabilities of an ALTO Server URI providing 2141 Endpoint Properties are defined by a JSON Object of type 2142 EndpointPropertyCapabilities: 2144 object { 2145 EndpointPropertyType prop-types<0..*>; 2146 } EndpointPropertyCapabilities; 2148 with members: 2150 prop-types The Endpoint Properties (see Section 9.7) supported by 2151 the corresponding URI. If not present, this member MUST be 2152 interpreted as an empty array. 2154 10.3.1.5. Response 2156 The returned InfoResourceEntity object has "data" member of type 2157 InfoResourceEndpointProperty, where: 2159 object { 2160 VersionTag map-vtag; [DEPEND ON PROPERTIES] 2161 EndpointPropertyMapData map; 2162 } InfoResourceEndpointProperty; 2164 object-map { 2165 TypedEndpointAddr -> EndpointProps; 2166 } EndpointPropertyMapData; 2168 object { 2169 EndpointPropertyType -> JSONValue; 2170 } EndpointProps; 2172 EndpointPropertyMapData has one member for each endpoint indicated in 2173 the input parameters (with the name being the endpoint encoded as a 2174 TypedEndpointAddr). The requested properties for each endpoint are 2175 encoded in a corresponding EndpointProps object, which encodes one 2176 name/value pair for each requested property, where the property names 2177 are encoded as strings of type EndpointPropertyType. An 2178 implementation of the protocol in this document SHOULD assume that 2179 the property value is a JSONString and fail to parse if it is not, 2180 unless the implementation is using an extension to this document that 2181 indicates when and how property values of other data types are 2182 signaled. 2184 The ALTO Server returns the value for each of the requested endpoint 2185 properties for each of the endpoints listed in the input parameters. 2187 If the ALTO Server does not define a requested property's value for a 2188 particular endpoint, then it MUST omit that property from the 2189 response for only that endpoint. 2191 The ALTO Server MAY include the Version Tag (Section 6.3) of the 2192 Network Map used to generate the response (if desired and applicable) 2193 as the 'map-vtag' member in the response. If the 'pid' property is 2194 returned for any endpoints in the response, the 'map-vtag' member is 2195 REQUIRED. Otherwise, it is OPTIONAL. 2197 10.3.1.6. Example 2199 POST /endpointprop/lookup HTTP/1.1 2200 Host: alto.example.com 2201 Content-Length: 96 2202 Content-Type: application/alto-endpointpropparams+json 2203 Accept: application/alto-endpointprop+json,application/alto-error+json 2205 { 2206 "properties" : [ "pid", "example-prop" ], 2207 "endpoints" : [ "ipv4:192.0.2.34", "ipv4:203.0.113.129" ] 2208 } 2210 HTTP/1.1 200 OK 2211 Content-Length: 149 2212 Content-Type: application/alto-endpointprop+json 2214 { 2215 "meta" : {}, 2216 "data": { 2217 "map-vtag" : "1266506139", 2218 "map" : { 2219 "ipv4:192.0.2.34" : { "pid": "PID1", "example-prop": "1" }, 2220 "ipv4:203.0.113.129" : { "pid": "PID3" } 2221 } 2222 } 2223 } 2225 10.4. Endpoint Cost Service 2227 The Endpoint Cost Service provides information about costs between 2228 individual endpoints. 2230 In particular, this service allows lists of Endpoint prefixes (and 2231 addresses, as a special case) to be ranked (ordered) by an ALTO 2232 Server. 2234 10.4.1. Endpoint Cost 2236 The Endpoint Cost resource provides information about costs between 2237 individual endpoints. It MAY be provided by an ALTO Server. 2239 It is important to note that although this resource allows an ALTO 2240 Server to reveal costs between individual endpoints, an ALTO Server 2241 is not required to do so. A simple alternative would be to compute 2242 the cost between two endpoints as the cost between the PIDs 2243 corresponding to the endpoints. See Section 14.3 for additional 2244 details. 2246 10.4.1.1. Media Type 2248 The media type of Endpoint Cost is "application/ 2249 alto-endpointcost+json". 2251 10.4.1.2. HTTP Method 2253 The Endpoint Cost resource is requested using the HTTP POST method. 2255 10.4.1.3. Accept Input Parameters 2257 An ALTO Client supplies the endpoint cost parameters through a media 2258 type "application/alto-endpointcostparams+json", with an HTTP POST 2259 entity body of a JSON Object of type ReqEndpointCostMap: 2261 object { 2262 CostType cost-type; 2263 [JSONString constraints<0..*>;] 2264 EndpointFilter endpoints; 2265 } ReqEndpointCostMap; 2267 object { 2268 [TypedEndpointAddr srcs<0..*>;] 2269 TypedEndpointAddr dsts<1..*>; 2270 } EndpointFilter; 2271 with members: 2273 cost-type The Cost Type ( Section 9.6) to use for returned costs. 2274 This MUST be one of the CostType indicated in this resource's 2275 capabilities ( Section 10.4.1.4). 2277 constraints Defined equivalently to the "constraints" input 2278 parameter of a Filtered Cost Map (see Section 10.2.2). 2280 endpoints A list of Source Endpoints and Destination Endpoints for 2281 which Path Costs are to be returned. If the list of Source 2282 Endpoints is empty (or not included), the ALTO Server MUST 2283 interpret it as if it contained the Endpoint Address corresponding 2284 to the client IP address from the incoming connection (see 2285 Section 12.3 for discussion and considerations regarding this 2286 mode). The list of destination Endpoints MUST NOT be empty. The 2287 ALTO Server MUST interpret entries appearing multiple times in a 2288 list as if they appeared only once. 2290 10.4.1.4. Capabilities 2292 In this document, we define EndpointCostCapabilities the same as 2293 FilteredCostMapCapabilities. See Section 10.2.2.4. 2295 10.4.1.5. Response 2297 The returned InfoResourceEntity object has "data" member equal to 2298 InfoResourceEndpointCostMap, where: 2300 object { 2301 CostType cost-type; 2302 EndpointCostMapData map; 2303 } InfoResourceEndpointCostMap; 2305 object-map { 2306 TypedEndpointAddr -> EndpointDstCosts; 2307 } EndpointCostMapData; 2309 object-map { 2310 TypedEndpointAddr -> JSONValue; 2311 } EndpointDstCosts; 2313 InfoResourceEndpointCostMap has members: 2315 cost-type The Cost Type used in the returned Cost Map. 2317 map The Endpoint Cost Map data itself. 2319 EndpointCostMapData is a dictionary map object with each key 2320 representing a TypedEndpointAddr string identifying the Source 2321 Endpoint specified in the input parameters; the name for a member is. 2322 For each Source Endpoint, a EndpointDstCosts dictionary map object 2323 denotes the associated cost to each Destination Endpoint specified in 2324 input parameters. An implementation of the protocol in this document 2325 SHOULD assume that the cost value is a JSONNumber and fail to parse 2326 if it is not, unless the implementation is using an extension to this 2327 document that indicates when and how costs of other data types are 2328 signaled. If the ALTO Server does not define a cost value from a 2329 Source Endpoint to a particular Destination Endpoint, it MAY be 2330 omitted from the response. 2332 10.4.1.6. Example 2334 POST /endpointcost/lookup HTTP/1.1 2335 Host: alto.example.com 2336 Content-Length: 195 2337 Content-Type: application/alto-endpointcostparams+json 2338 Accept: application/alto-endpointcost+json,application/alto-error+json 2340 { 2341 "cost-type": {"cost-mode" : "ordinal", 2342 "cost-metric" : "routingcost"}, 2343 "endpoints" : { 2344 "srcs": [ "ipv4:192.0.2.2" ], 2345 "dsts": [ 2346 "ipv4:192.0.2.89", 2347 "ipv4:198.51.100.34", 2348 "ipv4:203.0.113.45" 2349 ] 2350 } 2351 } 2353 HTTP/1.1 200 OK 2354 Content-Length: 231 2355 Content-Type: application/alto-endpointcost+json 2357 { 2358 "meta" : {}, 2359 "data" : { 2360 "cost-type": {"cost-mode" : "ordinal", 2361 "cost-metric" : "routingcost"}, 2362 "map" : { 2363 "ipv4:192.0.2.2": { 2364 "ipv4:192.0.2.89" : 1, 2365 "ipv4:198.51.100.34" : 2, 2366 "ipv4:203.0.113.45" : 3 2367 } 2368 } 2369 } 2370 } 2372 11. Use Cases 2374 The sections below depict typical use cases. While these use cases 2375 focus on peer-to-peer applications, ALTO can be applied to other 2376 environments such as CDNs [I-D.jenkins-alto-cdn-use-cases]. 2378 11.1. ALTO Client Embedded in P2P Tracker 2380 Many currently-deployed P2P systems use a Tracker to manage swarms 2381 and perform peer selection. Such a P2P Tracker can already use a 2382 variety of information to perform peer selection to meet application- 2383 specific goals. By acting as an ALTO Client, the P2P Tracker can use 2384 ALTO information as an additional information source to enable more 2385 network-efficient traffic patterns and improve application 2386 performance. 2388 A particular requirement of many P2P trackers is that they must 2389 handle a large number of P2P clients. A P2P tracker can obtain and 2390 locally store ALTO information (the Network Map and Cost Map) from 2391 the ISPs containing the P2P clients, and benefit from the same 2392 aggregation of network locations done by ALTO Servers. 2394 .---------. (1) Get Network Map .---------------. 2395 | | <----------------------> | | 2396 | ALTO | | P2P Tracker | 2397 | Server | (2) Get Cost Map | (ALTO Client) | 2398 | | <----------------------> | | 2399 `---------' `---------------' 2400 ^ | 2401 (3) Get Peers | | (4) Selected Peer 2402 | v List 2403 .---------. .-----------. 2404 | Peer 1 | <-------------- | P2P | 2405 `---------' | Client | 2406 . (5) Connect to `-----------' 2407 . Selected Peers / 2408 .---------. / 2409 | Peer 50 | <------------------ 2410 `---------' 2412 Figure 4: ALTO Client Embedded in P2P Tracker 2414 Figure 4 shows an example use case where a P2P tracker is an ALTO 2415 Client and applies ALTO information when selecting peers for its P2P 2416 clients. The example proceeds as follows: 2418 1. The P2P Tracker requests from the ALTO Server using the Network 2419 Map query the Network Map covering all PIDs. The Network Map 2420 includes the IP prefixes contained in each PID, allowing the P2P 2421 tracker to locally map P2P clients into PIDs. 2423 2. The P2P Tracker requests from the ALTO Server the Cost Map 2424 amongst all PIDs identified in the preceding step. 2426 3. A P2P Client joins the swarm, and requests a peer list from the 2427 P2P Tracker. 2429 4. The P2P Tracker returns a peer list to the P2P client. The 2430 returned peer list is computed based on the Network Map and Cost 2431 Map returned by the ALTO Server, and possibly other information 2432 sources. Note that it is possible that a tracker may use only 2433 the Network Map to implement hierarchical peer selection by 2434 preferring peers within the same PID and ISP. 2436 5. The P2P Client connects to the selected peers. 2438 Note that the P2P tracker may provide peer lists to P2P clients 2439 distributed across multiple ISPs. In such a case, the P2P tracker 2440 may communicate with multiple ALTO Servers. 2442 11.2. ALTO Client Embedded in P2P Client: Numerical Costs 2444 P2P clients may also utilize ALTO information themselves when 2445 selecting from available peers. It is important to note that not all 2446 P2P systems use a P2P tracker for peer discovery and selection. 2447 Furthermore, even when a P2P tracker is used, the P2P clients may 2448 rely on other sources, such as peer exchange and DHTs, to discover 2449 peers. 2451 When an P2P Client uses ALTO information, it typically queries only 2452 the ALTO Server servicing its own ISP. The my-Internet view provided 2453 by its ISP's ALTO Server can include preferences to all potential 2454 peers. 2456 .---------. (1) Get Network Map .---------------. 2457 | | <----------------------> | | 2458 | ALTO | | P2P Client | 2459 | Server | (2) Get Cost Map | (ALTO Client) | 2460 | | <----------------------> | | .---------. 2461 `---------' `---------------' <- | P2P | 2462 .---------. / | ^ ^ | Tracker | 2463 | Peer 1 | <-------------- | | \ `---------' 2464 `---------' | (3) Gather Peers 2465 . (4) Select Peers | | \ 2466 . and Connect / .--------. .--------. 2467 .---------. / | P2P | | DHT | 2468 | Peer 50 | <---------------- | Client | `--------' 2469 `---------' | (PEX) | 2470 `--------' 2472 Figure 5: ALTO Client Embedded in P2P Client 2474 Figure 5 shows an example use case where a P2P Client locally applies 2475 ALTO information to select peers. The use case proceeds as follows: 2477 1. The P2P Client requests the Network Map covering all PIDs from 2478 the ALTO Server servicing its own ISP. 2480 2. The P2P Client requests the Cost Map amongst all PIDs from the 2481 ALTO Server. The Cost Map by default specifies numerical costs. 2483 3. The P2P Client discovers peers from sources such as Peer Exchange 2484 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2485 P2P Trackers. 2487 4. The P2P Client uses ALTO information as part of the algorithm for 2488 selecting new peers, and connects to the selected peers. 2490 11.3. ALTO Client Embedded in P2P Client: Ranking 2492 It is also possible for a P2P Client to offload the selection and 2493 ranking process to an ALTO Server. In this use case, the ALTO Client 2494 gathers a list of known peers in the swarm, and asks the ALTO Server 2495 to rank them. 2497 As in the use case using numerical costs, the P2P Client typically 2498 only queries the ALTO Server servicing its own ISP. 2500 .---------. .---------------. 2501 | | | | 2502 | ALTO | (2) Get Endpoint Ranking | P2P Client | 2503 | Server | <----------------------> | (ALTO Client) | 2504 | | | | .---------. 2505 `---------' `---------------' <- | P2P | 2506 .---------. / | ^ ^ | Tracker | 2507 | Peer 1 | <-------------- | | \ `---------' 2508 `---------' | (1) Gather Peers 2509 . (3) Connect to | | \ 2510 . Selected Peers / .--------. .--------. 2511 .---------. / | P2P | | DHT | 2512 | Peer 50 | <---------------- | Client | `--------' 2513 `---------' | (PEX) | 2514 `--------' 2516 Figure 6: ALTO Client Embedded in P2P Client: Ranking 2518 Figure 6 shows an example of this scenario. The use case proceeds as 2519 follows: 2521 1. The P2P Client discovers peers from sources such as Peer Exchange 2522 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2523 P2P Trackers. 2525 2. The P2P Client queries the ALTO Server's Ranking Service, 2526 including discovered peers as the set of Destination Endpoints, 2527 and indicates the 'ordinal' Cost Mode. The response indicates 2528 the ranking of the candidate peers. 2530 3. The P2P Client connects to the peers in the order specified in 2531 the ranking. 2533 12. Discussions 2535 12.1. Discovery 2537 The discovery mechanism by which an ALTO Client locates an 2538 appropriate ALTO Server is out of scope for this document. This 2539 document assumes that an ALTO Client can discover an appropriate ALTO 2540 Server. Once it has done so, the ALTO Client may use the Information 2541 Resource Directory (see Section 8.5) to locate an Information 2542 Resource with the desired ALTO Information. 2544 12.2. Hosts with Multiple Endpoint Addresses 2546 In practical deployments, a particular host can be reachable using 2547 multiple addresses (e.g., a wireless IPv4 connection, a wireline IPv4 2548 connection, and a wireline IPv6 connection). In general, the 2549 particular network path followed when sending packets to the host 2550 will depend on the address that is used. Network providers may 2551 prefer one path over another. An additional consideration may be how 2552 to handle private address spaces (e.g., behind carrier-grade NATs). 2554 To support such behavior, this document allows multiple endpoint 2555 addresses and address types. With this support, the ALTO Protocol 2556 allows an ALTO Service Provider the flexibility to indicate 2557 preferences for paths from an endpoint address of one type to an 2558 endpoint address of a different type. 2560 12.3. Network Address Translation Considerations 2562 At this day and age of NAT v4<->v4, v4<->v6 [RFC6144], and possibly 2563 v6<->v6[I-D.mrw-nat66], a protocol should strive to be NAT friendly 2564 and minimize carrying IP addresses in the payload, or provide a mode 2565 of operation where the source IP address provide the information 2566 necessary to the server. 2568 The protocol specified in this document provides a mode of operation 2569 where the source network location is computed by the ALTO Server 2570 (i.e., the the Endpoint Cost Service) from the source IP address 2571 found in the ALTO Client query packets. This is similar to how some 2572 P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS 2573 Protocol" in [BitTorrent]) operate. 2575 There may be cases where an ALTO Client needs to determine its own IP 2576 address, such as when specifying a source Endpoint Address in the 2577 Endpoint Cost Service. It is possible that an ALTO Client has 2578 multiple network interface addresses, and that some or all of them 2579 may require NAT for connectivity to the public Internet. 2581 If a public IP address is required for a network interface, the ALTO 2582 client SHOULD use the Session Traversal Utilities for NAT (STUN) 2583 [RFC5389]. If using this method, the host MUST use the "Binding 2584 Request" message and the resulting "XOR-MAPPED-ADDRESS" parameter 2585 that is returned in the response. Using STUN requires cooperation 2586 from a publicly accessible STUN server. Thus, the ALTO client also 2587 requires configuration information that identifies the STUN server, 2588 or a domain name that can be used for STUN server discovery. To be 2589 selected for this purpose, the STUN server needs to provide the 2590 public reflexive transport address of the host. 2592 ALTO Clients should be cognizant that the network path between 2593 Endpoints can depend on multiple factors, e.g., source address, and 2594 destination address used for communication. An ALTO Server provides 2595 information based on Endpoint Addresses (more generally, Network 2596 Locations), but the mechanisms used for determining existence of 2597 connectivity or usage of NAT between Endpoints are out of scope of 2598 this document. 2600 12.4. Endpoint and Path Properties 2602 An ALTO Server could make available many properties about Endpoints 2603 beyond their network location or grouping. For example, connection 2604 type, geographical location, and others may be useful to 2605 applications. This specification focuses on network location and 2606 grouping, but the protocol may be extended to handle other Endpoint 2607 properties. 2609 13. IANA Considerations 2611 13.1. application/alto-* Media Types 2613 This document requests the registration of multiple media types, 2614 listed in Table 2. 2616 +-------------+------------------------------+----------------+ 2617 | Type | Subtype | Specification | 2618 +-------------+------------------------------+----------------+ 2619 | application | alto-directory+json | Section 8.5 | 2620 | application | alto-networkmap+json | Section 10.1.1 | 2621 | application | alto-networkmapfilter+json | Section 10.2.1 | 2622 | application | alto-costmap+json | Section 10.1.2 | 2623 | application | alto-costmapfilter+json | Section 10.2.2 | 2624 | application | alto-endpointprop+json | Section 10.3.1 | 2625 | application | alto-endpointpropparams+json | Section 10.3.1 | 2626 | application | alto-endpointcost+json | Section 10.4.1 | 2627 | application | alto-endpointcostparams+json | Section 10.4.1 | 2628 | application | alto-error+json | Section 8.7 | 2629 +-------------+------------------------------+----------------+ 2631 Table 2: ALTO Protocol Media Types. 2633 Type name: application 2635 Subtype name: This documents requests the registration of multiple 2636 subtypes, as listed in Table 2. 2638 Required parameters: n/a 2640 Optional parameters: n/a 2642 Encoding considerations: Encoding considerations are identical to 2643 those specified for the 'application/json' media type. See 2644 [RFC4627]. 2646 Security considerations: Security considerations relating to the 2647 generation and consumption of ALTO protocol messages are discussed 2648 in Section 14. 2650 Interoperability considerations: This document specifies format of 2651 conforming messages and the interpretation thereof. 2653 Published specification: This document is the specification for 2654 these media types; see Table 2 for the section documenting each 2655 media type. 2657 Applications that use this media type: ALTO Servers and ALTO Clients 2658 either standalone or embedded within other applications. 2660 Additional information: 2662 Magic number(s): n/a 2664 File extension(s): This document uses the mime type to refer to 2665 protocol messages and thus does not require a file extension. 2667 Macintosh file type code(s): n/a 2669 Person & email address to contact for further information: See 2670 "Authors' Addresses" section. 2672 Intended usage: COMMON 2674 Restrictions on usage: n/a 2676 Author: See "Authors' Addresses" section. 2678 Change controller: Internet Engineering Task Force 2679 (mailto:iesg@ietf.org). 2681 13.2. ALTO Cost Metric Registry 2683 This document requests the creation of an ALTO Cost Metric registry, 2684 listed in Table 3, to be maintained by IANA. 2686 +-------------+---------------------+ 2687 | Identifier | Intended Semantics | 2688 +-------------+---------------------+ 2689 | routingcost | See Section 6.1.1.1 | 2690 | priv: | Private use | 2691 | exp: | Experimental use | 2692 +-------------+---------------------+ 2694 Table 3: ALTO Cost Metrics. 2696 This registry serves two purposes. First, it ensures uniqueness of 2697 identifiers referring to ALTO Cost Metrics. Second, it provides 2698 references to particular semantics of allocated Cost Metrics to be 2699 applied by both ALTO Servers and applications utilizing ALTO Clients. 2701 New ALTO Cost Metrics are assigned after Expert Review [RFC5226]. 2702 The Expert Reviewer will generally consult the ALTO Working Group or 2703 its successor. Expert Review is used to ensure that proper 2704 documentation regarding ALTO Cost Metric semantics and security 2705 considerations has been provided. The provided documentation should 2706 be detailed enough to provide guidance to both ALTO Service Providers 2707 and applications utilizing ALTO Clients as to how values of the 2708 registered ALTO Cost Metric should be interpreted. Updates and 2709 deletions of ALTO Cost Metrics follow the same procedure. 2711 Registered ALTO Cost Metric identifiers MUST conform to the 2712 syntactical requirements specified in Section 9.5. Identifiers are 2713 to be recorded and displayed as ASCII strings. 2715 Identifiers prefixed with 'priv:' are reserved for Private Use. 2716 Identifiers prefixed with 'exp:' are reserved for Experimental use. 2718 Requests to add a new value to the registry MUST include the 2719 following information: 2721 o Identifier: The name of the desired ALTO Cost Metric. 2723 o Intended Semantics: ALTO Costs carry with them semantics to guide 2724 their usage by ALTO Clients. For example, if a value refers to a 2725 measurement, the measurement units must be documented. For proper 2726 implementation of the ordinal Cost Mode (e.g., by a third-party 2727 service), it should be documented whether higher or lower values 2728 of the cost are more preferred. 2730 o Security Considerations: ALTO Costs expose information to ALTO 2731 Clients. As such, proper usage of a particular Cost Metric may 2732 require certain information to be exposed by an ALTO Service 2733 Provider. Since network information is frequently regarded as 2734 proprietary or confidential, ALTO Service Providers should be made 2735 aware of the security ramifications related to usage of a Cost 2736 Metric. 2738 This specification requests registration of the identifier 2739 'routingcost'. Semantics for the this Cost Metric are documented in 2740 Section 6.1.1.1, and security considerations are documented in 2741 Section 14.3. 2743 13.3. ALTO Endpoint Property Type Registry 2745 This document requests the creation of an ALTO Endpoint Property 2746 Types registry, listed in Table 4, to be maintained by IANA. 2748 +------------+--------------------+ 2749 | Identifier | Intended Semantics | 2750 +------------+--------------------+ 2751 | pid | See Section 7.1.1 | 2752 | priv: | Private use | 2753 | exp: | Experimental use | 2754 +------------+--------------------+ 2756 Table 4: ALTO Endpoint Property Types. 2758 The maintenance of this registry is similar to that of the preceding 2759 ALTO Cost Metrics. 2761 13.4. ALTO Address Type Registry 2763 This document requests the creation of an ALTO Address Type registry, 2764 listed in Table 5, to be maintained by IANA. 2766 +------------+----------------+----------------+--------------------+ 2767 | Identifier | Address | Prefix | Mapping to/from | 2768 | | Encoding | Encoding | IPv4/v6 | 2769 +------------+----------------+----------------+--------------------+ 2770 | ipv4 | See | See | Direct mapping to | 2771 | | Section 9.3.2 | Section 9.3.3 | IPv4 | 2772 | ipv6 | See | See | Direct mapping to | 2773 | | Section 9.3.2 | Section 9.3.3 | IPv6 | 2774 +------------+----------------+----------------+--------------------+ 2776 Table 5: ALTO Address Types. 2778 This registry serves two purposes. First, it ensures uniqueness of 2779 identifiers referring to ALTO Address Types. Second, it states the 2780 requirements for allocated Address Type identifiers. 2782 New ALTO Address Types are assigned after Expert Review [RFC5226]. 2783 The Expert Reviewer will generally consult the ALTO Working Group or 2784 its successor. Expert Review is used to ensure that proper 2785 documentation regarding the new ALTO Address Types and their security 2786 considerations has been provided. The provided documentation should 2787 indicate how an address of a registered type is encoded as an 2788 EndpointAddr and, if possible, a compact method (e.g., IPv4 and IPv6 2789 prefixes) for encoding a set of addresses as an EndpointPrefix. 2790 Updates and deletions of ALTO Address Types follow the same 2791 procedure. 2793 Registered ALTO Address Type identifiers MUST conform to the 2794 syntactical requirements specified in Section 9.3.1. Identifiers are 2795 to be recorded and displayed as ASCII strings. 2797 Requests to add a new value to the registry MUST include the 2798 following information: 2800 o Identifier: The name of the desired ALTO Address Type. 2802 o Endpoint Address Encoding: The procedure for encoding an address 2803 of the registered type as an EndpointAddr (see Section 9.3.2). 2805 o Endpoint Prefix Encoding: The procedure for encoding a set of 2806 addresses of the registered type as an EndpointPrefix (see 2807 Section 9.3.3). If no such compact encoding is available, the 2808 same encoding used for a singular address may be used. In such a 2809 case, it must be documented that sets of addresses of this type 2810 always have exactly one element. 2812 o Mapping to/from IPv4/IPv6 Addresses: If possible, a mechanism to 2813 map addresses of the registered type to and from IPv4 or IPv6 2814 addresses should be specified. 2816 o Security Considerations: In some usage scenarios, Endpoint 2817 Addresses carried in ALTO Protocol messages may reveal information 2818 about an ALTO Client or an ALTO Service Provider. Applications 2819 and ALTO Service Providers using addresses of the registered type 2820 should be made aware of how (or if) the addressing scheme relates 2821 to private information and network proximity. 2823 This specification requests registration of the identifiers 'ipv4' 2824 and 'ipv6', as shown in Table 5. 2826 13.5. ALTO Error Code Registry 2828 This document requests the creation of an ALTO Error Code registry, 2829 listed in Table 1, to be maintained by IANA. 2831 14. Security Considerations 2833 Some environments and use cases of ALTO require consideration of 2834 security attacks on ALTO Servers and Clients. In order to support 2835 those environments interoperably, the ALTO requirements document 2836 outlines minimum-to-implement authentication 2837 and other security requirements. Below we consider the threats and 2838 protection strategies. 2840 14.1. Authenticity and Integrity of ALTO Information 2842 14.1.1. Risk Scenarios 2844 An attacker may want to provide false or modified ALTO Information 2845 Resources or Information Resource Directory to ALTO Clients to 2846 achieve certain malicious goals. As an example, an attacker may 2847 provide false endpoint properties. For example, suppose that a 2848 network supports an endpoint property named hasQuota which reports if 2849 the endpoint has usage quota. An attacker may want to generate a 2850 false reply to lead to unexpected charges to the endpoint. An attack 2851 may also want to provide false Cost Map. For example, by faking a 2852 Cost Map that highly prefers a small address range or a single 2853 address, the attacker may be able to turn a distributed application 2854 into a Distributed Denial of Service (DDoS) tool. 2856 Depending on the network scenario, an attacker can attack 2857 authenticity and integrity of ALTO Information Resources using 2858 various techniques, including, but not limited to, sending forged 2859 DHCP replies in an Ethernet, DNS poisoning, and installing a 2860 transparent HTTP proxy that does some modifications. 2862 14.1.2. Protection Strategies 2864 ALTO protects the authenticity and integrity of ALTO Information 2865 (both Information Directory and individual Information Resources) by 2866 leveraging the authenticity and integrity mechanisms in TLS. In 2867 particular, the ALTO Protocol requires that HTTP over TLS MUST be supported, when protecting the 2869 authenticity and integrity of ALTO Information is required. The 2870 rules in for a client to verify server 2871 identity using server certificates MUST be supported. ALTO Providers 2872 who request server certificates and certification authorities who 2873 issue ALTO-specific certificates SHOULD consider the recommendations 2874 and guidelines defined in . 2876 Software engineers developing and service providers deploying ALTO 2877 with should make themselves familar with up-to-date Best Current 2878 Practices on configuring HTTP over TLS. 2880 14.1.3. Limitations 2882 The protection of HTTP over TLS for ALTO depends on that the domain 2883 name in the URI for the Information Resources is not comprised. This 2884 will depend on the protection implemented by service discovery. 2886 A deployment scenario may require redistribution of ALTO information 2887 to improve scalability. When authenticity and integrity of ALTO 2888 information are still required, then ALTO Clients obtaining ALTO 2889 information through redistribution must be able to validate the 2890 received ALTO information. Support for this validation is not 2891 provided in this document, but may be provided by extension 2892 documents. 2894 14.2. Potential Undesirable Guidance from Authenticated ALTO 2895 Information 2897 14.2.1. Risk Scenarios 2899 The ALTO Service makes it possible for an ALTO Provider to influence 2900 the behavior of network applications. An ALTO Provider may be 2901 hostile to some applications and hence try to use ALTO Information 2902 Resources to achieve certain goals : 2903 "redirecting applications to corrupted mediators providing malicious 2904 content, or applying policies in computing Cost Map based on criteria 2905 other than network efficiency." See for additional discussions on faked ALTO Guidance. 2908 A related scenario is that an ALTO Server could unintentionally give 2909 "bad" guidance. For example, if many ALTO Clients follow the Cost 2910 Map or Endpoint Cost guidance without doing additional sanity checks 2911 or adaptation, more preferable hosts and/or links could get 2912 overloaded while less preferable ones remain idle; see AR-14 of 2913 [RFC6708] for related application considerations. 2915 14.2.2. Protection Strategies 2917 To protect applications from undesirable ALTO Information Resources, 2918 it is important to note that there is no protocol mechanism to 2919 require conforming behaviors on how applications use ALTO Information 2920 Resources. An application using ALTO may consider including a 2921 mechanism to detect misleading or undesirable results from using ALTO 2922 Information Resources. For example, if throughput measurements do 2923 not show "better-than-random" results when using the Cost Map to 2924 select resource providers, the application may want to disable ALTO 2925 usage or switch to an external ALTO Server provided by an 2926 "independent organization" (see AR-20 and AR-21 in [RFC 6708]). If 2927 the first ALTO server is provided by the access network service 2928 provider and the access network service provider tries to redirect 2929 access to the external ALTO Server back to the provider's ALTO Server 2930 or try to tamper with the responses, the preceding authentication and 2931 integrity protection can detect such a behavior. 2933 14.3. Confidentiality of ALTO Information 2935 14.3.1. Risk Scenarios 2937 Although in many cases ALTO Information Resources may be regarded as 2938 non-confidential information, there are deployment cases where ALTO 2939 Information Resources can be sensitive information that can pose 2940 risks if exposed to unauthorized parties. We discuss the risks and 2941 protection strategies for such deployment scenarios. 2943 For example, an attacker may infer details regarding the topology, 2944 status, and operational policies of a network through the Network and 2945 Cost Maps. As a result, a sophisticated attacker may be able to 2946 infer more fine-graind topology information than an ISP hosting an 2947 ALTO server intends to disclose. The attacker can leverage the 2948 information to mount effective attacks such as focusing on high-cost 2949 links. 2951 Revealing some endpoint properties may also reveal additional 2952 information than the Provider intended. For example, when adding the 2953 line bitrate as one endpoint property, such information may be 2954 potentially linked to the income of the habitants at the network 2955 location of an endpoint. 2957 In Section 5.2.1, three types of risks 2958 associated with the confidentiality of ALTO Information Resources are 2959 identified: risk type (1) Excess disclosure of the ALTO service 2960 provider's data to an authorized ALTO client; risk type (2) 2961 Disclosure of the ALTO service provider's data (e.g., network 2962 topology information) to an unauthorized third party; and risk type 2963 (3) Excess retrieval of the ALTO service provider's data by 2964 collaborating ALTO clients. Section 10 of also discusses information leakage from ALTO. 2967 14.3.2. Protection Strategies 2969 To address risk type (1), the Provider of an ALTO Server must be 2970 cognizant that the network topology and provisioning information 2971 provided through ALTO may lead to attacks. ALTO does not require any 2972 particular level of details of information disclosure, and hence the 2973 Provider should evaluate how much information is revealed and the 2974 associated risks. 2976 To address risk type (2), the ALTO Protocol need confidentiality. 2977 Since ALTO requires that HTTP over TLS MUST be supported, the 2978 confidentiality mechanism is provided by HTTP over TLS. 2980 For deployment scenarios where client authentication is desired to 2981 address risk type (2), ALTO requires that HTTP Digestion 2982 Authentication MUST be supported to achieve ALTO Client 2983 Authentication to limit the parties with whom ALTO information is 2984 directly shared. Depending on the use-case and scenario, an ALTO 2985 server may apply other access control techniques to restrict access 2986 to its services. Access control can also help to prevent Denial-of- 2987 Service attacks by arbitrary hosts from the Internet. See for a more detailed discussion 2989 on this issue. 2991 14.3.3. Limitations 2993 ALTO Information Providers should be cognizant that encryption only 2994 protects ALTO information until it is decrypted by the intended ALTO 2995 Client. Digital Rights Management (DRM) techniques and legal 2996 agreements protecting ALTO information are outside of the scope of 2997 this document. 2999 14.4. Privacy for ALTO Users 3001 14.4.1. Risk Scenarios 3003 The ALTO Protocol provides mechanisms in which the ALTO Client 3004 serving a user can send messages containing Network Location 3005 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server. 3006 This is particularly true for the Endpoint Property, Endpoint Cost, 3007 and fine-grained Filtered Map services. The ALTO Server or a third- 3008 party who is able to intercept such messages can store and process 3009 obtained information in order to analyze user behaviors and 3010 communication patterns. The analysis may correlate information 3011 collected from multiple clients to deduce additional application/ 3012 content information. Such analysis can lead to privacy risks. For a 3013 more comprehensive classification of related risk scenarios, see 3014 cases 4, 5, and 6 in [RFC 6708], Section 5.2. 3016 14.4.2. Protection Strategies 3018 To protect user privacy, an ALTO Client should be cognizant about 3019 potential ALTO Server tracking through client queries. An ALTO 3020 Client may consider the possibility of relying only on Network Map 3021 for PIDs and Cost Map amongst PIDs to avoid passing IP addresses of 3022 other endpoints (e.g., peers) to the ALTO Server. When specific IP 3023 addresses are needed (e.g., when using the Endpoint Cost Service), an 3024 ALTO Client may consider obfuscation techniques such as specifying a 3025 broader address range (i.e., a shorter prefix length) or by zeroing 3026 out or randomizing the last few bits of IP addresses. Note that 3027 obfuscation may yield less accurate results. 3029 14.5. Availability of ALTO Service 3031 14.5.1. Risk Scenarios 3033 An attacker may want to disable ALTO Service as a way to disable 3034 network guidance to large scale applications.In particular, queries 3035 which can be generated with low effort but result in expensive 3036 workloads at the ALTO Server could be exploited for Denial-of-Service 3037 attacks. For instance, a simple ALTO query with n Source Network 3038 Locations and m Destination Network Locations can be generated fairly 3039 easily but results in the computation of n*m Path Costs between pairs 3040 by the ALTO Server (see Section 5.2). 3042 14.5.2. Protection Strategies 3044 ALTO Provider should be cognizant of the workload at the ALTO Server 3045 generated by certain ALTO Queries, such as certain queries to the Map 3046 Service, the Map Filtering Service and the Endpoint Cost (Ranking) 3047 Service. One way to limit Denial-of-Service attacks is to employ 3048 access control to the ALTO Server. The ALTO Server can also indicate 3049 overload and reject repeated requests that can cause availability 3050 problems. More advanced protection schemes such as computational 3051 puzzles [I-D.jennings-sip-hashcash] may be considered in an extension 3052 document. 3054 An ALTO Provider should also leverage the fact that the Map Service 3055 allows ALTO Servers to pre-generate maps that can be distributed to 3056 many ALTO Clients. 3058 15. Manageability Considerations 3060 This section details operations and management considerations based 3061 on existing deployments and discussions during protocol development. 3062 It also indicates where extension documents are expected to provide 3063 appropriate functionality discussed in [RFC5706] as additional 3064 deployment experience becomes available. 3066 15.1. Operations 3067 15.1.1. Installation and Initial Setup 3069 The ALTO Protocol is based on HTTP. Thus, configuring an ALTO Server 3070 may require configuring the underlying HTTP server implementation to 3071 define appropriate security policies, caching policies, performance 3072 settings, etc. 3074 Additionally, an ALTO Service Provider will need to configure the 3075 ALTO information to be provided by the ALTO Server. The granularity 3076 of the topological map and the cost map is left to the specific 3077 policies of the ALTO Service Provider. However, a reasonable default 3078 may include two PIDs, one to hold the endpoints in the provider's 3079 network and the second PID to represent full IPv4 and IPv6 3080 reachability (see Section 5.2.1), with the cost between each source/ 3081 destination PID set to 1. Another operational issue that the ALTO 3082 Service Provider needs to consider is that the filtering service can 3083 degenerate into a full map service when the filtering input is empty. 3084 Although this choice as the degeneration behavior provides 3085 continuity, the operational impact should be considered. 3087 Implementers employing an ALTO Client should attempt to automatically 3088 discover an appropriate ALTO Server. Manual configuration of the 3089 ALTO Server location may be used where automatic discovery is not 3090 appropriate. Methods for automatic discovery and manual 3091 configuration are discussed in [I-D.ietf-alto-server-discovery]. 3093 Specifications for underlying protocols (e.g., TCP, HTTP, SSL/TLS) 3094 should be consulted for their available settings and proposed default 3095 configurations. 3097 15.1.2. Migration Path 3099 This document does not detail a migration path for ALTO Servers since 3100 there is no previous standard protocol providing the similar 3101 functionality. 3103 There are existing applications making use of network information 3104 discovered from other entities such as whois, geo-location databases, 3105 or round-trip time measurements, etc. Such applications should 3106 consider using ALTO as an additional source of information; ALTO need 3107 not be the sole source of network information. 3109 15.1.3. Requirements on Other Protocols and Functional Components 3111 The ALTO Protocol assumes that HTTP client and server implementations 3112 exist. It also assumes that JSON encoder and decoder implementations 3113 exist. 3115 An ALTO Server assumes that it can gather sufficient information to 3116 populate Network and Cost maps. "Sufficient information" is 3117 dependent on the information being exposed, but likely includes 3118 information gathered from protocols such as IGP and EGP Routing 3119 Information Bases (see Figure 1). Specific mechanisms have been 3120 proposed (e.g., [I-D.medved-alto-svr-apis]) and are expected to be 3121 provided in extension documents. 3123 15.1.4. Impact and Observation on Network Operation 3125 ALTO presents a new opportunity for managing network traffic by 3126 providing additional information to clients. The potential impact to 3127 network operation is large. 3129 Deployment of an ALTO Server may shift network traffic patterns. 3130 Thus, an ALTO Service Provider should consider impacts on (or 3131 integration with) traffic engineering and the deployment of a 3132 monitoring service to observe the effects of ALTO operations. Note 3133 that ALTO-specific monitoring and metrics are discussed in 6.3 of 3134 [I-D.ietf-alto-deployments] and future versions of that document. In 3135 particular, an ALTO Service Provider may observe that ALTO Clients 3136 are not bound to ALTO Server guidance as ALTO is only one source of 3137 information. 3139 An ALTO Service Provider should ensure that appropriate information 3140 is being exposed. Privacy implications for ISPs are discussed in 3141 Section 14.3. Both ALTO Service Providers and those using ALTO 3142 Clients should be aware of the impact of incorrect or faked guidance 3143 (see Section 10.3 of [I-D.ietf-alto-deployments] and future versions 3144 of that document). 3146 15.2. Management 3148 15.2.1. Management Interoperability 3150 A common management API would be desirable given that ALTO Servers 3151 may typically be configured with dynamic data from various sources, 3152 and ALTO Servers are intended to scale horizontally for fault- 3153 tolerance and reliability. A specific API or protocol is outside the 3154 scope of this document, but may be provided by an extension document. 3156 Logging is an important functionality for ALTO Servers and, depending 3157 on the deployment, ALTO Clients. Logging should be done via syslog 3158 [RFC5424]. 3160 15.2.2. Management Information 3162 A Management Information Model (see Section 3.2 of [RFC5706] is not 3163 provided by this document, but should be included or referenced by 3164 any extension documenting an ALTO-related management API or protocol. 3166 15.2.3. Fault Management 3168 Monitoring ALTO Servers and Clients is described in Section 6.3 of 3169 [I-D.ietf-alto-deployments] and future versions of that document. 3171 15.2.4. Configuration Management 3173 Standardized approaches and protocols to configuration management for 3174 ALTO are outside the scope of this document, but this document does 3175 outline high-level principles suggested for future standardization 3176 efforts. 3178 An ALTO Server requires at least the following logical inputs: 3180 o Data sources from which ALTO Information is derived. This can 3181 either be raw network information (e.g., from routing elements) or 3182 pre-processed ALTO-level information in the form of a Network Map, 3183 Cost Map, etc. 3185 o Algorithms for computing the ALTO information returned to clients. 3186 These could either return information from a database, or 3187 information customized for each client. 3189 o Security policies mapping potential clients to the information 3190 that they have privilege to access. 3192 Multiple ALTO Servers can be deployed for scalability. A centralized 3193 configuration database may be used to ensure they are providing the 3194 desired ALTO information with appropriate security controls. The 3195 ALTO information (e.g., Network Maps and Cost Maps) being served by 3196 each ALTO Server, as well as security policies (HTTP authentication, 3197 SSL/TLS client and server authentication, SSL/TLS encryption 3198 parameters) intended to serve the same information should be 3199 monitored for consistency. 3201 15.2.5. Performance Management 3203 An exhaustive list of desirable performance information from a ALTO 3204 Servers and ALTO Clients are outside of the scope of this document. 3205 The following is a list of suggested ALTO-specific to be monitored 3206 based on the existing deployment and protocol development experience: 3208 o Requests and responses for each service listed in a Information 3209 Directory (total counts and size in bytes). 3211 o CPU and memory utilization 3213 o ALTO map updates 3215 o Number of PIDs 3217 o ALTO map sizes (in-memory size, encoded size, number of entries) 3219 15.2.6. Security Management 3221 Section 14 documents ALTO-specific security considerations. 3222 Operators should configure security policies with those in mind. 3223 Readers should refer to HTTP [RFC2616] and SSL/TLS [RFC5246] and 3224 related documents for mechanisms available for configuring security 3225 policies. Other appropriate security mechanisms (e.g., physical 3226 security, firewalls, etc) should also be considered. 3228 16. References 3230 16.1. Normative References 3232 [IEEE.754.2008] 3233 Institute of Electrical and Electronics Engineers, 3234 "Standard for Binary Floating-Point Arithmetic", IEEE 3235 Standard 754, August 2008. 3237 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 3238 Extensions (MIME) Part Two: Media Types", RFC 2046, 3239 November 1996. 3241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3242 Requirement Levels", BCP 14, RFC 2119, March 1997. 3244 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3245 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3246 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3248 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3249 Resource Identifier (URI): Generic Syntax", STD 66, 3250 RFC 3986, January 2005. 3252 [RFC4627] Crockford, D., "The application/json Media Type for 3253 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 3255 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 3256 (CIDR): The Internet Address Assignment and Aggregation 3257 Plan", BCP 122, RFC 4632, August 2006. 3259 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3260 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3261 May 2008. 3263 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3264 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 3266 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3267 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3268 October 2008. 3270 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 3272 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 3273 Optimization (ALTO) Problem Statement", RFC 5693, 3274 October 2009. 3276 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 3277 Address Text Representation", RFC 5952, August 2010. 3279 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3280 Verification of Domain-Based Application Service Identity 3281 within Internet Public Key Infrastructure Using X.509 3282 (PKIX) Certificates in the Context of Transport Layer 3283 Security (TLS)", RFC 6125, March 2011. 3285 [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 3286 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 3287 Requirements", RFC 6708, September 2012. 3289 16.2. Informative References 3291 [BitTorrent] 3292 "Bittorrent Protocol Specification v1.0", 3293 . 3295 [Fielding-Thesis] 3296 Fielding, R., "Architectural Styles and the Design of 3297 Network-based Software Architectures", University of 3298 California, Irvine, Dissertation 2000, 2000. 3300 [I-D.akonjang-alto-proxidor] 3301 Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 3302 Saucez, "The PROXIDOR Service", 3303 draft-akonjang-alto-proxidor-00 (work in progress), 3304 March 2009. 3306 [I-D.ietf-alto-deployments] 3307 Stiemerling, M., Kiesel, S., and S. Previdi, "ALTO 3308 Deployment Considerations", draft-ietf-alto-deployments-06 3309 (work in progress), February 2013. 3311 [I-D.ietf-alto-reqs] 3312 Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, 3313 "Application-Layer Traffic Optimization (ALTO) 3314 Requirements", draft-ietf-alto-reqs-08 (work in progress), 3315 March 2011. 3317 [I-D.ietf-alto-server-discovery] 3318 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 3319 S. Yongchao, "ALTO Server Discovery", 3320 draft-ietf-alto-server-discovery-08 (work in progress), 3321 March 2013. 3323 [I-D.ietf-httpbis-p2-semantics] 3324 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 3325 (HTTP/1.1): Semantics and Content", 3326 draft-ietf-httpbis-p2-semantics-22 (work in progress), 3327 February 2013. 3329 [I-D.jenkins-alto-cdn-use-cases] 3330 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 3331 S. Previdi, "Use Cases for ALTO within CDNs", 3332 draft-jenkins-alto-cdn-use-cases-03 (work in progress), 3333 June 2012. 3335 [I-D.medved-alto-svr-apis] 3336 Medved, J., Ward, D., Peterson, J., Woundy, R., and D. 3337 McDysan, "ALTO Network-Server and Server-Server APIs", 3338 draft-medved-alto-svr-apis-00 (work in progress), 3339 March 2011. 3341 [I-D.mrw-nat66] 3342 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 3343 Translation", draft-mrw-nat66-16 (work in progress), 3344 April 2011. 3346 [I-D.p4p-framework] 3347 Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, 3348 "P4P: Provider Portal for P2P Applications", 3349 draft-p4p-framework-00 (work in progress), November 2008. 3351 [I-D.saumitra-alto-multi-ps] 3352 Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 3353 Dimensional Peer Selection Problem", 3354 draft-saumitra-alto-multi-ps-00 (work in progress), 3355 October 2008. 3357 [I-D.saumitra-alto-queryresponse] 3358 Das, S. and V. Narayanan, "A Client to Service Query 3359 Response Protocol for ALTO", 3360 draft-saumitra-alto-queryresponse-00 (work in progress), 3361 March 2009. 3363 [I-D.shalunov-alto-infoexport] 3364 Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 3365 Export Service", draft-shalunov-alto-infoexport-00 (work 3366 in progress), October 2008. 3368 [I-D.wang-alto-p4p-specification] 3369 Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, 3370 "P4P Protocol Specification", 3371 draft-wang-alto-p4p-specification-00 (work in progress), 3372 March 2009. 3374 [P4P-SIGCOMM08] 3375 Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A. 3376 Silberschatz, "P4P: Provider Portal for (P2P) 3377 Applications", SIGCOMM 2008, August 2008. 3379 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 3380 Management of New Protocols and Protocol Extensions", 3381 RFC 5706, November 2009. 3383 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 3384 IPv4/IPv6 Translation", RFC 6144, April 2011. 3386 Appendix A. Acknowledgments 3388 Thank you to Jan Seedorf and Sebastian Kiesel for contributions to 3389 the Security Considerations section. Ben Niven-Jenkins, Wendy Roome 3390 and Michael Scharf gave substantial feedback and suggestions on the 3391 protocol design. 3393 We would like to thank the following people whose input and 3394 involvement was indispensable in achieving this merged proposal: 3396 Obi Akonjang (DT Labs/TU Berlin), 3397 Saumitra M. Das (Qualcomm Inc.), 3399 Syon Ding (China Telecom), 3401 Doug Pasko (Verizon), 3403 Laird Popkin (Pando Networks), 3405 Satish Raghunath (Juniper Networks), 3407 Albert Tian (Ericsson/Redback), 3409 Yu-Shun Wang (Microsoft), 3411 David Zhang (PPLive), 3413 Yunfei Zhang (China Mobile). 3415 We would also like to thank the following additional people who were 3416 involved in the projects that contributed to this merged document: 3417 Alex Gerber (ATT), Chris Griffiths (Comcast), Ramit Hora (Pando 3418 Networks), Arvind Krishnamurthy (University of Washington), Marty 3419 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 3420 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (ATT), 3421 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 3422 Damien Saucez (UCL) Thomas Scholl (ATT), Emilio Sepulveda 3423 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 3424 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 3425 (Huawei), Oliver Spatscheck (ATT), See-Mong Tang (Microsoft), Jia 3426 Wang (ATT), Hao Wang (Yale University), Ye Wang (Yale University), 3427 Haiyong Xie (Yale University). 3429 Appendix B. Design History and Merged Proposals 3431 The ALTO Protocol specified in this document consists of 3432 contributions from 3434 o P4P [I-D.p4p-framework], [P4P-SIGCOMM08], 3435 [I-D.wang-alto-p4p-specification]; 3437 o ALTO Info-Export [I-D.shalunov-alto-infoexport]; 3439 o Query/Response [I-D.saumitra-alto-queryresponse], 3440 [I-D.saumitra-alto-multi-ps]; 3442 o ATTP [ATTP]; and 3443 o Proxidor [I-D.akonjang-alto-proxidor]. 3445 Appendix C. Authors 3447 [[CmtAuthors: RFC Editor: Please move information in this section to 3448 the Authors' Addresses section at publication time.]] 3450 Stefano Previdi 3451 Cisco 3453 Email: sprevidi@cisco.com 3455 Stanislav Shalunov 3456 BitTorrent 3458 Email: shalunov@bittorrent.com 3460 Richard Woundy 3461 Comcast 3463 Richard_Woundy@cable.comcast.com 3465 Authors' Addresses 3467 Richard Alimi (editor) 3468 Google 3469 1600 Amphitheatre Parkway 3470 Mountain View CA 3471 USA 3473 Email: ralimi@google.com 3475 Reinaldo Penno (editor) 3476 Cisco Systems 3477 170 West Tasman Dr 3478 San Jose CA 3479 USA 3481 Email: repenno@cisco.com 3482 Y. Richard Yang (editor) 3483 Yale University 3484 51 Prospect St 3485 New Haven CT 3486 USA 3488 Email: yry@cs.yale.edu