idnits 2.17.1 draft-ietf-alto-protocol-14.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 989 has weird spacing: '...etaData meta...' == Line 995 has weird spacing: '... meta meta-...' == Line 997 has weird spacing: '... data the d...' == Line 1065 has weird spacing: '...NString uri;...' == Line 1066 has weird spacing: '...NString medi...' == (9 more instances...) -- The document date (Feb 25, 2013) is 4070 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ATTP' is mentioned on line 255, but not defined == Missing Reference: 'OPTIONAL' is mentioned on line 2188, but not defined == Missing Reference: 'InfoResourceDataType' is mentioned on line 990, but not defined == Missing Reference: 'PIDName' is mentioned on line 1694, but not defined == Missing Reference: 'EndpointPropertyType' is mentioned on line 2079, but not defined == Missing Reference: 'TypedEndpointAddr' is mentioned on line 2225, but not defined == Unused Reference: 'I-D.gu-alto-redistribution' is defined on line 3135, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.2008' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 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) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == 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-07 Summary: 6 errors (**), 0 flaws (~~), 17 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: August 29, 2013 Cisco Systems 6 Y. Yang, Ed. 7 Yale University 8 Feb 25, 2013 10 ALTO Protocol 11 draft-ietf-alto-protocol-14.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 operator (e.g., an ISP), content service providers and third parties 37 could also operate this service. Applications that could use this 38 service are those that have a choice to which end points to connect. 39 Examples of such applications are peer-to-peer (P2P) and content 40 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 August 29, 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. Design History and Merged Proposals . . . . . . . . . . . 6 84 1.3. Solution Benefits . . . . . . . . . . . . . . . . . . . . 7 85 1.3.1. Service Providers . . . . . . . . . . . . . . . . . . 7 86 1.3.2. Applications . . . . . . . . . . . . . . . . . . . . . 7 87 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 89 2.1.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . . 8 90 2.1.2. Endpoint Address . . . . . . . . . . . . . . . . . . . 8 91 2.1.3. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 8 92 2.1.4. Network Location . . . . . . . . . . . . . . . . . . . 8 93 2.1.5. ALTO Information . . . . . . . . . . . . . . . . . . . 8 94 2.1.6. ALTO Information Base . . . . . . . . . . . . . . . . 9 95 2.2. ALTO Service and Protocol Scope . . . . . . . . . . . . . 9 96 2.3. ALTO Information Reuse and Redistribution . . . . . . . . 10 97 3. ALTO Information Service Framework . . . . . . . . . . . . . . 11 98 3.1. ALTO Information Services . . . . . . . . . . . . . . . . 12 99 3.1.1. Map Service . . . . . . . . . . . . . . . . . . . . . 12 100 3.1.2. Map Filtering Service . . . . . . . . . . . . . . . . 12 101 3.1.3. Endpoint Property Service . . . . . . . . . . . . . . 12 102 3.1.4. Endpoint Cost Service . . . . . . . . . . . . . . . . 12 103 4. Network Map . . . . . . . . . . . . . . . . . . . . . . . . . 12 104 4.1. Provider-defined Identifier (PID) . . . . . . . . . . . . 13 105 4.2. Endpoint Addresses . . . . . . . . . . . . . . . . . . . . 13 106 4.2.1. IP Addresses . . . . . . . . . . . . . . . . . . . . . 14 107 4.3. Example Network Map . . . . . . . . . . . . . . . . . . . 14 108 5. Cost Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 109 5.1. Cost Attributes . . . . . . . . . . . . . . . . . . . . . 15 110 5.1.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . 15 111 5.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 16 112 5.2. Cost Map Structure . . . . . . . . . . . . . . . . . . . . 17 113 5.3. Network Map and Cost Map Dependency . . . . . . . . . . . 17 114 6. Endpoint Properties . . . . . . . . . . . . . . . . . . . . . 18 115 6.1. Endpoint Property Type . . . . . . . . . . . . . . . . . . 18 116 6.1.1. Endpoint Property Type: pid . . . . . . . . . . . . . 18 117 7. Protocol Specification: General Processing . . . . . . . . . . 18 118 7.1. Overall Design . . . . . . . . . . . . . . . . . . . . . . 18 119 7.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 19 120 7.3. Basic Operation . . . . . . . . . . . . . . . . . . . . . 19 121 7.3.1. Discovering Information Resources . . . . . . . . . . 19 122 7.3.2. Requesting Information Resources . . . . . . . . . . . 19 123 7.3.3. Response . . . . . . . . . . . . . . . . . . . . . . . 20 124 7.3.4. Client Behavior . . . . . . . . . . . . . . . . . . . 21 125 7.3.5. Authentication and Encryption . . . . . . . . . . . . 21 126 7.3.6. HTTP Cookies . . . . . . . . . . . . . . . . . . . . . 21 127 7.3.7. Parsing . . . . . . . . . . . . . . . . . . . . . . . 21 128 7.4. Information Resource Attributes . . . . . . . . . . . . . 21 129 7.4.1. Capability Advertisement . . . . . . . . . . . . . . . 22 130 7.4.2. Accept Input Parameters . . . . . . . . . . . . . . . 22 131 7.4.3. Media Type . . . . . . . . . . . . . . . . . . . . . . 22 132 7.5. Information Resource Media Type Encoding . . . . . . . . . 22 133 7.5.1. Meta Information . . . . . . . . . . . . . . . . . . . 22 134 7.5.2. ALTO Information . . . . . . . . . . . . . . . . . . . 23 135 7.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 23 136 7.6. Information Resource Directory . . . . . . . . . . . . . . 23 137 7.6.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 24 138 7.6.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . 24 139 7.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 25 140 7.6.4. Usage Considerations . . . . . . . . . . . . . . . . . 28 141 7.7. Protocol Errors . . . . . . . . . . . . . . . . . . . . . 29 142 7.7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 29 143 7.7.2. Resource Format . . . . . . . . . . . . . . . . . . . 30 144 7.7.3. Error Codes . . . . . . . . . . . . . . . . . . . . . 30 145 7.7.4. Overload Conditions and Server Unavailability . . . . 31 146 8. Protocol Specification: Basic ALTO Data Types . . . . . . . . 31 147 8.1. PID Name . . . . . . . . . . . . . . . . . . . . . . . . . 31 148 8.2. Version Tag . . . . . . . . . . . . . . . . . . . . . . . 31 149 8.3. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 32 150 8.3.1. Address Type . . . . . . . . . . . . . . . . . . . . . 32 151 8.3.2. Endpoint Address . . . . . . . . . . . . . . . . . . . 32 152 8.3.3. Endpoint Prefixes . . . . . . . . . . . . . . . . . . 33 153 8.3.4. Endpoint Address Group . . . . . . . . . . . . . . . . 33 154 8.4. Cost Mode . . . . . . . . . . . . . . . . . . . . . . . . 34 155 8.5. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . 34 156 8.6. Endpoint Property . . . . . . . . . . . . . . . . . . . . 35 157 9. Protocol Specification: Service Information Resources . . . . 35 158 9.1. Map Service . . . . . . . . . . . . . . . . . . . . . . . 35 159 9.1.1. Network Map . . . . . . . . . . . . . . . . . . . . . 35 160 9.1.2. Cost Map . . . . . . . . . . . . . . . . . . . . . . . 37 161 9.2. Map Filtering Service . . . . . . . . . . . . . . . . . . 40 162 9.2.1. Filtered Network Map . . . . . . . . . . . . . . . . . 40 163 9.2.2. Filtered Cost Map . . . . . . . . . . . . . . . . . . 42 164 9.3. Endpoint Property Service . . . . . . . . . . . . . . . . 46 165 9.3.1. Endpoint Property . . . . . . . . . . . . . . . . . . 46 166 9.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 49 167 9.4.1. Endpoint Cost . . . . . . . . . . . . . . . . . . . . 49 168 10. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 53 169 10.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 54 170 10.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 55 171 10.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 56 172 11. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 57 173 11.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 57 174 11.2. Hosts with Multiple Endpoint Addresses . . . . . . . . . . 58 175 11.3. Network Address Translation Considerations . . . . . . . . 58 176 11.4. Endpoint and Path Properties . . . . . . . . . . . . . . . 59 177 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 178 12.1. application/alto-* Media Types . . . . . . . . . . . . . . 59 179 12.2. ALTO Cost Type Registry . . . . . . . . . . . . . . . . . 60 180 12.3. ALTO Endpoint Property Type Registry . . . . . . . . . . . 62 181 12.4. ALTO Address Type Registry . . . . . . . . . . . . . . . . 62 182 12.5. ALTO Error Code Registry . . . . . . . . . . . . . . . . . 63 183 13. Security Considerations . . . . . . . . . . . . . . . . . . . 64 184 13.1. Privacy Considerations for ISPs . . . . . . . . . . . . . 64 185 13.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 64 186 13.3. Authentication, Integrity Protection, and Encryption . . . 65 187 13.4. ALTO Information Redistribution . . . . . . . . . . . . . 65 188 13.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 66 189 13.6. ALTO Server Access Control . . . . . . . . . . . . . . . . 66 190 14. Manageability Considerations . . . . . . . . . . . . . . . . . 66 191 14.1. Operations . . . . . . . . . . . . . . . . . . . . . . . . 67 192 14.1.1. Installation and Initial Setup . . . . . . . . . . . . 67 193 14.1.2. Migration Path . . . . . . . . . . . . . . . . . . . . 67 194 14.1.3. Requirements on Other Protocols and Functional 195 Components . . . . . . . . . . . . . . . . . . . . . . 67 196 14.1.4. Impact and Observation on Network Operation . . . . . 68 197 14.2. Management . . . . . . . . . . . . . . . . . . . . . . . . 68 198 14.2.1. Management Interoperability . . . . . . . . . . . . . 68 199 14.2.2. Management Information . . . . . . . . . . . . . . . . 69 200 14.2.3. Fault Management . . . . . . . . . . . . . . . . . . . 69 201 14.2.4. Configuration Management . . . . . . . . . . . . . . . 69 202 14.2.5. Performance Management . . . . . . . . . . . . . . . . 69 203 14.2.6. Security Management . . . . . . . . . . . . . . . . . 70 204 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 205 15.1. Normative References . . . . . . . . . . . . . . . . . . . 70 206 15.2. Informative References . . . . . . . . . . . . . . . . . . 71 207 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 73 208 Appendix B. Authors . . . . . . . . . . . . . . . . . . . . . . . 74 209 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 211 1. Introduction 213 1.1. Background and Problem Statement 215 Today, network information available to applications is mostly from 216 the view of endhosts. There is no clear mechanism for a network to 217 convey to network applications its point of view on its network 218 topological structures and path preferences, forcing applications to 219 make approximations using data sources such as BGP Looking Glass 220 and/or applications' own measurements, which can be misleading or 221 inaccurate. On the other hand, modern network applications can be 222 adaptive, with the potential to become more network-efficient (e.g., 223 reduce network resource consumption) and achieve better application 224 performance (e.g., accelerated download rate), by leveraging better 225 network-provided information. 227 This document defines the ALTO protocol to implement the ALTO 228 Service, which provides a simple mechanism to convey useful network 229 topological and path preference information to applications from the 230 underlying network's Provider's point of view. The ALTO protocol 231 meets the ALTO requirements [I-D.ietf-alto-reqs], and unifies 232 multiple protocols previously designed with similar intentions (see 233 Section 1.2). 235 The ALTO protocol uses a REST-ful design [Fielding-Thesis], and 236 encodes its requests and responses using JSON [RFC4627]. These 237 designs are chosen because of their flexibility and extensibility. 238 In addition, these designs make it possible for ALTO to leverage the 239 existing HTTP [RFC2616] implementations and infrastructures for 240 better, scalable deployment. 242 1.2. Design History and Merged Proposals 244 The ALTO Protocol specified in this document consists of 245 contributions from 247 o P4P [I-D.p4p-framework], [P4P-SIGCOMM08], 248 [I-D.wang-alto-p4p-specification]; 250 o ALTO Info-Export [I-D.shalunov-alto-infoexport]; 252 o Query/Response [I-D.saumitra-alto-queryresponse], 253 [I-D.saumitra-alto-multi-ps]; 255 o ATTP [ATTP]; and 257 o Proxidor [I-D.akonjang-alto-proxidor]. 259 See Appendix A for a list of people who have made significant 260 contributions to this effort as well as the aforementioned projects 261 and proposals. 263 1.3. Solution Benefits 265 At a high level, the ALTO Service allows a Service Provider (e.g., an 266 ISP) to publish information about network locations and costs between 267 them at configurable granularities. 269 A mechanism to publish such information can benefit both Service 270 Providers (providers of the information) and Applications (consumers 271 of the information). We enumerate some benefits below. 273 1.3.1. Service Providers 275 Service Providers that use the ALTO Service can benefit in achieving 276 better traffic management. For example, by using ALTO as a tool to 277 interact with applications, a Service Provider gives network 278 information to applications to manage traffic on more expensive or 279 difficult to provision links such as long distance, transit or backup 280 links. This improves the efficiency of provisioning the networking 281 infrastructure of the Service Provider. 283 1.3.2. Applications 285 Applications that use the ALTO Service can benefit in achieving 286 better network cooperation and reducing overhead. Specifically, 287 applications taking advantage of the ISP's knowledge can both avoid 288 network bottlenecks and boost application performance. By using ALTO 289 information, applications can reduce the reliance on obtaining 290 network information through third-party databases. Applications 291 relying on measuring path performance metrics themselves can reduce 292 the measurement overhead by conducting only fine-tuning or fault- 293 tolerant measurements on top of ALTO information. A specific example 294 application that can use ALTO information is peer-to-peer overlay 295 applications who can use ALTO information in peer selection. 297 2. Architecture 299 We start by introducing the terminology. Then we define the ALTO 300 architecture and the ALTO Protocol's place in the overall 301 architecture. 303 2.1. Terminology 305 We use the following terms defined in [RFC5693]: Application, Overlay 306 Network, Peer, Resource, Resource Identifier, Resource Provider, 307 Resource Consumer, Resource Directory, Transport Address, Host 308 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 309 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 310 Transit Traffic. 312 We also use the following additional terms: Endpoint Address, 313 Autonomous System Number (ASN), Network Location, ALTO Information, 314 and ALTO Information Base. 316 2.1.1. Endpoint 318 An Endpoint is an entity that is capable of communicating (sending 319 and/or receiving messages) on a network. 321 An Endpoint is typically either a Resource Provider or Resource 322 Consumer. 324 2.1.2. Endpoint Address 326 An Endpoint Address represents the communication address of an 327 endpoint. An Endpoint Address can be network-attachment based (IP 328 address) or network-attachment agnostic. Common forms of Endpoint 329 Addresses include IP address, MAC address, overlay ID, and phone 330 number. 332 Each Endpoint Address has an associated Address Type, which indicates 333 both its syntax and semantics. 335 2.1.3. ASN 337 An Autonomous System Number. 339 2.1.4. Network Location 341 Network Location is a generic term denoting a single Endpoint or a 342 group of Endpoints. For instance, it can be a single IPv4 or IPv6 343 address, an IPv4 or IPv6 prefix, or a set of prefixes. 345 2.1.5. ALTO Information 347 ALTO Information is a generic term referring to the network 348 information sent by an ALTO Server. 350 2.1.6. ALTO Information Base 352 Internal representation of the ALTO Information maintained by the 353 ALTO Server. Note that the structure of this internal representation 354 is not defined by this document. 356 2.2. ALTO Service and Protocol Scope 358 Each network region in the global Internet can provide its ALTO 359 Service, which conveys network information from the perspective of 360 that network region. A network region in this context can be an 361 Autonomous System (AS), an ISP, a region smaller than an AS or ISP, 362 or a set of ISPs. The specific network region that an ALTO Service 363 represents will depend on the ALTO deployment scenario and ALTO 364 service discovery mechanism. 366 Specifically, the ALTO Service of a network region defines network 367 Endpoints (and aggregations thereof) and generic costs amongst them 368 from the region's perspective. The network Endpoints may include all 369 Endpoints in the global Internet. Hence, we say that the network 370 information provided by the ALTO Service of a network region 371 represents the "my-Internet View" of the network region. 373 To better understand the ALTO Service and the role of the ALTO 374 Protocol, we show in Figure 1 the overall ALTO system architecture. 375 In this architecture, an ALTO Server prepares ALTO Information; an 376 ALTO Client uses ALTO Service Discovery to identify an appropriate 377 ALTO Server; and the ALTO Client requests available ALTO Information 378 from the ALTO Server using the ALTO Protocol. 380 The ALTO Information provided by the ALTO Server can be updated 381 dynamically based on network conditions, or can be seen as a policy 382 which is updated at a larger time-scale. 384 Figure 1 illustrates that the ALTO Information provided by an ALTO 385 Server may be influenced (at the operator's discretion) by other 386 systems. In particular, the ALTO Server can aggregate information 387 from multiple systems to provide an abstract, unified, useful network 388 view to applications. Examples of other systems include (but are not 389 limited to) static network configuration databases, dynamic network 390 information, routing protocols, provisioning policies, and interfaces 391 to outside parties. These components are shown in the figure for 392 completeness but are outside the scope of this specification. Recall 393 that while ALTO may convey dynamic network information, it is not 394 intended to replace near-real-time congestion control protocols. 396 It may also be possible for an ALTO Server to exchange network 397 information with other ALTO Servers (either within the same 398 administrative domain or another administrative domain with the 399 consent of both parties) in order to adjust exported ALTO 400 Information. Such a protocol is also outside the scope of this 401 specification. 403 +-------------------------------------------------------------------+ 404 | Network Region | 405 | | 406 | +-----------+ | 407 | | Routing | | 408 | +--------------+ | Protocols | | 409 | | Provisioning | +-----------+ | 410 | | Policy | | | 411 | +--------------+\ | | 412 | \ | | 413 | \ | | 414 | +-----------+ \+---------+ +--------+ | 415 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 416 | |Network |.......| Server | ==================== | Client | | 417 | |Information| +---------+ +--------+ | 418 | +-----------+ / / | 419 | / ALTO SD Query/Response / | 420 | / / | 421 | +----------+ +----------------+ | 422 | | External | | ALTO Service | | 423 | | Interface| | Discovery (SD) | | 424 | +----------+ +----------------+ | 425 | | | 426 +-------------------------------------------------------------------+ 427 | 428 +------------------+ 429 | Third Parties | 430 | | 431 | Content Providers| 432 +------------------+ 434 Figure 1: Basic ALTO Architecture. 436 2.3. ALTO Information Reuse and Redistribution 438 ALTO information may be useful to a large number of applications and 439 users. At the same time, distributing ALTO information must be 440 efficient and not become a bottleneck. 442 Beyond integration with existing HTTP caching infrastructure, ALTO 443 information may also be cached or redistributed using application- 444 dependent mechanisms, such as P2P DHTs or P2P file-sharing. This 445 document does not define particular mechanisms for such 446 redistribution. 448 Additional protocol mechanisms (e.g., expiration times and digital 449 signatures for returned ALTO information) are left for future 450 investigation. 452 If caching or redistribution is used, the response message may be 453 returned from another (possibly third-party) entity. 455 3. ALTO Information Service Framework 457 The ALTO Protocol conveys network information through services, where 458 each service defines a set of related functionalities. An ALTO 459 Client can query each service individually. All of the services 460 defined in ALTO are said to form the ALTO service framework and are 461 provided through a common transport protocol, messaging structure and 462 encoding, and transaction model. Functionalities offered in 463 different services can overlap. 465 In this document, we focus on achieving the goal of conveying Network 466 Locations, which denote the locations of Endpoints at a network, and 467 provider-defined costs for paths between pairs of Network Locations. 468 We achieve the goal by defining the Map Service, which provides the 469 core ALTO information to clients, and three additional services: the 470 Map Filtering Service, Endpoint Property Service, and Endpoint Cost 471 Service. Additional services can be defined in companion documents. 472 Below we give an overview of the services. Details of the services 473 will be presented in the following sections. 475 .-----------------------------------------. 476 | ALTO Information Services | 477 | .-----------. .----------. .----------. | 478 | | Map | | Endpoint | | Endpoint | | 479 | | Filtering | | Property | | Cost | | 480 | | Service | | Service | | Service | | 481 | `-----------' `----------' `----------' | 482 | .-------------------------------------. | 483 | | Map Service | | 484 | | .-------------. .--------------. | | 485 | | | Network Map | | Cost Map | | | 486 | | `-------------' `--------------' | | 487 | `-------------------------------------' | 488 `-----------------------------------------' 490 Figure 2: ALTO Service Framework. 492 3.1. ALTO Information Services 494 3.1.1. Map Service 496 The Map Service provides batch information to ALTO Clients in the 497 form of Network Map and Cost Map. The Network Map (See Section 4) 498 provides the full set of Network Location groupings defined by the 499 ALTO Server and the Endpoints contained with each grouping. The Cost 500 Map (see Section 5) provides costs between the defined groupings. 502 These two maps can be thought of (and implemented as) as simple files 503 with appropriate encoding provided by the ALTO Server. 505 3.1.2. Map Filtering Service 507 Resource constrained ALTO Clients may benefit from query results 508 being filtered at the ALTO Server. This avoids an ALTO Client 509 spending network bandwidth or CPU collecting results and performing 510 client-side filtering. The Map Filtering Service allows ALTO Clients 511 to query for the ALTO Server Network Map and Cost Map based on 512 additional parameters. 514 3.1.3. Endpoint Property Service 516 This service allows ALTO Clients to look up properties for individual 517 Endpoints. An example endpoint property is its Network Location 518 (i.e., its grouping defined by the ALTO Server). Another endpoint 519 property is its connectivity type such as ADSL (Asymmetric Digital 520 Subscriber Line), Cable, or FTTH (Fiber To The Home). 522 3.1.4. Endpoint Cost Service 524 Some ALTO Clients may also benefit from querying for costs and 525 rankings based on Endpoints. The Endpoint Cost Service allows an 526 ALTO Server to return either numerical costs or ordinal costs 527 (rankings) directly amongst Endpoints. 529 4. Network Map 531 An ALTO Network Map defines a grouping of network endpoints. In this 532 document, we use Network Map to refer to the syntax and semantics of 533 the information distributed by the ALTO Server. This document does 534 not discuss the internal representation of this data structure within 535 the ALTO Server. 537 The definition of Network Map is based on the observation that in 538 reality, many endpoints are close by to one another in terms of 539 network connectivity. By treating a group of close-by endpoints 540 together as a single entity, an ALTO Server indicates aggregation of 541 these endpoints due to their proximity. This aggregation can also 542 lead to greater scalability without losing critical information when 543 conveying other network information (e.g., when defining Cost Map). 545 4.1. Provider-defined Identifier (PID) 547 One issue is that proximity varies depending on the granularity of 548 the ALTO information configured by the provider. In one deployment, 549 endpoints on the same subnet may be considered close; while in 550 another deployment, endpoints connected to the same Point of Presence 551 (PoP) may be considered close. 553 ALTO introduces provider-defined Network Location identifiers called 554 Provider-defined Identifiers (PIDs) to provide an indirect and 555 network-agnostic way to specify an aggregation of network endpoints 556 that may be treated similarly, based on network topology, type, or 557 other properties. Specifically, a PID is a US-ASCII string of type 558 PIDName (see Section 8.1) and its associated set of Endpoint 559 Addresses. As we discussed above, there can be many different ways 560 of grouping the endpoints and assigning PIDs. For example, a PID may 561 denote a subnet, a set of subnets, a metropolitan area, a PoP, an 562 autonomous system, or a set of autonomous systems. 564 A key use case of PIDs is to specify network preferences (costs) 565 between PIDs instead of individual endpoints. This allows cost 566 information to be more compactly represented and updated at a faster 567 time scale than the network aggregations themselves. For example, an 568 ISP may prefer that endpoints associated with the same PoP (Point-of- 569 Presence) in a P2P application communicate locally instead of 570 communicating with endpoints in other PoPs. The ISP may aggregate 571 endhosts within a PoP into a single PID in the Network Map. The cost 572 may be encoded to indicate that Network Locations within the same PID 573 are preferred; for example, cost(PID_i, PID_i) == c* and cost(PID_i, 574 PID_j) > c* for i != j. Section 5 provides further details on using 575 PIDs to represent costs in an ALTO Cost Map. 577 4.2. Endpoint Addresses 579 The endpoints aggregated into a PID are denoted by endpoint 580 addresses. There are many types of addresses, such as IP addresses, 581 MAC addresses, or overlay IDs. The current specification only 582 considers IP addresses. 584 4.2.1. IP Addresses 586 When either an ALTO Client or ALTO Server needs to determine which 587 PID in a Network Map contains a particular IP address, longest-prefix 588 matching MUST be used. 590 A Network Map MUST define a PID for each possible address in the IP 591 address space for all of the address types contained in the map. A 592 RECOMMENDED way to satisfy this property is to define a PID with the 593 shortest enclosing prefix of the addresses provided in the map. For 594 a map with full IPv4 reachability, this would mean including the 595 0.0.0.0/0 prefix in a PID; for full IPv6 reachability, this would be 596 the ::/0 prefix. 598 Each endpoint MUST map into exactly one PID. Since longest-prefix 599 matching is used to map an endpoint to a PID, this can be 600 accomplished by ensuring that no two PIDs contain an identical IP 601 prefix. 603 4.3. Example Network Map 605 Figure 3 illustrates an example Network Map. PIDs are used to 606 identify network-agnostic aggregations. 608 .-----------------------------------------------------------. 609 | ALTO Network Map | 610 | | 611 | .-----------------------------------. .---------------. | 612 | | NetLoc: PID-1 | | NetLoc: PID-2 | | 613 | | .------------------------------. | | ... | | 614 | | | 192.0.2.0/24 | | `---------------` | 615 | | | .--------------------------. | | | 616 | | | | Endpoint: 192.0.2.34 | | | .---------------. | 617 | | | `--------------------------` | | | NetLoc: PID-3 | | 618 | | `------------------------------` | | ... | | 619 | | .------------------------------. | `---------------` | 620 | | | 198.51.100.0/25 | | | 621 | | | .--------------------------. | | .---------------. | 622 | | | | Endpoint: 198.51.100.100 | | | | NetLoc: PID-4 | | 623 | | | `--------------------------` | | | ... | | 624 | | `------------------------------` | `---------------` | 625 | `-----------------------------------` | 626 | | 627 `-----------------------------------------------------------` 629 Figure 3: Example Network Map. 631 5. Cost Map 633 An ALTO Server indicates preferences amongst network locations in the 634 form of Path Costs. Path Costs are generic costs and can be 635 internally computed by a network provider according to its own needs. 637 An ALTO Cost Map defines Path Costs pairwise amongst sets of source 638 and destination Network Locations defined by PIDs. Each Path Cost is 639 the end-to-end cost from the source to the destination. 641 As cost directional from the source to the destination, an 642 application, when using ALTO, may independently determine how the 643 Resource Consumer and Resource Provider are designated as the source 644 or destination, and hence how to utilize the Path Cost provided by 645 ALTO. For example, if the cost is expected to be correlated with 646 throughput, a typical application concerned with bulk data retrieval 647 may use the Resource Provider as the source, and Resource Consumer as 648 the destination. 650 One advantage of separating ALTO information into a Network Map and a 651 Cost Map is that the two components can be updated at different time 652 scales. For example, Network Maps may be stable for a longer time 653 while Cost Maps may be updated to reflect dynamic network conditions. 655 As used in this document, the Cost Map refers to the syntax and 656 semantics of the information distributed by the ALTO Server. This 657 document does not discuss the internal representation of this data 658 structure within the ALTO Server. 660 5.1. Cost Attributes 662 Path Costs have attributes: 664 o Type: identifies what the costs represent; 666 o Mode: identifies how the costs should be interpreted. 668 Certain queries for Cost Maps allow the ALTO Client to indicate the 669 desired Type and Mode. 671 5.1.1. Cost Type 673 The Type attribute indicates what the cost represents. For example, 674 an ALTO Server could define costs representing air-miles, hop-counts, 675 or generic routing costs. 677 Cost types are indicated in protocol messages as strings. 679 5.1.1.1. Cost Type: routingcost 681 An ALTO Server MUST define the 'routingcost' Cost Type. 683 This Cost Type conveys a generic measure for the cost of routing 684 traffic from a source to a destination. Lower values indicate a 685 higher preference for traffic to be sent from a source to a 686 destination. 688 Note that an ISP may internally compute routing cost using any method 689 it chooses (e.g., air-miles or hop-count) as long as it conforms to 690 these semantics. 692 5.1.2. Cost Mode 694 The Mode attribute indicates how costs should be interpreted. 695 Specifically, the Mode attribute indicates whether returned costs 696 should be interpreted as numerical values or ordinal rankings. 698 It is important to communicate such information to ALTO Clients, as 699 certain operations may not be valid on certain costs returned by an 700 ALTO Server. For example, it is possible for an ALTO Server to 701 return a set of IP addresses with costs indicating a ranking of the 702 IP addresses. Arithmetic operations that would make sense for 703 numerical values, do not make sense for ordinal rankings. ALTO 704 Clients may handle such costs differently. 706 Cost Modes are indicated in protocol messages as strings. 708 An ALTO Server MUST support at least one of 'numerical' and 'ordinal' 709 costs. An ALTO Client SHOULD be cognizant of operations when a 710 desired cost mode is not supported. For example, an ALTO Client 711 desiring numerical costs may adjust behavior if only the ordinal Cost 712 Mode is available. Alternatively, an ALTO Client desiring ordinal 713 costs may construct ordinal costs given numerical values if only the 714 numerical Cost Mode is available. 716 5.1.2.1. Cost Mode: numerical 718 This Cost Mode is indicated by the string 'numerical'. This mode 719 indicates that it is safe to perform numerical operations (e.g. 720 normalization or computing ratios for weighted load-balancing) on the 721 returned costs. The values are floating-point numbers. 723 5.1.2.2. Cost Mode: ordinal 725 This Cost Mode is indicated by the string 'ordinal'. This mode 726 indicates that the costs values in a Cost Map are a ranking (relative 727 to all other values in the Cost Map), with lower values indicating a 728 higher preference. The values are non-negative integers. Ordinal 729 cost values in a Cost Map need not be unique nor contiguous. In 730 particular, it is possible that two entries in a map have an 731 identical rank (ordinal cost value). This document does not specify 732 any behavior by an ALTO Client in this case; an ALTO Client may 733 decide to break ties by random selection, other application 734 knowledge, or some other means. 736 It is important to note that the values in the Cost Map provided with 737 the ordinal Cost Mode are not necessarily the actual cost known to 738 the ALTO Server. 740 5.2. Cost Map Structure 742 A query for a Cost Map either explicitly or implicitly includes a 743 list of Source Network Locations and a list of Destination Network 744 Locations. (Recall that a Network Location can be an endpoint 745 address or a PID.) 747 Specifically, assume that a query has a list of multiple Source 748 Network Locations, say [Src_1, Src_2, ..., Src_m], and a list of 749 multiple Destination Network Locations, say [Dst_1, Dst_2, ..., 750 Dst_n]. 752 The ALTO Server will return the Path Cost for each of the m*n 753 communicating pairs (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., 754 Src_m -> Dst_1, ..., Src_m -> Dst_n). If the ALTO Server does not 755 define a Path Cost for a particular pair, it may be omitted. We 756 refer to this structure as a Cost Map. 758 If the Cost Mode is 'ordinal', the Path Cost of each communicating 759 pair is relative to the m*n entries. 761 5.3. Network Map and Cost Map Dependency 763 If a Cost Map contains PIDs in the list of Source Network Locations 764 or the list of Destination Network Locations, the Path Costs are 765 generated based on a particular Network Map (which defines the PIDs). 766 Version Tags are introduced to ensure that ALTO Clients are able to 767 use consistent information even though the information is provided in 768 two maps. 770 A Version Tag is an opaque string associated with a Network Map 771 maintained by the ALTO Server. Two Version Tags match only if their 772 strings are the same. Whenever the content of the Network Map 773 maintained by the ALTO Server changes, the Version Tag MUST also be 774 changed. Possibilities for generating a Version Tag include the 775 last-modified timestamp for the Network Map, or a hash of its 776 contents, where the collision probability is considered zero in 777 practical deployment scenarios. 779 A Network Map distributed by the ALTO Server includes its Version 780 Tag. A Cost Map referring to PIDs also includes the Version Tag of 781 the Network Map on which it is based. 783 6. Endpoint Properties 785 An endpoint property defines a network-aware property of an endpoint. 787 6.1. Endpoint Property Type 789 For each endpoint and an endpoint property type, there can be a value 790 for the property. The type of an Endpoint property is indicated in 791 protocol messages as a string. The value depends on the specific 792 property. For example, for a property such as whether an endpoint is 793 metered, the value is a true or false value. 795 6.1.1. Endpoint Property Type: pid 797 An ALTO Server MUST define the 'pid' Endpoint Property Type, which 798 provides the PID of an endpoint. Since the PID of an endpoint 799 depends on the Network Map, Version Tag of the Network Map used to 800 return the pid property MUST be included. 802 7. Protocol Specification: General Processing 804 This section first specifies general client and server processing. 805 The details of specific services will be covered in the following 806 sections. 808 7.1. Overall Design 810 The ALTO Protocol uses a REST-ful design. There are two primary 811 components to this design: 813 o Information Resources: Each service provides network information 814 as a set of resources, which are distinguished by their media 815 types [RFC2046]. An ALTO Client may construct an HTTP request for 816 a particular resource (including any parameters, if necessary), 817 and an ALTO Server returns the requested resource in an HTTP 818 response. 820 o Information Resource Directory: An ALTO Server provides to ALTO 821 Clients a list of available resources and the URI at which each is 822 provided. This document refers to this list as the Information 823 Resource Directory. This directory is the single entry point to 824 an ALTO Service. ALTO Clients consult the directory to determine 825 the services provided by an ALTO Server. 827 7.2. Notation 829 This document uses an adaptation of the C-style struct notation to 830 define the required and optional members of JSON objects. Unless 831 explicitly noted, each member of a struct is REQUIRED. 833 The types 'JSONString', 'JSONNumber', 'JSONBool' indicate the JSON 834 string, number, and boolean types, respectively. 'JSONValue' 835 indicates a JSON value, as specified in Section 2.1 of [RFC4627]. 837 Note that no standard, machine-readable interface definition or 838 schema is provided. Extension documents may document these as 839 necessary. 841 7.3. Basic Operation 843 The ALTO Protocol employs standard HTTP [RFC2616]. It is used for 844 discovering available Information Resources at an ALTO Server and 845 retrieving Information Resources. ALTO Clients and ALTO Servers use 846 HTTP requests and responses carrying ALTO-specific content with 847 encoding as specified in this document, and MUST be compliant with 848 [RFC2616]. 850 7.3.1. Discovering Information Resources 852 To discover available resources, an ALTO Client requests the 853 Information Resource Directory, which an ALTO Server provides at the 854 URI found by the ALTO Discovery protocol. 856 Informally, an Information Resource Directory enumerates URIs at 857 which an ALTO Server offers Information Resources. Each entry in the 858 directory indicates a URI at which an ALTO Server accepts requests, 859 and returns either the requested Information Resource or an 860 Information Resource Directory that references additional Information 861 Resources. See Section 7.6 for a detailed specification. 863 7.3.2. Requesting Information Resources 865 Through the retrieved Information Resource Directories, an ALTO 866 Client can determine whether an ALTO Server supports the desired 867 Information Resource, and if it is supported, the URI at which it is 868 available. 870 Where possible, the ALTO Protocol uses the HTTP GET method to request 871 resources. However, some ALTO services provide Information Resources 872 that are the function of one or more input parameters. Input 873 parameters are encoded in the HTTP request's entity body, and the 874 ALTO Client MUST use the HTTP POST method. 876 When requesting an ALTO Information Resource that requires input 877 parameters specified in a HTTP POST request, an ALTO Client MUST set 878 the Content-Type HTTP header to the media type corresponding to the 879 format of the supplied input parameters. 881 It is possible for an ALTO Server to leverage caching HTTP 882 intermediaries for responses to both GET and POST requests by 883 including explicit freshness information (see Section 14 of 884 [RFC2616]). Caching of POST requests is not widely implemented by 885 HTTP intermediaries, however an alternative approach is for an ALTO 886 Server, in response to POST requests, to return an HTTP 303 status 887 code ("See Other") indicating to the ALTO Client that the resulting 888 Information Resource is available via a GET request to an alternate 889 URL. HTTP intermediaries that do not support caching of POST 890 requests could then cache the response to the GET request from the 891 ALTO Client following the alternate URL in the 303 response if the 892 response to the subsequent GET request contains explicit freshness 893 information. 895 7.3.3. Response 897 Upon receiving a request, an ALTO server either returns the requested 898 resource, provides the ALTO Client an Information Resource Directory 899 indicating how to reach the desired resource, or returns an error. 901 The type of response MUST be indicated by the media type attached to 902 the response (the Content-Type HTTP header). If an ALTO Client 903 receives an Information Resource Directory, it can consult the 904 received directory to determine if any of the offered URIs contain 905 the desired Information Resource. 907 The generic encoding for an Information Resource is specified in 908 Section 7.4. 910 Errors are indicated via either ALTO-level error codes, or via HTTP 911 status codes; see Section 7.7. 913 7.3.4. Client Behavior 915 7.3.4.1. Using Information Resources 917 This specification does not indicate any required actions taken by 918 ALTO Clients upon successfully receiving an Information Resource from 919 an ALTO Server. Although ALTO Clients are suggested to interpret the 920 received ALTO Information and adapt application behavior, ALTO 921 Clients are not required to do so. 923 7.3.4.2. Error Conditions 925 If an ALTO Client does not successfully receive a desired Information 926 Resource from a particular ALTO Server, it can either choose another 927 server (if one is available) or fall back to a default behavior 928 (e.g., perform peer selection without the use of ALTO information, 929 when used in a peer-to-peer system). An ALTO Client may also retry 930 the request at a later time. 932 7.3.5. Authentication and Encryption 934 An ALTO Server MUST support SSL/TLS [RFC5246] to implement server 935 and/or client authentication, encryption, and/or integrity 936 protection. See [RFC6125] for considerations regarding verification 937 of server identity. 939 7.3.6. HTTP Cookies 941 If cookies are included in an HTTP request received by an ALTO 942 Server, they MUST be ignored. 944 7.3.7. Parsing 946 This document only details object members used by this specification. 947 Extensions may include additional members within JSON objects defined 948 in this document. ALTO implementations MUST ignore such unknown 949 fields when processing ALTO messages. 951 7.4. Information Resource Attributes 953 An Information Resource encodes the ALTO Information desired by an 954 ALTO Client. This document specifies multiple Information Resources 955 that can be provided by an ALTO Server. Each Information Resource 956 has certain attributes associated with it, including its 957 capabilities, the accepted input parameters, and output data format. 959 7.4.1. Capability Advertisement 961 An ALTO Server may advertise to an ALTO Client that it supports 962 certain capabilities in requests for an Information Resource. For 963 example, if an ALTO Server allows requests for a Cost Map to include 964 constraints, it may advertise that it supports this capability. 966 7.4.2. Accept Input Parameters 968 An ALTO Server may allow an ALTO Client to supply input parameters 969 when requesting certain Information Resources. The format of the 970 input parameters (i.e., as contained in the entity body of the HTTP 971 POST request) is indicated by the media type [RFC2046]. 973 7.4.3. Media Type 975 An ALTO Server uses Media Type [RFC2046] to uniquely indicate the 976 data format of the Information Resource that it returns in the HTTP 977 entity body. 979 7.5. Information Resource Media Type Encoding 981 Though each Information Resource may have a distinct syntax, they are 982 designed to have a common structure containing generic ALTO-layer 983 metadata about the resource, as well as data itself. 985 Specifically, each Information Resource has a single top-level JSON 986 object of type InfoResourceEntity: 988 object { 989 InfoResourceMetaData meta; [OPTIONAL] 990 [InfoResourceDataType] data; 991 } InfoResourceEntity; 993 with members: 995 meta meta-information pertaining to the Information Resource 997 data the data contained in the Information Resource 999 7.5.1. Meta Information 1001 Meta information is encoded as a JSON object. This document does not 1002 specify any members, but it is defined here as a standard container 1003 for extensibility. Specifically, InfoResourceMetaData is defined as: 1005 object { 1006 } InfoResourceMetaData; 1008 7.5.2. ALTO Information 1010 The "data" member of the InfoResourceEntity encodes the resource- 1011 specific data; the structure of this member is detailed later for 1012 each particular Information Resource. 1014 7.5.3. Example 1016 The following is an example of the encoding for an Information 1017 Resource: 1019 HTTP/1.1 200 OK 1020 Content-Length: 40 1021 Content-Type: application/alto-costmap+json 1023 { 1024 "meta" : {}, 1025 "data" : { 1026 ... 1027 } 1028 } 1030 7.6. Information Resource Directory 1032 An Information Resource Directory indicates to ALTO Clients which 1033 Information Resources are made available by an ALTO Server. 1035 Since resource selection happens after consumption of the Information 1036 Resource Directory, the format of the Information Resource Directory 1037 is designed to be simple with the intention of future ALTO Protocol 1038 versions maintaining backwards compatibility. Future extensions or 1039 versions of the ALTO Protocol SHOULD be accomplished by extending 1040 existing media types or adding new media types, but retaining the 1041 same format for the Information Resource Directory. 1043 An ALTO Server MUST make an Information Resource Directory available 1044 via the HTTP GET method to a URI discoverable by an ALTO Client. 1045 Discovery of this URI is out of scope of this document, but could be 1046 accomplished by manual configuration or by returning the URI of an 1047 Information Resource Directory from the ALTO Discovery Protocol 1048 [I-D.ietf-alto-server-discovery]. For recommendations on how the URI 1049 may look like, see [I-D.ietf-alto-server-discovery]. 1051 7.6.1. Media Type 1053 The media type is "application/alto-directory+json". 1055 7.6.2. Encoding 1057 An Information Resource Directory is a JSON object of type 1058 InfoResourceDirectory: 1060 object { 1061 ... 1062 } Capabilities; 1064 object { 1065 JSONString uri; 1066 JSONString media-types<1..*>; 1067 JSONString accepts<0..*>; [OPTIONAL] 1068 Capabilities capabilities; [OPTIONAL] 1069 } ResourceEntry; 1071 object { 1072 ResourceEntry resources<0..*>; 1073 } InfoResourceDirectory; 1075 where the "resources" array indicates a list of Information Resources 1076 provided by an ALTO Server. Note that the list of available 1077 resources is enclosed in a JSON object for extensibility; future 1078 protocol versions may specify additional members in the 1079 InfoResourceDirectory object. 1081 Any URI endpoint indicated in an Information Resource Directory MAY 1082 provide a response to an OPTIONS request that is in the format of an 1083 Information Resource Directory response. This provides ALTO Clients 1084 a means to discover resources and capabilities offered by that URI 1085 endpoint. ALTO Servers that reply with an HTTP 300 status code 1086 ("Multiple Choices") SHOULD use the Information Resource Directory 1087 format in the reply. 1089 Each entry in the directory specifies: 1091 uri A URI at which the ALTO Server provides one or more Information 1092 Resources, or an Information Resource Directory indicating 1093 additional Information Resources. URIs can be relative and MUST 1094 be resolved according to section 5 of [RFC3986]. 1096 media-types The list of all media types of Information Resources 1097 (see Section 7.4.3) available via GET or POST requests to the 1098 corresponding URI or URIs discoverable via the URI. 1100 accepts The list of all media types of input parameters (see 1101 Section 7.4.2) accepted by POST requests to the corresponding URI 1102 or URIs discoverable via the URI. If this member is not present, 1103 it MUST be assumed to be an empty array. 1105 capabilities A JSON Object enumerating capabilities of an ALTO 1106 Server in providing the Information Resource at the corresponding 1107 URI and Information Resources discoverable via the URI. If this 1108 member is not present, it MUST be assumed to be an empty object. 1109 If a capability for one of the offered Information Resources is 1110 not explicitly listed here, an ALTO Client may either issue an 1111 OPTIONS HTTP request to the corresponding URI to determine if the 1112 capability is supported, or assume its default value documented in 1113 this specification or an extension document describing the 1114 capability. 1116 If an entry has an empty list for "accepts", then the corresponding 1117 URI MUST support GET requests. If an entry has a non-empty list for 1118 "accepts", then the corresponding URI MUST support POST requests. If 1119 an ALTO Server wishes to support both GET and POST on a single URI, 1120 it MUST specify two entries in the Information Resource Directory. 1122 7.6.3. Example 1124 The following is an example Information Resource Directory returned 1125 by an ALTO Server. In this example, the ALTO Server provides 1126 additional Network and Cost Maps via a separate subdomain, 1127 "custom.alto.example.com". The maps available via this subdomain are 1128 Filtered Network and Cost Maps as well as pre-generated maps for the 1129 "hopcount" and "routingcost" Cost Types in the "ordinal" Cost Mode. 1131 An ALTO Client can discover the maps available by 1132 "custom.alto.example.com" by successfully performing an OPTIONS 1133 request to "http://custom.alto.example.com/maps". 1135 In this example, the ALTO server provides the Endpoint Cost Service 1136 for Cost Types 'routingcost' and 'hopcount', each available for both 1137 'numerical' and 'ordinal' mode". 1139 GET /directory HTTP/1.1 1140 Host: alto.example.com 1141 Accept: application/alto-directory+json,application/alto-error+json 1142 HTTP/1.1 200 OK 1143 Content-Length: 1472 1144 Content-Type: application/alto-directory+json 1146 { 1147 "resources" : [ 1148 { 1149 "uri" : "http://alto.example.com/networkmap", 1150 "media-types" : [ "application/alto-networkmap+json" ] 1151 }, { 1152 "uri" : "http://alto.example.com/costmap/num/routingcost", 1153 "media-types" : [ "application/alto-costmap+json" ], 1154 "capabilities" : { 1155 "cost-modes" : [ "numerical" ], 1156 "cost-types" : [ "routingcost" ] 1157 } 1158 }, { 1159 "uri" : "http://alto.example.com/costmap/num/hopcount", 1160 "media-types" : [ "application/alto-costmap+json" ], 1161 "capabilities" : { 1162 "cost-modes" : [ "numerical" ], 1163 "cost-types" : [ "hopcount" ] 1164 } 1165 }, { 1166 "uri" : "http://custom.alto.example.com/maps", 1167 "media-types" : [ 1168 "application/alto-networkmap+json", 1169 "application/alto-costmap+json" 1170 ], 1171 "accepts" : [ 1172 "application/alto-networkmapfilter+json", 1173 "application/alto-costmapfilter+json" 1174 ] 1175 }, { 1176 "uri" : "http://alto.example.com/endpointprop/lookup", 1177 "media-types" : [ "application/alto-endpointprop+json" ], 1178 "accepts" : [ "application/alto-endpointpropparams+json" ], 1179 "capabilities" : { 1180 "prop-types" : [ "pid" ] 1181 } 1182 }, { 1183 "uri" : "http://alto.example.com/endpointcost/lookup", 1184 "media-types" : [ "application/alto-endpointcost+json" ], 1185 "accepts" : [ "application/alto-endpointcostparams+json" ], 1186 "capabilities" : { 1187 "cost-constraints" : true, 1188 "cost-modes" : [ "ordinal", "numerical" ], 1189 "cost-types" : [ "routingcost", "hopcount" ] 1191 } 1192 } 1193 ] 1194 } 1196 OPTIONS /maps HTTP/1.1 1197 Host: custom.alto.example.com 1198 Accept: application/alto-directory+json,application/alto-error+json 1199 HTTP/1.1 200 OK 1200 Content-Length: 1001 1201 Content-Type: application/alto-directory+json 1203 { 1204 "resources" : [ 1205 { 1206 "uri" : "http://custom.alto.example.com/networkmap/filtered", 1207 "media-types" : [ "application/alto-networkmap+json" ], 1208 "accepts" : [ "application/alto-networkmapfilter+json" ] 1209 }, { 1210 "uri" : "http://custom.alto.example.com/costmap/filtered", 1211 "media-types" : [ "application/alto-costmap+json" ], 1212 "accepts" : [ "application/alto-costmapfilter+json" ], 1213 "capabilities" : { 1214 "cost-constraints" : true, 1215 "cost-modes" : [ "ordinal", "numerical" ], 1216 "cost-types" : [ "routingcost", "hopcount" ] 1217 } 1218 }, { 1219 "uri" : "http://custom.alto.example.com/ord/routingcost", 1220 "media-types" : [ "application/alto-costmap+json" ], 1221 "capabilities" : { 1222 "cost-modes" : [ "ordinal" ], 1223 "cost-types" : [ "routingcost" ] 1224 } 1225 }, { 1226 "uri" : "http://custom.alto.example.com/ord/hopcount", 1227 "media-types" : [ "application/alto-costmap+json" ], 1228 "capabilities" : { 1229 "cost-modes" : [ "ordinal" ], 1230 "cost-types" : [ "hopcount" ] 1231 } 1232 } 1233 ] 1234 } 1236 7.6.4. Usage Considerations 1238 7.6.4.1. ALTO Client 1240 This document specifies no requirements or constraints on ALTO 1241 Clients with regards to how they process an Information Resource 1242 Directory to identify the URI corresponding to a desired Information 1243 Resource. However, some advice is provided for implementors. 1245 It is possible that multiple entries in the directory match a desired 1246 Information Resource. For instance, in the example in Section 7.6.3, 1247 a full Cost Map with "numerical" Cost Mode and "routingcost" Cost 1248 Type could be retrieved via a GET request to 1249 "http://alto.example.com/costmap/num/routingcost", or via a POST 1250 request to "http://custom.alto.example.com/costmap/filtered". 1252 In general, it is preferred for ALTO Clients to use GET requests 1253 where appropriate, since it is more likely for responses to be 1254 cacheable. 1256 7.6.4.2. ALTO Server 1258 This document indicates that an ALTO Server may or may not provide 1259 the Information Resources specified in the Map Filtering Service. If 1260 these resources are not provided, it is indicated to an ALTO Client 1261 by the absence of a Network Map or Cost Map with any media types 1262 listed under "accepts". 1264 7.7. Protocol Errors 1266 If there is an error processing a request, an ALTO Server SHOULD 1267 return additional ALTO-layer information, if it is available, in the 1268 form of an ALTO Error Resource encoded in the HTTP response's entity 1269 body. 1271 If no ALTO-layer information is available, an ALTO Server may omit an 1272 ALTO Error resource from the response. An appropriate HTTP status 1273 code MUST be set. 1275 It is important to note that the HTTP Status Code and ALTO Error Code 1276 have distinct roles. An ALTO Error Code provides detailed 1277 information about why a particular request for an ALTO Resource was 1278 not successful. The HTTP status code indicates to HTTP processing 1279 elements (e.g., intermediaries and clients) how the response should 1280 be treated. 1282 An ALTO Client MUST interpret both HTTP Status Code and ALTO Error 1283 Code. If the ALTO Error Code indicates an error, the ALTO Client 1284 should consider that the request has failed. 1286 7.7.1. Media Type 1288 The media type for an ALTO Error Resource is "application/ 1289 alto-error+json". 1291 7.7.2. Resource Format 1293 An ALTO Error Resource has the format: 1295 object { 1296 JSONString code; 1297 } ErrorResourceEntity; 1299 where: 1301 code An ALTO Error Code defined in Table 1 1303 7.7.3. Error Codes 1305 This document defines ALTO Error Codes to support the error 1306 conditions needed for purposes of this document. Additional status 1307 codes may be defined in companion or extension documents. 1309 The HTTP status codes corresponding to each ALTO Error Code are 1310 defined to provide correct behavior with HTTP intermediaries and 1311 clients. When an ALTO Server returns a particular ALTO Error Code, 1312 it MUST indicate one of the corresponding HTTP status codes in 1313 Table 1 in the HTTP response. 1315 +-------------------------+-------------+---------------------------+ 1316 | ALTO Error Code | HTTP Status | Description | 1317 | | Code(s) | | 1318 +-------------------------+-------------+---------------------------+ 1319 | E_SYNTAX | 400 | Parsing error in request | 1320 | | | (including identifiers) | 1321 | E_JSON_FIELD_MISSING | 400 | Required field missing | 1322 | E_JSON_VALUE_TYPE | 400 | JSON Value of unexpected | 1323 | | | type | 1324 | E_INVALID_COST_MODE | 400 | Invalid cost mode | 1325 | E_INVALID_COST_TYPE | 400 | Invalid cost type | 1326 | E_INVALID_PROPERTY_TYPE | 400 | Invalid property type | 1327 +-------------------------+-------------+---------------------------+ 1329 Table 1: Defined ALTO Error Codes 1331 If multiple errors are present in a single request (e.g., a request 1332 uses a JSONString when a JSONInteger is expected and a required field 1333 is missing), then the ALTO Server MUST return exactly one of the 1334 detected errors. However, the reported error is implementation 1335 defined, since specifying a particular order for message processing 1336 encroaches needlessly on implementation technique. 1338 7.7.4. Overload Conditions and Server Unavailability 1340 If an ALTO Server detects that it cannot handle a request from an 1341 ALTO Client due to excessive load, technical problems, or system 1342 maintenance, it SHOULD do one of the following: 1344 o Return an HTTP 503 ("Service Unavailable") status code to the ALTO 1345 Client. As indicated by [RFC2616], a the Retry-After HTTP header 1346 may be used to indicate when the ALTO Client should retry the 1347 request. 1349 o Return an HTTP 307 ("Temporary Redirect") status code indicating 1350 an alternate ALTO Server that may be able to satisfy the request. 1352 The ALTO Server MAY also terminate the connection with the ALTO 1353 Client. 1355 The particular policy applied by an ALTO Server to determine that it 1356 cannot service a request is outside of the scope of this document. 1358 8. Protocol Specification: Basic ALTO Data Types 1360 This section details the format for particular data values used in 1361 the ALTO Protocol. 1363 8.1. PID Name 1365 A PID Name is encoded as a US-ASCII string. The string MUST be no 1366 more than 64 characters, and MUST NOT contain any ASCII character 1367 below 0x21 or above 0x7E or the '.' separator (0x2E). The '.' 1368 separator is reserved for future use and MUST NOT be used unless 1369 specifically indicated by a companion or extension document. 1371 The type 'PIDName' is used in this document to indicate a string of 1372 this format. 1374 8.2. Version Tag 1376 A Version Tag is encoded as a US-ASCII string. The string MUST be no 1377 more than 64 characters, and MUST NOT contain any ASCII character 1378 below 0x21 or above 0x7E. 1380 The type 'VersionTag' is used in this document to indicate a string 1381 of this type. 1383 8.3. Endpoints 1385 This section defines formats used to encode addresses for Endpoints. 1386 In a case that multiple textual representations encode the same 1387 Endpoint address or prefix (within the guidelines outlined in this 1388 document), the ALTO Protocol does not require ALTO Clients or ALTO 1389 Servers to use a particular textual representation, nor does it 1390 require that ALTO Servers reply to requests using the same textual 1391 representation used by requesting ALTO Clients. ALTO Clients must be 1392 cognizant of this. 1394 8.3.1. Address Type 1396 Address Types are encoded as US-ASCII strings consisting of only 1397 alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, and 0x61- 1398 0x7A). This document defines the address type 'ipv4' to refer to 1399 IPv4 addresses, and 'ipv6' to refer to IPv6 addresses. All Address 1400 Type identifiers appearing in an HTTP request or response with an 1401 'application/alto-*' media type MUST be registered in the ALTO 1402 Address Type registry Section 12.4. 1404 The type 'AddressType' is used in this document to indicate a string 1405 of this format. 1407 8.3.2. Endpoint Address 1409 Endpoint Addresses are encoded as US-ASCII strings. The exact 1410 characters and format depend on the type of endpoint address. 1412 The type 'EndpointAddr' is used in this document to indicate a string 1413 of this format. 1415 8.3.2.1. IPv4 1417 IPv4 Endpoint Addresses are encoded as specified by the 'IPv4address' 1418 rule in Section 3.2.2 of [RFC3986]. 1420 8.3.2.2. IPv6 1422 IPv6 Endpoint Addresses are encoded as specified in Section 4 of 1423 [RFC5952]. 1425 8.3.2.3. Typed Endpoint Addresses 1427 When an Endpoint Address is used, an ALTO implementation must be able 1428 to determine its type. For this purpose, the ALTO Protocol allows 1429 endpoint addresses to also explicitly indicate their type. 1431 Typed Endpoint Addresses are encoded as US-ASCII strings of the 1432 format 'AddressType:EndpointAddr' (with the ':' character as a 1433 separator). The type 'TypedEndpointAddr' is used to indicate a 1434 string of this format. 1436 8.3.3. Endpoint Prefixes 1438 For efficiency, it is useful to denote a set of Endpoint Addresses 1439 using a special notation (if one exists). This specification makes 1440 use of the prefix notations for both IPv4 and IPv6 for this purpose. 1442 Endpoint Prefixes are encoded as US-ASCII strings. The exact 1443 characters and format depend on the type of endpoint address. 1445 The type 'EndpointPrefix' is used in this document to indicate a 1446 string of this format. 1448 8.3.3.1. IPv4 1450 IPv4 Endpoint Prefixes are encoded as specified in Section 3.1 of 1451 [RFC4632]. 1453 8.3.3.2. IPv6 1455 IPv6 Endpoint Prefixes are encoded as specified in Section 7 of 1456 [RFC5952]. 1458 8.3.4. Endpoint Address Group 1460 The ALTO Protocol includes messages that specify potentially large 1461 sets of endpoint addresses. Endpoint Address Groups provide a more 1462 efficient way to encode such sets, even when the set contains 1463 endpoint addresses of different types. 1465 An Endpoint Address Group is defined as: 1467 object { 1468 EndpointPrefix [AddressType]<0..*>; 1469 ... 1470 } EndpointAddrGroup; 1472 In particular, an Endpoint Address Group is a JSON object with the 1473 name of each member being the string corresponding to the address 1474 type, and the member's corresponding value being a list of prefixes 1475 of addresses of that type. 1477 The following is an example with both IPv4 and IPv6 endpoint 1478 addresses: 1480 { 1481 "ipv4": [ 1482 "192.0.2.0/24", 1483 "198.51.100.0/25" 1484 ], 1485 "ipv6": [ 1486 "2001:db8:0:1::/64", 1487 "2001:db8:0:2::/64" 1488 ] 1489 } 1491 8.4. Cost Mode 1493 A Cost Mode is encoded as a US-ASCII string. The string MUST either 1494 have the value 'numerical' or 'ordinal'. 1496 The type 'CostMode' is used in this document to indicate a string of 1497 this format. 1499 8.5. Cost Type 1501 A Cost Type is encoded as a US-ASCII string. The string MUST be no 1502 more than 32 characters, and MUST NOT contain characters other than 1503 alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, and 0x61- 1504 0x7A), the hyphen ('-', code point 0x2D), or the colon (':', code 1505 point 0x3A). 1507 Identifiers prefixed with 'priv:' are reserved for Private Use 1508 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for 1509 Experimental use. For an identifier with the 'priv:' or 'exp:' 1510 prefix, an additional string (e.g., company identifier or random 1511 string) MUST follow to reduce potential collisions. For example, a 1512 short string after 'exp:' to indicate the starting time of a specific 1513 experiment is recommended. All other identifiers appearing in an 1514 HTTP request or response with an 'application/alto-*' media type MUST 1515 be registered in the ALTO Cost Types registry Section 12.2. 1517 The type 'CostType' is used in this document to indicate a string of 1518 this format. 1520 8.6. Endpoint Property 1522 An Endpoint Property is encoded as a US-ASCII string. The string 1523 MUST be no more than 32 characters, and MUST NOT contain characters 1524 other than alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, 1525 and 0x61-0x7A), the hyphen ('-', code point 0x2D), or the colon (':', 1526 code point 0x3A). 1528 Identifiers prefixed with 'priv:' are reserved for Private Use 1529 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for 1530 Experimental use. All other identifiers appearing in an HTTP request 1531 or response with an 'application/alto-*' media type MUST be 1532 registered in the ALTO Endpoint Property registry Section 12.3. 1534 The type 'EndpointPropertyType' is used in this document to indicate 1535 a string of this format. 1537 9. Protocol Specification: Service Information Resources 1539 This section documents the individual Information Resources defined 1540 to provide the services define in this document. 1542 9.1. Map Service 1544 The Map Service provides batch information to ALTO Clients in the 1545 form of two types of maps: a Network Map and Cost Map. 1547 9.1.1. Network Map 1549 The Network Map Information Resource lists for each PID, the network 1550 locations (endpoints) within the PID. It MUST be provided by an ALTO 1551 Server. 1553 9.1.1.1. Media Type 1555 The media type is "application/alto-networkmap+json". 1557 9.1.1.2. HTTP Method 1559 This resource is requested using the HTTP GET method. 1561 9.1.1.3. Accept Input Parameters 1563 None. 1565 9.1.1.4. Capabilities 1567 None. 1569 9.1.1.5. Response 1571 The returned InfoResourceEntity object "data" member of type 1572 InfoResourceNetworkMap: 1574 object { 1575 EndpointAddrGroup [pidname]<0..*>; 1576 ... 1577 } NetworkMapData; 1579 object { 1580 VersionTag map-vtag; 1581 NetworkMapData map; 1582 } InfoResourceNetworkMap; 1584 with members: 1586 map-vtag The Version Tag (Section 5.3) of the Network Map. 1588 map The Network Map data itself. 1590 NetworkMapData is a JSON object with each member representing a 1591 single PID and its associated set of endpoint addresses. A member's 1592 name is a string of type PIDName. 1594 The returned Network Map MUST include all PIDs known to the ALTO 1595 Server. 1597 9.1.1.6. Example 1599 GET /networkmap HTTP/1.1 1600 Host: alto.example.com 1601 Accept: application/alto-networkmap+json,application/alto-error+json 1602 HTTP/1.1 200 OK 1603 Content-Length: 370 1604 Content-Type: application/alto-networkmap+json 1606 { 1607 "meta" : {}, 1608 "data" : { 1609 "map-vtag" : "1266506139", 1610 "map" : { 1611 "PID1" : { 1612 "ipv4" : [ 1613 "192.0.2.0/24", 1614 "198.51.100.0/25" 1615 ] 1616 }, 1617 "PID2" : { 1618 "ipv4" : [ 1619 "198.51.100.128/25" 1620 ] 1621 }, 1622 "PID3" : { 1623 "ipv4" : [ 1624 "0.0.0.0/0" 1625 ], 1626 "ipv6" : [ 1627 "::/0" 1628 ] 1629 } 1630 } 1631 } 1632 } 1634 9.1.2. Cost Map 1636 The Cost Map resource lists the Path Cost for each pair of source/ 1637 destination PID defined by the ALTO Server for a given Cost Type and 1638 Cost Mode. This resource MUST be provided for at least the 1639 'routingcost' Cost Type and 'numerical' Cost Mode. 1641 Note that since this resource, an unfiltered Cost Map requested by an 1642 HTTP GET, does not indicate the desired Cost Mode or Cost Type as 1643 input parameters, an ALTO Server MUST indicate in an Information 1644 Resource Directory a unfiltered Cost Map Information Resource by 1645 specifying the capabilities (Section 9.1.2.4) with "cost-types" and 1646 "cost-modes" members each having a single element. This technique 1647 will allow an ALTO Client to determine a URI for an unfiltered Cost 1648 Map of the desired Cost Mode and Cost Type. 1650 9.1.2.1. Media Type 1652 The media type is "application/alto-costmap+json". 1654 9.1.2.2. HTTP Method 1656 This resource is requested using the HTTP GET method. 1658 9.1.2.3. Accept Input Parameters 1660 None. 1662 9.1.2.4. Capabilities 1664 This resource may be defined for across multiple Cost Types and Cost 1665 Modes. The capabilities of an ALTO Server URI providing this 1666 resource are defined by a JSON Object of type CostMapCapability: 1668 object { 1669 CostMode cost-modes<0..*>; 1670 CostType cost-types<0..*>; 1671 } CostMapCapability; 1673 with members: 1675 cost-modes The Cost Modes ( Section 5.1.2) supported by the 1676 corresponding URI. If not present, this member MUST be 1677 interpreted as an empty array. 1679 cost-types The Cost Types ( Section 5.1.1) supported by the 1680 corresponding URI. If not present, this member MUST be 1681 interpreted as an empty array. 1683 An ALTO Server MUST support all of the Cost Types listed here for 1684 each of the listed Cost Modes. Note that an ALTO Server may provide 1685 multiple Cost Map Information Resources, each with different 1686 capabilities. 1688 9.1.2.5. Response 1690 The returned InfoResourceEntity object has "data" member of type 1691 InfoResourceCostMap: 1693 object DstCosts { 1694 JSONValue [PIDName]; 1695 ... 1696 }; 1698 object { 1699 DstCosts [PIDName]<0..*>; 1700 ... 1701 } CostMapData; 1703 object { 1704 CostMode cost-mode; 1705 CostType cost-type; 1706 VersionTag map-vtag; 1707 CostMapData map; 1708 } InfoResourceCostMap; 1710 with members: 1712 cost-mode Cost Mode (Section 5.1.2) used in the Cost Map. 1714 cost-type Cost Type (Section 5.1.1) used in the Cost Map. 1716 map-vtag The Version Tag (Section 5.3) of the Network Map used to 1717 generate the Cost Map. 1719 map The Cost Map data itself. 1721 CostMapData is a JSON object with each member representing a single 1722 Source PID; the name for a member is the PIDName string identifying 1723 the corresponding Source PID. For each Source PID, a DstCosts object 1724 denotes the associated cost to a set of destination PIDs ( 1725 Section 5.2); the name for each member in the object is the PIDName 1726 string identifying the corresponding Destination PID. An 1727 implementation of the protocol in this document SHOULD assume that 1728 the cost is a JSONNumber and fail to parse if it is not, unless the 1729 implementation is using an extension to this document that indicates 1730 when and how costs of other data types are signaled. 1732 The returned Cost Map MUST include the Path Cost for each (Source 1733 PID, Destination PID) pair for which a Path Cost is defined. An ALTO 1734 Server MAY omit entries for which a Path Cost is not defined (e.g., 1735 both the Source and Destination PIDs contain addresses outside of the 1736 Network Provider's administrative domain). 1738 9.1.2.6. Example 1740 GET /costmap/num/routingcost HTTP/1.1 1741 Host: alto.example.com 1742 Accept: application/alto-costmap+json,application/alto-error+json 1744 HTTP/1.1 200 OK 1745 Content-Length: 262 1746 Content-Type: application/alto-costmap+json 1748 { 1749 "meta" : {}, 1750 "data" : { 1751 "cost-mode" : "numerical", 1752 "cost-type" : "routingcost", 1753 "map-vtag" : "1266506139", 1754 "map" : { 1755 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 1756 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 1757 "PID3": { "PID1": 20, "PID2": 15 } 1758 } 1759 } 1760 } 1762 9.2. Map Filtering Service 1764 The Map Filtering Service allows ALTO Clients to specify filtering 1765 criteria to return a subset of the full maps available in the Map 1766 Service. 1768 9.2.1. Filtered Network Map 1770 A Filtered Network Map is a Network Map Information Resource 1771 (Section 9.1.1) for which an ALTO Client may supply a list of PIDs to 1772 be included. A Filtered Network Map MAY be provided by an ALTO 1773 Server. 1775 9.2.1.1. Media Type 1777 See Section 9.1.1.1. 1779 9.2.1.2. HTTP Method 1781 This resource is requested using the HTTP POST method. 1783 9.2.1.3. Accept Input Parameters 1785 An ALTO Client supplies filtering parameters by specifying media type 1786 "application/alto-networkmapfilter+json" with HTTP POST body 1787 containing a JSON Object of type ReqFilteredNetworkMap, where: 1789 object { 1790 PIDName pids<0..*>; 1791 AddressType address-types<0..*>; 1792 } ReqFilteredNetworkMap; 1794 with members: 1796 pids Specifies list of PIDs to be included in the returned Filtered 1797 Network Map. If the list of PIDs is empty, the ALTO Server MUST 1798 interpret the list as if it contained a list of all currently- 1799 defined PIDs. The ALTO Server MUST interpret entries appearing 1800 multiple times as if they appeared only once. 1802 address-types Specifies list of address types to be included in the 1803 returned Filtered Network Map. If the list of address types is 1804 empty, the ALTO Server MUST interpret the list as if it contained 1805 a list of all address types known to the ALTO Server. The ALTO 1806 Server MUST interpret entries appearing multiple times as if they 1807 appeared only once. 1809 9.2.1.4. Capabilities 1811 None. 1813 9.2.1.5. Response 1815 See Section 9.1.1.5 for the format. 1817 The ALTO Server MUST only include PIDs in the response that were 1818 specified (implicitly or explicitly) in the request. If the input 1819 parameters contain a PID name that is not currently defined by the 1820 ALTO Server, the ALTO Server MUST behave as if the PID did not appear 1821 in the input parameters. Similarly, the ALTO Server MUST only 1822 enumerate addresses within each PID that have types which were 1823 specified (implicitly or explicitly) in the request. If the input 1824 parameters contain an address type that is not currently known to the 1825 ALTO Server, the ALTO Server MUST behave as if the address type did 1826 not appear in the input parameters. 1828 9.2.1.6. Example 1830 POST /networkmap/filtered HTTP/1.1 1831 Host: custom.alto.example.com 1832 Content-Length: 27 1833 Content-Type: application/alto-networkmapfilter+json 1834 Accept: application/alto-networkmap+json,application/alto-error+json 1836 { 1837 "pids": [ "PID1", "PID2" ] 1838 } 1840 HTTP/1.1 200 OK 1841 Content-Length: 255 1842 Content-Type: application/alto-networkmap+json 1844 { 1845 "meta" : {}, 1846 "data" : { 1847 "map-vtag" : "1266506139", 1848 "map" : { 1849 "PID1" : { 1850 "ipv4" : [ 1851 "192.0.2.0/24", 1852 "198.51.100.0/24" 1853 ] 1854 }, 1855 "PID2" : { 1856 "ipv4": [ 1857 "198.51.100.128/24" 1858 ] 1859 } 1860 } 1861 } 1862 } 1864 9.2.2. Filtered Cost Map 1866 A Filtered Cost Map is a Cost Map Information Resource 1867 (Section 9.1.2) for which an ALTO Client may supply additional 1868 parameters limiting the scope of the resulting Cost Map. A Filtered 1869 Cost Map MAY be provided by an ALTO Server. 1871 9.2.2.1. Media Type 1873 See Section 9.1.2.1. 1875 9.2.2.2. HTTP Method 1877 This resource is requested using the HTTP POST method. 1879 9.2.2.3. Accept Input Parameters 1881 Input parameters are supplied in the entity body of the POST request. 1882 This document specifies the input parameters with a data format 1883 indicated by the media type "application/alto-costmapfilter+json", 1884 which is a JSON Object of type ReqFilteredCostMap, where: 1886 object { 1887 PIDName srcs<0..*>; 1888 PIDName dsts<0..*>; 1889 } PIDFilter; 1891 object { 1892 CostMode cost-mode; 1893 CostType cost-type; 1894 JSONString constraints<0..*>; [OPTIONAL] 1895 PIDFilter pids; [OPTIONAL] 1896 } ReqFilteredCostMap; 1898 with members: 1900 cost-type The Cost Type ( Section 5.1.1) for the returned costs. 1901 This MUST be one of the supported Cost Types indicated in this 1902 resource's capabilities ( Section 9.2.2.4). 1904 cost-mode The Cost Mode ( Section 5.1.2) for the returned costs. 1905 This MUST be one of the supported Cost Modes indicated in this 1906 resource's capabilities ( Section 9.2.2.4). 1908 constraints Defines a list of additional constraints on which 1909 elements of the Cost Map are returned. This parameter MUST NOT be 1910 specified if this resource's capabilities ( Section 9.2.2.4) 1911 indicate that constraint support is not available. A constraint 1912 contains two entities separated by whitespace: (1) an operator, 1913 'gt' for greater than, 'lt' for less than, 'ge' for greater than 1914 or equal to, 'le' for less than or equal to, or 'eq' for equal to; 1915 (2) a target cost value. The cost value is a number that MUST be 1916 defined in the same units as the Cost Type indicated by the cost- 1917 type parameter. ALTO Servers SHOULD use at least IEEE 754 double- 1918 precision floating point [IEEE.754.2008] to store the cost value, 1919 and SHOULD perform internal computations using double-precision 1920 floating-point arithmetic. If multiple 'constraint' parameters 1921 are specified, they are interpreted as being related to each other 1922 with a logical AND. 1924 pids A list of Source PIDs and a list of Destination PIDs for which 1925 Path Costs are to be returned. If a list is empty, the ALTO 1926 Server MUST interpret it as the full set of currently-defined 1927 PIDs. The ALTO Server MUST interpret entries appearing in a list 1928 multiple times as if they appeared only once. If the "pids" 1929 member is not present, both lists MUST be interpreted by the ALTO 1930 Server as containing the full set of currently-defined PIDs. 1932 9.2.2.4. Capabilities 1934 The URI providing this resource supports all capabilities documented 1935 in Section 9.1.2.4 (with identical semantics), plus additional 1936 capabilities. In particular, the capabilities are defined by a JSON 1937 object of type FilteredCostMapCapability: 1939 object { 1940 CostMode cost-modes<0..*>; 1941 CostType cost-types<0..*>; 1942 JSONBool cost-constraints; 1943 } FilteredCostMapCapability; 1945 with members: 1947 cost-modes See Section 9.1.2.4. 1949 cost-types See Section 9.1.2.4. 1951 cost-constraints If true, then the ALTO Server allows cost 1952 constraints to be included in requests to the corresponding URI. 1953 If not present, this member MUST be interpreted as if it specified 1954 false. ALTO Clients should be aware that constraints may not have 1955 the intended effect for cost maps with the 'ordinal' Cost Mode 1956 since ordinal costs are not restricted to being sequential 1957 integers. 1959 9.2.2.5. Response 1961 See Section 9.1.2.5 for the format. 1963 The returned Cost Map MUST contain only source/destination pairs that 1964 have been indicated (implicitly or explicitly) in the input 1965 parameters. If the input parameters contain a PID name that is not 1966 currently defined by the ALTO Server, the ALTO Server MUST behave as 1967 if the PID did not appear in the input parameters. 1969 If any constraints are specified, Source/Destination pairs for which 1970 the Path Costs do not meet the constraints MUST NOT be included in 1971 the returned Cost Map. If no constraints were specified, then all 1972 Path Costs are assumed to meet the constraints. 1974 Note that ALTO Clients should verify that the Version Tag included in 1975 the response is consistent with the Version Tag of the Network Map 1976 used to generate the request (if applicable). If it is not, the ALTO 1977 Client may wish to request an updated Network Map, identify changes, 1978 and consider requesting a new Filtered Cost Map. 1980 9.2.2.6. Example 1982 POST /costmap/filtered HTTP/1.1 1983 Host: custom.alto.example.com 1984 Content-Type: application/alto-costmapfilter+json 1985 Accept: application/alto-costmap+json,application/alto-error+json 1987 { 1988 "cost-mode" : "numerical", 1989 "cost-type" : "routingcost", 1990 "pids" : { 1991 "srcs" : [ "PID1" ], 1992 "dsts" : [ "PID1", "PID2", "PID3" ] 1993 } 1994 } 1996 HTTP/1.1 200 OK 1997 Content-Length: 177 1998 Content-Type: application/alto-costmap+json 2000 { 2001 "meta" : {}, 2002 "data" : { 2003 "cost-mode" : "numerical", 2004 "cost-type" : "routingcost", 2005 "map-vtag" : "1266506139", 2006 "map" : { 2007 "PID1": { "PID1": 0, "PID2": 1, "PID3": 2 } 2008 } 2009 } 2010 } 2012 9.3. Endpoint Property Service 2014 The Endpoint Property Service provides information about Endpoint 2015 properties to ALTO Clients. 2017 9.3.1. Endpoint Property 2019 The Endpoint Property resource provides information about properties 2020 for individual endpoints. It MAY be provided by an ALTO Server. If 2021 an ALTO Server provides one or more Endpoint Property resources, then 2022 at least one MUST provide the 'pid' property. 2024 9.3.1.1. Media Type 2026 The media type is "application/alto-endpointprop+json". 2028 9.3.1.2. HTTP Method 2030 This resource is requested using the HTTP POST method. 2032 9.3.1.3. Accept Input Parameters 2034 An ALTO Client supplies the endpoint properties to be queried through 2035 a media type "application/alto-endpointpropparams+json", and 2036 specifies in the HTTP POST entity body a JSON Object of type 2037 ReqEndpointProp: 2039 object { 2040 EndpointPropertyType properties<1..*>; 2041 TypedEndpointAddr endpoints<1..*>; 2042 } ReqEndpointProp; 2044 with members: 2046 properties List of endpoint properties to be returned for each 2047 endpoint. Each specified property MUST be included in the list of 2048 supported properties indicated by this resource's capabilities 2049 (Section 9.3.1.4). The ALTO Server MUST interpret entries 2050 appearing multiple times as if they appeared only once. 2052 endpoints List of endpoint addresses for which the specified 2053 properties are to be returned. The ALTO Server MUST interpret 2054 entries appearing multiple times as if they appeared only once. 2056 9.3.1.4. Capabilities 2058 This resource may be defined across multiple types of endpoint 2059 properties. The capabilities of an ALTO Server URI providing 2060 Endpoint Properties are defined by a JSON Object of type 2061 EndpointPropertyCapability: 2063 object { 2064 EndpointPropertyType prop-types<0..*>; 2065 } EndpointPropertyCapability; 2067 with members: 2069 prop-types The Endpoint Properties (see Section 8.6) supported by 2070 the corresponding URI. If not present, this member MUST be 2071 interpreted as an empty array. 2073 9.3.1.5. Response 2075 The returned InfoResourceEntity object has "data" member of type 2076 InfoResourceEndpointProperty, where: 2078 object { 2079 JSONValue [EndpointPropertyType]; 2080 ... 2081 } EndpointProps; 2083 object { 2084 EndpointProps [TypedEndpointAddr]<0..*>; 2085 ... 2086 } EndpointPropertyMapData; 2088 object { 2089 VersionTag map-vtag; 2090 EndpointPropertyMapData map; 2091 } InfoResourceEndpointProperty; 2093 EndpointPropertyMapData has one member for each endpoint indicated in 2094 the input parameters (with the name being the endpoint encoded as a 2095 TypedEndpointAddr). The requested properties for each endpoint are 2096 encoded in a corresponding EndpointProps object, which encodes one 2097 name/value pair for each requested property, where the property names 2098 are encoded as strings of type EndpointProperty. An implementation 2099 of the protocol in this document SHOULD assume that the property 2100 value is a JSONString and fail to parse if it is not, unless the 2101 implementation is using an extension to this document that indicates 2102 when and how property values of other data types are signaled. 2104 The ALTO Server returns the value for each of the requested endpoint 2105 properties for each of the endpoints listed in the input parameters. 2107 If the ALTO Server does not define a requested property's value for a 2108 particular endpoint, then it MUST omit that property from the 2109 response for only that endpoint. 2111 The ALTO Server MAY include the Version Tag (Section 5.3) of the 2112 Network Map used to generate the response (if desired and applicable) 2113 as the 'map-vtag' member in the response. If the 'pid' property is 2114 returned for any endpoints in the response, the 'map-vtag' member is 2115 REQUIRED. Otherwise, it is OPTIONAL. 2117 9.3.1.6. Example 2119 POST /endpointprop/lookup HTTP/1.1 2120 Host: alto.example.com 2121 Content-Length: 96 2122 Content-Type: application/alto-endpointpropparams+json 2123 Accept: application/alto-endpointprop+json,application/alto-error+json 2125 { 2126 "properties" : [ "pid", "example-prop" ], 2127 "endpoints" : [ "ipv4:192.0.2.34", "ipv4:203.0.113.129" ] 2128 } 2130 HTTP/1.1 200 OK 2131 Content-Length: 149 2132 Content-Type: application/alto-endpointprop+json 2134 { 2135 "meta" : {}, 2136 "data": { 2137 "map-vtag" : "1266506139", 2138 "map" : { 2139 "ipv4:192.0.2.34" : { "pid": "PID1", "example-prop": "1" }, 2140 "ipv4:203.0.113.129" : { "pid": "PID3" } 2141 } 2142 } 2143 } 2145 9.4. Endpoint Cost Service 2147 The Endpoint Cost Service provides information about costs between 2148 individual endpoints. 2150 In particular, this service allows lists of Endpoint prefixes (and 2151 addresses, as a special case) to be ranked (ordered) by an ALTO 2152 Server. 2154 9.4.1. Endpoint Cost 2156 The Endpoint Cost resource provides information about costs between 2157 individual endpoints. It MAY be provided by an ALTO Server. 2159 It is important to note that although this resource allows an ALTO 2160 Server to reveal costs between individual endpoints, an ALTO Server 2161 is not required to do so. A simple alternative would be to compute 2162 the cost between two endpoints as the cost between the PIDs 2163 corresponding to the endpoints. See Section 13.1 for additional 2164 details. 2166 9.4.1.1. Media Type 2168 The media type is "application/alto-endpointcost+json". 2170 9.4.1.2. HTTP Method 2172 This resource is requested using the HTTP POST method. 2174 9.4.1.3. Accept Input Parameters 2176 An ALTO Client supplies the endpoint cost parameters through a media 2177 type "application/alto-endpointcostparams+json", with an HTTP POST 2178 entity body of a JSON Object of type ReqEndpointCostMap: 2180 object { 2181 TypedEndpointAddr srcs<0..*>; [OPTIONAL] 2182 TypedEndpointAddr dsts<1..*>; 2183 } EndpointFilter; 2185 object { 2186 CostMode cost-mode; 2187 CostType cost-type; 2188 JSONString constraints<0..*>; [OPTIONAL] 2189 EndpointFilter endpoints; 2190 } ReqEndpointCostMap; 2192 with members: 2194 cost-mode The Cost Mode ( Section 5.1.2) to use for returned costs. 2195 This MUST be one of the Cost Modes indicated in this resource's 2196 capabilities ( Section 9.4.1.4). 2198 cost-type The Cost Type ( Section 5.1.1) to use for returned costs. 2199 This MUST be one of the Cost Types indicated in this resource's 2200 capabilities ( Section 9.4.1.4). 2202 constraints Defined equivalently to the "constraints" input 2203 parameter of a Filtered Cost Map (see Section 9.2.2). 2205 endpoints A list of Source Endpoints and Destination Endpoints for 2206 which Path Costs are to be returned. If the list of Source 2207 Endpoints is empty (or not included), the ALTO Server MUST 2208 interpret it as if it contained the Endpoint Address corresponding 2209 to the client IP address from the incoming connection (see 2210 Section 11.3 for discussion and considerations regarding this 2211 mode). The list of destination Endpoints MUST NOT be empty. The 2212 ALTO Server MUST interpret entries appearing multiple times in a 2213 list as if they appeared only once. 2215 9.4.1.4. Capabilities 2217 See Section 9.2.2.4. 2219 9.4.1.5. Response 2221 The returned InfoResourceEntity object has "data" member equal to 2222 InfoResourceEndpointCostMap, where: 2224 object EndpointDstCosts { 2225 JSONValue [TypedEndpointAddr]; 2226 ... 2227 }; 2229 object { 2230 EndpointDstCosts [TypedEndpointAddr]<0..*>; 2231 ... 2232 } EndpointCostMapData; 2234 object { 2235 CostMode cost-mode; 2236 CostType cost-type; 2237 EndpointCostMapData map; 2238 } InfoResourceEndpointCostMap; 2240 InfoResourceEndpointCostMap has members: 2242 cost-mode The Cost Mode used in the returned Cost Map. 2244 cost-type The Cost Type used in the returned Cost Map. 2246 map The Endpoint Cost Map data itself. 2248 EndpointCostMapData is a JSON object with each member representing a 2249 single Source Endpoint specified in the input parameters; the name 2250 for a member is the TypedEndpointAddr string identifying the 2251 corresponding Source Endpoint. For each Source Endpoint, a 2252 EndpointDstCosts object denotes the associated cost to each 2253 Destination Endpoint specified in the input parameters; the name for 2254 each member in the object is the TypedEndpointAddr string identifying 2255 the corresponding Destination Endpoint. An implementation of the 2256 protocol in this document SHOULD assume that the cost value is a 2257 JSONNumber and fail to parse if it is not, unless the implementation 2258 is using an extension to this document that indicates when and how 2259 costs of other data types are signaled. If the ALTO Server does not 2260 define a cost value from a Source Endpoint to a particular 2261 Destination Endpoint, it MAY be omitted from the response. 2263 9.4.1.6. Example 2265 POST /endpointcost/lookup HTTP/1.1 2266 Host: alto.example.com 2267 Content-Length: 195 2268 Content-Type: application/alto-endpointcostparams+json 2269 Accept: application/alto-endpointcost+json,application/alto-error+json 2271 { 2272 "cost-mode" : "ordinal", 2273 "cost-type" : "routingcost", 2274 "endpoints" : { 2275 "srcs": [ "ipv4:192.0.2.2" ], 2276 "dsts": [ 2277 "ipv4:192.0.2.89", 2278 "ipv4:198.51.100.34", 2279 "ipv4:203.0.113.45" 2280 ] 2281 } 2282 } 2284 HTTP/1.1 200 OK 2285 Content-Length: 231 2286 Content-Type: application/alto-endpointcost+json 2288 { 2289 "meta" : {}, 2290 "data" : { 2291 "cost-mode" : "ordinal", 2292 "cost-type" : "routingcost", 2293 "map" : { 2294 "ipv4:192.0.2.2": { 2295 "ipv4:192.0.2.89" : 1, 2296 "ipv4:198.51.100.34" : 2, 2297 "ipv4:203.0.113.45" : 3 2298 } 2299 } 2300 } 2301 } 2303 10. Use Cases 2305 The sections below depict typical use cases. While these use cases 2306 focus on peer-to-peer applications, ALTO can be applied to other 2307 environments such as CDNs [I-D.jenkins-alto-cdn-use-cases]. 2309 10.1. ALTO Client Embedded in P2P Tracker 2311 Many currently-deployed P2P systems use a Tracker to manage swarms 2312 and perform peer selection. Such a P2P Tracker can already use a 2313 variety of information to perform peer selection to meet application- 2314 specific goals. By acting as an ALTO Client, the P2P Tracker can use 2315 ALTO information as an additional information source to enable more 2316 network-efficient traffic patterns and improve application 2317 performance. 2319 A particular requirement of many P2P trackers is that they must 2320 handle a large number of P2P clients. A P2P tracker can obtain and 2321 locally store ALTO information (the Network Map and Cost Map) from 2322 the ISPs containing the P2P clients, and benefit from the same 2323 aggregation of network locations done by ALTO Servers. 2325 .---------. (1) Get Network Map .---------------. 2326 | | <----------------------> | | 2327 | ALTO | | P2P Tracker | 2328 | Server | (2) Get Cost Map | (ALTO Client) | 2329 | | <----------------------> | | 2330 `---------' `---------------' 2331 ^ | 2332 (3) Get Peers | | (4) Selected Peer 2333 | v List 2334 .---------. .-----------. 2335 | Peer 1 | <-------------- | P2P | 2336 `---------' | Client | 2337 . (5) Connect to `-----------' 2338 . Selected Peers / 2339 .---------. / 2340 | Peer 50 | <------------------ 2341 `---------' 2343 Figure 4: ALTO Client Embedded in P2P Tracker 2345 Figure 4 shows an example use case where a P2P tracker is an ALTO 2346 Client and applies ALTO information when selecting peers for its P2P 2347 clients. The example proceeds as follows: 2349 1. The P2P Tracker requests the Network Map covering all PIDs from 2350 the ALTO Server using the Network Map query. The Network Map 2351 includes the IP prefixes contained in each PID, allowing the P2P 2352 tracker to locally map P2P clients into a PIDs. 2354 2. The P2P Tracker requests the Cost Map amongst all PIDs from the 2355 ALTO Server. 2357 3. A P2P Client joins the swarm, and requests a peer list from the 2358 P2P Tracker. 2360 4. The P2P Tracker returns a peer list to the P2P client. The 2361 returned peer list is computed based on the Network Map and Cost 2362 Map returned by the ALTO Server, and possibly other information 2363 sources. Note that it is possible that a tracker may use only 2364 the Network Map to implement hierarchical peer selection by 2365 preferring peers within the same PID and ISP. 2367 5. The P2P Client connects to the selected peers. 2369 Note that the P2P tracker may provide peer lists to P2P clients 2370 distributed across multiple ISPs. In such a case, the P2P tracker 2371 may communicate with multiple ALTO Servers. 2373 10.2. ALTO Client Embedded in P2P Client: Numerical Costs 2375 P2P clients may also utilize ALTO information themselves when 2376 selecting from available peers. It is important to note that not all 2377 P2P systems use a P2P tracker for peer discovery and selection. 2378 Furthermore, even when a P2P tracker is used, the P2P clients may 2379 rely on other sources, such as peer exchange and DHTs, to discover 2380 peers. 2382 When an P2P Client uses ALTO information, it typically queries only 2383 the ALTO Server servicing its own ISP. The my-Internet view provided 2384 by its ISP's ALTO Server can include preferences to all potential 2385 peers. 2387 .---------. (1) Get Network Map .---------------. 2388 | | <----------------------> | | 2389 | ALTO | | P2P Client | 2390 | Server | (2) Get Cost Map | (ALTO Client) | 2391 | | <----------------------> | | .---------. 2392 `---------' `---------------' <- | P2P | 2393 .---------. / | ^ ^ | Tracker | 2394 | Peer 1 | <-------------- | | \ `---------' 2395 `---------' | (3) Gather Peers 2396 . (4) Select Peers | | \ 2397 . and Connect / .--------. .--------. 2398 .---------. / | P2P | | DHT | 2399 | Peer 50 | <---------------- | Client | `--------' 2400 `---------' | (PEX) | 2401 `--------' 2403 Figure 5: ALTO Client Embedded in P2P Client 2405 Figure 5 shows an example use case where a P2P Client locally applies 2406 ALTO information to select peers. The use case proceeds as follows: 2408 1. The P2P Client requests the Network Map covering all PIDs from 2409 the ALTO Server servicing its own ISP. 2411 2. The P2P Client requests the Cost Map amongst all PIDs from the 2412 ALTO Server. The Cost Map by default specifies numerical costs. 2414 3. The P2P Client discovers peers from sources such as Peer Exchange 2415 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2416 P2P Trackers. 2418 4. The P2P Client uses ALTO information as part of the algorithm for 2419 selecting new peers, and connects to the selected peers. 2421 10.3. ALTO Client Embedded in P2P Client: Ranking 2423 It is also possible for a P2P Client to offload the selection and 2424 ranking process to an ALTO Server. In this use case, the ALTO Client 2425 gathers a list of known peers in the swarm, and asks the ALTO Server 2426 to rank them. 2428 As in the use case using numerical costs, the P2P Client typically 2429 only queries the ALTO Server servicing its own ISP. 2431 .---------. .---------------. 2432 | | | | 2433 | ALTO | (2) Get Endpoint Ranking | P2P Client | 2434 | Server | <----------------------> | (ALTO Client) | 2435 | | | | .---------. 2436 `---------' `---------------' <- | P2P | 2437 .---------. / | ^ ^ | Tracker | 2438 | Peer 1 | <-------------- | | \ `---------' 2439 `---------' | (1) Gather Peers 2440 . (3) Connect to | | \ 2441 . Selected Peers / .--------. .--------. 2442 .---------. / | P2P | | DHT | 2443 | Peer 50 | <---------------- | Client | `--------' 2444 `---------' | (PEX) | 2445 `--------' 2447 Figure 6: ALTO Client Embedded in P2P Client: Ranking 2449 Figure 6 shows an example of this scenario. The use case proceeds as 2450 follows: 2452 1. The P2P Client discovers peers from sources such as Peer Exchange 2453 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2454 P2P Trackers. 2456 2. The P2P Client queries the ALTO Server's Ranking Service, 2457 including discovered peers as the set of Destination Endpoints, 2458 and indicates the 'ordinal' Cost Mode. The response indicates 2459 the ranking of the candidate peers. 2461 3. The P2P Client connects to the peers in the order specified in 2462 the ranking. 2464 11. Discussions 2466 11.1. Discovery 2468 The discovery mechanism by which an ALTO Client locates an 2469 appropriate ALTO Server is out of scope for this document. This 2470 document assumes that an ALTO Client can discover an appropriate ALTO 2471 Server. Once it has done so, the ALTO Client may use the Information 2472 Resource Directory (see Section 7.6) to locate an Information 2473 Resource with the desired ALTO Information. 2475 11.2. Hosts with Multiple Endpoint Addresses 2477 In practical deployments, a particular host can be reachable using 2478 multiple addresses (e.g., a wireless IPv4 connection, a wireline IPv4 2479 connection, and a wireline IPv6 connection). In general, the 2480 particular network path followed when sending packets to the host 2481 will depend on the address that is used. Network providers may 2482 prefer one path over another. An additional consideration may be how 2483 to handle private address spaces (e.g., behind carrier-grade NATs). 2485 To support such behavior, this document allows multiple endpoint 2486 addresses and address types. With this support, the ALTO Protocol 2487 allows an ALTO Service Provider the flexibility to indicate 2488 preferences for paths from an endpoint address of one type to an 2489 endpoint address of a different type. 2491 11.3. Network Address Translation Considerations 2493 At this day and age of NAT v4<->v4, v4<->v6 [RFC6144], and possibly 2494 v6<->v6[I-D.mrw-nat66], a protocol should strive to be NAT friendly 2495 and minimize carrying IP addresses in the payload, or provide a mode 2496 of operation where the source IP address provide the information 2497 necessary to the server. 2499 The protocol specified in this document provides a mode of operation 2500 where the source network location is computed by the ALTO Server 2501 (i.e., the the Endpoint Cost Service) from the source IP address 2502 found in the ALTO Client query packets. This is similar to how some 2503 P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS 2504 Protocol" in [BitTorrent]) operate. 2506 There may be cases where an ALTO Client needs to determine its own IP 2507 address, such as when specifying a source Endpoint Address in the 2508 Endpoint Cost Service. It is possible that an ALTO Client has 2509 multiple network interface addresses, and that some or all of them 2510 may require NAT for connectivity to the public Internet. 2512 If a public IP address is required for a network interface, the ALTO 2513 client SHOULD use the Session Traversal Utilities for NAT (STUN) 2514 [RFC5389]. If using this method, the host MUST use the "Binding 2515 Request" message and the resulting "XOR-MAPPED-ADDRESS" parameter 2516 that is returned in the response. Using STUN requires cooperation 2517 from a publicly accessible STUN server. Thus, the ALTO client also 2518 requires configuration information that identifies the STUN server, 2519 or a domain name that can be used for STUN server discovery. To be 2520 selected for this purpose, the STUN server needs to provide the 2521 public reflexive transport address of the host. 2523 ALTO Clients should be cognizant that the network path between 2524 Endpoints can depend on multiple factors, e.g., source address, and 2525 destination address used for communication. An ALTO Server provides 2526 information based on Endpoint Addresses (more generally, Network 2527 Locations), but the mechanisms used for determining existence of 2528 connectivity or usage of NAT between Endpoints are out of scope of 2529 this document. 2531 11.4. Endpoint and Path Properties 2533 An ALTO Server could make available many properties about Endpoints 2534 beyond their network location or grouping. For example, connection 2535 type, geographical location, and others may be useful to 2536 applications. This specification focuses on network location and 2537 grouping, but the protocol may be extended to handle other Endpoint 2538 properties. 2540 12. IANA Considerations 2542 12.1. application/alto-* Media Types 2544 This document requests the registration of multiple media types, 2545 listed in Table 2. 2547 +-------------+------------------------------+---------------+ 2548 | Type | Subtype | Specification | 2549 +-------------+------------------------------+---------------+ 2550 | application | alto-directory+json | Section 7.6 | 2551 | application | alto-networkmap+json | Section 9.1.1 | 2552 | application | alto-networkmapfilter+json | Section 9.2.1 | 2553 | application | alto-costmap+json | Section 9.1.2 | 2554 | application | alto-costmapfilter+json | Section 9.2.2 | 2555 | application | alto-endpointprop+json | Section 9.3.1 | 2556 | application | alto-endpointpropparams+json | Section 9.3.1 | 2557 | application | alto-endpointcost+json | Section 9.4.1 | 2558 | application | alto-endpointcostparams+json | Section 9.4.1 | 2559 | application | alto-error+json | Section 7.7 | 2560 +-------------+------------------------------+---------------+ 2562 Table 2: ALTO Protocol Media Types 2564 Type name: application 2566 Subtype name: This documents requests the registration of multiple 2567 subtypes, as listed in Table 2. 2569 Required parameters: n/a 2571 Optional parameters: n/a 2573 Encoding considerations: Encoding considerations are identical to 2574 those specified for the 'application/json' media type. See 2575 [RFC4627]. 2577 Security considerations: Security considerations relating to the 2578 generation and consumption of ALTO protocol messages are discussed 2579 in Section 13. 2581 Interoperability considerations: This document specifies format of 2582 conforming messages and the interpretation thereof. 2584 Published specification: This document is the specification for 2585 these media types; see Table 2 for the section documenting each 2586 media type. 2588 Applications that use this media type: ALTO Servers and ALTO Clients 2589 either standalone or embedded within other applications. 2591 Additional information: 2593 Magic number(s): n/a 2595 File extension(s): This document uses the mime type to refer to 2596 protocol messages and thus does not require a file extension. 2598 Macintosh file type code(s): n/a 2600 Person & email address to contact for further information: See 2601 "Authors' Addresses" section. 2603 Intended usage: COMMON 2605 Restrictions on usage: n/a 2607 Author: See "Authors' Addresses" section. 2609 Change controller: Internet Engineering Task Force 2610 (mailto:iesg@ietf.org). 2612 12.2. ALTO Cost Type Registry 2614 This document requests the creation of an ALTO Cost Type registry, 2615 listed in Table 3, to be maintained by IANA. 2617 +-------------+---------------------+ 2618 | Identifier | Intended Semantics | 2619 +-------------+---------------------+ 2620 | routingcost | See Section 5.1.1.1 | 2621 | priv: | Private use | 2622 | exp: | Experimental use | 2623 +-------------+---------------------+ 2625 Table 3: ALTO Cost Types. 2627 This registry serves two purposes. First, it ensures uniqueness of 2628 identifiers referring to ALTO Cost Types. Second, it provides 2629 references to particular semantics of allocated Cost Types to be 2630 applied by both ALTO Servers and applications utilizing ALTO Clients. 2632 New ALTO Cost Types are assigned after Expert Review [RFC5226]. The 2633 Expert Reviewer will generally consult the ALTO Working Group or its 2634 successor. Expert Review is used to ensure that proper documentation 2635 regarding ALTO Cost Type semantics and security considerations has 2636 been provided. The provided documentation should be detailed enough 2637 to provide guidance to both ALTO Service Providers and applications 2638 utilizing ALTO Clients as to how values of the registered ALTO Cost 2639 Type should be interpreted. Updates and deletions of ALTO Cost Types 2640 follow the same procedure. 2642 Registered ALTO Cost Type identifiers MUST conform to the syntactical 2643 requirements specified in Section 8.5. Identifiers are to be 2644 recorded and displayed as ASCII strings. 2646 Identifiers prefixed with 'priv:' are reserved for Private Use. 2647 Identifiers prefixed with 'exp:' are reserved for Experimental use. 2649 Requests to add a new value to the registry MUST include the 2650 following information: 2652 o Identifier: The name of the desired ALTO Cost Type. 2654 o Intended Semantics: ALTO Costs carry with them semantics to guide 2655 their usage by ALTO Clients. For example, if a value refers to a 2656 measurement, the measurement units must be documented. For proper 2657 implementation of the ordinal Cost Mode (e.g., by a third-party 2658 service), it should be documented whether higher or lower values 2659 of the cost are more preferred. 2661 o Security Considerations: ALTO Costs expose information to ALTO 2662 Clients. As such, proper usage of a particular Cost Type may 2663 require certain information to be exposed by an ALTO Service 2664 Provider. Since network information is frequently regarded as 2665 proprietary or confidential, ALTO Service Providers should be made 2666 aware of the security ramifications related to usage of a Cost 2667 Type. 2669 This specification requests registration of the identifier 2670 'routingcost'. Semantics for the this Cost Type are documented in 2671 Section 5.1.1.1, and security considerations are documented in 2672 Section 13.1. 2674 12.3. ALTO Endpoint Property Type Registry 2676 This document requests the creation of an ALTO Endpoint Property 2677 Types registry, listed in Table 4, to be maintained by IANA. 2679 +------------+--------------------+ 2680 | Identifier | Intended Semantics | 2681 +------------+--------------------+ 2682 | pid | See Section 6.1.1 | 2683 | priv: | Private use | 2684 | exp: | Experimental use | 2685 +------------+--------------------+ 2687 Table 4: ALTO Endpoint Property Types. 2689 The maintenance of this registry is similar to that of the preceding 2690 ALTO Cost Types. 2692 12.4. ALTO Address Type Registry 2694 This document requests the creation of an ALTO Address Type registry, 2695 listed in Table 5, to be maintained by IANA. 2697 +------------+----------------+----------------+--------------------+ 2698 | Identifier | Address | Prefix | Mapping to/from | 2699 | | Encoding | Encoding | IPv4/v6 | 2700 +------------+----------------+----------------+--------------------+ 2701 | ipv4 | See | See | Direct mapping to | 2702 | | Section 8.3.2 | Section 8.3.3 | IPv4 | 2703 | ipv6 | See | See | Direct mapping to | 2704 | | Section 8.3.2 | Section 8.3.3 | IPv6 | 2705 +------------+----------------+----------------+--------------------+ 2707 Table 5: ALTO Address Types. 2709 This registry serves two purposes. First, it ensures uniqueness of 2710 identifiers referring to ALTO Address Types. Second, it states the 2711 requirements for allocated Address Type identifiers. 2713 New ALTO Address Types are assigned after Expert Review [RFC5226]. 2714 The Expert Reviewer will generally consult the ALTO Working Group or 2715 its successor. Expert Review is used to ensure that proper 2716 documentation regarding the new ALTO Address Types and their security 2717 considerations has been provided. The provided documentation should 2718 indicate how an address of a registered type is encoded as an 2719 EndpointAddr and, if possible, a compact method (e.g., IPv4 and IPv6 2720 prefixes) for encoding a set of addresses as an EndpointPrefix. 2721 Updates and deletions of ALTO Address Types follow the same 2722 procedure. 2724 Registered ALTO Address Type identifiers MUST conform to the 2725 syntactical requirements specified in Section 8.3.1. Identifiers are 2726 to be recorded and displayed as ASCII strings. 2728 Requests to add a new value to the registry MUST include the 2729 following information: 2731 o Identifier: The name of the desired ALTO Address Type. 2733 o Endpoint Address Encoding: The procedure for encoding an address 2734 of the registered type as an EndpointAddr (see Section 8.3.2). 2736 o Endpoint Prefix Encoding: The procedure for encoding a set of 2737 addresses of the registered type as an EndpointPrefix (see 2738 Section 8.3.3). If no such compact encoding is available, the 2739 same encoding used for a singular address may be used. In such a 2740 case, it must be documented that sets of addresses of this type 2741 always have exactly one element. 2743 o Mapping to/from IPv4/IPv6 Addresses: If possible, a mechanism to 2744 map addresses of the registered type to and from IPv4 or IPv6 2745 addresses should be specified. 2747 o Security Considerations: In some usage scenarios, Endpoint 2748 Addresses carried in ALTO Protocol messages may reveal information 2749 about an ALTO Client or an ALTO Service Provider. Applications 2750 and ALTO Service Providers using addresses of the registered type 2751 should be made aware of how (or if) the addressing scheme relates 2752 to private information and network proximity. 2754 This specification requests registration of the identifiers 'ipv4' 2755 and 'ipv6', as shown in Table 5. 2757 12.5. ALTO Error Code Registry 2759 This document requests the creation of an ALTO Error Code registry, 2760 listed in Table 1, to be maintained by IANA. 2762 13. Security Considerations 2764 13.1. Privacy Considerations for ISPs 2766 ISPs must be cognizant of the network topology and provisioning 2767 information provided through ALTO Interfaces. ISPs should evaluate 2768 how much information is revealed and the associated risks. On the 2769 one hand, providing overly fine-grained information may make it 2770 easier for attackers to infer network topology. In particular, 2771 attackers may try to infer details regarding ISPs' operational 2772 policies or inter-ISP business relationships by intentionally posting 2773 a multitude of selective queries to an ALTO server and analyzing the 2774 responses. Such sophisticated attacks may reveal more information 2775 than an ISP hosting an ALTO server intends to disclose. On the other 2776 hand, revealing overly coarse-grained information may not provide 2777 benefits to network efficiency or performance improvements to ALTO 2778 Clients. 2780 It is possible that one or multiple ALTO Clients issue queries in an 2781 effort to reverse-engineer specific details (e.g., network topology) 2782 that was used to produce ALTO information. Operators should have 2783 security policies in place such that confidential information or 2784 information that could be reverse-engineered to reveal confidential 2785 information is not sent to unauthorized ALTO Clients. 2787 ISPs must also be cognizant that ALTO may reveal additional 2788 information about IP addresses and associated information about it. 2789 For example, when adding the line bitrate as one endpoint property, 2790 such information may be potentially linked to the income of the 2791 habitants at the network location of an endpoint. 2793 13.2. ALTO Clients 2795 Applications using the information must be cognizant of the 2796 possibility that the information is malformed or incorrect. Even if 2797 an ALTO Server has been properly authenticated by the ALTO Client, 2798 the information provided may be malicious because the ALTO Server and 2799 its credentials have been compromised (e.g., through malware). Other 2800 considerations (e.g., relating to application performance) can be 2801 found in Section 6 of [RFC5693]. 2803 ALTO Clients should also be cognizant of revealing Network Location 2804 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, 2805 as doing so may allow the ALTO Server to infer communication 2806 patterns. As an ALTO Server may collect information from multiple 2807 client queries, the server may deduce additional application/content 2808 information through correlation. One possibility is for the ALTO 2809 Client to only rely on Network Map for PIDs and Cost Map amongst PIDs 2810 to avoid passing IP addresses of other endpoints (e.g., peers) to the 2811 ALTO Server. 2813 In addition, ALTO clients should be cautious not to unintentionally 2814 or indirectly disclose the resource identifier (of which they try to 2815 improve the retrieval through ALTO-guidance), e.g., the name/ 2816 identifier of a certain video stream in P2P live streaming, to the 2817 ALTO server. Note that the ALTO Protocol specified in this document 2818 does not explicitly reveal any resource identifier to the ALTO 2819 Server. However, for instance, depending on the popularity or other 2820 specifics (such as language) of the resource, an ALTO server could 2821 potentially deduce information about the desired resource from 2822 information such as the Network Locations the client sends as part of 2823 its request to the server. 2825 13.3. Authentication, Integrity Protection, and Encryption 2827 SSL/TLS [RFC5246] can provide encryption and integrity protection of 2828 transmitted messages as well as authentication of the ALTO Client and 2829 Server. HTTP Basic or Digest authentication can provide 2830 authentication of the client (combined with SSL/TLS, it can 2831 additionally provide encryption, integrity protection and server 2832 authentication). 2834 Issues resulting from an attacker controlling the data received by an 2835 ALTO Client are discussed in Section 13.2. 2837 An ALTO Server may optionally use authentication (and potentially 2838 encryption) to limit the parties with whom ALTO information is 2839 directly shared. There may be special use cases where encryption of 2840 ALTO information is desirable. In many cases, however, information 2841 sent out by an ALTO Server may be regarded as non-confidential 2842 information. 2844 ISPs should be cognizant that encryption only protects ALTO 2845 information until it is decrypted by the intended ALTO Client. 2846 Digital Rights Management (DRM) techniques and legal agreements 2847 protecting ALTO information are outside of the scope of this 2848 document. 2850 13.4. ALTO Information Redistribution 2852 It is possible for applications to redistribute ALTO information to 2853 improve scalability. Even with such a distribution scheme, ALTO 2854 Clients obtaining ALTO information must be able to validate the 2855 received ALTO information to ensure that it was generated by an 2856 appropriate ALTO Server. Support for this validation is not provided 2857 in this document, but may be provided by extension documents. 2859 13.5. Denial of Service 2861 ISPs should be cognizant of the workload at the ALTO Server generated 2862 by certain ALTO Queries, such as certain queries to the Map Filtering 2863 Service and Ranking Service. In particular, queries which can be 2864 generated with low effort but result in expensive workloads at the 2865 ALTO Server could be exploited for Denial-of-Service attacks. For 2866 instance, a simple ALTO query with n Source Network Locations and m 2867 Destination Network Locations can be generated fairly easily but 2868 results in the computation of n*m Path Costs between pairs by the 2869 ALTO Server (see Section 5.2). One way to limit Denial-of-Service 2870 attacks is to employ access control to the ALTO server. The ALTO 2871 server can also indicate overload. Yet another possible mechanism 2872 for an ALTO Server to protect itself against a multitude of 2873 computationally expensive bogus requests is to demand that each ALTO 2874 Client to solve a computational puzzle first before allocating 2875 resources for answering a request (see, e.g., 2876 [I-D.jennings-sip-hashcash]). The current specification does not use 2877 such computational puzzles, and discussion regarding tradeoffs of 2878 such an approach would be needed before including such a technique in 2879 the ALTO Protocol. 2881 ISPs should also leverage the fact that the the Map Service allows 2882 ALTO Servers to pre-generate maps that can be useful to many ALTO 2883 Clients. 2885 13.6. ALTO Server Access Control 2887 In order to limit access to an ALTO server (e.g., for an ISP to only 2888 allow its users to access its ALTO server, or to prevent Denial-of- 2889 Service attacks by arbitrary hosts from the Internet), an ALTO server 2890 may employ access control policies. Depending on the use-case and 2891 scenario, an ALTO server may restrict access to its services more 2892 strictly or rather openly (see [I-D.ietf-alto-deployments] for a more 2893 detailed discussion on this issue). 2895 14. Manageability Considerations 2897 This section details operations and management considerations based 2898 on existing deployments and discussions during protocol development. 2899 It also indicates where extension documents are expected to provide 2900 appropriate functionality discussed in [RFC5706] as additional 2901 deployment experience becomes available. 2903 14.1. Operations 2905 14.1.1. Installation and Initial Setup 2907 The ALTO Protocol is based on HTTP. Thus, configuring an ALTO Server 2908 may require configuring the underlying HTTP server implementation to 2909 define appropriate security policies, caching policies, performance 2910 settings, etc. 2912 Additionally, an operator of an ALTO Server will need to configure 2913 the ALTO information to be provided by the ALTO Server. The 2914 granularity of the topological map and the cost map is left to the 2915 specific policies of the operator of the ALTO Server. However, a 2916 reasonable default may include two PIDs, one to hold the endpoints in 2917 the operator's network and the second PID to represent full IPv4 and 2918 IPv4 reachability (see Section 4.2.1), with the cost between each 2919 source/destination PID set to 1. Another operational issue that the 2920 operator of an ALTO Server needs to consider is that the filtering 2921 service can degenerate into a full map service when the filtering 2922 input is empty. Although this choice as the degeneration behavior 2923 provides continuity, the operational impact should be considered. 2925 Implementers employing an ALTO Client should attempt to automatically 2926 discover an appropriate ALTO Server. Manual configuration of the 2927 ALTO Server location may be used where automatic discovery is not 2928 appropriate. Methods for automatic discovery and manual 2929 configuration are discussed in [I-D.ietf-alto-server-discovery]. 2931 Specifications for underlying protocols (e.g., TCP, HTTP, SSL/TLS) 2932 should be consulted for their available settings and proposed default 2933 configurations. 2935 14.1.2. Migration Path 2937 This document does not detail a migration path for ALTO Servers since 2938 there is no previous standard protocol providing the similar 2939 functionality. 2941 There are existing applications making use of network information 2942 discovered from other entities such as whois, geo-location databases, 2943 or round-trip time measurements, etc. Such applications should 2944 consider using ALTO as an additional source of information; ALTO need 2945 not be the sole source of network information. 2947 14.1.3. Requirements on Other Protocols and Functional Components 2949 The ALTO Protocol assumes that HTTP client and server implementations 2950 exist. It also assumes that JSON encoder and decoder implementations 2951 exist. 2953 An ALTO Server assumes that it can gather sufficient information to 2954 populate Network and Cost maps. "Sufficient information" is 2955 dependent on the information being exposed, but likely includes 2956 information gathered from protocols such as IGP and EGP Routing 2957 Information Bases (see Figure 1). Specific mechanisms have been 2958 proposed (e.g., [I-D.medved-alto-svr-apis]) and are expected to be 2959 provided in extension documents. 2961 14.1.4. Impact and Observation on Network Operation 2963 ALTO presents a new opportunity for managing network traffic by 2964 providing additional information to clients. The potential impact to 2965 network operation is large. 2967 Deployment of an ALTO Server may shift network traffic patterns. 2968 Thus, operators should consider impacts on (or integration with) 2969 traffic engineering and the deployment of a monitoring service to 2970 observe the effects of ALTO operations. Note that ALTO-specific 2971 monitoring and metrics are discussed in 6.3 of 2972 [I-D.ietf-alto-deployments] and future versions of that document. In 2973 particular, operators may observe that ALTO Clients are not bound to 2974 ALTO Server guidance as ALTO is only one source of information. 2976 Operators providing an ALTO Server should ensure that appropriate 2977 information is being exposed. Privacy implications for ISPs are 2978 discussed in Section 13.1. Both operators and ALTO Servers and those 2979 using ALTO Clients should be aware of the impact of incorrect or 2980 faked guidance (see Section 10.3 of [I-D.ietf-alto-deployments] and 2981 future versions of that document). 2983 14.2. Management 2985 14.2.1. Management Interoperability 2987 A common management API would be desirable given that ALTO Servers 2988 may typically be configured with dynamic data from various sources, 2989 and ALTO Servers are intended to scale horizontally for fault- 2990 tolerance and reliability. A specific API or protocol is outside the 2991 scope of this document, but may be provided by an extension document. 2993 Logging is an important functionality for ALTO Servers and, depending 2994 on the deployment, ALTO Clients. Logging should be done via syslog 2995 [RFC5424]. 2997 14.2.2. Management Information 2999 A Management Information Model (see Section 3.2 of [RFC5706] is not 3000 provided by this document, but should be included or referenced by 3001 any extension documenting an ALTO-related management API or protocol. 3003 14.2.3. Fault Management 3005 Monitoring ALTO Servers and Clients is described in Section 6.3 of 3006 [I-D.ietf-alto-deployments] and future versions of that document. 3008 14.2.4. Configuration Management 3010 Standardized approaches and protocols to configuration management for 3011 ALTO are outside the scope of this document, but this document does 3012 outline high-level principles suggested for future standardization 3013 efforts. 3015 An ALTO Server requires at least the following logical inputs: 3017 o Data sources from which ALTO Information is derived. This can 3018 either be raw network information (e.g., from routing elements) or 3019 pre-processed ALTO-level information in the form of a Network Map, 3020 Cost Map, etc. 3022 o Algorithms for computing the ALTO information returned to clients. 3023 These could either return information from a database, or 3024 information customized for each client. 3026 o Security policies mapping potential clients to the information 3027 that they have privilege to access. 3029 Multiple ALTO Servers can be deployed for scalability. A centralized 3030 configuration database may be used to ensure they are providing the 3031 desired ALTO information with appropriate security controls. The 3032 ALTO information (e.g., Network Maps and Cost Maps) being served by 3033 each ALTO Server, as well as security policies (HTTP authentication, 3034 SSL/TLS client and server authentication, SSL/TLS encryption 3035 parameters) intended to serve the same information should be 3036 monitored for consistency. 3038 14.2.5. Performance Management 3040 An exhaustive list of desirable performance information from a ALTO 3041 Servers and ALTO Clients are outside of the scope of this document. 3042 The following is a list of suggested ALTO-specific to be monitored 3043 based on the existing deployment and protocol development experience: 3045 o Requests and responses for each service listed in a Information 3046 Directory (total counts and size in bytes). 3048 o CPU and memory utilization 3050 o ALTO map updates 3052 o Number of PIDs 3054 o ALTO map sizes (in-memory size, encoded size, number of entries) 3056 14.2.6. Security Management 3058 Section 13 documents ALTO-specific security considerations. 3059 Operators should configure security policies with those in mind. 3060 Readers should refer to HTTP [RFC2616] and SSL/TLS [RFC5246] and 3061 related documents for mechanisms available for configuring security 3062 policies. Other appropriate security mechanisms (e.g., physical 3063 security, firewalls, etc) should also be considered. 3065 15. References 3067 15.1. Normative References 3069 [IEEE.754.2008] 3070 Institute of Electrical and Electronics Engineers, 3071 "Standard for Binary Floating-Point Arithmetic", IEEE 3072 Standard 754, August 2008. 3074 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 3075 Extensions (MIME) Part Two: Media Types", RFC 2046, 3076 November 1996. 3078 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3079 Requirement Levels", BCP 14, RFC 2119, March 1997. 3081 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3082 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3083 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3085 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3086 Resource Identifier (URI): Generic Syntax", STD 66, 3087 RFC 3986, January 2005. 3089 [RFC4627] Crockford, D., "The application/json Media Type for 3090 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 3092 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 3093 (CIDR): The Internet Address Assignment and Aggregation 3094 Plan", BCP 122, RFC 4632, August 2006. 3096 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3097 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3098 May 2008. 3100 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3101 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 3103 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3104 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3105 October 2008. 3107 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 3109 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 3110 Address Text Representation", RFC 5952, August 2010. 3112 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3113 Verification of Domain-Based Application Service Identity 3114 within Internet Public Key Infrastructure Using X.509 3115 (PKIX) Certificates in the Context of Transport Layer 3116 Security (TLS)", RFC 6125, March 2011. 3118 15.2. Informative References 3120 [BitTorrent] 3121 "Bittorrent Protocol Specification v1.0", 3122 . 3124 [Fielding-Thesis] 3125 Fielding, R., "Architectural Styles and the Design of 3126 Network-based Software Architectures", University of 3127 California, Irvine, Dissertation 2000, 2000. 3129 [I-D.akonjang-alto-proxidor] 3130 Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 3131 Saucez, "The PROXIDOR Service", 3132 draft-akonjang-alto-proxidor-00 (work in progress), 3133 March 2009. 3135 [I-D.gu-alto-redistribution] 3136 Yingjie, G., Alimi, R., and R. Even, "ALTO Information 3137 Redistribution", draft-gu-alto-redistribution-03 (work in 3138 progress), July 2010. 3140 [I-D.ietf-alto-deployments] 3141 Stiemerling, M., Kiesel, S., and S. Previdi, "ALTO 3142 Deployment Considerations", draft-ietf-alto-deployments-06 3143 (work in progress), February 2013. 3145 [I-D.ietf-alto-reqs] 3146 Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, 3147 "Application-Layer Traffic Optimization (ALTO) 3148 Requirements", draft-ietf-alto-reqs-08 (work in progress), 3149 March 2011. 3151 [I-D.ietf-alto-server-discovery] 3152 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 3153 S. Yongchao, "ALTO Server Discovery", 3154 draft-ietf-alto-server-discovery-07 (work in progress), 3155 January 2013. 3157 [I-D.jenkins-alto-cdn-use-cases] 3158 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 3159 S. Previdi, "Use Cases for ALTO within CDNs", 3160 draft-jenkins-alto-cdn-use-cases-03 (work in progress), 3161 June 2012. 3163 [I-D.jennings-sip-hashcash] 3164 Jennings, C., "Computational Puzzles for SPAM Reduction in 3165 SIP", draft-jennings-sip-hashcash-06 (work in progress), 3166 July 2007. 3168 [I-D.medved-alto-svr-apis] 3169 Medved, J., Ward, D., Peterson, J., Woundy, R., and D. 3170 McDysan, "ALTO Network-Server and Server-Server APIs", 3171 draft-medved-alto-svr-apis-00 (work in progress), 3172 March 2011. 3174 [I-D.mrw-nat66] 3175 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 3176 Translation", draft-mrw-nat66-16 (work in progress), 3177 April 2011. 3179 [I-D.p4p-framework] 3180 Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, 3181 "P4P: Provider Portal for P2P Applications", 3182 draft-p4p-framework-00 (work in progress), November 2008. 3184 [I-D.saumitra-alto-multi-ps] 3185 Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 3186 Dimensional Peer Selection Problem", 3187 draft-saumitra-alto-multi-ps-00 (work in progress), 3188 October 2008. 3190 [I-D.saumitra-alto-queryresponse] 3191 Das, S. and V. Narayanan, "A Client to Service Query 3192 Response Protocol for ALTO", 3193 draft-saumitra-alto-queryresponse-00 (work in progress), 3194 March 2009. 3196 [I-D.shalunov-alto-infoexport] 3197 Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 3198 Export Service", draft-shalunov-alto-infoexport-00 (work 3199 in progress), October 2008. 3201 [I-D.wang-alto-p4p-specification] 3202 Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, 3203 "P4P Protocol Specification", 3204 draft-wang-alto-p4p-specification-00 (work in progress), 3205 March 2009. 3207 [P4P-SIGCOMM08] 3208 Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A. 3209 Silberschatz, "P4P: Provider Portal for (P2P) 3210 Applications", SIGCOMM 2008, August 2008. 3212 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 3213 Optimization (ALTO) Problem Statement", RFC 5693, 3214 October 2009. 3216 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 3217 Management of New Protocols and Protocol Extensions", 3218 RFC 5706, November 2009. 3220 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 3221 IPv4/IPv6 Translation", RFC 6144, April 2011. 3223 Appendix A. Acknowledgments 3225 Thank you to Jan Seedorf for contributions to the Security 3226 Considerations section. 3228 We would like to thank the following people whose input and 3229 involvement was indispensable in achieving this merged proposal: 3231 Obi Akonjang (DT Labs/TU Berlin), 3233 Saumitra M. Das (Qualcomm Inc.), 3234 Syon Ding (China Telecom), 3236 Doug Pasko (Verizon), 3238 Laird Popkin (Pando Networks), 3240 Satish Raghunath (Juniper Networks), 3242 Albert Tian (Ericsson/Redback), 3244 Yu-Shun Wang (Microsoft), 3246 David Zhang (PPLive), 3248 Yunfei Zhang (China Mobile). 3250 We would also like to thank the following additional people who were 3251 involved in the projects that contributed to this merged document: 3252 Alex Gerber (AT&T), Chris Griffiths (Comcast), Ramit Hora (Pando 3253 Networks), Arvind Krishnamurthy (University of Washington), Marty 3254 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 3255 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T), 3256 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 3257 Damien Saucez (UCL) Thomas Scholl (AT&T), Emilio Sepulveda 3258 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 3259 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 3260 (Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia 3261 Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University), 3262 Haiyong Xie (Yale University). 3264 Appendix B. Authors 3266 [[CmtAuthors: RFC Editor: Please move information in this section to 3267 the Authors' Addresses section at publication time.]] 3269 Stefano Previdi 3270 Cisco 3272 Email: sprevidi@cisco.com 3274 Stanislav Shalunov 3275 BitTorrent 3277 Email: shalunov@bittorrent.com 3278 Richard Woundy 3279 Comcast 3281 Richard_Woundy@cable.comcast.com 3283 Authors' Addresses 3285 Richard Alimi (editor) 3286 Google 3287 1600 Amphitheatre Parkway 3288 Mountain View CA 3289 USA 3291 Email: ralimi@google.com 3293 Reinaldo Penno (editor) 3294 Cisco Systems 3295 170 West Tasman Dr 3296 San Jose CA 3297 USA 3299 Email: repenno@cisco.com 3301 Y. Richard Yang (editor) 3302 Yale University 3303 51 Prospect St 3304 New Haven CT 3305 USA 3307 Email: yry@cs.yale.edu