idnits 2.17.1 draft-ietf-alto-protocol-12.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 945 has weird spacing: '...etaData meta...' == Line 951 has weird spacing: '... meta meta-...' == Line 953 has weird spacing: '... data the d...' == Line 1290 has weird spacing: '...NString uri;...' == Line 1291 has weird spacing: '...NString medi...' == (9 more instances...) -- The document date (July 11, 2012) is 4306 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 225, but not defined == Missing Reference: 'OPTIONAL' is mentioned on line 2140, but not defined == Missing Reference: 'InfoResourceDataType' is mentioned on line 946, but not defined == Missing Reference: 'PIDName' is mentioned on line 1645, but not defined == Missing Reference: 'EndpointProperty' is mentioned on line 2031, but not defined == Missing Reference: 'TypedEndpointAddr' is mentioned on line 2177, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.2008' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-08 == Outdated reference: A later version (-10) exists of draft-ietf-alto-server-discovery-03 Summary: 5 errors (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG R. Alimi, Ed. 3 Internet-Draft Google 4 Intended status: Standards Track R. Penno, Ed. 5 Expires: January 12, 2013 Cisco Systems 6 Y. Yang, Ed. 7 Yale University 8 July 11, 2012 10 ALTO Protocol 11 draft-ietf-alto-protocol-12.txt 13 Abstract 15 Networking applications today already have access to a great amount 16 of Inter-Provider network topology information. For example, views 17 of the Internet routing table are easily available at looking glass 18 servers and entirely practical to be downloaded by clients. What is 19 missing is knowledge of the underlying network topology from the ISP 20 or Content Provider (henceforth referred as Provider) point of view. 21 In other words, what a Provider prefers in terms of traffic 22 optimization -- and a way to distribute it. 24 The ALTO Service provides network information (e.g., basic network 25 location structure, preferences of network paths) with the goal of 26 modifying network resource consumption patterns while maintaining or 27 improving application performance. The basic information of ALTO is 28 based on abstract maps of a network. These maps provide a simplified 29 view, yet enough information about a network for applications to 30 effectively utilize them. Additional services are built on top the 31 maps. 33 This document describes a protocol implementing the ALTO Service. 34 Although the ALTO service would primarily be provided by the network 35 operator (e.g., an ISP), content providers and third parties could 36 also operate this service. Applications that could use this service 37 are those that have a choice in connection endpoints. Examples of 38 such applications are peer-to-peer (P2P) and content delivery 39 networks. 41 Requirements Language 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC 2119 [RFC2119]. 47 Status of this Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on January 12, 2013. 63 Copyright Notice 65 Copyright (c) 2012 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 1.1. Background and Problem Statement . . . . . . . . . . . . . 6 82 1.2. Design History and Merged Proposals . . . . . . . . . . . 6 83 1.3. Solution Benefits . . . . . . . . . . . . . . . . . . . . 7 84 1.3.1. Service Providers . . . . . . . . . . . . . . . . . . 7 85 1.3.2. Applications . . . . . . . . . . . . . . . . . . . . . 7 86 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 88 2.1.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . . 8 89 2.1.2. Endpoint Address . . . . . . . . . . . . . . . . . . . 8 90 2.1.3. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 8 91 2.1.4. Network Location . . . . . . . . . . . . . . . . . . . 8 92 2.1.5. ALTO Information . . . . . . . . . . . . . . . . . . . 8 93 2.1.6. ALTO Information Base . . . . . . . . . . . . . . . . 9 94 2.2. ALTO Service and Protocol Scope . . . . . . . . . . . . . 9 95 2.3. ALTO Information Reuse and Redistribution . . . . . . . . 10 96 3. Service Framework . . . . . . . . . . . . . . . . . . . . . . 11 97 3.1. ALTO Information Services . . . . . . . . . . . . . . . . 12 98 3.1.1. Map Service . . . . . . . . . . . . . . . . . . . . . 12 99 3.1.2. Map Filtering Service . . . . . . . . . . . . . . . . 12 100 3.1.3. Endpoint Property Service . . . . . . . . . . . . . . 12 101 3.1.4. Endpoint Cost Service . . . . . . . . . . . . . . . . 12 102 4. Network Map . . . . . . . . . . . . . . . . . . . . . . . . . 12 103 4.1. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 104 4.2. Endpoint Addresses . . . . . . . . . . . . . . . . . . . . 14 105 4.2.1. IP Addresses . . . . . . . . . . . . . . . . . . . . . 14 106 4.3. Example Network Map . . . . . . . . . . . . . . . . . . . 14 107 5. Cost Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 108 5.1. Cost Attributes . . . . . . . . . . . . . . . . . . . . . 16 109 5.1.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . 16 110 5.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 16 111 5.2. Cost Map Structure . . . . . . . . . . . . . . . . . . . . 17 112 5.3. Network Map and Cost Map Dependency . . . . . . . . . . . 18 113 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 18 114 6.1. Overall Design . . . . . . . . . . . . . . . . . . . . . . 18 115 6.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 19 116 6.3. Basic Operation . . . . . . . . . . . . . . . . . . . . . 19 117 6.3.1. Discovering Information Resources . . . . . . . . . . 19 118 6.3.2. Requesting Information Resources . . . . . . . . . . . 19 119 6.3.3. Response . . . . . . . . . . . . . . . . . . . . . . . 20 120 6.3.4. Client Behavior . . . . . . . . . . . . . . . . . . . 21 121 6.3.5. Authentication and Encryption . . . . . . . . . . . . 21 122 6.3.6. HTTP Cookies . . . . . . . . . . . . . . . . . . . . . 21 123 6.3.7. Parsing . . . . . . . . . . . . . . . . . . . . . . . 21 124 6.4. Information Resource . . . . . . . . . . . . . . . . . . . 21 125 6.4.1. Capabilities . . . . . . . . . . . . . . . . . . . . . 22 126 6.4.2. Input Parameters Media Type . . . . . . . . . . . . . 22 127 6.4.3. Media Type . . . . . . . . . . . . . . . . . . . . . . 22 128 6.4.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . 22 129 6.5. ALTO Errors . . . . . . . . . . . . . . . . . . . . . . . 23 130 6.5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 24 131 6.5.2. Resource Format . . . . . . . . . . . . . . . . . . . 24 132 6.5.3. Error Codes . . . . . . . . . . . . . . . . . . . . . 24 133 6.5.4. Overload Conditions and Server Unavailability . . . . 25 134 6.6. ALTO Types . . . . . . . . . . . . . . . . . . . . . . . . 25 135 6.6.1. PID Name . . . . . . . . . . . . . . . . . . . . . . . 26 136 6.6.2. Version Tag . . . . . . . . . . . . . . . . . . . . . 26 137 6.6.3. Endpoints . . . . . . . . . . . . . . . . . . . . . . 26 138 6.6.4. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 28 139 6.6.5. Cost Type . . . . . . . . . . . . . . . . . . . . . . 29 140 6.6.6. Endpoint Property . . . . . . . . . . . . . . . . . . 29 141 6.7. Information Resource Directory . . . . . . . . . . . . . . 29 142 6.7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 30 143 6.7.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . 30 144 6.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 31 145 6.7.4. Usage Considerations . . . . . . . . . . . . . . . . . 34 146 6.8. Information Resources . . . . . . . . . . . . . . . . . . 35 147 6.8.1. Map Service . . . . . . . . . . . . . . . . . . . . . 35 148 6.8.2. Map Filtering Service . . . . . . . . . . . . . . . . 40 149 6.8.3. Endpoint Property Service . . . . . . . . . . . . . . 46 150 6.8.4. Endpoint Cost Service . . . . . . . . . . . . . . . . 49 151 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 53 152 7.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 54 153 7.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 55 154 7.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 56 155 8. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 57 156 8.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 57 157 8.2. Hosts with Multiple Endpoint Addresses . . . . . . . . . . 58 158 8.3. Network Address Translation Considerations . . . . . . . . 58 159 8.4. Endpoint and Path Properties . . . . . . . . . . . . . . . 59 160 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 161 9.1. application/alto-* Media Types . . . . . . . . . . . . . . 59 162 9.2. ALTO Cost Type Registry . . . . . . . . . . . . . . . . . 61 163 9.3. ALTO Endpoint Property Registry . . . . . . . . . . . . . 62 164 9.4. ALTO Address Type Registry . . . . . . . . . . . . . . . . 63 165 10. Security Considerations . . . . . . . . . . . . . . . . . . . 64 166 10.1. Privacy Considerations for ISPs . . . . . . . . . . . . . 64 167 10.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 65 168 10.3. Authentication, Integrity Protection, and Encryption . . . 65 169 10.4. ALTO Information Redistribution . . . . . . . . . . . . . 66 170 10.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 66 171 10.6. ALTO Server Access Control . . . . . . . . . . . . . . . . 67 172 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67 173 11.1. Normative References . . . . . . . . . . . . . . . . . . . 67 174 11.2. Informative References . . . . . . . . . . . . . . . . . . 68 175 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 70 176 Appendix B. Authors . . . . . . . . . . . . . . . . . . . . . . . 71 177 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71 179 1. Introduction 181 1.1. Background and Problem Statement 183 Today, network information available to applications is mostly from 184 the view of endhosts. There is no clear mechanism to convey 185 information about the network infrastructure (e.g., preferences or 186 topological properties) to applications, forcing applications to make 187 approximations using data sources such as BGP Looking Glass or their 188 own measurements, which can be misleading or inaccurate. On the 189 other hand, modern network applications can be adaptive, with the 190 potential to become more network-efficient (e.g., reduce network 191 resource consumption) and achieve better application performance 192 (e.g., accelerated download rate), by leveraging better network- 193 provided information. 195 The ALTO Service provides a simple mechanism to convey network 196 information to applications. Its objective is to provide basic, 197 abstract but useful network information to applications. The 198 mechanism includes abstractions to achieve concise, flexible network 199 information expression. 201 The goal of this document is to specify a simple and unified protocol 202 that meets the ALTO requirements [I-D.ietf-alto-reqs] while providing 203 a migration path for Internet Service Providers (ISP), Content 204 Providers, and clients that have deployed protocols with similar 205 intentions (see Section 1.2). 207 The ALTO Protocol design uses a REST-ful design with the goal of 208 leveraging current HTTP [RFC2616] implementations and infrastructure. 209 The REST-ful design supports flexible deployment strategies and 210 provides extensibility. ALTO requests and responses are encoded with 211 JSON [RFC4627]. 213 1.2. Design History and Merged Proposals 215 The protocol specified here consists of contributions from 217 o P4P [I-D.p4p-framework], [P4P-SIGCOMM08], 218 [I-D.wang-alto-p4p-specification]; 220 o ALTO Info-Export [I-D.shalunov-alto-infoexport]; 222 o Query/Response [I-D.saumitra-alto-queryresponse], 223 [I-D.saumitra-alto-multi-ps]; 225 o ATTP [ATTP]; 226 o Proxidor [I-D.akonjang-alto-proxidor]. 228 See Appendix A for a list of people that have contributed 229 significantly to this effort and the projects and proposals listed 230 above. 232 1.3. Solution Benefits 234 At a high level, the ALTO Service allows a Service Provider (e.g., an 235 ISP) to publish information about network locations and costs between 236 them at configurable granularities. 238 The ALTO Service offers many benefits to both end-users (consumers of 239 the service) and Internet Service Providers (providers of the 240 service). 242 1.3.1. Service Providers 244 The ALTO Service enables Service Providers to influence the peer or 245 resource selection process in distributed applications in order to 246 increase locality of traffic, improve user-experience, amongst 247 others. It also helps ISPs to efficiently manage traffic that 248 traverses more expensive links such as transit and backup links, thus 249 allowing a better provisioning of the networking infrastructure. 251 1.3.2. Applications 253 Applications that use the ALTO Service can benefit in multiple ways. 254 For example, they may no longer need to infer topology information, 255 and some applications can reduce reliance on measuring path 256 performance metrics themselves. They can take advantage of the ISP's 257 knowledge to avoid bottlenecks and boost performance. 259 An example type of application is a Peer-to-Peer overlay where peer 260 selection can be improved by including ALTO information in the 261 selection process. 263 2. Architecture 265 Two key design objectives of the ALTO Protocol are simplicity and 266 extensibility. At the same time, it introduces additional techniques 267 to address potential scalability and privacy issues. This section 268 first introduces the terminology, and then defines the ALTO 269 architecture and the ALTO Protocol's place in the overall 270 architecture. 272 2.1. Terminology 274 We use the following terms defined in [RFC5693]: Application, Overlay 275 Network, Peer, Resource, Resource Identifier, Resource Provider, 276 Resource Consumer, Resource Directory, Transport Address, Host 277 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 278 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 279 Transit Traffic. 281 We also use the following additional terms: Endpoint Address, 282 Autonomous System Number (ASN), and Network Location. 284 2.1.1. Endpoint 286 An endpoint is an entity capable of communicating (sending and/or 287 receiving messages) on a network. 289 An Endpoint is typically either a Resource Provider or Resource 290 Consumer. 292 2.1.2. Endpoint Address 294 An Endpoint Address represents the communication address of an 295 endpoint. An Endpoint Address can be network-attachment based (IP 296 address) or network-attachment agnostic. Common forms of Endpoint 297 Addresses include IP address, MAC address, overlay ID, and phone 298 number. 300 Each Endpoint Address has an associated Address Type, which indicates 301 both its syntax and semantics. 303 2.1.3. ASN 305 An Autonomous System Number. 307 2.1.4. Network Location 309 Network Location is a generic term denoting a single endpoint or 310 group of endpoints. 312 2.1.5. ALTO Information 314 ALTO Information is a generic term referring to the network 315 information sent by an ALTO Server. 317 2.1.6. ALTO Information Base 319 Internal representation of the ALTO Information maintained by the 320 ALTO Server. Note that the structure of this internal representation 321 is not defined by this document. 323 2.2. ALTO Service and Protocol Scope 325 An ALTO Server conveys the network information from the perspective 326 of a network region; the ALTO Server presents its "my-Internet View" 327 of the network region. In particular, an ALTO Server defines network 328 Endpoints (and aggregations thereof) and generic costs amongst them 329 from the network region's own perspective. A network region in this 330 context can be an Autonomous System, an ISP, or perhaps a smaller 331 region or set of ISPs; the details depend on the ALTO deployment 332 scenario and ALTO service discovery mechanism. 334 To better understand the ALTO Service and the role of the ALTO 335 Protocol, we show in Figure 1 the overall ALTO system architecture. 336 In this architecture, an ALTO Server prepares ALTO Information; an 337 ALTO Client uses ALTO Service Discovery to identify an appropriate 338 ALTO Server; and the ALTO Client requests available ALTO Information 339 from the ALTO Server using the ALTO Protocol. 341 The ALTO Information provided by the ALTO Server can be updated 342 dynamically based on network conditions, or can be seen as a policy 343 which is updated at a larger time-scale. 345 More specifically, the ALTO Information provided by an ALTO Server 346 may be influenced (at the operator's discretion) by other systems. 347 The ALTO Server aggregates information from multiple systems to 348 provide an abstract, unified, useful network view to applications. 349 Examples of other systems include (but are not limited to) static 350 network configuration databases, dynamic network information, routing 351 protocols, provisioning policies, and interfaces to outside parties. 352 These components are shown in the figure for completeness but are 353 outside the scope of this specification. Recall that while ALTO may 354 convey dynamic network information, it is not intended to replace 355 near-real-time congestion protocols. 357 It may also be possible for ALTO Servers to exchange network 358 information with other ALTO Servers (either within the same 359 administrative domain or another administrative domain with the 360 consent of both parties) in order to adjust exported ALTO 361 Information. Such a protocol is also outside the scope of this 362 specification. 364 +-------------------------------------------------------------------+ 365 | Network Region | 366 | | 367 | +-----------+ | 368 | | Routing | | 369 | +--------------+ | Protocols | | 370 | | Provisioning | +-----------+ | 371 | | Policy | | | 372 | +--------------+\ | | 373 | \ | | 374 | \ | | 375 | +-----------+ \+---------+ +--------+ | 376 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 377 | |Network |.......| Server | -------------------- | Client | | 378 | |Information| +---------+ +--------+ | 379 | +-----------+ / / | 380 | / ALTO SD Query/Response / | 381 | / / | 382 | +----------+ +--------------+ | 383 | | External | | ALTO Service | | 384 | | Interface| | Discovery | | 385 | +----------+ +--------------+ | 386 | | | 387 +-------------------------------------------------------------------+ 388 | 389 +------------------+ 390 | Third Parties | 391 | | 392 | Content Providers| 393 +------------------+ 395 Figure 1: Basic ALTO Architecture. 397 2.3. ALTO Information Reuse and Redistribution 399 ALTO information may be useful to a large number of applications and 400 users. At the same time, distributing ALTO information must be 401 efficient and not become a bottleneck. 403 Beyond integration with existing HTTP caching infrastructure, ALTO 404 information may also be cached or redistributed using application- 405 dependent mechanisms, such as P2P DHTs or P2P file-sharing. This 406 document does not define particular mechanisms for such 407 redistribution. See [I-D.gu-alto-redistribution] for further 408 discussion. 410 Additional protocol mechanisms (e.g., expiration times and digital 411 signatures for returned ALTO information) are left for extension 412 documents. 414 If caching or redistribution is used, the response message may be 415 returned from another (possibly third-party) entity. 417 3. Service Framework 419 The ALTO Protocol uses a simple extensible framework to convey 420 network information. In the general framework, the ALTO protocol 421 will convey properties on both Network Locations and the paths 422 between Network Locations. 424 In this document, we focus on a particular Endpoint property to 425 denote the location of an endpoint, and provider-defined costs for 426 paths between pairs of Network Locations. 428 The ALTO Protocol is built on a common transport protocol, messaging 429 structure and encoding, and transaction model. The protocol is 430 subdivided into services of related functionality. The Map Service 431 provides the core ALTO information to clients. Other ALTO 432 Information services provide additional functionalities. There are 433 three such services defined in this document: the Map Filtering 434 Service, Endpoint Property Service, and Endpoint Cost Service. 435 Additional services may be defined in companion documents. 436 Functionalities offered in different services may overlap (e.g., the 437 Map Service and Map Filtering Service). 439 .-----------------------------------------. 440 | ALTO Information Services | 441 | .-----------. .----------. .----------. | 442 | | Map | | Endpoint | | Endpoint | | 443 | | Filtering | | Property | | Cost | | 444 | | Service | | Service | | Service | | 445 | `-----------' `----------' `----------' | 446 | .-------------------------------------. | 447 | | Map Service | | 448 | | .-------------. .--------------. | | 449 | | | Network Map | | Cost Map | | | 450 | | `-------------' `--------------' | | 451 | `-------------------------------------' | 452 `-----------------------------------------' 454 Figure 2: ALTO Service Framework 456 3.1. ALTO Information Services 458 Multiple, distinct services are defined to allow ALTO Clients to 459 query ALTO Information from an ALTO Server. The ALTO Server 460 internally maintains an ALTO Information Base that encodes the 461 network provider's preferences. The ALTO Information Base encodes 462 the Network Locations defined by the ALTO Server (and their 463 corresponding properties), as well as the provider-defined costs 464 between pairs of Network Locations. 466 3.1.1. Map Service 468 The Map Service provides batch information to ALTO Clients in the 469 form of Network Map and Cost Map. The Network Map (See Section 4) 470 provides the full set of Network Location groupings defined by the 471 ALTO Server and the Endpoints contained with each grouping. The Cost 472 Map (see Section 5) provides costs between the defined groupings. 474 These two maps can be thought of (and implemented as) as simple files 475 with appropriate encoding provided by the ALTO Server. 477 3.1.2. Map Filtering Service 479 Resource constrained ALTO Clients may benefit from query results 480 being filtered at the ALTO Server. This avoids an ALTO Client 481 spending network bandwidth or CPU collecting results and performing 482 client-side filtering. The Map Filtering Service allows ALTO Clients 483 to query for the ALTO Server Network Map and Cost Map based on 484 additional parameters. 486 3.1.3. Endpoint Property Service 488 This service allows ALTO Clients to look up properties for individual 489 Endpoints. An example endpoint property is its Network Location (its 490 grouping defined by the ALTO Server) or connectivity type (e.g., 491 ADSL, Cable, or FTTH). 493 3.1.4. Endpoint Cost Service 495 Some ALTO Clients may also benefit from querying for costs and 496 rankings based on Endpoints. The Endpoint Cost Service allows an 497 ALTO Server to return either numerical costs or ordinal costs 498 (rankings) directly amongst Endpoints. 500 4. Network Map 502 The Network Location Endpoint Property allows an ALTO Server to group 503 endpoints together to indicate their proximity. The resulting set of 504 groupings is called the ALTO Network Map. 506 In reality, many endpoints are very close to one another in terms of 507 network connectivity, for example, endpoints on the same site of an 508 enterprise. By treating a group of endpoints together as a single 509 entity in ALTO, we can achieve much greater scalability without 510 losing critical information. 512 The definition of proximity varies depending on the granularity of 513 the ALTO information configured by the provider. In one deployment, 514 endpoints on the same subnet may be considered close; while in 515 another deployment, endpoints connected to the same PoP may be 516 considered close. 518 As used in this document, the Network Map refers to the syntax and 519 semantics of the information distributed by the ALTO Server. This 520 document does not discuss the internal representation of this data 521 structure within the ALTO Server. 523 4.1. PID 525 Each group of Endpoints is identified by a provider-defined Network 526 Location identifier called a PID. A PID is a US-ASCII string of type 527 PIDName (see Section 6.6.1) and its associated set of Endpoint 528 Addresses. There can be many different ways of grouping the 529 endpoints and assigning PIDs. 531 A PID is an identifier that provides an indirect and network-agnostic 532 way to specify an aggregation of network endpoints that may be 533 treated similarly, based on network topology, type, or other 534 properties. For example, a PID may be defined by the ALTO service 535 provider to denote a subnet, a set of subnets, a metropolitan area, a 536 PoP, an autonomous system, or a set of autonomous systems. 537 Aggregation of endpoints into PIDs can indicate proximity and can 538 improve scalability. In particular, network preferences (costs) may 539 be specified between PIDs, allowing cost information to be more 540 compactly represented and updated at a faster time scale than the 541 network aggregations themselves. 543 Using PIDs, the Network Map may also be used to communicate simple 544 preferences with only minimal information from the Cost Map. For 545 example, an ISP may prefer that endpoints associated with the same 546 PoP (Point-of-Presence) in a P2P application communicate locally 547 instead of communicating with endpoints in other PoPs. The ISP may 548 aggregate endhosts within a PoP into a single PID in the Network Map. 549 The Cost Map may be encoded to indicate that Network Locations within 550 the same PID are preferred; for example, cost(PID_i, PID_i) == c* and 551 cost(PID_i, PID_j) > c* for i != j. Section 5 provides further 552 details about Cost Map structure. 554 4.2. Endpoint Addresses 556 Communicating endpoints may have many types of addresses, such as IP 557 addresses, MAC addresses, or overlay IDs. The current specification 558 only considers IP addresses. 560 4.2.1. IP Addresses 562 The endpoints aggregated into a PID are denoted by a list of IP 563 prefixes. When either an ALTO Client or ALTO Server needs to 564 determine which PID in a Network Map contains a particular IP 565 address, longest-prefix matching MUST be used. 567 A Network Map MUST define a PID for each possible address in the IP 568 address space for all of the address types contained in the map. A 569 RECOMMENDED way to satisfy this property is to define a PID with the 570 shortest enclosing prefix of the addresses provided in the map. For 571 a map with full IPv4 reachability, this would mean including the 572 0.0.0.0/0 prefix in a PID; for full IPv6 reachability, this would be 573 the ::/0 prefix. 575 Each endpoint MUST map into exactly one PID. Since longest-prefix 576 matching is used to map an endpoint to a PID, this can be 577 accomplished by ensuring that no two PIDs contain an identical IP 578 prefix. 580 4.3. Example Network Map 582 Figure 3 illustrates an example Network Map. PIDs are used to 583 identify network-agnostic aggregations. 585 .-----------------------------------------------------------. 586 | ALTO Network Map | 587 | | 588 | .-----------------------------------. .---------------. | 589 | | NetLoc: PID-1 | | NetLoc: PID-2 | | 590 | | .------------------------------. | | ... | | 591 | | | 192.0.2.0/24 | | `---------------` | 592 | | | .--------------------------. | | | 593 | | | | Endpoint: 192.0.2.34 | | | .---------------. | 594 | | | `--------------------------` | | | NetLoc: PID-3 | | 595 | | `------------------------------` | | ... | | 596 | | .------------------------------. | `---------------` | 597 | | | 198.51.100.0/25 | | | 598 | | | .--------------------------. | | .---------------. | 599 | | | | Endpoint: 198.51.100.100 | | | | NetLoc: PID-4 | | 600 | | | `--------------------------` | | | ... | | 601 | | `------------------------------` | `---------------` | 602 | `-----------------------------------` | 603 | | 604 `-----------------------------------------------------------` 606 Figure 3: Example Network Map 608 5. Cost Map 610 An ALTO Server indicates preferences amongst network locations in the 611 form of Path Costs. Path Costs are generic costs and can be 612 internally computed by a network provider according to its own needs. 614 An ALTO Cost Map defines Path Costs pairwise amongst sets of source 615 and destination Network Locations. Each Path Cost is the end-to-end 616 cost from the source to the destination. 618 Each application may independently determine how the Resource 619 Consumer and Resource Provider are designated as the source or 620 destination, and hence how to utilize the Path Cost provided by ALTO. 621 For example, if the cost is expected to be correlated with 622 throughput, a typical application concerned with bulk data retrieval 623 may use the Resource Provider as the source, and Resource Consumer as 624 the destination. 626 One advantage of separating ALTO information into a Network Map and a 627 Cost Map is that the two components can be updated at different time 628 scales. For example, Network Maps may be stable for a longer time 629 while Cost Maps may be updated to reflect dynamic network conditions. 631 As used in this document, the Cost Map refers to the syntax and 632 semantics of the information distributed by the ALTO Server. This 633 document does not discuss the internal representation of this data 634 structure within the ALTO Server. 636 5.1. Cost Attributes 638 Path Costs have attributes: 640 o Type: identifies what the costs represent; 642 o Mode: identifies how the costs should be interpreted. 644 Certain queries for Cost Maps allow the ALTO Client to indicate the 645 desired Type and Mode. 647 5.1.1. Cost Type 649 The Type attribute indicates what the cost represents. For example, 650 an ALTO Server could define costs representing air-miles, hop-counts, 651 or generic routing costs. 653 Cost types are indicated in protocol messages as strings. 655 5.1.1.1. Cost Type: routingcost 657 An ALTO Server MUST define the 'routingcost' Cost Type. 659 This Cost Type conveys a generic measure for the cost of routing 660 traffic from a source to a destination. Lower values indicate a 661 higher preference for traffic to be sent from a source to a 662 destination. 664 Note that an ISP may internally compute routing cost using any method 665 it chooses (e.g., air-miles or hop-count) as long as it conforms to 666 these semantics. 668 5.1.2. Cost Mode 670 The Mode attribute indicates how costs should be interpreted. 671 Specifically, the Mode attribute indicates whether returned costs 672 should be interpreted as numerical values or ordinal rankings. 674 It is important to communicate such information to ALTO Clients, as 675 certain operations may not be valid on certain costs returned by an 676 ALTO Server. For example, it is possible for an ALTO Server to 677 return a set of IP addresses with costs indicating a ranking of the 678 IP addresses. Arithmetic operations that would make sense for 679 numerical values, do not make sense for ordinal rankings. ALTO 680 Clients may handle such costs differently. 682 Cost Modes are indicated in protocol messages as strings. 684 An ALTO Server MUST support at least one of 'numerical' and 'ordinal' 685 costs. ALTO Clients SHOULD be cognizant of operations when a desired 686 cost mode is not supported. For example, an ALTO Client desiring 687 numerical costs may adjust behavior if only the ordinal Cost Mode is 688 available. Alternatively, an ALTO Client desiring ordinal costs may 689 construct ordinal costs given numerical values if only the numerical 690 Cost Mode is available. 692 5.1.2.1. Cost Mode: numerical 694 This Cost Mode is indicated by the string 'numerical'. This mode 695 indicates that it is safe to perform numerical operations (e.g. 696 normalization or computing ratios for weighted load-balancing) on the 697 returned costs. The values are floating-point numbers. 699 5.1.2.2. Cost Mode: ordinal 701 This Cost Mode is indicated by the string 'ordinal'. This mode 702 indicates that the costs values in a Cost Map are a ranking (relative 703 to all other values in the Cost Map), with lower values indicating a 704 higher preference. The values are non-negative integers. Ordinal 705 cost values in a Cost Map need not be unique nor contiguous. In 706 particular, it is possible that two entries in a map have an 707 identical rank (ordinal cost value). This document does not specify 708 any behavior by an ALTO Client in this case; an ALTO Client may 709 decide to break ties by random selection, other application 710 knowledge, or some other means. 712 It is important to note that the values in the Cost Map provided with 713 the ordinal Cost Mode are not necessarily the actual cost known to 714 the ALTO Server. 716 5.2. Cost Map Structure 718 A query for a Cost Map either explicitly or implicitly includes a 719 list of Source Network Locations and a list of Destination Network 720 Locations. (Recall that a Network Location can be an endpoint 721 address or a PID.) 723 Specifically, assume that a query has a list of multiple Source 724 Network Locations, say [Src_1, Src_2, ..., Src_m], and a list of 725 multiple Destination Network Locations, say [Dst_1, Dst_2, ..., 726 Dst_n]. 728 The ALTO Server will return the Path Cost for each communicating pair 729 (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., Src_m -> Dst_1, ..., 730 Src_m -> Dst_n). If the ALTO Server does not define a Path Cost for 731 a particular pair, it may be omitted. We refer to this structure as 732 a Cost Map. 734 If the Cost Mode is 'ordinal', the Path Cost of each communicating 735 pair is relative to the m*n entries. 737 5.3. Network Map and Cost Map Dependency 739 If a Cost Map contains PIDs in the list of Source Network Locations 740 or the list of Destination Network Locations, the Path Costs are 741 generated based on a particular Network Map (which defines the PIDs). 742 Version Tags are introduced to ensure that ALTO Clients are able to 743 use consistent information even though the information is provided in 744 two maps. 746 A Version Tag is an opaque string associated with a Network Map 747 maintained by the ALTO Server. When the Network Map changes, the 748 Version Tag MUST also be changed. (Thus, the Version Tag is defined 749 similarly to HTTP's Entity Tags; see Section 3.11 of [RFC2616].) 750 Possibilities for generating a Version Tag include the last-modified 751 timestamp for the Network Map, or a hash of its contents. 753 A Network Map distributed by the ALTO Server includes its Version 754 Tag. A Cost Map referring to PIDs also includes the Version Tag of 755 the Network Map on which it is based. 757 6. Protocol Specification 759 This section first specifies general client and server processing, 760 followed by a detailed specification for each ALTO Information 761 Resource. 763 6.1. Overall Design 765 The ALTO Protocol uses a REST-ful design. There are two primary 766 components to this design: 768 o Information Resources: Each service provides network information 769 as a set of resources, which are distinguished by their media 770 types [RFC2046]. An ALTO Client may construct an HTTP request for 771 a particular resource (including any parameters, if necessary), 772 and an ALTO Server returns the requested resource in an HTTP 773 response. 775 o Information Resource Directory: An ALTO Server provides to ALTO 776 Clients a list of available resources and the URI at which each is 777 provided. This document refers to this list as the Information 778 Resource Directory. This directory is the single entry point to 779 an ALTO Service. ALTO Clients consult the directory to determine 780 the services provided by an ALTO Server. 782 6.2. Notation 784 This document uses an adaptation of the C-style struct notation to 785 define the required and optional members of JSON objects. Unless 786 explicitly noted, each member of a struct is REQUIRED. 788 The types 'JSONString', 'JSONNumber', 'JSONBool' indicate the JSON 789 string, number, and boolean types, respectively. 'JSONValue' 790 indicates a JSON value, as specified in Section 2.1 of [RFC4627]. 792 Note that no standard, machine-readable interface definition or 793 schema is provided. Extension documents may document these as 794 necessary. 796 6.3. Basic Operation 798 The ALTO Protocol employs standard HTTP [RFC2616]. It is used for 799 discovering available Information Resources at an ALTO Server and 800 retrieving Information Resources. ALTO Clients and ALTO Servers use 801 HTTP requests and responses carrying ALTO-specific content with 802 encoding as specified in this document, and MUST be compliant with 803 [RFC2616]. 805 6.3.1. Discovering Information Resources 807 To discover available resources, an ALTO Client requests the 808 Information Resource Directory, which an ALTO Server provides at the 809 URI found by the ALTO Discovery protocol. 811 Informally, an Information Resource Directory enumerates URIs at 812 which an ALTO Server offers Information Resources. Each entry in the 813 directory indicates a URI at which an ALTO Server accepts requests, 814 and returns either the requested Information Resource or an 815 Information Resource Directory that references additional Information 816 Resources. See Section 6.7 for a detailed specification. 818 6.3.2. Requesting Information Resources 820 Through the retrieved Information Resource Directories, an ALTO 821 Client can determine whether an ALTO Server supports the desired 822 Information Resource, and if it is supported, the URI at which it is 823 available. 825 Where possible, the ALTO Protocol uses the HTTP GET method to request 826 resources. However, some ALTO services provide Information Resources 827 that are the function of one or more input parameters. Input 828 parameters are encoded in the HTTP request's entity body, and the 829 request uses the HTTP POST method. 831 It is possible for an ALTO Server to leverage caching HTTP 832 intermediaries for responses to both GET and POST requests by 833 including explicit freshness information (see Section 14 of 834 [RFC2616]). Caching of POST requests is not widely implemented by 835 HTTP intermediaries, however an alternative approach is for an ALTO 836 Server, in response to POST requests, to return an HTTP 303 status 837 code ("See Other") indicating to the ALTO Client that the resulting 838 Information Resource is available via a GET request to an alternate 839 URL. HTTP intermediaries that do not support caching of POST 840 requests could then cache the response to the GET request from the 841 ALTO Client following the alternate URL in the 303 response if the 842 response to the subsequent GET request contains explicit freshness 843 information. 845 When requesting an ALTO Information Resource that requires input 846 parameters specified in a HTTP POST request, an ALTO Client MUST set 847 the Content-Type HTTP header to the media type corresponding to the 848 format of the supplied input parameters. 850 6.3.3. Response 852 Upon receiving a request, an ALTO server either returns the requested 853 resource, provides the ALTO Client an Information Resource Directory 854 indicating how to reach the desired resource, or returns an error. 856 The type of response MUST be indicated by the media type attached to 857 the response (the Content-Type HTTP header). If an ALTO Client 858 receives an Information Resource Directory, it can consult the 859 received directory to determine if any of the offered URIs contain 860 the desired Information Resource. 862 The generic encoding for an Information Resource is specified in 863 Section 6.4. 865 Errors are indicated via either ALTO-level error codes, or via HTTP 866 status codes; see Section 6.5. 868 6.3.4. Client Behavior 870 6.3.4.1. Using Information Resources 872 This specification does not indicate any required actions taken by 873 ALTO Clients upon successfully receiving an Information Resource from 874 an ALTO Server. Although ALTO Clients are suggested to interpret the 875 received ALTO Information and adapt application behavior, ALTO 876 Clients are not required to do so. 878 6.3.4.2. Error Conditions 880 If an ALTO Client does not successfully receive a desired Information 881 Resource from a particular ALTO Server, it can either choose another 882 server (if one is available) or fall back to a default behavior 883 (e.g., perform peer selection without the use of ALTO information). 884 An ALTO Client may also retry the request at a later time. 886 6.3.5. Authentication and Encryption 888 An ALTO Server MAY support SSL/TLS to implement server and/or client 889 authentication, encryption, and/or integrity protection. See 890 [RFC6125] for considerations regarding verification of server 891 identity. 893 6.3.6. HTTP Cookies 895 If cookies are included in an HTTP request received by an ALTO 896 Server, they MUST be ignored. 898 6.3.7. Parsing 900 This document only details object members used by this specification. 901 Extensions may include additional members within JSON objects defined 902 in this document. ALTO implementations MUST ignore such unknown 903 fields when processing ALTO messages. 905 6.4. Information Resource 907 An Information Resource is an HTTP entity body received by an ALTO 908 Server that encodes the ALTO Information desired by an ALTO Client. 910 This document specifies multiple Information Resources that can be 911 provided by an ALTO Server. Each Information Resource has certain 912 attributes associated with it, indicating its data format, the input 913 parameters it supports, and format of the input parameters. 915 6.4.1. Capabilities 917 An ALTO Server may advertise to an ALTO Client that it supports 918 certain capabilities in requests for an Information Resource. For 919 example, if an ALTO Server allows requests for a Cost Map to include 920 constraints, it may advertise that it supports this capability. 922 6.4.2. Input Parameters Media Type 924 An ALTO Server may allow an ALTO Client to supply input parameters 925 when requesting certain Information Resources. The format of the 926 input parameters (i.e., as contained in the entity body of the HTTP 927 POST request) is indicated by the media type [RFC2046]. 929 6.4.3. Media Type 931 The media type [RFC2046] uniquely indicates the data format of the 932 Information Resource as returned by an ALTO Server in the HTTP entity 933 body. 935 6.4.4. Encoding 937 Though each Information Resource may have a distinct syntax, they are 938 designed to have a common structure containing generic ALTO-layer 939 metadata about the resource, as well as data itself. 941 An Information Resource has a single top-level JSON object of type 942 InfoResourceEntity: 944 object { 945 InfoResourceMetaData meta; [OPTIONAL] 946 [InfoResourceDataType] data; 947 } InfoResourceEntity; 949 with members: 951 meta meta-information pertaining to the Information Resource 953 data the data contained in the Information Resource 955 6.4.4.1. Meta Information 957 Meta information is encoded as a JSON object. This document does not 958 specify any members, but it is defined here as a standard container 959 for extensibility. Specifically, InfoResourceMetaData is defined as: 961 object { 962 } InfoResourceMetaData; 964 6.4.4.2. ALTO Information 966 The "data" member of the InfoResourceEntity encodes the resource- 967 specific data; the structure of this member is detailed later in this 968 section for each particular Information Resource. 970 6.4.4.3. Example 972 The following is an example of the encoding for an Information 973 Resource: 975 HTTP/1.1 200 OK 976 Content-Length: 40 977 Content-Type: application/alto-costmap+json 979 { 980 "meta" : {}, 981 "data" : { 982 ... 983 } 984 } 986 6.5. ALTO Errors 988 If there is an error processing a request, an ALTO Server SHOULD 989 return additional ALTO-layer information, if it is available, in the 990 form of an ALTO Error Resource encoded in the HTTP response's entity 991 body. 993 If no ALTO-layer information is available, an ALTO Server may omit an 994 ALTO Error resource from the response. An appropriate HTTP status 995 code MUST be set. 997 It is important to note that the HTTP Status Code and ALTO Error Code 998 have distinct roles. An ALTO Error Code provides detailed 999 information about why a particular request for an ALTO Resource was 1000 not successful. The HTTP status code indicates to HTTP processing 1001 elements (e.g., intermediaries and clients) how the response should 1002 be treated. 1004 6.5.1. Media Type 1006 The media type for an ALTO Error Resource is "application/ 1007 alto-error+json". 1009 6.5.2. Resource Format 1011 An ALTO Error Resource has the format: 1013 object { 1014 JSONString code; 1015 } ErrorResourceEntity; 1017 where: 1019 code An ALTO Error Code defined in Table 1 1021 6.5.3. Error Codes 1023 This document defines ALTO Error Codes to support the error 1024 conditions needed for purposes of this document. Additional status 1025 codes may be defined in companion or extension documents. 1027 The HTTP status codes corresponding to each ALTO Error Code are 1028 defined to provide correct behavior with HTTP intermediaries and 1029 clients. When an ALTO Server returns a particular ALTO Error Code, 1030 it MUST indicate one of the corresponding HTTP status codes in 1031 Table 1 in the HTTP response. 1033 If multiple errors are present in a single request (e.g., a request 1034 uses a JSONString when a JSONInteger is expected and a required field 1035 is missing), then the ALTO Server MUST return exactly one of the 1036 detected errors. However, the reported error is implementation 1037 defined, since specifying a particular order for message processing 1038 encroaches needlessly on implementation technique. 1040 +-------------------------+-------------+---------------------------+ 1041 | ALTO Error Code | HTTP Status | Description | 1042 | | Code(s) | | 1043 +-------------------------+-------------+---------------------------+ 1044 | E_SYNTAX | 400 | Parsing error in request | 1045 | | | (including identifiers) | 1046 | | | | 1047 | E_JSON_FIELD_MISSING | 400 | Required field missing | 1048 | | | | 1049 | E_JSON_VALUE_TYPE | 400 | JSON Value of unexpected | 1050 | | | type | 1051 | | | | 1052 | E_INVALID_COST_MODE | 400 | Invalid cost mode | 1053 | | | | 1054 | E_INVALID_COST_TYPE | 400 | Invalid cost type | 1055 | | | | 1056 | E_INVALID_PROPERTY_TYPE | 400 | Invalid property type | 1057 +-------------------------+-------------+---------------------------+ 1059 Table 1: Defined ALTO Error Codes 1061 6.5.4. Overload Conditions and Server Unavailability 1063 If an ALTO Server detects that it cannot handle a request from an 1064 ALTO Client due to excessive load, technical problems, or system 1065 maintenance, it SHOULD do one of the following: 1067 o Return an HTTP 503 ("Service Unavailable") status code to the ALTO 1068 Client. As indicated by [RFC2616], a the Retry-After HTTP header 1069 may be used to indicate when the ALTO Client should retry the 1070 request. 1072 o Return an HTTP 307 ("Temporary Redirect") status code indicating 1073 an alternate ALTO Server that may be able to satisfy the request. 1075 The ALTO Server MAY also terminate the connection with the ALTO 1076 Client. 1078 The particular policy applied by an ALTO Server to determine that it 1079 cannot service a request is outside of the scope of this document. 1081 6.6. ALTO Types 1083 This section details the format for particular data values used in 1084 the ALTO Protocol. 1086 6.6.1. PID Name 1088 A PID Name is encoded as a US-ASCII string. The string MUST be no 1089 more than 64 characters, and MUST NOT contain any ASCII character 1090 below 0x21 or above 0x7E or the '.' separator (0x2E). The '.' 1091 separator is reserved for future use and MUST NOT be used unless 1092 specifically indicated by a companion or extension document. 1094 The type 'PIDName' is used in this document to indicate a string of 1095 this format. 1097 6.6.2. Version Tag 1099 A Version Tag is encoded as a US-ASCII string. The string MUST be no 1100 more than 64 characters, and MUST NOT contain any ASCII character 1101 below 0x21 or above 0x7E. 1103 The type 'VersionTag' is used in this document to indicate a string 1104 of this type. 1106 6.6.3. Endpoints 1108 This section defines formats used to encode addresses for Endpoints. 1109 In a case that multiple textual representations encode the same 1110 Endpoint address or prefix (within the guidelines outlined in this 1111 document), the ALTO Protocol does not require ALTO Clients or ALTO 1112 Servers to use a particular textual representation, nor does it 1113 require that ALTO Servers reply to requests using the same textual 1114 representation used by requesting ALTO Clients. ALTO Clients must be 1115 cognizant of this. 1117 6.6.3.1. Address Type 1119 Address Types are encoded as US-ASCII strings consisting of only 1120 alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, and 0x61- 1121 0x7A). This document defines the address type 'ipv4' to refer to 1122 IPv4 addresses, and 'ipv6' to refer to IPv6 addresses. All Address 1123 Type identifiers appearing in an HTTP request or response with an 1124 'application/alto-*' media type MUST be registered in the ALTO 1125 Address Type registry Section 9.4. 1127 The type 'AddressType' is used in this document to indicate a string 1128 of this format. 1130 6.6.3.2. Endpoint Address 1132 Endpoint Addresses are encoded as US-ASCII strings. The exact 1133 characters and format depend on the type of endpoint address. 1135 The type 'EndpointAddr' is used in this document to indicate a string 1136 of this format. 1138 6.6.3.2.1. IPv4 1140 IPv4 Endpoint Addresses are encoded as specified by the 'IPv4address' 1141 rule in Section 3.2.2 of [RFC3986]. 1143 6.6.3.2.2. IPv6 1145 IPv6 Endpoint Addresses are encoded as specified in Section 4 of 1146 [RFC5952]. 1148 6.6.3.2.3. Typed Endpoint Addresses 1150 When an Endpoint Address is used, an ALTO implementation must be able 1151 to determine its type. For this purpose, the ALTO Protocol allows 1152 endpoint addresses to also explicitly indicate their type. 1154 Typed Endpoint Addresses are encoded as US-ASCII strings of the 1155 format 'AddressType:EndpointAddr' (with the ':' character as a 1156 separator). The type 'TypedEndpointAddr' is used to indicate a 1157 string of this format. 1159 6.6.3.3. Endpoint Prefixes 1161 For efficiency, it is useful to denote a set of Endpoint Addresses 1162 using a special notation (if one exists). This specification makes 1163 use of the prefix notations for both IPv4 and IPv6 for this purpose. 1165 Endpoint Prefixes are encoded as US-ASCII strings. The exact 1166 characters and format depend on the type of endpoint address. 1168 The type 'EndpointPrefix' is used in this document to indicate a 1169 string of this format. 1171 6.6.3.3.1. IPv4 1173 IPv4 Endpoint Prefixes are encoded as specified in Section 3.1 of 1174 [RFC4632]. 1176 6.6.3.3.2. IPv6 1178 IPv6 Endpoint Prefixes are encoded as specified in Section 7 of 1179 [RFC5952]. 1181 6.6.3.4. Endpoint Address Group 1183 The ALTO Protocol includes messages that specify potentially large 1184 sets of endpoint addresses. Endpoint Address Groups provide a more 1185 efficient way to encode such sets, even when the set contains 1186 endpoint addresses of different types. 1188 An Endpoint Address Group is defined as: 1190 object { 1191 EndpointPrefix [AddressType]<0..*>; 1192 ... 1193 } EndpointAddrGroup; 1195 In particular, an Endpoint Address Group is a JSON object with the 1196 name of each member being the string corresponding to the address 1197 type, and the member's corresponding value being a list of prefixes 1198 of addresses of that type. 1200 The following is an example with both IPv4 and IPv6 endpoint 1201 addresses: 1203 { 1204 "ipv4": [ 1205 "192.0.2.0/24", 1206 "198.51.100.0/25" 1207 ], 1208 "ipv6": [ 1209 "2001:db8:0:1::/64", 1210 "2001:db8:0:2::/64" 1211 ] 1212 } 1214 6.6.4. Cost Mode 1216 A Cost Mode is encoded as a US-ASCII string. The string MUST either 1217 have the value 'numerical' or 'ordinal'. 1219 The type 'CostMode' is used in this document to indicate a string of 1220 this format. 1222 6.6.5. Cost Type 1224 A Cost Type is encoded as a US-ASCII string. The string MUST be no 1225 more than 32 characters, and MUST NOT contain characters other than 1226 alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, and 0x61- 1227 0x7A), the hyphen ('-', code point 0x2D), or the colon (':', code 1228 point 0x3A). 1230 Identifiers prefixed with 'priv:' are reserved for Private Use 1231 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for 1232 Experimental use. All other identifiers appearing in an HTTP request 1233 or response with an 'application/alto-*' media type MUST be 1234 registered in the ALTO Cost Types registry Section 9.2. 1236 The type 'CostType' is used in this document to indicate a string of 1237 this format. 1239 6.6.6. Endpoint Property 1241 An Endpoint Property is encoded as a US-ASCII string. The string 1242 MUST be no more than 32 characters, and MUST NOT contain characters 1243 other than alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, 1244 and 0x61-0x7A), the hyphen ('-', code point 0x2D), or the colon (':', 1245 code point 0x3A). 1247 Identifiers prefixed with 'priv:' are reserved for Private Use 1248 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for 1249 Experimental use. All other identifiers appearing in an HTTP request 1250 or response with an 'application/alto-*' media type MUST be 1251 registered in the ALTO Endpoint Property registry Section 9.3. 1253 The type 'EndpointProperty' is used in this document to indicate a 1254 string of this format. 1256 6.7. Information Resource Directory 1258 An Information Resource Directory indicates to ALTO Clients which 1259 Information Resources are made available by an ALTO Server. 1261 Since resource selection happens after consumption of the Information 1262 Resource Directory, the format of the Information Resource Directory 1263 is designed to be simple with the intention of future ALTO Protocol 1264 versions maintaining backwards compatibility. Future extensions or 1265 versions of the ALTO Protocol SHOULD be accomplished by extending 1266 existing media types or adding new media types, but retaining the 1267 same format for the Information Resource Directory. 1269 An ALTO Server MUST make an Information Resource Directory available 1270 via the HTTP GET method to a URI discoverable by an ALTO Client. 1271 Discovery of this URI is out of scope of this document, but could be 1272 accomplished by manual configuration or by returning the URI of an 1273 Information Resource Directory from the ALTO Discovery Protocol 1274 [I-D.ietf-alto-server-discovery]. 1276 6.7.1. Media Type 1278 The media type is "application/alto-directory+json". 1280 6.7.2. Encoding 1282 An Information Resource Directory is a JSON object of type 1283 InfoResourceDirectory: 1285 object { 1286 ... 1287 } Capabilities; 1289 object { 1290 JSONString uri; 1291 JSONString media-types<1..*>; 1292 JSONString accepts<0..*>; [OPTIONAL] 1293 Capabilities capabilities; [OPTIONAL] 1294 } ResourceEntry; 1296 object { 1297 ResourceEntry resources<0..*>; 1298 } InfoResourceDirectory; 1300 where the "resources" array indicates a list of Information Resources 1301 provided by an ALTO Server. Note that the list of available 1302 resources is enclosed in a JSON object for extensibility; future 1303 protocol versions may specify additional members in the 1304 InfoResourceDirectory object. 1306 Any URI endpoint indicated in an Information Resource Directory MAY 1307 provide a response to an OPTIONS request that is in the format of an 1308 Information Resource Directory response. This provides ALTO Clients 1309 a means to discover resources and capabilities offered by that URI 1310 endpoint. ALTO Servers that reply with an HTTP 300 status code 1311 ("Multiple Choices") SHOULD use the Information Resource Directory 1312 format in the reply. 1314 Each entry in the directory specifies: 1316 uri A URI at which the ALTO Server provides one or more Information 1317 Resources, or an Information Resource Directory indicating 1318 additional Information Resources. 1320 media-types The list of all media types of Information Resources 1321 (see Section 6.4.3) available via GET or POST requests to the 1322 corresponding URI or URIs discoverable via the URI. 1324 accepts The list of all media types of input parameters (see 1325 Section 6.4.2) accepted by POST requests to the corresponding URI 1326 or URIs discoverable via the URI. If this member is not present, 1327 it MUST be assumed to be an empty array. 1329 capabilities A JSON Object enumerating capabilities of an ALTO 1330 Server in providing the Information Resource at the corresponding 1331 URI and Information Resources discoverable via the URI. If this 1332 member is not present, it MUST be assumed to be an empty object. 1333 If a capability for one of the offered Information Resources is 1334 not explicitly listed here, an ALTO Client may either issue an 1335 OPTIONS HTTP request to the corresponding URI to determine if the 1336 capability is supported, or assume its default value documented in 1337 this specification or an extension document describing the 1338 capability. 1340 If an entry has an empty list for "accepts", then the corresponding 1341 URI MUST support GET requests. If an entry has a non-empty list for 1342 "accepts", then the corresponding URI MUST support POST requests. If 1343 an ALTO Server wishes to support both GET and POST on a single URI, 1344 it MUST specify two entries in the Information Resource Directory. 1346 6.7.3. Example 1348 The following is an example Information Resource Directory returned 1349 by an ALTO Server. In this example, the ALTO Server provides 1350 additional Network and Cost Maps via a separate subdomain, 1351 "custom.alto.example.com". The maps available via this subdomain are 1352 Filtered Network and Cost Maps as well as pre-generated maps for the 1353 "hopcount" and "routingcost" Cost Types in the "ordinal" Cost Mode. 1355 An ALTO Client can discover the maps available by 1356 "custom.alto.example.com" by successfully performing an OPTIONS 1357 request to "http://custom.alto.example.com/maps". 1359 In this example, the ALTO server provides the Endpoint Cost Service 1360 for Cost Types 'routingcost' and 'hopcount', each available for both 1361 'numerical' and 'ordinal' mode". 1363 GET /directory HTTP/1.1 1364 Host: alto.example.com 1365 Accept: application/alto-directory+json,application/alto-error+json 1367 HTTP/1.1 200 OK 1368 Content-Length: 1472 1369 Content-Type: application/alto-directory+json 1371 { 1372 "resources" : [ 1373 { 1374 "uri" : "http://alto.example.com/networkmap", 1375 "media-types" : [ "application/alto-networkmap+json" ] 1376 }, { 1377 "uri" : "http://alto.example.com/costmap/num/routingcost", 1378 "media-types" : [ "application/alto-costmap+json" ], 1379 "capabilities" : { 1380 "cost-modes" : [ "numerical" ], 1381 "cost-types" : [ "routingcost" ] 1382 } 1383 }, { 1384 "uri" : "http://alto.example.com/costmap/num/hopcount", 1385 "media-types" : [ "application/alto-costmap+json" ], 1386 "capabilities" : { 1387 "cost-modes" : [ "numerical" ], 1388 "cost-types" : [ "hopcount" ] 1389 } 1390 }, { 1391 "uri" : "http://custom.alto.example.com/maps", 1392 "media-types" : [ 1393 "application/alto-networkmap+json", 1394 "application/alto-costmap+json" 1395 ], 1396 "accepts" : [ 1397 "application/alto-networkmapfilter+json", 1398 "application/alto-costmapfilter+json" 1399 ] 1400 }, { 1401 "uri" : "http://alto.example.com/endpointprop/lookup", 1402 "media-types" : [ "application/alto-endpointprop+json" ], 1403 "accepts" : [ "application/alto-endpointpropparams+json" ], 1404 "capabilities" : { 1405 "prop-types" : [ "pid" ] 1406 } 1407 }, { 1408 "uri" : "http://alto.example.com/endpointcost/lookup", 1409 "media-types" : [ "application/alto-endpointcost+json" ], 1410 "accepts" : [ "application/alto-endpointcostparams+json" ], 1411 "capabilities" : { 1412 "cost-constraints" : true, 1413 "cost-modes" : [ "ordinal", "numerical" ], 1414 "cost-types" : [ "routingcost", "hopcount" ] 1415 } 1416 } 1417 ] 1418 } 1420 OPTIONS /maps HTTP/1.1 1421 Host: custom.alto.example.com 1422 Accept: application/alto-directory+json,application/alto-error+json 1423 HTTP/1.1 200 OK 1424 Content-Length: 1001 1425 Content-Type: application/alto-directory+json 1427 { 1428 "resources" : [ 1429 { 1430 "uri" : "http://custom.alto.example.com/networkmap/filtered", 1431 "media-types" : [ "application/alto-networkmap+json" ], 1432 "accepts" : [ "application/alto-networkmapfilter+json" ] 1433 }, { 1434 "uri" : "http://custom.alto.example.com/costmap/filtered", 1435 "media-types" : [ "application/alto-costmap+json" ], 1436 "accepts" : [ "application/alto-costmapfilter+json" ], 1437 "capabilities" : { 1438 "cost-constraints" : true, 1439 "cost-modes" : [ "ordinal", "numerical" ], 1440 "cost-types" : [ "routingcost", "hopcount" ] 1441 } 1442 }, { 1443 "uri" : "http://custom.alto.example.com/ord/routingcost", 1444 "media-types" : [ "application/alto-costmap+json" ], 1445 "capabilities" : { 1446 "cost-modes" : [ "ordinal" ], 1447 "cost-types" : [ "routingcost" ] 1448 } 1449 }, { 1450 "uri" : "http://custom.alto.example.com/ord/hopcount", 1451 "media-types" : [ "application/alto-costmap+json" ], 1452 "capabilities" : { 1453 "cost-modes" : [ "ordinal" ], 1454 "cost-types" : [ "hopcount" ] 1455 } 1456 } 1457 ] 1458 } 1460 6.7.4. Usage Considerations 1462 6.7.4.1. ALTO Client 1464 This document specifies no requirements or constraints on ALTO 1465 Clients with regards to how they process an Information Resource 1466 Directory to identify the URI corresponding to a desired Information 1467 Resource. However, some advice is provided for implementors. 1469 It is possible that multiple entries in the directory match a desired 1470 Information Resource. For instance, in the example in Section 6.7.3, 1471 a full Cost Map with "numerical" Cost Mode and "routingcost" Cost 1472 Type could be retrieved via a GET request to 1473 "http://alto.example.com/costmap/num/routingcost", or via a POST 1474 request to "http://custom.alto.example.com/costmap/filtered". 1476 In general, it is preferred for ALTO Clients to use GET requests 1477 where appropriate, since it is more likely for responses to be 1478 cacheable. 1480 6.7.4.2. ALTO Server 1482 This document indicates that an ALTO Server may or may not provide 1483 the Information Resources specified in the Map Filtering Service. If 1484 these resources are not provided, it is indicated to an ALTO Client 1485 by the absence of a Network Map or Cost Map with any media types 1486 listed under "accepts". 1488 6.8. Information Resources 1490 This section documents the individual Information Resources defined 1491 in the ALTO Protocol. 1493 6.8.1. Map Service 1495 The Map Service provides batch information to ALTO Clients in the 1496 form of two types of maps: a Network Map and Cost Map. 1498 6.8.1.1. Network Map 1500 The Network Map Information Resource lists for each PID, the network 1501 locations (endpoints) within the PID. It MUST be provided by an ALTO 1502 Server. 1504 6.8.1.1.1. Media Type 1506 The media type is "application/alto-networkmap+json". 1508 6.8.1.1.2. HTTP Method 1510 This resource is requested using the HTTP GET method. 1512 6.8.1.1.3. Input Parameters 1514 None. 1516 6.8.1.1.4. Capabilities 1518 None. 1520 6.8.1.1.5. Response 1522 The returned InfoResourceEntity object "data" member of type 1523 InfoResourceNetworkMap: 1525 object { 1526 EndpointAddrGroup [pidname]<0..*>; 1527 ... 1528 } NetworkMapData; 1530 object { 1531 VersionTag map-vtag; 1532 NetworkMapData map; 1533 } InfoResourceNetworkMap; 1535 with members: 1537 map-vtag The Version Tag (Section 5.3) of the Network Map. 1539 map The Network Map data itself. 1541 NetworkMapData is a JSON object with each member representing a 1542 single PID and its associated set of endpoint addresses. A member's 1543 name is a string of type PIDName. 1545 The returned Network Map MUST include all PIDs known to the ALTO 1546 Server. 1548 6.8.1.1.6. Example 1550 GET /networkmap HTTP/1.1 1551 Host: alto.example.com 1552 Accept: application/alto-networkmap+json,application/alto-error+json 1553 HTTP/1.1 200 OK 1554 Content-Length: 370 1555 Content-Type: application/alto-networkmap+json 1557 { 1558 "meta" : {}, 1559 "data" : { 1560 "map-vtag" : "1266506139", 1561 "map" : { 1562 "PID1" : { 1563 "ipv4" : [ 1564 "192.0.2.0/24", 1565 "198.51.100.0/25" 1566 ] 1567 }, 1568 "PID2" : { 1569 "ipv4" : [ 1570 "198.51.100.128/25" 1571 ] 1572 }, 1573 "PID3" : { 1574 "ipv4" : [ 1575 "0.0.0.0/0" 1576 ], 1577 "ipv6" : [ 1578 "::/0" 1579 ] 1580 } 1581 } 1582 } 1583 } 1585 6.8.1.2. Cost Map 1587 The Cost Map resource lists the Path Cost for each pair of source/ 1588 destination PID defined by the ALTO Server for a given Cost Type and 1589 Cost Mode. This resource MUST be provided for at least the 1590 'routingcost' Cost Type and 'numerical' Cost Mode. 1592 Note that since this resource, an unfiltered Cost Map requested by an 1593 HTTP GET, does not indicate the desired Cost Mode or Cost Type as 1594 input parameters, an ALTO Server MUST indicate in an Information 1595 Resource Directory a unfiltered Cost Map Information Resource by 1596 specifying the capabilities (Section 6.8.1.2.4) with "cost-types" and 1597 "cost-modes" members each having a single element. This technique 1598 will allow an ALTO Client to determine a URI for an unfiltered Cost 1599 Map of the desired Cost Mode and Cost Type. 1601 6.8.1.2.1. Media Type 1603 The media type is "application/alto-costmap+json". 1605 6.8.1.2.2. HTTP Method 1607 This resource is requested using the HTTP GET method. 1609 6.8.1.2.3. Input Parameters 1611 None. 1613 6.8.1.2.4. Capabilities 1615 This resource may be defined for across multiple Cost Types and Cost 1616 Modes. The capabilities of an ALTO Server URI providing this 1617 resource are defined by a JSON Object of type CostMapCapability: 1619 object { 1620 CostMode cost-modes<0..*>; 1621 CostType cost-types<0..*>; 1622 } CostMapCapability; 1624 with members: 1626 cost-modes The Cost Modes ( Section 5.1.2) supported by the 1627 corresponding URI. If not present, this member MUST be 1628 interpreted as an empty array. 1630 cost-types The Cost Types ( Section 5.1.1) supported by the 1631 corresponding URI. If not present, this member MUST be 1632 interpreted as an empty array. 1634 An ALTO Server MUST support all of the Cost Types listed here for 1635 each of the listed Cost Modes. Note that an ALTO Server may provide 1636 multiple Cost Map Information Resources, each with different 1637 capabilities. 1639 6.8.1.2.5. Response 1641 The returned InfoResourceEntity object has "data" member of type 1642 InfoResourceCostMap: 1644 object DstCosts { 1645 JSONValue [PIDName]; 1646 ... 1647 }; 1649 object { 1650 DstCosts [PIDName]<0..*>; 1651 ... 1652 } CostMapData; 1654 object { 1655 CostMode cost-mode; 1656 CostType cost-type; 1657 VersionTag map-vtag; 1658 CostMapData map; 1659 } InfoResourceCostMap; 1661 with members: 1663 cost-mode Cost Mode (Section 5.1.2) used in the Cost Map. 1665 cost-type Cost Type (Section 5.1.1) used in the Cost Map. 1667 map-vtag The Version Tag (Section 5.3) of the Network Map used to 1668 generate the Cost Map. 1670 map The Cost Map data itself. 1672 CostMapData is a JSON object with each member representing a single 1673 Source PID; the name for a member is the PIDName string identifying 1674 the corresponding Source PID. For each Source PID, a DstCosts object 1675 denotes the associated cost to a set of destination PIDs ( 1676 Section 5.2); the name for each member in the object is the PIDName 1677 string identifying the corresponding Destination PID. An 1678 implementation of the protocol in this document SHOULD assume that 1679 the cost is a JSONNumber and fail to parse if it is not, unless the 1680 implementation is using an extension to this document that indicates 1681 when and how costs of other data types are signaled. 1683 The returned Cost Map MUST include the Path Cost for each (Source 1684 PID, Destination PID) pair for which a Path Cost is defined. An ALTO 1685 Server MAY omit entries for which a Path Cost is not defined (e.g., 1686 both the Source and Destination PIDs contain addresses outside of the 1687 Network Provider's administrative domain). 1689 6.8.1.2.6. Example 1691 GET /costmap/num/routingcost HTTP/1.1 1692 Host: alto.example.com 1693 Accept: application/alto-costmap+json,application/alto-error+json 1695 HTTP/1.1 200 OK 1696 Content-Length: 262 1697 Content-Type: application/alto-costmap+json 1699 { 1700 "meta" : {}, 1701 "data" : { 1702 "cost-mode" : "numerical", 1703 "cost-type" : "routingcost", 1704 "map-vtag" : "1266506139", 1705 "map" : { 1706 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 1707 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 1708 "PID3": { "PID1": 20, "PID2": 15 } 1709 } 1710 } 1711 } 1713 6.8.2. Map Filtering Service 1715 The Map Filtering Service allows ALTO Clients to specify filtering 1716 criteria to return a subset of the full maps available in the Map 1717 Service. 1719 6.8.2.1. Filtered Network Map 1721 A Filtered Network Map is a Network Map Information Resource 1722 (Section 6.8.1.1) for which an ALTO Client may supply a list of PIDs 1723 to be included. A Filtered Network Map MAY be provided by an ALTO 1724 Server. 1726 6.8.2.1.1. Media Type 1728 See Section 6.8.1.1.1. 1730 6.8.2.1.2. HTTP Method 1732 This resource is requested using the HTTP POST method. 1734 6.8.2.1.3. Input Parameters 1736 Input parameters are supplied in the entity body of the POST request. 1737 This document specifies the input parameters with a data format 1738 indicated by the media type "application/alto-networkmapfilter+json", 1739 which is a JSON Object of type ReqFilteredNetworkMap, where: 1741 object { 1742 PIDName pids<0..*>; 1743 AddressType address-types<0..*>; 1744 } ReqFilteredNetworkMap; 1746 with members: 1748 pids Specifies list of PIDs to be included in the returned Filtered 1749 Network Map. If the list of PIDs is empty, the ALTO Server MUST 1750 interpret the list as if it contained a list of all currently- 1751 defined PIDs. The ALTO Server MUST interpret entries appearing 1752 multiple times as if they appeared only once. 1754 address-types Specifies list of address types to be included in the 1755 returned Filtered Network Map. If the list of address types is 1756 empty, the ALTO Server MUST interpret the list as if it contained 1757 a list of all address types known to the ALTO Server. The ALTO 1758 Server MUST interpret entries appearing multiple times as if they 1759 appeared only once. 1761 6.8.2.1.4. Capabilities 1763 None. 1765 6.8.2.1.5. Response 1767 See Section 6.8.1.1.5 for the format. 1769 The ALTO Server MUST only include PIDs in the response that were 1770 specified (implicitly or explicitly) in the request. If the input 1771 parameters contain a PID name that is not currently defined by the 1772 ALTO Server, the ALTO Server MUST behave as if the PID did not appear 1773 in the input parameters. Similarly, the ALTO Server MUST only 1774 enumerate addresses within each PID that have types which were 1775 specified (implicitly or explicitly) in the request. If the input 1776 parameters contain an address type that is not currently known to the 1777 ALTO Server, the ALTO Server MUST behave as if the address type did 1778 not appear in the input parameters. 1780 6.8.2.1.6. Example 1782 POST /networkmap/filtered HTTP/1.1 1783 Host: custom.alto.example.com 1784 Content-Length: 27 1785 Content-Type: application/alto-networkmapfilter+json 1786 Accept: application/alto-networkmap+json,application/alto-error+json 1788 { 1789 "pids": [ "PID1", "PID2" ] 1790 } 1792 HTTP/1.1 200 OK 1793 Content-Length: 255 1794 Content-Type: application/alto-networkmap+json 1796 { 1797 "meta" : {}, 1798 "data" : { 1799 "map-vtag" : "1266506139", 1800 "map" : { 1801 "PID1" : { 1802 "ipv4" : [ 1803 "192.0.2.0/24", 1804 "198.51.100.0/24" 1805 ] 1806 }, 1807 "PID2" : { 1808 "ipv4": [ 1809 "198.51.100.128/24" 1810 ] 1811 } 1812 } 1813 } 1814 } 1816 6.8.2.2. Filtered Cost Map 1818 A Filtered Cost Map is a Cost Map Information Resource 1819 (Section 6.8.1.2) for which an ALTO Client may supply additional 1820 parameters limiting the scope of the resulting Cost Map. A Filtered 1821 Cost Map MAY be provided by an ALTO Server. 1823 6.8.2.2.1. Media Type 1825 See Section 6.8.1.2.1. 1827 6.8.2.2.2. HTTP Method 1829 This resource is requested using the HTTP POST method. 1831 6.8.2.2.3. Input Parameters 1833 Input parameters are supplied in the entity body of the POST request. 1834 This document specifies the input parameters with a data format 1835 indicated by the media type "application/alto-costmapfilter+json", 1836 which is a JSON Object of type ReqFilteredCostMap, where: 1838 object { 1839 PIDName srcs<0..*>; 1840 PIDName dsts<0..*>; 1841 } PIDFilter; 1843 object { 1844 CostMode cost-mode; 1845 CostType cost-type; 1846 JSONString constraints<0..*>; [OPTIONAL] 1847 PIDFilter pids; [OPTIONAL] 1848 } ReqFilteredCostMap; 1850 with members: 1852 cost-type The Cost Type ( Section 5.1.1) for the returned costs. 1853 This MUST be one of the supported Cost Types indicated in this 1854 resource's capabilities ( Section 6.8.2.2.4). 1856 cost-mode The Cost Mode ( Section 5.1.2) for the returned costs. 1857 This MUST be one of the supported Cost Modes indicated in this 1858 resource's capabilities ( Section 6.8.2.2.4). 1860 constraints Defines a list of additional constraints on which 1861 elements of the Cost Map are returned. This parameter MUST NOT be 1862 specified if this resource's capabilities ( Section 6.8.2.2.4) 1863 indicate that constraint support is not available. A constraint 1864 contains two entities separated by whitespace: (1) an operator, 1865 'gt' for greater than, 'lt' for less than, 'ge' for greater than 1866 or equal to, 'le' for less than or equal to, or 'eq' for equal to 1867 (2) a target cost value. The cost value is a number that MUST be 1868 defined in the same units as the Cost Type indicated by the cost- 1869 type parameter. ALTO Servers SHOULD use at least IEEE 754 double- 1870 precision floating point [IEEE.754.2008] to store the cost value, 1871 and SHOULD perform internal computations using double-precision 1872 floating-point arithmetic. If multiple 'constraint' parameters 1873 are specified, they are interpreted as being related to each other 1874 with a logical AND. 1876 pids A list of Source PIDs and a list of Destination PIDs for which 1877 Path Costs are to be returned. If a list is empty, the ALTO 1878 Server MUST interpret it as the full set of currently-defined 1879 PIDs. The ALTO Server MUST interpret entries appearing in a list 1880 multiple times as if they appeared only once. If the "pids" 1881 member is not present, both lists MUST be interpreted by the ALTO 1882 Server as containing the full set of currently-defined PIDs. 1884 6.8.2.2.4. Capabilities 1886 The URI providing this resource supports all capabilities documented 1887 in Section 6.8.1.2.4 (with identical semantics), plus additional 1888 capabilities. In particular, the capabilities are defined by a JSON 1889 object of type FilteredCostMapCapability: 1891 object { 1892 CostMode cost-modes<0..*>; 1893 CostType cost-types<0..*>; 1894 JSONBool cost-constraints; 1895 } FilteredCostMapCapability; 1897 with members: 1899 cost-modes See Section 6.8.1.2.4. 1901 cost-types See Section 6.8.1.2.4. 1903 cost-constraints If true, then the ALTO Server allows cost 1904 constraints to be included in requests to the corresponding URI. 1905 If not present, this member MUST be interpreted as if it specified 1906 false. ALTO Clients should be aware that constraints may not have 1907 the intended effect for cost maps with the 'ordinal' Cost Mode 1908 since ordinal costs are not restricted to being sequential 1909 integers. 1911 6.8.2.2.5. Response 1913 See Section 6.8.1.2.5 for the format. 1915 The returned Cost Map MUST NOT contain any source/destination pair 1916 that was not indicated (implicitly or explicitly) in the input 1917 parameters. If the input parameters contain a PID name that is not 1918 currently defined by the ALTO Server, the ALTO Server MUST behave as 1919 if the PID did not appear in the input parameters. 1921 If any constraints are specified, Source/Destination pairs for which 1922 the Path Costs do not meet the constraints MUST NOT be included in 1923 the returned Cost Map. If no constraints were specified, then all 1924 Path Costs are assumed to meet the constraints. 1926 Note that ALTO Clients should verify that the Version Tag included in 1927 the response is consistent with the Version Tag of the Network Map 1928 used to generate the request (if applicable). If it is not, the ALTO 1929 Client may wish to request an updated Network Map, identify changes, 1930 and consider requesting a new Filtered Cost Map. 1932 6.8.2.2.6. Example 1934 POST /costmap/filtered HTTP/1.1 1935 Host: custom.alto.example.com 1936 Content-Type: application/alto-costmapfilter+json 1937 Accept: application/alto-costmap+json,application/alto-error+json 1939 { 1940 "cost-mode" : "numerical", 1941 "cost-type" : "routingcost", 1942 "pids" : { 1943 "srcs" : [ "PID1" ], 1944 "dsts" : [ "PID1", "PID2", "PID3" ] 1945 } 1946 } 1948 HTTP/1.1 200 OK 1949 Content-Length: 177 1950 Content-Type: application/alto-costmap+json 1952 { 1953 "meta" : {}, 1954 "data" : { 1955 "cost-mode" : "numerical", 1956 "cost-type" : "routingcost", 1957 "map-vtag" : "1266506139", 1958 "map" : { 1959 "PID1": { "PID1": 0, "PID2": 1, "PID3": 2 } 1960 } 1961 } 1962 } 1964 6.8.3. Endpoint Property Service 1966 The Endpoint Property Service provides information about Endpoint 1967 properties to ALTO Clients. 1969 6.8.3.1. Endpoint Property 1971 The Endpoint Property resource provides information about properties 1972 for individual endpoints. It MAY be provided by an ALTO Server. If 1973 an ALTO Server provides one or more Endpoint Property resources, then 1974 at least one MUST provide the 'pid' property. 1976 6.8.3.1.1. Media Type 1978 The media type is "application/alto-endpointprop+json". 1980 6.8.3.1.2. HTTP Method 1982 This resource is requested using the HTTP POST method. 1984 6.8.3.1.3. Input Parameters 1986 Input parameters are supplied in the entity body of the POST request. 1987 This document specifies the data format of input parameters with the 1988 media type "application/alto-endpointpropparams+json", which is a 1989 JSON Object of type ReqEndpointProp: 1991 object { 1992 EndpointProperty properties<1..*>; 1993 TypedEndpointAddr endpoints<1..*>; 1994 } ReqEndpointProp; 1996 with members: 1998 properties List of endpoint properties to be returned for each 1999 endpoint. Each specified property MUST be included in the list of 2000 supported properties indicated by this resource's capabilities ( 2001 Section 6.8.3.1.4). The ALTO Server MUST interpret entries 2002 appearing multiple times as if they appeared only once. 2004 endpoints List of endpoint addresses for which the specified 2005 properties are to be returned. The ALTO Server MUST interpret 2006 entries appearing multiple times as if they appeared only once. 2008 6.8.3.1.4. Capabilities 2010 This resource may be defined across multiple types of endpoint 2011 properties. The capabilities of an ALTO Server URI providing 2012 Endpoint Properties are defined by a JSON Object of type 2013 EndpointPropertyCapability: 2015 object { 2016 EndpointProperty prop-types<0..*>; 2017 } EndpointPropertyCapability; 2019 with members: 2021 prop-types The Endpoint Property Types (see Section 6.6.6) supported 2022 by the corresponding URI. If not present, this member MUST be 2023 interpreted as an empty array. 2025 6.8.3.1.5. Response 2027 The returned InfoResourceEntity object has "data" member of type 2028 InfoResourceEndpointProperty, where: 2030 object { 2031 JSONValue [EndpointProperty]; 2032 ... 2033 } EndpointProps; 2035 object { 2036 EndpointProps [TypedEndpointAddr]<0..*>; 2037 ... 2038 } EndpointPropertyMapData; 2040 object { 2041 VersionTag map-vtag; [OPTIONAL] 2042 EndpointPropertyMapData map; 2043 } InfoResourceEndpointProperty; 2045 EndpointPropertyMapData has one member for each endpoint indicated in 2046 the input parameters (with the name being the endpoint encoded as a 2047 TypedEndpointAddr). The requested properties for each endpoint are 2048 encoded in a corresponding EndpointProps object, which encodes one 2049 name/value pair for each requested property, where the property names 2050 are encoded as strings of type EndpointProperty. An implementation 2051 of the protocol in this document SHOULD assume that the property 2052 value is a JSONString and fail to parse if it is not, unless the 2053 implementation is using an extension to this document that indicates 2054 when and how property values of other data types are signaled. 2056 The ALTO Server returns the value for each of the requested endpoint 2057 properties for each of the endpoints listed in the input parameters. 2059 If the ALTO Server does not define a requested property's value for a 2060 particular endpoint, then it MUST omit that property from the 2061 response for only that endpoint. 2063 The ALTO Server MAY include the Version Tag (Section 5.3) of the 2064 Network Map used to generate the response (if desired and applicable) 2065 as the 'map-vtag' member in the response. If the 'pid' property is 2066 returned for any endpoints in the response, the 'map-vtag' member is 2067 REQUIRED instead of OPTIONAL. 2069 6.8.3.1.6. Example 2071 POST /endpointprop/lookup HTTP/1.1 2072 Host: alto.example.com 2073 Content-Length: 96 2074 Content-Type: application/alto-endpointpropparams+json 2075 Accept: application/alto-endpointprop+json,application/alto-error+json 2077 { 2078 "properties" : [ "pid", "example-prop" ], 2079 "endpoints" : [ "ipv4:192.0.2.34", "ipv4:203.0.113.129" ] 2080 } 2082 HTTP/1.1 200 OK 2083 Content-Length: 149 2084 Content-Type: application/alto-endpointprop+json 2086 { 2087 "meta" : {}, 2088 "data": { 2089 "map" : { 2090 "ipv4:192.0.2.34" : { "pid": "PID1", "example-prop": "1" }, 2091 "ipv4:203.0.113.129" : { "pid": "PID3" } 2092 } 2093 } 2094 } 2096 6.8.4. Endpoint Cost Service 2098 The Endpoint Cost Service provides information about costs between 2099 individual endpoints. 2101 In particular, this service allows lists of Endpoint prefixes (and 2102 addresses, as a special case) to be ranked (ordered) by an ALTO 2103 Server. 2105 6.8.4.1. Endpoint Cost 2107 The Endpoint Cost resource provides information about costs between 2108 individual endpoints. It MAY be provided by an ALTO Server. 2110 It is important to note that although this resource allows an ALTO 2111 Server to reveal costs between individual endpoints, an ALTO Server 2112 is not required to do so. A simple alternative would be to compute 2113 the cost between two endpoints as the cost between the PIDs 2114 corresponding to the endpoints. See Section 10.1 for additional 2115 details. 2117 6.8.4.1.1. Media Type 2119 The media type is "application/alto-endpointcost+json". 2121 6.8.4.1.2. HTTP Method 2123 This resource is requested using the HTTP POST method. 2125 6.8.4.1.3. Input Parameters 2127 Input parameters are supplied in the entity body of the POST request. 2128 This document specifies input parameters with a data format indicated 2129 by media type "application/alto-endpointcostparams+json", which is a 2130 JSON Object of type ReqEndpointCostMap: 2132 object { 2133 TypedEndpointAddr srcs<0..*>; [OPTIONAL] 2134 TypedEndpointAddr dsts<1..*>; 2135 } EndpointFilter; 2137 object { 2138 CostMode cost-mode; 2139 CostType cost-type; 2140 JSONString constraints; [OPTIONAL] 2141 EndpointFilter endpoints; 2142 } ReqEndpointCostMap; 2144 with members: 2146 cost-mode The Cost Mode ( Section 5.1.2) to use for returned costs. 2147 This MUST be one of the Cost Modes indicated in this resource's 2148 capabilities ( Section 6.8.4.1.4). 2150 cost-type The Cost Type ( Section 5.1.1) to use for returned costs. 2151 This MUST be one of the Cost Types indicated in this resource's 2152 capabilities ( Section 6.8.4.1.4). 2154 constraints Defined equivalently to the "constraints" input 2155 parameter of a Filtered Cost Map (see Section 6.8.2.2). 2157 endpoints A list of Source Endpoints and Destination Endpoints for 2158 which Path Costs are to be returned. If the list of Source 2159 Endpoints is empty (or not included), the ALTO Server MUST 2160 interpret it as if it contained the Endpoint Address corresponding 2161 to the client IP address from the incoming connection (see 2162 Section 8.3 for discussion and considerations regarding this 2163 mode). The list of destination Endpoints MUST NOT be empty. The 2164 ALTO Server MUST interpret entries appearing multiple times in a 2165 list as if they appeared only once. 2167 6.8.4.1.4. Capabilities 2169 See Section 6.8.2.2.4. 2171 6.8.4.1.5. Response 2173 The returned InfoResourceEntity object has "data" member equal to 2174 InfoResourceEndpointCostMap, where: 2176 object EndpointDstCosts { 2177 JSONValue [TypedEndpointAddr]; 2178 ... 2179 }; 2181 object { 2182 EndpointDstCosts [TypedEndpointAddr]<0..*>; 2183 ... 2184 } EndpointCostMapData; 2186 object { 2187 CostMode cost-mode; 2188 CostType cost-type; 2189 EndpointCostMapData map; 2190 } InfoResourceEndpointCostMap; 2192 InfoResourceEndpointCostMap has members: 2194 cost-mode The Cost Mode used in the returned Cost Map. 2196 cost-type The Cost Type used in the returned Cost Map. 2198 map The Endpoint Cost Map data itself. 2200 EndpointCostMapData is a JSON object with each member representing a 2201 single Source Endpoint specified in the input parameters; the name 2202 for a member is the TypedEndpointAddr string identifying the 2203 corresponding Source Endpoint. For each Source Endpoint, a 2204 EndpointDstCosts object denotes the associated cost to each 2205 Destination Endpoint specified in the input parameters; the name for 2206 each member in the object is the TypedEndpointAddr string identifying 2207 the corresponding Destination Endpoint. An implementation of the 2208 protocol in this document SHOULD assume that the cost value is a 2209 JSONNumber and fail to parse if it is not, unless the implementation 2210 is using an extensions to this document that indicates when and how 2211 costs of other data types are signaled. If the ALTO Server does not 2212 define a cost value from a Source Endpoint to a particular 2213 Destination Endpoint, it MAY be omitted from the response. 2215 6.8.4.1.6. Example 2217 POST /endpointcost/lookup HTTP/1.1 2218 Host: alto.example.com 2219 Content-Length: 195 2220 Content-Type: application/alto-endpointcostparams+json 2221 Accept: application/alto-endpointcost+json,application/alto-error+json 2223 { 2224 "cost-mode" : "ordinal", 2225 "cost-type" : "routingcost", 2226 "endpoints" : { 2227 "srcs": [ "ipv4:192.0.2.2" ], 2228 "dsts": [ 2229 "ipv4:192.0.2.89", 2230 "ipv4:198.51.100.34", 2231 "ipv4:203.0.113.45" 2232 ] 2233 } 2234 } 2236 HTTP/1.1 200 OK 2237 Content-Length: 231 2238 Content-Type: application/alto-endpointcost+json 2240 { 2241 "meta" : {}, 2242 "data" : { 2243 "cost-mode" : "ordinal", 2244 "cost-type" : "routingcost", 2245 "map" : { 2246 "ipv4:192.0.2.2": { 2247 "ipv4:192.0.2.89" : 1, 2248 "ipv4:198.51.100.34" : 2, 2249 "ipv4:203.0.113.45" : 3 2250 } 2251 } 2252 } 2253 } 2255 7. Use Cases 2257 The sections below depict typical use cases. While these use cases 2258 focus on peer-to-peer applications, ALTO can be applied to ther 2259 environments such as CDNs [I-D.jenkins-alto-cdn-use-cases]. 2261 7.1. ALTO Client Embedded in P2P Tracker 2263 Many currently-deployed P2P systems use a Tracker to manage swarms 2264 and perform peer selection. P2P trackers may currently use a variety 2265 of information to perform peer selection to meet application-specific 2266 goals. By acting as an ALTO Client, an P2P tracker can use ALTO 2267 information as an additional information source to enable more 2268 network-efficient traffic patterns and improve application 2269 performance. 2271 A particular requirement of many P2P trackers is that they must 2272 handle a large number of P2P clients. A P2P tracker can obtain and 2273 locally store ALTO information (the Network Map and Cost Map) from 2274 the ISPs containing the P2P clients, and benefit from the same 2275 aggregation of network locations done by ALTO Servers. 2277 .---------. (1) Get Network Map .---------------. 2278 | | <----------------------> | | 2279 | ALTO | | P2P Tracker | 2280 | Server | (2) Get Cost Map | (ALTO Client) | 2281 | | <----------------------> | | 2282 `---------' `---------------' 2283 ^ | 2284 (3) Get Peers | | (4) Selected Peer 2285 | v List 2286 .---------. .-----------. 2287 | Peer 1 | <-------------- | P2P | 2288 `---------' | Client | 2289 . (5) Connect to `-----------' 2290 . Selected Peers / 2291 .---------. / 2292 | Peer 50 | <------------------ 2293 `---------' 2295 Figure 4: ALTO Client Embedded in P2P Tracker 2297 Figure 4 shows an example use case where a P2P tracker is an ALTO 2298 Client and applies ALTO information when selecting peers for its P2P 2299 clients. The example proceeds as follows: 2301 1. The P2P Tracker requests the Network Map covering all PIDs from 2302 the ALTO Server using the Network Map query. The Network Map 2303 includes the IP prefixes contained in each PID, allowing the P2P 2304 tracker to locally map P2P clients into a PIDs. 2306 2. The P2P Tracker requests the Cost Map amongst all PIDs from the 2307 ALTO Server. 2309 3. A P2P Client joins the swarm, and requests a peer list from the 2310 P2P Tracker. 2312 4. The P2P Tracker returns a peer list to the P2P client. The 2313 returned peer list is computed based on the Network Map and Cost 2314 Map returned by the ALTO Server, and possibly other information 2315 sources. Note that it is possible that a tracker may use only 2316 the Network Map to implement hierarchical peer selection by 2317 preferring peers within the same PID and ISP. 2319 5. The P2P Client connects to the selected peers. 2321 Note that the P2P tracker may provide peer lists to P2P clients 2322 distributed across multiple ISPs. In such a case, the P2P tracker 2323 may communicate with multiple ALTO Servers. 2325 7.2. ALTO Client Embedded in P2P Client: Numerical Costs 2327 P2P clients may also utilize ALTO information themselves when 2328 selecting from available peers. It is important to note that not all 2329 P2P systems use a P2P tracker for peer discovery and selection. 2330 Furthermore, even when a P2P tracker is used, the P2P clients may 2331 rely on other sources, such as peer exchange and DHTs, to discover 2332 peers. 2334 When an P2P Client uses ALTO information, it typically queries only 2335 the ALTO Server servicing its own ISP. The my-Internet view provided 2336 by its ISP's ALTO Server can include preferences to all potential 2337 peers. 2339 .---------. (1) Get Network Map .---------------. 2340 | | <----------------------> | | 2341 | ALTO | | P2P Client | 2342 | Server | (2) Get Cost Map | (ALTO Client) | 2343 | | <----------------------> | | .---------. 2344 `---------' `---------------' <- | P2P | 2345 .---------. / | ^ ^ | Tracker | 2346 | Peer 1 | <-------------- | | \ `---------' 2347 `---------' | (3) Gather Peers 2348 . (4) Select Peers | | \ 2349 . and Connect / .--------. .--------. 2350 .---------. / | P2P | | DHT | 2351 | Peer 50 | <---------------- | Client | `--------' 2352 `---------' | (PEX) | 2353 `--------' 2355 Figure 5: ALTO Client Embedded in P2P Client 2357 Figure 5 shows an example use case where a P2P Client locally applies 2358 ALTO information to select peers. The use case proceeds as follows: 2360 1. The P2P Client requests the Network Map covering all PIDs from 2361 the ALTO Server servicing its own ISP. 2363 2. The P2P Client requests the Cost Map amongst all PIDs from the 2364 ALTO Server. The Cost Map by default specifies numerical costs. 2366 3. The P2P Client discovers peers from sources such as Peer Exchange 2367 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2368 P2P Trackers. 2370 4. The P2P Client uses ALTO information as part of the algorithm for 2371 selecting new peers, and connects to the selected peers. 2373 7.3. ALTO Client Embedded in P2P Client: Ranking 2375 It is also possible for a P2P Client to offload the selection and 2376 ranking process to an ALTO Server. In this use case, the ALTO Client 2377 gathers a list of known peers in the swarm, and asks the ALTO Server 2378 to rank them. 2380 As in the use case using numerical costs, the P2P Client typically 2381 only queries the ALTO Server servicing its own ISP. 2383 .---------. .---------------. 2384 | | | | 2385 | ALTO | (2) Get Endpoint Ranking | P2P Client | 2386 | Server | <----------------------> | (ALTO Client) | 2387 | | | | .---------. 2388 `---------' `---------------' <- | P2P | 2389 .---------. / | ^ ^ | Tracker | 2390 | Peer 1 | <-------------- | | \ `---------' 2391 `---------' | (1) Gather Peers 2392 . (3) Connect to | | \ 2393 . Selected Peers / .--------. .--------. 2394 .---------. / | P2P | | DHT | 2395 | Peer 50 | <---------------- | Client | `--------' 2396 `---------' | (PEX) | 2397 `--------' 2399 Figure 6: ALTO Client Embedded in P2P Client: Ranking 2401 Figure 6 shows an example of this scenario. The use case proceeds as 2402 follows: 2404 1. The P2P Client discovers peers from sources such as Peer Exchange 2405 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 2406 P2P Trackers. 2408 2. The P2P Client queries the ALTO Server's Ranking Service, 2409 including discovered peers as the set of Destination Endpoints, 2410 and indicates the 'ordinal' Cost Mode. The response indicates 2411 the ranking of the candidate peers. 2413 3. The P2P Client connects to the peers in the order specified in 2414 the ranking. 2416 8. Discussions 2418 8.1. Discovery 2420 The discovery mechanism by which an ALTO Client locates an 2421 appropriate ALTO Server is out of scope for this document. This 2422 document assumes that an ALTO Client can discover an appropriate ALTO 2423 Server. Once it has done so, the ALTO Client may use the Information 2424 Resource Directory (see Section 6.7) to locate an Information 2425 Resource with the desired ALTO Information. 2427 8.2. Hosts with Multiple Endpoint Addresses 2429 In practical deployments, especially during the transition from IPv4 2430 to IPv6, a particular host may be reachable using multiple addresses. 2431 Furthermore, the particular network path followed when sending 2432 packets to the host may differ based on the address that is used. 2433 Network providers may prefer one path over another (e.g., one path 2434 may have a NAT64 middlebox). An additional consideration may be how 2435 to handle private address spaces (e.g., behind carrier-grade NATs). 2437 To support such behavior, this document allows multiple types of 2438 endpoint addresses. In supporting multiple address types, the ALTO 2439 Protocol also allows ALTO Service Provider the flexibility to 2440 indicate preferences for paths from an endpoint address of one type 2441 to an endpoint address of a different type. Note that in general, 2442 the path through the network may differ dependent on the types of 2443 addresses that are used. 2445 Note that there are limitations as to what information ALTO can 2446 provide in this regard. In particular, a particular ALTO Service 2447 provider may not be able to determine if connectivity with a 2448 particular endhost will succeed over IPv4 or IPv6, as this may depend 2449 upon information unknown to the ISP such as particular application 2450 implementations. 2452 8.3. Network Address Translation Considerations 2454 At this day and age of NAT v4<->v4, v4<->v6 [RFC6144], and possibly 2455 v6<->v6[I-D.mrw-nat66], a protocol should strive to be NAT friendly 2456 and minimize carrying IP addresses in the payload, or provide a mode 2457 of operation where the source IP address provide the information 2458 necessary to the server. 2460 The protocol specified in this document provides a mode of operation 2461 where the source network location is computed by the ALTO Server 2462 (i.e., the the Endpoint Cost Service) from the source IP address 2463 found in the ALTO Client query packets. This is similar to how some 2464 P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS 2465 Protocol" in [BitTorrent]) operate. 2467 There may be cases where an ALTO Client needs to determine its own IP 2468 address, such as when specifying a source Endpoint Address in the 2469 Endpoint Cost Service. It is possible that an ALTO Client has 2470 multiple network interface addresses, and that some or all of them 2471 may require NAT for connectivity to the public Internet. 2473 If a public IP address is required for a network interface, the ALTO 2474 client SHOULD use the Session Traversal Utilities for NAT (STUN) 2476 [RFC5389]. If using this method, the host MUST use the "Binding 2477 Request" message and the resulting "XOR-MAPPED-ADDRESS" parameter 2478 that is returned in the response. Using STUN requires cooperation 2479 from a publicly accessible STUN server. Thus, the ALTO client also 2480 requires configuration information that identifies the STUN server, 2481 or a domain name that can be used for STUN server discovery. To be 2482 selected for this purpose, the STUN server needs to provide the 2483 public reflexive transport address of the host. 2485 ALTO Clients should be cognizant that the network path between 2486 Endpoints can be dependent on the network interfaces, source address, 2487 and destination address used for communication. An ALTO Server 2488 provides information based on Endpoint Addresses (more generally, 2489 Network Locations), but the mechanisms used for determining existence 2490 of connectivity or usage of NAT between Endpoints are out of scope of 2491 this document. 2493 8.4. Endpoint and Path Properties 2495 An ALTO Server could make available many properties about Endpoints 2496 beyond their network location or grouping. For example, connection 2497 type, geographical location, and others may be useful to 2498 applications. This specification focuses on network location and 2499 grouping, but the protocol may be extended to handle other Endpoint 2500 properties. 2502 9. IANA Considerations 2504 9.1. application/alto-* Media Types 2506 This document requests the registration of multiple media types, 2507 listed in Table 2. 2509 +-------------+------------------------------+-----------------+ 2510 | Type | Subtype | Specification | 2511 +-------------+------------------------------+-----------------+ 2512 | application | alto-directory+json | Section 6.7 | 2513 | application | alto-networkmap+json | Section 6.8.1.1 | 2514 | application | alto-networkmapfilter+json | Section 6.8.2.1 | 2515 | application | alto-costmap+json | Section 6.8.1.2 | 2516 | application | alto-costmapfilter+json | Section 6.8.2.2 | 2517 | application | alto-endpointprop+json | Section 6.8.3.1 | 2518 | application | alto-endpointpropparams+json | Section 6.8.3.1 | 2519 | application | alto-endpointcost+json | Section 6.8.4.1 | 2520 | application | alto-endpointcostparams+json | Section 6.8.4.1 | 2521 | application | alto-error+json | Section 6.5 | 2522 +-------------+------------------------------+-----------------+ 2524 Table 2: ALTO Protocol Media Types 2526 Type name: application 2528 Subtype name: This documents requests the registration of multiple 2529 subtypes, as listed in Table 2. 2531 Required parameters: n/a 2533 Optional parameters: n/a 2535 Encoding considerations: Encoding considerations are identical to 2536 those specified for the 'application/json' media type. See 2537 [RFC4627]. 2539 Security considerations: Security considerations relating to the 2540 generation and consumption of ALTO protocol messages are discussed 2541 in Section 10. 2543 Interoperability considerations: This document specifies format of 2544 conforming messages and the interpretation thereof. 2546 Published specification: This document is the specification for 2547 these media types; see Table 2 for the section documenting each 2548 media type. 2550 Applications that use this media type: ALTO Servers and ALTO Clients 2551 either standalone or embedded within other applications. 2553 Additional information: 2555 Magic number(s): n/a 2557 File extension(s): This document uses the mime type to refer to 2558 protocol messages and thus does not require a file extension. 2560 Macintosh file type code(s): n/a 2562 Person & email address to contact for further information: See 2563 "Authors' Addresses" section. 2565 Intended usage: COMMON 2567 Restrictions on usage: n/a 2569 Author: See "Authors' Addresses" section. 2571 Change controller: Internet Engineering Task Force 2572 (mailto:iesg@ietf.org). 2574 9.2. ALTO Cost Type Registry 2576 This document requests the creation of an ALTO Cost Type registry to 2577 be maintained by IANA. 2579 This registry serves two purposes. First, it ensures uniqueness of 2580 identifiers referring to ALTO Cost Types. Second, it provides 2581 references to particular semantics of allocated Cost Types to be 2582 applied by both ALTO Servers and applications utilizing ALTO Clients. 2584 New ALTO Cost Types are assigned after Expert Review [RFC5226]. The 2585 Expert Reviewer will generally consult the ALTO Working Group or its 2586 successor. Expert Review is used to ensure that proper documentation 2587 regarding ALTO Cost Type semantics and security considerations has 2588 been provided. The provided documentation should be detailed enough 2589 to provide guidance to both ALTO Service Providers and applications 2590 utilizing ALTO Clients as to how values of the registered ALTO Cost 2591 Type should be interpreted. Updates and deletions of ALTO Cost Types 2592 follow the same procedure. 2594 Registered ALTO Cost Type identifiers MUST conform to the syntatical 2595 requirements specified in Section 6.6.5. Identifiers are to be 2596 recorded and displayed as ASCII strings. 2598 Identifiers prefixed with 'priv:' are reserved for Private Use. 2599 Identifiers prefixed with 'exp:' are reserved for Experimental use. 2601 Requests to add a new value to the registry MUST include the 2602 following information: 2604 o Identifier: The name of the desired ALTO Cost Type. 2606 o Intended Semantics: ALTO Costs carry with them semantics to guide 2607 their usage by ALTO Clients. For example, if a value refers to a 2608 measurement, the measurement units must be documented. For proper 2609 implementation of the ordinal Cost Mode (e.g., by a third-party 2610 service), it should be documented whether higher or lower values 2611 of the cost are more preferred. 2613 o Security Considerations: ALTO Costs expose information to ALTO 2614 Clients. As such, proper usage of a particular Cost Type may 2615 require certain information to be exposed by an ALTO Service 2616 Provider. Since network information is frequently regarded as 2617 proprietary or confidential, ALTO Service Providers should be made 2618 aware of the security ramifications related to usage of a Cost 2619 Type. 2621 This specification requests registration of the identifier 2622 'routingcost'. Semantics for the this Cost Type are documented in 2623 Section 5.1.1.1, and security considerations are documented in 2624 Section 10.1. 2626 9.3. ALTO Endpoint Property Registry 2628 This document requests the creation of an ALTO Endpoint Property 2629 registry to be maintained by IANA. 2631 This registry serves two purposes. First, it ensures uniqueness of 2632 identifiers referring to ALTO Endpoint Properties. Second, it 2633 provides references to particular semantics of allocated Endpoint 2634 Properties to be applied by both ALTO Servers and applications 2635 utilizing ALTO Clients. 2637 New ALTO Endpoint Properties are assigned after Expert Review 2638 [RFC5226]. The Expert Reviewer will generally consult the ALTO 2639 Working Group or its successor. Expert Review is used to ensure that 2640 proper documentation regarding ALTO Endpoint Property semantics and 2641 security considerations has been provided. The provided 2642 documentation should be detailed enough to provide guidance to both 2643 ALTO Service Providers and applications utilizing ALTO Clients as to 2644 how values of the registered ALTO Endpoint Properties should be 2645 interpreted. Updates and deletions of ALTO Endpoint Properties 2646 follow the same procedure. 2648 Registered ALTO Endpoint Property identifiers MUST conform to the 2649 syntatical requirements specified in Section 6.6.6. Identifiers are 2650 to be recorded and displayed as ASCII strings. 2652 Identifiers prefixed with 'priv:' are reserved for Private Use. 2653 Identifiers prefixed with 'exp:' are reserved for Experimental use. 2655 Requests to add a new value to the registry MUST include the 2656 following information: 2658 o Identifier: The name of the desired ALTO Endpoint Property. 2660 o Intended Semantics: ALTO Endpoint Properties carry with them 2661 semantics to guide their usage by ALTO Clients. For example, if a 2662 value refers to a measurement, the measurement units must be 2663 documented. 2665 o Security Considerations: ALTO Endpoint Properties expose 2666 information to ALTO Clients. As such, proper usage of a 2667 particular Endpoint Properties may require certain information to 2668 be exposed by an ALTO Service Provider. Since network information 2669 is frequently regarded as proprietary or confidential, ALTO 2670 Service Providers should be made aware of the security 2671 ramifications related to usage of an Endpoint Property. 2673 This specification requests registration of the identifier 'pid'. 2674 Semantics for the this Endpoint Property are documented in 2675 Section 4.1, and security considerations are documented in 2676 Section 10.1. 2678 9.4. ALTO Address Type Registry 2680 This document requests the creation of an ALTO Address Type registry 2681 to be maintained by IANA. 2683 This registry serves two purposes. First, it ensures uniqueness of 2684 identifiers referring to ALTO Address Types. Second, it states the 2685 requirements for allocated Address Type identifiers. 2687 New ALTO Address Types are assigned after Expert Review [RFC5226]. 2688 The Expert Reviewer will generally consult the ALTO Working Group or 2689 its successor. Expert Review is used to ensure that proper 2690 documentation regarding the new ALTO Address Types and their security 2691 considerations has been provided. The provided documentation should 2692 indicate how an address of a registered type is encoded as an 2693 EndpointAddr and, if possible, a compact method (e.g., IPv4 and IPv6 2694 prefixes) for encoding a set of addresses as an EndpointPrefix. 2695 Updates and deletions of ALTO Address Types follow the same 2696 procedure. 2698 Registered ALTO Address Type identifiers MUST conform to the 2699 syntatical requirements specified in Section 6.6.3.1. Identifiers 2700 are to be recorded and displayed as ASCII strings. 2702 Requests to add a new value to the registry MUST include the 2703 following information: 2705 o Identifier: The name of the desired ALTO Address Type. 2707 o Endpoint Address Encoding: The procedure for encoding an address 2708 of the registered type as an EndpointAddr (see Section 6.6.3.2). 2710 o Endpoint Prefix Encoding: The procedure for encoding a set of 2711 addresses of the registered type as an EndpointPrefix (see 2712 Section 6.6.3.3). If no such compact encoding is available, the 2713 same encoding used for a singular address may be used. In such a 2714 case, it must be documented that sets of addresses of this type 2715 always have exactly one element. 2717 o Mapping to/from IPv4/IPv6 Addresses: If possible, a mechanism to 2718 map addresses of the registered type to and from IPv4 or IPv6 2719 addresses should be specified. 2721 o Security Considerations: In some usage scenarios, Endpoint 2722 Addresses carried in ALTO Protocol messages may reveal information 2723 about an ALTO Client or an ALTO Service Provider. Applications 2724 and ALTO Service Providers using addresses of the registered type 2725 should be made aware of how (or if) the addressing scheme relates 2726 to private information and network proximity. 2728 This specification requests registration of the identifiers 'ipv4' 2729 and 'ipv6'. Endpoint Address Encoding is documented in 2730 Section 6.6.3.2.1 and Section 6.6.3.2.2. Endpoint Prefix Encoding is 2731 documented in Section 6.6.3.3.1 and Section 6.6.3.3.2. Since these 2732 are registrations for IPv4 and IPv6 address types, no mapping is 2733 required. Security considerations are documented in Section 10.1 and 2734 Section 10.2. 2736 10. Security Considerations 2738 10.1. Privacy Considerations for ISPs 2740 ISPs must be cognizant of the network topology and provisioning 2741 information provided through ALTO Interfaces. ISPs should evaluate 2742 how much information is revealed and the associated risks. On the 2743 one hand, providing overly fine-grained information may make it 2744 easier for attackers to infer network topology. In particular, 2745 attackers may try to infer details regarding ISPs' operational 2746 policies or inter-ISP business relationships by intentionally posting 2747 a multitude of selective queries to an ALTO server and analyzing the 2748 responses. Such sophisticated attacks may reveal more information 2749 than an ISP hosting an ALTO server intends to disclose. On the other 2750 hand, revealing overly coarse-grained information may not provide 2751 benefits to network efficiency or performance improvements to ALTO 2752 Clients. 2754 10.2. ALTO Clients 2756 Applications using the information must be cognizant of the 2757 possibility that the information is malformed or incorrect. Even if 2758 an ALTO Server has been properly authenticated by the ALTO Client, 2759 the information provided may be malicious because the ALTO Server and 2760 its credentials have been compromised (e.g., through malware). Other 2761 considerations (e.g., relating to application performance) can be 2762 found in Section 6 of [RFC5693]. 2764 ALTO Clients should also be cognizant of revealing Network Location 2765 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, 2766 as doing so may allow the ALTO Server to infer communication 2767 patterns. One possibility is for the ALTO Client to only rely on 2768 Network Map for PIDs and Cost Map amongst PIDs to avoid passing IP 2769 addresses of other endpoints (e.g., peers) to the ALTO Server. 2771 In addition, ALTO clients should be cautious not to unintentionally 2772 or indirectly disclose the resource identifier (of which they try to 2773 improve the retrieval through ALTO-guidance), e.g., the name/ 2774 identifier of a certain video stream in P2P live streaming, to the 2775 ALTO server. Note that the ALTO Protocol specified in this document 2776 does not explicitly reveal any resource identifier to the ALTO 2777 Server. However, for instance, depending on the popularity or other 2778 specifics (such as language) of the resource, an ALTO server could 2779 potentially deduce information about the desired resource from 2780 information such as the Network Locations the client sends as part of 2781 its request to the server. 2783 10.3. Authentication, Integrity Protection, and Encryption 2785 SSL/TLS can provide encryption and integrity protection of 2786 transmitted messages as well as authentication of the ALTO Client and 2787 Server. HTTP Basic or Digest authentication can provide 2788 authentication of the client (combined with SSL/TLS, it can 2789 additionally provide encryption, integrity protection and server 2790 authentication). 2792 Issues resulting from an attacker controlling the data received by an 2793 ALTO Client are discussed in Section 10.2. 2795 An ALTO Server may optionally use authentication (and potentially 2796 encryption) to limit the parties with whom ALTO information is 2797 directly shared. There may be special use cases where encryption of 2798 ALTO information is desirable. In many cases, however, information 2799 sent out by an ALTO Server may be regarded as non-confidential 2800 information. 2802 ISPs should be cognizant that encryption only protects ALTO 2803 information until it is decrypted by the intended ALTO Client. 2804 Digital Rights Management (DRM) techniques and legal agreements 2805 protecting ALTO information are outside of the scope of this 2806 document. 2808 10.4. ALTO Information Redistribution 2810 It is possible for applications to redistribute ALTO information to 2811 improve scalability. Even with such a distribution scheme, ALTO 2812 Clients obtaining ALTO information must be able to validate the 2813 received ALTO information to ensure that it was generated by an 2814 appropriate ALTO Server. Support for this validation is not provided 2815 in this document, but may be provided by extension documents. 2817 10.5. Denial of Service 2819 ISPs should be cognizant of the workload at the ALTO Server generated 2820 by certain ALTO Queries, such as certain queries to the Map Filtering 2821 Service and Ranking Service. In particular, queries which can be 2822 generated with low effort but result in expensive workloads at the 2823 ALTO Server could be exploited for Denial-of-Service attacks. For 2824 instance, a simple ALTO query with n Source Network Locations and m 2825 Destination Network Locations can be generated fairly easily but 2826 results in the computation of n*m Path Costs between pairs by the 2827 ALTO Server (see Section 5.2). One way to limit Denial-of-Service 2828 attacks is to employ access control to the ALTO server. Another 2829 possible mechanism for an ALTO Server to protect itself against a 2830 multitude of computationally expensive bogus requests is to demand 2831 that each ALTO Client to solve a computational puzzle first before 2832 allocating resources for answering a request (see, e.g., 2833 [I-D.jennings-sip-hashcash]). The current specification does not use 2834 such computational puzzles, and discussion regarding tradeoffs of 2835 such an approach would be needed before including such a technique in 2836 the ALTO Protocol. 2838 ISPs should also leverage the fact that the the Map Service allows 2839 ALTO Servers to pre-generate maps that can be useful to many ALTO 2840 Clients. 2842 10.6. ALTO Server Access Control 2844 In order to limit access to an ALTO server (e.g., for an ISP to only 2845 allow its users to access its ALTO server, or to prevent Denial-of- 2846 Service attacks by arbitrary hosts from the Internet), an ALTO server 2847 may employ access control policies. Depending on the use-case and 2848 scenario, an ALTO server may restrict access to its services more 2849 strictly or rather openly (see [I-D.stiemerling-alto-deployments] for 2850 a more detailed discussion on this issue). 2852 11. References 2854 11.1. Normative References 2856 [IEEE.754.2008] 2857 Institute of Electrical and Electronics Engineers, 2858 "Standard for Binary Floating-Point Arithmetic", IEEE 2859 Standard 754, August 2008. 2861 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2862 Extensions (MIME) Part Two: Media Types", RFC 2046, 2863 November 1996. 2865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2866 Requirement Levels", BCP 14, RFC 2119, March 1997. 2868 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2869 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2870 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2872 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2873 Resource Identifier (URI): Generic Syntax", STD 66, 2874 RFC 3986, January 2005. 2876 [RFC4627] Crockford, D., "The application/json Media Type for 2877 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 2879 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 2880 (CIDR): The Internet Address Assignment and Aggregation 2881 Plan", BCP 122, RFC 4632, August 2006. 2883 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2884 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2885 May 2008. 2887 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 2888 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 2889 October 2008. 2891 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2892 Address Text Representation", RFC 5952, August 2010. 2894 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2895 Verification of Domain-Based Application Service Identity 2896 within Internet Public Key Infrastructure Using X.509 2897 (PKIX) Certificates in the Context of Transport Layer 2898 Security (TLS)", RFC 6125, March 2011. 2900 11.2. Informative References 2902 [BitTorrent] 2903 "Bittorrent Protocol Specification v1.0", 2904 . 2906 [I-D.akonjang-alto-proxidor] 2907 Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 2908 Saucez, "The PROXIDOR Service", 2909 draft-akonjang-alto-proxidor-00 (work in progress), 2910 March 2009. 2912 [I-D.gu-alto-redistribution] 2913 Yingjie, G., Alimi, R., and R. Even, "ALTO Information 2914 Redistribution", draft-gu-alto-redistribution-03 (work in 2915 progress), July 2010. 2917 [I-D.ietf-alto-reqs] 2918 Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, 2919 "Application-Layer Traffic Optimization (ALTO) 2920 Requirements", draft-ietf-alto-reqs-08 (work in progress), 2921 March 2011. 2923 [I-D.ietf-alto-server-discovery] 2924 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 2925 S. Yongchao, "ALTO Server Discovery", 2926 draft-ietf-alto-server-discovery-03 (work in progress), 2927 March 2012. 2929 [I-D.jenkins-alto-cdn-use-cases] 2930 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 2931 S. Previdi, "Use Cases for ALTO within CDNs", 2932 draft-jenkins-alto-cdn-use-cases-03 (work in progress), 2933 June 2012. 2935 [I-D.jennings-sip-hashcash] 2936 Jennings, C., "Computational Puzzles for SPAM Reduction in 2937 SIP", draft-jennings-sip-hashcash-06 (work in progress), 2938 July 2007. 2940 [I-D.mrw-nat66] 2941 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 2942 Translation", draft-mrw-nat66-16 (work in progress), 2943 April 2011. 2945 [I-D.p4p-framework] 2946 Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, 2947 "P4P: Provider Portal for P2P Applications", 2948 draft-p4p-framework-00 (work in progress), November 2008. 2950 [I-D.saumitra-alto-multi-ps] 2951 Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 2952 Dimensional Peer Selection Problem", 2953 draft-saumitra-alto-multi-ps-00 (work in progress), 2954 October 2008. 2956 [I-D.saumitra-alto-queryresponse] 2957 Das, S. and V. Narayanan, "A Client to Service Query 2958 Response Protocol for ALTO", 2959 draft-saumitra-alto-queryresponse-00 (work in progress), 2960 March 2009. 2962 [I-D.shalunov-alto-infoexport] 2963 Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 2964 Export Service", draft-shalunov-alto-infoexport-00 (work 2965 in progress), October 2008. 2967 [I-D.stiemerling-alto-deployments] 2968 Stiemerling, M. and S. Kiesel, "ALTO Deployment 2969 Considerations", draft-stiemerling-alto-deployments-06 2970 (work in progress), January 2011. 2972 [I-D.wang-alto-p4p-specification] 2973 Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, 2974 "P4P Protocol Specification", 2975 draft-wang-alto-p4p-specification-00 (work in progress), 2976 March 2009. 2978 [P4P-SIGCOMM08] 2979 Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A. 2980 Silberschatz, "P4P: Provider Portal for (P2P) 2981 Applications", SIGCOMM 2008, August 2008. 2983 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 2984 Optimization (ALTO) Problem Statement", RFC 5693, 2985 October 2009. 2987 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 2988 IPv4/IPv6 Translation", RFC 6144, April 2011. 2990 Appendix A. Acknowledgments 2992 Thank you to Jan Seedorf for contributions to the Security 2993 Considerations section. 2995 We would like to thank the following people whose input and 2996 involvement was indispensable in achieving this merged proposal: 2998 Obi Akonjang (DT Labs/TU Berlin), 3000 Saumitra M. Das (Qualcomm Inc.), 3002 Syon Ding (China Telecom), 3004 Doug Pasko (Verizon), 3006 Laird Popkin (Pando Networks), 3008 Satish Raghunath (Juniper Networks), 3010 Albert Tian (Ericsson/Redback), 3012 Yu-Shun Wang (Microsoft), 3014 David Zhang (PPLive), 3016 Yunfei Zhang (China Mobile). 3018 We would also like to thank the following additional people who were 3019 involved in the projects that contributed to this merged document: 3020 Alex Gerber (AT&T), Chris Griffiths (Comcast), Ramit Hora (Pando 3021 Networks), Arvind Krishnamurthy (University of Washington), Marty 3022 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 3023 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T), 3024 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 3025 Damien Saucez (UCL) Thomas Scholl (AT&T), Emilio Sepulveda 3026 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 3027 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 3028 (Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia 3029 Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University), 3030 Haiyong Xie (Yale University). 3032 Appendix B. Authors 3034 [[CmtAuthors: RFC Editor: Please move information in this section to 3035 the Authors' Addresses section at publication time.]] 3037 Stefano Previdi 3038 Cisco 3040 Email: sprevidi@cisco.com 3042 Stanislav Shalunov 3043 BitTorrent 3045 Email: shalunov@bittorrent.com 3047 Richard Woundy 3048 Comcast 3050 Richard_Woundy@cable.comcast.com 3052 Authors' Addresses 3054 Richard Alimi (editor) 3055 Google 3056 1600 Amphitheatre Parkway 3057 Mountain View CA 3058 USA 3060 Email: ralimi@google.com 3062 Reinaldo Penno (editor) 3063 Cisco Systems 3064 170 West Tasman Dr 3065 San Jose CA 3066 USA 3068 Email: repenno@cisco.com 3069 Y. Richard Yang (editor) 3070 Yale University 3071 51 Prospect St 3072 New Haven CT 3073 USA 3075 Email: yry@cs.yale.edu