idnits 2.17.1 draft-penno-alto-protocol-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2009) is 5399 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) -- Looks like a reference, but probably isn't: 'ATTP' on line 199 ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '2') ** Obsolete normative reference: RFC 2616 (ref. '3') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-02) exists of draft-kiesel-alto-reqs-01 == Outdated reference: A later version (-05) exists of draft-marocco-alto-problem-statement-04 == Outdated reference: A later version (-03) exists of draft-song-alto-server-discovery-00 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG R. Penno, Ed. 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track Y. Yang, Ed. 5 Expires: January 14, 2010 Yale University 6 July 13, 2009 8 ALTO Protocol 9 draft-penno-alto-protocol-03.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 14, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Applications already have access to great amount of underlying 48 network topology information. For example, views of the Internet 49 routing table are easily available at looking glass servers and 50 entirely practical to downloaded by clients. What is missing is 51 network side information such as the network preference information 52 -- what an ISP or Content Provider actually prefers -- and a way to 53 distribute it. 55 The ALTO Service provides information such as preferences of network 56 resources with the goal of modifying network resource consumption 57 patterns while maintaining or improving application performance. 58 This document describes a protocol implementing the ALTO Service. 59 While such service would primarily be provided by the network (i.e., 60 the ISP), content providers and third parties could also operate this 61 service. Applications that could use this service are those that 62 have a choice in connection endpoints. Examples of such applications 63 are peer-to-peer (P2P) and content delivery networks. 65 Requirements Language 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [1]. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1.1. Background and Problem Statement . . . . . . . . . . . . . 6 75 1.2. Design History and Merged Proposals . . . . . . . . . . . 6 76 1.3. Solution Benefits . . . . . . . . . . . . . . . . . . . . 6 77 1.3.1. Service Providers . . . . . . . . . . . . . . . . . . 7 78 1.3.2. P2P Applications . . . . . . . . . . . . . . . . . . . 7 79 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 81 2.1.1. Endpoint Address . . . . . . . . . . . . . . . . . . . 7 82 2.1.2. Network Location . . . . . . . . . . . . . . . . . . . 8 83 2.2. ALTO Service and Protocol Scope . . . . . . . . . . . . . 8 84 2.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 9 85 2.3.1. Server Capability . . . . . . . . . . . . . . . . . . 9 86 2.3.2. Endpoint Property . . . . . . . . . . . . . . . . . . 10 87 2.3.3. Reverse Property Map . . . . . . . . . . . . . . . . . 10 88 2.3.4. Path Property Lookup . . . . . . . . . . . . . . . . . 10 89 3. Network Map . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 3.1. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 3.2. Example Network Map . . . . . . . . . . . . . . . . . . . 11 92 3.3. Endpoint PID Query . . . . . . . . . . . . . . . . . . . . 12 93 3.4. Reverse Network Map Query . . . . . . . . . . . . . . . . 12 94 4. Path Rating . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 4.1. Path Cost . . . . . . . . . . . . . . . . . . . . . . . . 12 96 4.1.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . 12 97 4.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 12 98 4.2. Path Rating Query . . . . . . . . . . . . . . . . . . . . 13 99 4.2.1. Cost Map . . . . . . . . . . . . . . . . . . . . . . . 13 100 4.2.2. Ranking List . . . . . . . . . . . . . . . . . . . . . 13 101 4.2.3. Implicit Source Network Location . . . . . . . . . . . 14 102 4.2.4. Implicit Destination Network Location . . . . . . . . 14 103 4.2.5. Network Map and Cost Map Dependency . . . . . . . . . 14 104 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14 105 5.1. Design Approach . . . . . . . . . . . . . . . . . . . . . 14 106 5.1.1. Use of Existing Infrastructure . . . . . . . . . . . . 14 107 5.1.2. ALTO Information Reuse and Redistribution . . . . . . 15 108 5.2. Message Format . . . . . . . . . . . . . . . . . . . . . . 15 109 5.2.1. Query Message . . . . . . . . . . . . . . . . . . . . 15 110 5.2.2. Response Message . . . . . . . . . . . . . . . . . . . 16 111 5.2.3. Query and Response Body Encoding . . . . . . . . . . . 16 112 6. Protocol Messaging . . . . . . . . . . . . . . . . . . . . . . 17 113 6.1. Client Processing . . . . . . . . . . . . . . . . . . . . 17 114 6.1.1. General Processing . . . . . . . . . . . . . . . . . . 17 115 6.1.2. General Error Conditions . . . . . . . . . . . . . . . 17 116 6.2. Server Processing . . . . . . . . . . . . . . . . . . . . 17 117 6.2.1. General Error Conditions . . . . . . . . . . . . . . . 17 118 6.3. ALTO Queries . . . . . . . . . . . . . . . . . . . . . . . 18 119 6.3.1. Server Capability . . . . . . . . . . . . . . . . . . 18 120 6.3.2. Endpoint Property Lookup . . . . . . . . . . . . . . . 19 121 6.3.3. Reverse Property Lookup . . . . . . . . . . . . . . . 21 122 6.3.4. Path Rating Lookup . . . . . . . . . . . . . . . . . . 22 123 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 26 124 7.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 26 125 7.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 28 126 7.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 29 127 8. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 30 128 8.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 30 129 8.2. Network Address Translation Considerations . . . . . . . . 30 130 8.3. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . 31 131 8.4. Endpoint and Path Properties . . . . . . . . . . . . . . . 31 132 8.5. P2P Peer Selection . . . . . . . . . . . . . . . . . . . . 31 133 8.5.1. Client-based Peer Selection . . . . . . . . . . . . . 32 134 8.5.2. Server-based Peer Selection . . . . . . . . . . . . . 32 135 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 136 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 137 10.1. ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 138 10.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 32 139 10.3. ALTO Information . . . . . . . . . . . . . . . . . . . . . 33 140 10.4. ALTO Information Redistribution . . . . . . . . . . . . . 33 141 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 142 11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 143 11.2. Informative References . . . . . . . . . . . . . . . . . . 34 144 Appendix A. Data Types . . . . . . . . . . . . . . . . . . . . . 35 145 A.1. Endpoint Name . . . . . . . . . . . . . . . . . . . . . . 35 146 A.2. PID Name . . . . . . . . . . . . . . . . . . . . . . . . . 35 147 A.3. Property Name . . . . . . . . . . . . . . . . . . . . . . 35 148 A.4. IP Prefix . . . . . . . . . . . . . . . . . . . . . . . . 35 149 A.5. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . 35 150 A.6. Cost Mode . . . . . . . . . . . . . . . . . . . . . . . . 36 151 A.7. Constraint . . . . . . . . . . . . . . . . . . . . . . . . 36 152 Appendix B. XML Encoding . . . . . . . . . . . . . . . . . . . . 36 153 B.1. Server Configuration . . . . . . . . . . . . . . . . . . . 36 154 B.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . 37 155 B.3. Endpoint List . . . . . . . . . . . . . . . . . . . . . . 37 156 B.4. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 157 B.5. PID List . . . . . . . . . . . . . . . . . . . . . . . . . 37 158 B.6. Cost Map Specification . . . . . . . . . . . . . . . . . . 37 159 B.7. Cost Row . . . . . . . . . . . . . . . . . . . . . . . . . 37 160 B.8. Cost Map . . . . . . . . . . . . . . . . . . . . . . . . . 37 161 Appendix C. Additional Protocol Message Examples . . . . . . . . 38 162 C.1. Endpoint Property Lookup . . . . . . . . . . . . . . . . . 38 163 C.2. Reverse Property Lookup . . . . . . . . . . . . . . . . . 39 164 C.3. Path Cost Lookup . . . . . . . . . . . . . . . . . . . . . 41 165 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 41 166 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 44 167 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 169 1. Introduction 171 1.1. Background and Problem Statement 173 Today, network information available to applications is mostly from 174 the view of endhosts. There is no clear mechanism to convey 175 information about the network's preferences to applications. By 176 leveraging better network-provided information, applications have 177 potential to become more network-efficient (e.g., reduce network 178 resource consumption) and achieve better application performance 179 (e.g., accelerated download rate). The ALTO Service intends to 180 provide a simple way to convey network information to applications. 182 The goal of the protocol specified in this document is to provide a 183 simple, unified protocol that meets the ALTO requirements [5], 184 providing a migration path for Internet Service Providers (ISP), 185 Content Providers, and clients that have deployed protocols with 186 similar intentions (see below). This document is a work in progress 187 and will be updated with further developments. 189 1.2. Design History and Merged Proposals 191 The protocol specified here consists of contributions from 193 o P4P [6],[7]; 195 o ALTO Info-Export [8]; 197 o Query/Response [9],[10]; 199 o ATTP [ATTP]. 201 o Proxidor [19]. 203 The people listed here should be viewed as co-authors of this 204 document: Obi Akonjang, Richard Alimi, Saumitra M. Das, Syon Ding, 205 Anja Feldmann, Doug Pasko, Reinaldo Penno, Laird Popkin, Stefano 206 Previdi, Satish Raghunath, Stanislav Shalunov, Albert Tian, Yu-Shun 207 Wang, Richard Woundy, Y. Richard Yang, David Zhang, and Yunfei Zhang. 208 Due to the limit of 5 authors per draft, the complete list of authors 209 were moved to the contributors section at this point. 211 1.3. Solution Benefits 213 The ALTO Service offers many benefits to both end-users (consumers of 214 the service) and Internet Service Providers (providers of the 215 service). 217 1.3.1. Service Providers 219 The ALTO Service enables ISPs to influence the neighborhood selection 220 process of overlay networks to increase locality of traffic and also 221 regain the ability to efficiently engineer traffic that traverses 222 more expensive links such as backbone and transit links, thus 223 allowing a better provisioning of the networking infrastructure. 225 1.3.2. P2P Applications 227 Applications that use the ALTO Service can benefit in multiple ways. 228 For example, they may no longer need to infer topology information, 229 and some applications can reduce reliance on measuring path 230 performance metrics themselves. They can take advantage of the ISP's 231 knowledge to avoid bottlenecks and boost performance. 233 2. Architecture 235 Two key design objectives of the ALTO Protocol are simplicity and 236 extensibility. At the same time, it introduces additional techniques 237 to address potential scalability and privacy issues. Below we start 238 with an introduction to the terminology. Then we define the overall 239 architecture and how the ALTO Protocol fits into the architecture. 240 At the end of this section, we specify the simple, but general 241 protocol framework which demonstrates its extensibility. 243 2.1. Terminology 245 We use the following terms defined in [11]: Application, Overlay 246 Network, Peer, Resource, Resource Identifier, Resource Provider, 247 Resource Consumer, Resource Directory, Transport Address, Host 248 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 249 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 250 Transit Traffic. 252 We also use the following additional terms: Endpoint Address and 253 Network Location. 255 2.1.1. Endpoint Address 257 An endpoint address represents the communication address of an end 258 point. An endpoint address can be network-attachment based (IP 259 address) or network-attachment agnostic. Common forms of endpoint 260 addresses include IP address, MAC address, overlay ID, and phone 261 number. 263 2.1.2. Network Location 265 Network Location is a generic concept denoting a single endpoint or 266 group of endpoints. Whenever we say Network Location, we refer to 267 either a single endpoint or a group of endpoints. 269 2.2. ALTO Service and Protocol Scope 271 An ALTO Server conveys the network information from the perspective 272 of a network region. We say that the ALTO Server presents its "my- 273 Internet View" [12] of the network region. A network region in this 274 context can be an Autonomous System, an ISP, perhaps a smaller 275 region, or perhaps a set of ISPs; the details depend on the 276 deployment scenario and discovery mechanism. 278 To better understand the ALTO Service and the role of the ALTO 279 Protocol, we show in Figure 1 the overall system architecture. In 280 this architecture, an ALTO Client uses ALTO Service Discovery to 281 identify an appropriate ALTO Server; an ALTO Server prepares ALTO 282 Information; and the ALTO Client requests available ALTO Information 283 from the ALTO Server using the ALTO Protocol. 285 The ALTO Information provided by the ALTO Server can be updated 286 dynamically based on network conditions, or can be seen as a policy 287 which is updated at a larger time-scale. 289 More specifically, the ALTO Information provided by an ALTO Server 290 may be influenced (at the operator's discretion) by other systems. 291 Examples include (but are not limited to) static network 292 configuration databases, dynamic network information, routing 293 protocols, provisioning policies, and interfaces to outside parties. 294 These components are shown in the figure for completeness but outside 295 the scope of this specification. 297 +-------------------------------------------------------------------+ 298 | ISP | 299 | | 300 | +-----------+ | 301 | | Routing | | 302 | +--------------+ | Protocols | | 303 | | Provisioning | +-----------+ | 304 | | Policy | | | 305 | +--------------+\ | | 306 | \ | | 307 | \ | | 308 | +-----------+ \+---------+ +--------+ | 309 | |Dynamic | | ALTO | ALTO Protocol | ALTO | | 310 | |Network |.......| Server | -------------------- | Client | | 311 | |Information| +---------+ +--------+ | 312 | +-----------+ / / | 313 | / ALTO SD Query/Response / | 314 | / / | 315 | +----------+ +--------------+ | 316 | | External | | ALTO Service | | 317 | | Interface| | Discovery | | 318 | +----------+ +--------------+ | 319 | | | 320 | | Figure 1: Basic ALTO Architecture. | 321 | | | 322 +-------------------------------------------------------------------+ 323 | 324 +------------------+ 325 | Third Parties | 326 | | 327 | Content Providers| 328 +------------------+ 330 ALTO Architecture 332 2.3. Query Types 334 As a general framework, ALTO Information is provided via the ALTO 335 Protocol by answering the following four types of queries: 337 2.3.1. Server Capability 339 It lists the details on the information that can be provided by an 340 ALTO Server. 342 2.3.2. Endpoint Property 344 Given an endpoint, it gives the set of network-aware properties 345 associated with the endpoint. An example endpoint property is its 346 Network Location property or connectivity type (e.g., ADSL, Cable, or 347 FioS). 349 2.3.3. Reverse Property Map 351 It is the reverse of the preceding. In particular, given a property, 352 it lists the endpoints with the property. 354 2.3.4. Path Property Lookup 356 It gives information on the properties of paths among Network 357 Locations. 359 3. Network Map 361 The preceding section specifies a simple, extensible ALTO Protocol 362 framework. In this section, we focus on a particular endpoint 363 property named Network Map. In the next section, we introduce a 364 particular path property named Path Rating. 366 In reality many endpoints are very close to one another in terms of 367 network connectivity, for example, endpoints on the same site of an 368 enterprise. By treating a group of endpoints together as a single 369 entity in ALTO, we can achieve much greater scalability without 370 loosing any critical information. 372 The Network Location endpoint property allows an ALTO Server to group 373 endpoints together to indicate their proximity. The resulting set of 374 groupings is called the ALTO Network Map. 376 The Network Map may also be used to communicate simple preferences. 377 For example, an ISP may prefer that endpoints associated with the 378 same PoP (Point-of-Presence) in a P2P application communicate locally 379 instead of communicating with endpoints in other PoPs. 381 Note that the definition of proximity varies depending on the 382 granularity of the ALTO algorithm. In one deployment, endpoints on 383 the same subnet may be considered close; while in another deployment, 384 endpoints connected to the same PoP may be considered close. 386 3.1. PID 388 Each group can be identified by a Network Location identifier called 389 a PID. There can be many different ways of grouping the endpoints 390 and assigning PIDs. 392 Thus, a PID is an identifier providing an indirect and network- 393 agnostic way to specify a network aggregation. For example, a PID 394 may be defined (by the ALTO service provider) to denote a subnet, a 395 set of subnets, a metropolitan area, a PoP, an autonomous system, or 396 a set of autonomous systems. Aggregation of endpoints into PIDs can 397 indicate proximity. Also, aggregation can improve scalability. In 398 particular, network preferences (costs) may be specified between 399 PIDs, allowing cost information to be more compact and updated at a 400 smaller time scale than the network aggregations themselves. 402 3.2. Example Network Map 404 Figure 1 illustrates an example Network Map. PIDs are used to 405 identify network-agnostic aggregations. 407 .--------------------------------------------------------. 408 | ALTO Network Map | 409 | | 410 | .--------------------------------. .---------------. | 411 | | NetLoc: PID-1 | | NetLoc: PID-2 | | 412 | | .---------------------------. | | ... | | 413 | | | 128.36.0.0/16 | | `---------------` | 414 | | | .-----------------------. | | | 415 | | | | Endpoint: 128.36.9.8 | | | .---------------. | 416 | | | `-----------------------` | | | NetLoc: PID-3 | | 417 | | `---------------------------` | | ... | | 418 | | .---------------------------. | `---------------` | 419 | | | 130.132.0.0/16 | | | 420 | | | .-----------------------. | | .---------------. | 421 | | | | Endpoint: 130.132.1.2 | | | | NetLoc: PID-4 | | 422 | | | `-----------------------` | | | ... | | 423 | | `---------------------------` | `---------------` | 424 | `--------------------------------` | 425 | | 426 `--------------------------------------------------------` 428 Figure 1: Example Network Map 430 3.3. Endpoint PID Query 432 The Endpoint Property query against the Network Map allows an ALTO 433 Client to retrieve the PID of a given endpoint. 435 3.4. Reverse Network Map Query 437 The Reverse Property Map query for Network Map allows an ALTO Client 438 to obtain a map from PIDs to lists of endpoints: for each PID, the 439 map includes its list of endpoints. 441 4. Path Rating 443 In this section we define a particular path property named Path 444 Rating. 446 4.1. Path Cost 448 Path Rating is based on Path Cost, which conveys the preference of an 449 ALTO Server on communication among Network Locations. Path Costs 450 have attributes: 452 o Type: identifies what the costs represent; 454 o Mode: identifies how the costs should be interpreted (numerical or 455 ordinal interpretation). 457 4.1.1. Cost Type 459 The Type attribute indicates what the cost represents. For example, 460 an ALTO Server could define costs representing air-miles, hop-counts, 461 or generic routing costs. 463 Cost types are indicated in protocol messages as alphanumeric 464 strings. An ALTO Server MUST at least define the routing cost type 465 denoted by the string 'routingcost'. 467 Note that an ISP may internally compute routing cost using any method 468 it chooses (including air-miles or hop-count). 470 If an ALTO Client requests a Cost Type that is not available, the 471 ALTO Server responds with an error as specified in Section 6.2.1.2. 473 4.1.2. Cost Mode 475 The Mode attribute indicates how costs should be interpreted. For 476 example, an ALTO Server could return costs that should be interpreted 477 as numerical values or ordinal rankings. 479 It is important to communicate such information to ALTO Clients, as 480 certain operations may not be valid on certain costs returned by an 481 ALTO Server. For example, it is possible for an ALTO Server to 482 return a set of IP addresses with costs indicating a ranking of the 483 IP addresses. Arithmetic operations, such as summation, that would 484 make sense for numerical values, do not make sense for ordinal 485 rankings. ALTO Clients may want to handle such costs differently. 487 Cost Modes are indicated in protocol messages as alphanumeric 488 strings. An ALTO Server MUST at least define the modes 'numerical' 489 and 'ordinal'. 491 If an ALTO Client requests a cost Mode that is not supported, the 492 ALTO Server MUST reply with costs having Mode either 'numerical' or 493 'ordinal'. Thus, an ALTO Server must implement at least one of 494 'numerical' or 'ordinal' Costs, but it may choose which to support. 495 ALTO Clients may choose how to handle such situations. Two 496 particular possibilities are to use the returned costs as-is (e.g., 497 treat numerical costs as ordinal rankings) or ignore the ALTO 498 information altogether. 500 4.2. Path Rating Query 502 The Path Rating Query consists of a Cost Type, a Cost Mode, a list of 503 Source Network Locations (note that a Network Location can be an 504 endpoint address or a PID), and a list of Destination Network 505 Locations. 507 Specifically, assume that a Path Rating query has a list of multiple 508 Source Network Locations, say [Src_1, Src_2, ..., Src_m], and a list 509 of multiple Destination Network Locations, say [Dst_1, Dst_2, ..., 510 Dst_n], then the ALTO Server will compute the Path Cost for each 511 communicating pair (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., 512 Src_m -> Dst_1, ..., Src_m -> Dst_n). 514 4.2.1. Cost Map 516 We refer to the Response containing the m*n entries as a Cost Map. 518 If the Cost Type is ordinal, the ranking of each communicating pair 519 is relative to the m*n entries. 521 4.2.2. Ranking List 523 If there is a single Source Network Location and the Cost Mode is 524 ordinal, we also say that the response is a Ranking List. 526 4.2.3. Implicit Source Network Location 528 If the Source Network Location is not specified in the Query message, 529 it is inferred by the ALTO server as the address of the Query message 530 sender. 532 4.2.4. Implicit Destination Network Location 534 If the Destination Network Location is not specified in the Query 535 message, it is inferred by the ALTO server as the list of all PIDs. 537 4.2.5. Network Map and Cost Map Dependency 539 Note that if a Path Rating query contains any PID in the list of 540 Source Network Locations or the list of Destination Network 541 Locations, we say that the particular Path Rating is generated based 542 on a particular Network Map. Version Tags are introduced to ensure 543 that ALTO Clients are able to use consistent information even though 544 the information is provided in two maps. One advantage of separating 545 ALTO information into a Network Map and a Cost Map is that the two 546 components can be updated at different time scales. For example, 547 Network Maps may be stable for a longer time while Cost Maps may be 548 updated to reflect dynamic network conditions. 550 5. Protocol Overview 552 5.1. Design Approach 554 The ALTO Protocol design uses a RESTful interface using a lightweight 555 XML encoding, with the goal of leveraging current HTTP [2] [3] 556 implementations and infrastructure. ALTO messages are denoted with 557 HTTP Content-Type "application/alto". 559 These design decisions make the protocol easy to understand and 560 debug, and allows for flexible ALTO Server implementation strategies. 561 More importantly, however, this enables use of existing 562 implementations and infrastructure, and allows for simple caching and 563 redistribution of ALTO information to increase scalability. 565 5.1.1. Use of Existing Infrastructure 567 An important design consideration for the ALTO Protocol is easy 568 integration with existing applications and infrastructure. As 569 outlined above, HTTP is a natural choice. In particular, this ALTO 570 Protocol design leverages: 572 o the huge installed base of HTTP infrastructure, including HTTP 573 caches, 575 o mature software implementations for both HTTP and XML, 577 o the fact that many P2P clients already have an embedded HTTP 578 client, and 580 o authentication and encryption mechanisms in HTTP and SSL. 582 5.1.2. ALTO Information Reuse and Redistribution 584 ALTO information may be useful to a large number of applications and 585 users. Distributing ALTO information must be efficient and not 586 become a bottleneck. Therefore, the ALTO Protocol specified in this 587 document integrates with existing HTTP caching infrastructure to 588 allow reuse of ALTO information by ALTO Clients and reduce load on 589 ALTO servers. ALTO information may also be cached or redistributed 590 using application-dependent mechanisms, such as P2P DHTs or P2P file- 591 sharing. 593 For example, a Cost Map amongst PIDs may be reused by all ALTO 594 Clients within a particular Source Grouping [12]. A full Network Map 595 may be reused by all ALTO Clients using the ALTO Server. 597 5.2. Message Format 599 The ALTO Protocol uses a RESTful design operating over HTTP. Both 600 Query and Response follow the standard format for HTTP Request and 601 Response messages [2] [3]. This section provides an overview of the 602 components of a Query message sent from an ALTO Client to an ALTO 603 Server, as well as the components of a Response message returned by 604 an ALTO Server. Note that if caching or redistribution is used, the 605 Response message may be returned from another (possibly third-party) 606 entity. Reuse and Redistrubution is further discussed in 607 Section 10.4. 609 5.2.1. Query Message 611 A Query message is generated by an ALTO Client and sent to an ALTO 612 Server. The ALTO Protocol employs the following components of the 613 HTTP request message: 615 Method: Indicates operation requested by the ALTO Client (along with 616 URI Path). 618 URI Path: Indicates the operation requested by the ALTO Client 619 (along with Method). 621 URI Query String Parameters: Indicates parameters for the requested 622 operation. Note that in the messaging specification in Section 6, 623 we abbreviate these as 'URI QS Params'. Order of query string 624 parameters is not specified. Some parameters are restricted in 625 how many times they appear. We use the notation 'min..max' to 626 denote the the minimum and maximum times they may appear, where 627 'max' may be '*' to denote unbounded. 629 Headers: Indicates encoding of the Body. 631 Body: Indicates additional request parameters that are not concisely 632 representable as Query String parameters. 634 5.2.2. Response Message 636 A Response message is generated by an ALTO Server, which corresponds 637 to a particular Query message. The ALTO Protocol employs the 638 following components of the HTTP Response message: 640 Status Code: Indicates either success or an error condition. 642 Headers: Indicates encoding of the Body and caching directives. 644 Body: Contains data requested by the ALTO Client. 646 5.2.3. Query and Response Body Encoding 648 When the Body of a Query or Response message is not empty, it MUST 649 contain a well-formed XML document and it SHOULD contain an encoding 650 declaration in the XML declaration. If the charset parameter of the 651 MIME content type declaration is present and it is different from the 652 encoding declaration, the charset parameter takes precedence. Every 653 application conforment to this specification MUST accept the UTF-8 654 character encoding to ensure maximum interoperability. The namespace 655 for the elements defined in this specification is 656 urn:ietf:params:xml:ns:p2p:alto. 658 659 660 661 ... 662 664 Example XML Document Carried by ALTO Protocol Messages 666 6. Protocol Messaging 668 This section specifies client and server processing, as well as 669 messages in the ALTO Protocol. Details common to ALTO Server 670 processing of all messages is first discussed, followed by details of 671 the individual messages. Note that the primary focus of the current 672 draft is the architecture and protocol operations. This section will 673 be updated as revisions are made to protocol details and encodings. 674 For clarity of the examples, details such as URL encoding have been 675 omitted. 677 6.1. Client Processing 679 6.1.1. General Processing 681 An ALTO Client implementing the ALTO protocol can make use of a set 682 of queries, each for a different purpose. The protocol is structured 683 in such a way that independent of the query type there are a set of 684 general processing steps. The ALTO Client selects a specific ALTO 685 Server to communicate with and establishes a TCP connection. The 686 ALTO protocol on top of this TCP connection can be secured through 687 SSL/TLS. The client then decides which query to use and formats it 688 as specified in Section 6.3, which includes HTTP request-line, 689 headers and body. Finally the client sends it down the TCP/IP stack. 690 All HTTP encoding rules apply, as well as TCP transport 691 considerarions. 693 6.1.2. General Error Conditions 695 In the case the client does not receive an appropriate response from 696 the server it can choose another server to communicate or fall back 697 to perform peer selection without the use of ALTO information. 699 6.2. Server Processing 701 6.2.1. General Error Conditions 703 This section specifies ALTO Server behavior when it recevies a Query 704 message that cannot be processed due to a problem with processing the 705 Query message itself. 707 6.2.1.1. Invalid Query Format 709 If any component of the Query message is formatted incorrectly (i.e., 710 it does not follow the formats in Section 6.3), the ALTO Server MUST 711 return HTTP Status Code 400. 713 6.2.1.2. Unsupported Query 715 If an ALTO Server does not support the operation indicated in the 716 Query message, the ALTO Server MUST return HTTP Status Code 501. 718 6.3. ALTO Queries 720 6.3.1. Server Capability 722 The Server Capability query allows an ALTO Client to determine the 723 configuration of a particular ALTO Server. The configuration 724 includes, for example, details about the operations and cost metrics 725 supported by the ALTO Server. The returned document can be 726 downloaded by ALTO Clients or provisioned into devices. 728 6.3.1.1. Query 730 The Query message MUST follow: 732 Method : 'GET' 733 URI Path : '/capability' 734 URI QS Params : MUST be empty 735 Headers : None required 736 Body : MUST be empty 738 6.3.1.2. Response 740 The Response message MUST follow: 742 Status Code : '200' 743 Headers : 'Content-Encoding: application/alto' 744 Body : See Below 746 The Body MUST be an XML document containing the Server Configuration 747 XML structure in Appendix B.1. 749 6.3.1.3. Example Query and Response 751 GET /capability HTTP/1.1 752 Host: alto.example.com 754 HTTP/1.1 200 OK 755 Date: Fri, 31 Dec 1999 23:59:59 GMT 756 Content-Type: application/alto 757 Content-Length: [...] 759 760 761 762 763 764 765 766 767 768 769 771 6.3.2. Endpoint Property Lookup 773 The Endpoint Property Lookup query allows an ALTO Client to query for 774 properties of Endpoints known to the ALTO Server. 776 6.3.2.1. Query 778 There are multiple forms of the Query message. The Query message 779 from the ALTO Client MUST follow one of the forms. 781 The first form allows an ALTO Client to query for properties of a 782 single endpoint: 784 Method : 'GET' 785 URI Path : '/endpoint/[endpointname]' 786 URI QS Params : 'prop=[propertyname]' (multiplicity: 1..*) 787 Headers : None Required 788 Body : MUST be empty 790 Note that the '[endpointname]' and '[propertyname]' strings above are 791 placeholders to be substituted with valid values indicated in 792 Appendix A.1 and Appendix A.3, respectively. 794 Also note that the 'prop' parameter may be specified multiple times 795 to query for multiple properties simultaneously. For example, the 796 query string could be 'prop=pid&prop=bandwidth'. 798 The second form allows an ALTO Client to query for properties of 799 multiple endpoints: 801 Method : 'POST' 802 URI Path : '/endpoint/m' 803 URI QS Params : 'prop=[propertyname]' (multiplicity: 1..*) 804 Headers : 'Content-Encoding: application/alto' 805 Body : See Below 807 In the second form, the Body MUST be an XML document containing the 808 Endpoint List XML structure in Appendix B.3, with the additional 809 requirement that 'endpoint' elements specify no attributes except for 810 'name'. 812 6.3.2.2. Response 814 The Response message MUST follow: 816 Status Code : '200' if all property types are supported 817 '501' if at least one property is not supported 818 Headers : 'Content-Encoding: application/alto' 819 Body : See Below 821 The Body MUST be an XML document containing the Endpoint List XML 822 structure in Appendix B.3. 824 6.3.2.3. Example Query and Response 826 For additional message examples, see Appendix C.1. 828 GET /endpoint/ipv4:128.36.1.34?prop=pid HTTP/1.1 829 Host: alto.example.com 831 HTTP/1.1 200 OK 832 Date: Fri, 31 Dec 1999 23:59:59 GMT 833 Content-Type: application/alto 834 Content-Length: [...] 836 837 838 839 840 842 Example Query for Single Endpoint 844 6.3.3. Reverse Property Lookup 846 The Reverse Property Lookup query allows an ALTO Client to query for 847 Endpoints with common properties. This draft focuses on the case 848 where an ALTO Client wishes to determine the Endpoints within a PID. 849 For scalability, the Endpoints within a PID may be enumerated using 850 IP Prefixes. 852 6.3.3.1. Query 854 There are multiple forms of the Query message. The Query message 855 from the ALTO Client MUST follow one of the forms. 857 The first form allows an ALTO Client to query for the IP prefixes 858 within a specific PID defined by the ALTO Server: 860 Method : 'GET' 861 URI Path : '/prop/pid/[pidname]' 862 URI QS Params : MUST be empty 863 Headers : None Required 864 Body : MUST be empty 866 Note that the '[pidname]' string above is a placeholder to be 867 substituted with valid values indicated in Appendix A.2. 869 The second form allows an ALTO Client to query for the IP prefixes 870 within all PIDs defined by the ALTO Server: 872 Method : 'GET' 873 URI Path : '/prop/pid' 874 URI QS Params : MUST be empty 875 Headers : None Required 876 Body : MUST be empty 878 The third form allows an ALTO Client to query for the IP prefixes 879 within a specific set of PIDs: 881 Method : 'POST' 882 URI Path : '/prop/pid/m' 883 URI QS Params : MUST be empty 884 Headers : 'Content-Encoding: application/alto' 885 Body : See Below 887 In the second form, the Body MUST be an XML document containing the 888 PID List XML structure in Appendix B.5, with the additional 889 requirement that 'pid' elements specify no attributes except for 890 'name'. 892 6.3.3.2. Response 894 The Response message MUST follow: 896 Status Code : '200' if all PIDs specified in request are 897 valid, or no PIDs are specified in request. 898 '404' if at least one PID specified in request 899 is not valid. 900 Headers : 'Content-Encoding: application/alto' 901 Body : See Below 903 The Body MUST be an XML document containing the PID List XML 904 structure in Appendix B.5. 906 6.3.3.3. Example Query and Response 908 For additional message examples, see Appendix C.2. 910 GET /prop/pid/PID1 HTTP/1.1 911 Host: alto.example.com 913 HTTP/1.1 200 OK 914 Date: Fri, 31 Dec 1999 23:59:59 GMT 915 Content-Type: application/alto 916 Content-Length: [...] 918 919 920 921 922 923 924 925 926 928 Example Query for Single PID 930 6.3.4. Path Rating Lookup 932 The Path Rating Lookup query allows ALTO Clients to query for Costs 933 amongst Network Locations. 935 6.3.4.1. Query 937 There are multiple forms of the Query message. The Query message 938 from the ALTO Client MUST follow one of the forms. 940 The first form allows an ALTO Client to query for costs amongst all 941 PIDs defined by the ALTO Server: 943 Method : 'GET' 944 URI Path : '/cost/map' 945 URI QS Params : 'type=[costtype]' (multiplicity: 0..1) 946 'mode=[costmode]' (multiplicity: 0..1) 947 'constraint=[constraint]' (multiplicity: 0..*) 948 Headers : None Required 949 Body : MUST be empty 951 Note that the '[costtype]', '[costmode]', '[constraint]' strings 952 above are placeholders to be substituted with valid values indicated 953 in Appendix A.5, Appendix A.6, and Appendix A.7 respectively. 955 The 'constraint' parameter is optional and is to be used only if the 956 ALTO service supports it. It allows a client to specify a target 957 numerical cost. The constraint contains two entities: (1) an 958 operator either 'gt' for greater than , 'lt' for less than or 'eq' 959 for equal to with 10 percent on either side, (2) a target numerical 960 cost. The numerical cost is a number that MUST be defined in the 961 units specified in the ALTO service configuration document obtained 962 from ALTO service discovery. These cost constraints allows a 963 resource constrained ALTO client to filter query results at the ALTO 964 server instead of spending network bandwidth and multiple round trips 965 collecting results and performing client side filtering. If multiple 966 'constraint' parameters are specified, the ALTO Server assumes they 967 are related to each other with a logical AND. 969 If the query does not specify the 'type' and 'mode' query string 970 parameters, then the server assumes the type to be 'routingcost' and 971 the mode to be 'numerical'. A Query MUST contain no more than one 972 'type' parameter, and no more than one 'mode' parameter. 974 The second form allows an ALTO Client to query for costs from a 975 single Endpoint or PID to all other PIDs: 977 Method : 'GET' 978 URI Path : '/cost/row' 979 URI QS Params : 'srcpid=[pidname]' (multiplicity: 0..*) 980 'srcendp=[endpointname]' (multiplicity: 0..*) 981 'type=[costtype]' (multiplicity: 0..1) 982 'mode=[costmode]' (multiplicity: 0..1) 983 'constraint=[constraint]' (multiplicity: 0..*) 984 Headers : None Required 985 Body : MUST be empty 987 Note that in this form, exactly one of 'srcpid' and 'srcendp' query 988 string parameters MUST be specified. 990 The third form allows an ALTO Client to query for costs amongst an 991 arbitrary set of sources and destinations: 993 Method : 'POST' 994 URI Path : '/cost/m' 995 URI QS Params : 'type=[costtype]' (multiplicity: 0..1) 996 'mode=[costmode]' (multiplicity: 0..1) 997 'constraint=[constraint]' (multiplicity: 0..*) 998 Headers : 'Content-Encoding: application/alto' 999 Body : See Below 1001 In the third form, the Body MUST be an XML document containing the 1002 Cost Map Specification XML structure in Appendix B.6. 1004 6.3.4.2. Response 1006 The Response message MUST follow: 1008 Status Code : '200' if all PIDs specified in request are 1009 valid, or no PIDs are specified in request. 1010 '404' if at least one PID specified in request 1011 is not valid. 1012 '501' if specified cost type is not supported 1013 '501' if constraints not supported but are 1014 included 1015 Headers : 'Content-Encoding: application/alto' 1016 Body : See Below 1018 The Body MUST be an XML document containing the Cost Map XML 1019 structure in Appendix B.8. 1021 Note that the ALTO Server is not required to return a 501 code 1022 (unsupported query) if an unsupported cost type or cost mode is 1023 specified. In such a case, the ALTO Server MAY instead reply with 1024 Costs for a default type. 1026 6.3.4.3. Examples of Query and Response 1028 We give two examples. For additional message examples, see 1029 Appendix C.3. 1031 GET /cost/map HTTP/1.1 1032 Host: alto.example.com 1034 HTTP/1.1 200 OK 1035 Date: Fri, 31 Dec 1999 23:59:59 GMT 1036 Content-Type: application/alto 1037 Content-Length: [...] 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1052 1053 1054 1055 1056 1058 Example Query for Cost Map for All PIDs 1060 POST /cost/m?mode=ordinal HTTP/1.1 1061 Host: alto.example.com 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1078 HTTP/1.1 200 OK 1079 Date: Fri, 31 Dec 1999 23:59:59 GMT 1080 Content-Type: application/alto 1081 Content-Length: [...] 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1095 Example Query for Specific Destinations (Ranking List) 1097 7. Use Cases 1099 The sections below depict typical use cases. 1101 7.1. ALTO Client Embedded in P2P Tracker 1103 Many P2P currently-deployed P2P systems use a Tracker to manage 1104 swarms and perform peer selection. P2P trackers may currently use a 1105 variety of information to perform peer selection to meet application- 1106 specific goals. By acting as an ALTO Client, an P2P tracker can use 1107 ALTO information as an additional information source to enable more 1108 network-efficient traffic patterns and improve application 1109 performance. 1111 A particular requirement of many P2P trackers is that they must 1112 handle a large number of P2P clients. A P2P tracker can obtain and 1113 locally store ALTO information (the Network Map and Cost Map) from 1114 the ISPs containing the P2P clients, and benefit from the same 1115 aggregation of network locations done by ALTO Servers. 1117 .---------. (1) Get Network Map .---------------. 1118 | | <----------------------> | | 1119 | ALTO | | P2P Tracker | 1120 | Server | (2) Get Cost Map | (ALTO Client) | 1121 | | <----------------------> | | 1122 `---------' `---------------' 1123 ^ | 1124 (3) Get Peers | | (4) Selected Peer 1125 | v List 1126 .---------. .-----------. 1127 | Peer 1 | <-------------- | P2P | 1128 `---------' | Client | 1129 . (5) Connect to `-----------' 1130 . Selected Peers / 1131 .---------. / 1132 | Peer 50 | <------------------ 1133 `---------' 1135 Figure 2: ALTO Client Embedded in P2P Tracker 1137 Figure 2 shows an example use case where a P2P tracker is an ALTO 1138 Client and applies ALTO information when selecting peers for its P2P 1139 clients. The example proceeds as follows: 1141 1. The P2P Tracker requests the Network Map covering all PIDs from 1142 the ALTO Server using the Reverse Property Lookup query. The 1143 Network Map includes the IP prefixes contained in each PID, 1144 allowing the P2P tracker to locally map P2P clients into a PIDs. 1146 2. The P2P Tracker requests the Cost Map amongst all PIDs from the 1147 ALTO Server. 1149 3. A P2P Client joins the swarm, and requests a peer list from the 1150 P2P Tracker. 1152 4. The P2P Tracker returns a peer list to the P2P client. The 1153 returned peer list is computed based on the Network Map and Cost 1154 Map returned by the ALTO Server, and possibly other information 1155 sources. Note that it is possible that a tracker may use only 1156 the Network Map to implement hierarchical peer selection by 1157 preferring peers within the same PID and ISP. 1159 5. The P2P Client connects to the selected peers. 1161 Note that the P2P tracker may provide peer lists to P2P clients 1162 distributed across multiple ISPs. In such a case, the P2P tracker 1163 may communicate with multiple ALTO Servers. 1165 7.2. ALTO Client Embedded in P2P Client: Numerical Costs 1167 P2P clients may also utilize ALTO information themselves when 1168 selecting from available peers. It is important to note that not all 1169 P2P systems use a P2P tracker for peer discovery and selection. 1170 Furthermore, even when a P2P tracker is used, the P2P clients may 1171 rely on other sources, such as peer exchange and DHTs, to discover 1172 peers. 1174 When an P2P Client uses ALTO information, it typically queries only 1175 the ALTO Server servicing its own ISP. The my-Internet view provided 1176 by its ISP's ALTO Server can include preferences to all potential 1177 peers. 1179 .---------. (1) Get Network Map .---------------. 1180 | | <----------------------> | | 1181 | ALTO | | P2P Client | 1182 | Server | (2) Get Cost Map | (ALTO Client) | 1183 | | <----------------------> | | .---------. 1184 `---------' `---------------' <- | P2P | 1185 .---------. / | ^ ^ | Tracker | 1186 | Peer 1 | <-------------- | | \ `---------' 1187 `---------' | (3) Gather Peers 1188 . (4) Select Peers | | \ 1189 . and Connect / .--------. .--------. 1190 .---------. / | P2P | | DHT | 1191 | Peer 50 | <---------------- | Client | `--------' 1192 `---------' | (PEX) | 1193 `--------' 1195 Figure 3: ALTO Client Embedded in P2P Client 1197 Figure 3 shows an example use case where a P2P Client locally applies 1198 ALTO information to select peers. The use case proceeds as follows: 1200 1. The P2P Client requests the Network Map covering all PIDs from 1201 the ALTO Server servicing its own ISP. 1203 2. The P2P Client requests the Cost Map amongst all PIDs from the 1204 ALTO Server. The Cost Map by default specifies numerical costs. 1206 3. The P2P Client discovers peers from sources such as Peer Exchange 1207 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 1208 P2P Trackers. 1210 4. The P2P Client uses ALTO information as part of the algorithm for 1211 selecting new peers, and connects to the selected peers. 1213 7.3. ALTO Client Embedded in P2P Client: Ranking 1215 It is also possible for a P2P Client to offload the selection and 1216 ranking process to an ALTO Server. In this use case, the ALTO Client 1217 gathers a list of known peers in the swarm, and asks the ALTO Server 1218 to rank them. 1220 As in the use case using numerical costs, the P2P Client typically 1221 only queries the ALTO Server servicing its own ISP. 1223 .---------. .---------------. 1224 | | | | 1225 | ALTO | (2) Get Path Ranking | P2P Client | 1226 | Server | <----------------------> | (ALTO Client) | 1227 | | | | .---------. 1228 `---------' `---------------' <- | P2P | 1229 .---------. / | ^ ^ | Tracker | 1230 | Peer 1 | <-------------- | | \ `---------' 1231 `---------' | (1) Gather Peers 1232 . (3) Connect to | | \ 1233 . Selected Peers / .--------. .--------. 1234 .---------. / | P2P | | DHT | 1235 | Peer 50 | <---------------- | Client | `--------' 1236 `---------' | (PEX) | 1237 `--------' 1239 Figure 4: ALTO Client Embedded in P2P Client: Ranking 1241 Figure 4 shows an example of this scenario. The use case proceeds as 1242 follows: 1244 1. The P2P Client discovers peers from sources such as Peer Exchange 1245 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 1246 P2P Trackers. 1248 2. The P2P Client queries its ALTO Server, including discovered 1249 peers as the set of Destination Network Locations, and indicates 1250 the 'ordinal' Cost Mode. The returned Cost Map indicates the 1251 ranking of the candidate peers. 1253 3. The P2P Client connects to the peers in the order specified in 1254 the ranking. 1256 8. Discussions 1258 8.1. Discovery 1260 The particular mechanism by which an ALTO Client discovers its ALTO 1261 Server is an important component to the ALTO architecture and 1262 numerous techniques have been discussed [13] [14]. However, the 1263 discovery mechanism is out of scope for this document. 1265 Some ISPs have proposed the possibility of delegation, in which an 1266 ISP provides information for customer networks which do not wish to 1267 run Portal Servers themselves. A consideration for delegation is 1268 that customer networks may wish to explicitly configure such 1269 delegation. 1271 8.2. Network Address Translation Considerations 1273 At this day and age of NAT v4<->v4, v4<->v6 [15], and possibly 1274 v6<->v6[16], a protocol should strive to be NAT friendly and minimize 1275 carrying IP addresses in the payload, or provide a mode of operation 1276 where the source IP address provide the information necessary to the 1277 server. 1279 The protocol specified in this document provides a mode of operation 1280 (the GetCostMap-Source interface) where the source NL-ID is computed 1281 by the ALTO Server (via the Endpoint Property Lookup interface) from 1282 the source IP address found in the ALTO Client query packets. This 1283 is similar to how some P2P Trackers (e.g., BitTorrent Trackers - see 1284 "Tracker HTTP/HTTPS Protocol" in [17]). 1286 The ALTO client SHOULD use the Session Traversal Utilities for NAT 1287 (STUN) [4] to determine a public IP address to use as a source NL-ID. 1288 If using this method, the host MUST the "Binding Request" message and 1289 the resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the 1290 response. Using STUN requires cooperation from a publicly accessible 1291 STUN server. Thus, the ALTO client also requires configuration 1292 information that identifies the STUN server, or a domain name that 1293 can be used for STUN server discovery. To be selected for this 1294 purpose, the STUN server needs to provide the public reflexive 1295 transport address of the host. 1297 8.3. Mapping IPs to ASNs 1299 It may be desired for the ALTO Protocol to provide ALTO information 1300 including ASNs. Thus, ALTO Clients may need to identify the ASN for 1301 a Resource Provider to determine the cost to that Resource Provider. 1303 Applications can already map IPs to ASNs using information from a BGP 1304 Looking Glass. To do so, they must download a file of about 1.5MB 1305 when compressed (as of October 2008, with all information not needed 1306 for IP to ASN mapping removed) and periodically (perhaps monthly) 1307 refresh it. 1309 Alternatively, Reverse Property Lookup query defined in this document 1310 could be extended to map ASNs into a set of IP prefixes. The 1311 mappings provided by the ISP would be both smaller and more 1312 authoritative. 1314 For simplicity of implementation, it's highly desirable that clients 1315 only have to implement exactly one mechanism of mapping IPs to ASNs. 1317 8.4. Endpoint and Path Properties 1319 An ALTO Server could make available many properties about Endpoints 1320 beyond their network location or grouping. For example, connection 1321 type, geographical location, and others may be useful to 1322 applications. The current draft focuses on network location and 1323 grouping, but the protocol may be extended to handle other Endpoint 1324 properties. 1326 8.5. P2P Peer Selection 1328 This section discusses possible approaches to peer selection using 1329 ALTO information (Network Location Identifiers and associated Costs) 1330 from an ALTO Server. Specifically, the application must select which 1331 peers to use based on this and other sources of information. With 1332 this in mind, the usage of ALTO Costs is intentionally flexible, 1333 because: 1335 Different applications may use the information differently. For 1336 example, an application that connects to just one address may have 1337 a different algorithm for selecting it than an application that 1338 connects to many. 1340 Though initial experiments have been conducted [18], more 1341 investigation is needed to identify other methods. 1343 In addition, the application might account for robustness, perhaps 1344 using randomized exploration to determine if it performs better 1345 without ALTO information. 1347 8.5.1. Client-based Peer Selection 1349 One possibility is for peer selection using ALTO costs to be done 1350 entirely by a P2P client. The following are some techniques have 1351 been proposed and/or used: 1353 o Prefer network locations with lower ordinal rankings (i.e., higher 1354 priority) [19] [8]. 1356 o Optimistically unchoking low-cost peers with higher probability 1357 [8]. 1359 8.5.2. Server-based Peer Selection 1361 Another possibility is for ALTO costs to be used by an Application 1362 Tracker (e.g., BitTorrent Tracker) when returning peer lists. The 1363 following are techniques that have been proposed and/or used: 1365 o Using bandwidth matching (e.g., at an Application Tracker) and 1366 choosing solution (within bound of optimal) with minimal network 1367 cost [18]. 1369 9. IANA Considerations 1371 This document request the registration of a new media type: 1372 "application/alto" 1374 10. Security Considerations 1376 10.1. ISPs 1378 ISPs must be cognizant of the network topology and provisioning 1379 information provided through ALTO Interfaces. ISPs should evaluate 1380 how much information is revealed and the associated risks. In 1381 particular, providing overly fine-grained information may make it 1382 easier for attackers to infer network topology. On the other hand, 1383 revealing overly coarse-grained information may not provide benefits 1384 to network efficiency or performance improvements to ALTO Clients. 1386 10.2. ALTO Clients 1388 Applications using the information must be cognizant of the 1389 possibility that the information is malformed or incorrect. Even 1390 when it is correct, its use might harm the performance. When an 1391 application concludes that it would get better performance 1392 disregarding the ALTO information, the decision to discontinue the 1393 use of ALTO information is likely best left to the user. 1395 ALTO Clients should also be cognizant of revealing Network Location 1396 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, 1397 as doing so may allow the ALTO Server to infer communication 1398 patterns. One possibility is for the ALTO Client to only rely on 1399 Network Map for PIDs and Cost Map amongst PIDs to avoid passing IP 1400 addresses of their peers to the ALTO Server. 1402 The use of SSL/TLS can make it easier for clients to verify the 1403 origin of ALTO information. 1405 10.3. ALTO Information 1407 An ALTO Server may optionally use authentication and encryption to 1408 protect ALTO information. Authentication and encryption may be 1409 provided using HTTP Basic or Digest Authentication and/or SSL/TLS. 1411 10.4. ALTO Information Redistribution 1413 It is possible for applications to redistribute ALTO information to 1414 improve scalability. Even with such a distribution scheme, ALTO 1415 Clients obtaining ALTO information must be able to validate the 1416 received ALTO information to ensure that it was actually generated by 1417 the correct ALTO Server. Further, to prevent the ALTO Server from 1418 being a target of attack, the verification scheme must not require 1419 ALTO Clients to contact the ALTO Server. 1421 To fulfill these requirements, ALTO Information meant to be 1422 redistributable contains a digital signature which includes a hash of 1423 the ALTO information encrypted by the ALTO Server's private key. The 1424 corresponding public key should either be part of the ALTO 1425 information itself, or it could be included in the interface 1426 descriptor. The public key SHOULD include the hostname of the ALTO 1427 Server and it SHOULD be signed by a trusted authority. 1429 11. References 1431 11.1. Normative References 1433 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1434 Levels", BCP 14, RFC 2119, March 1997. 1436 [2] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1437 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1439 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1440 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1441 HTTP/1.1", RFC 2616, June 1999. 1443 [4] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 1444 Traversal Utilities for (NAT) (STUN)", 1445 draft-ietf-behave-rfc3489bis-18 (work in progress), July 2008. 1447 11.2. Informative References 1449 [5] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, 1450 "Application-Layer Traffic Optimization (ALTO) Requirements", 1451 draft-kiesel-alto-reqs-01 (work in progress), November 2008. 1453 [6] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, "P4P: 1454 Provider Portal for P2P Applications", draft-p4p-framework-00 1455 (work in progress), November 2008. 1457 [7] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, "P4P 1458 Protocol Specification", draft-wang-alto-p4p-specification-00 1459 (work in progress), March 2009. 1461 [8] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 1462 Export Service", draft-shalunov-alto-infoexport-00 (work in 1463 progress), October 2008. 1465 [9] Das, S. and V. Narayanan, "A Client to Service Query Response 1466 Protocol for ALTO", draft-saumitra-alto-queryresponse-00 (work 1467 in progress), March 2009. 1469 [10] Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 1470 Dimensional Peer Selection Problem", 1471 draft-saumitra-alto-multi-ps-00 (work in progress), 1472 October 2008. 1474 [11] Seedorf, J. and E. Burger, "Application-Layer Traffic 1475 Optimization (ALTO) Problem Statement", 1476 draft-marocco-alto-problem-statement-04 (work in progress), 1477 February 2009. 1479 [12] Yang, Y., Popkin, L., Penno, R., and S. Shalunov, "An 1480 Architecture of ALTO for P2P Applications", 1481 draft-yang-alto-architecture-00 (work in progress), March 2009. 1483 [13] Garcia, G., Tomsu, M., and Y. Wang, "ALTO Discovery Protocols", 1484 draft-wang-alto-discovery-00 (work in progress), March 2009. 1486 [14] Song, H., Even, R., Pascual, V., and Y. Zhang, "Application- 1487 Layer Traffic Optimization (ALTO): Discover ALTO Servers", 1488 draft-song-alto-server-discovery-00 (work in progress), 1489 March 2009. 1491 [15] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 1492 Translation", draft-baker-behave-v4v6-framework-02 (work in 1493 progress), February 2009. 1495 [16] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address 1496 Translation (NAT66)", draft-mrw-behave-nat66-02 (work in 1497 progress), March 2009. 1499 [17] "Bittorrent Protocol Specification v1.0", 1500 http://wiki.theory.org/BitTorrentSpecification, 2009. 1502 [18] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A. 1503 Silberschatz., "P4P: Provider Portal for (P2P) Applications", 1504 In SIGCOMM 2008. 1506 [19] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 1507 Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00 1508 (work in progress), March 2009. 1510 Appendix A. Data Types 1512 A.1. Endpoint Name 1514 TBD. 1516 A.2. PID Name 1518 TBD. 1520 A.3. Property Name 1522 TBD. 1524 A.4. IP Prefix 1526 TBD. 1528 A.5. Cost Type 1530 TBD. 1532 A.6. Cost Mode 1534 TBD. 1536 A.7. Constraint 1538 TBD. 1540 Appendix B. XML Encoding 1542 B.1. Server Configuration 1544 The Response contains a 'configuration' XML element which contains 1545 the configuration information for an ALTO. service. The 1546 'configuration' element MUST have the following attributes: 1548 o name of the ALTO service 1550 The 'configuration' element MAY contain the following child elements: 1552 o specifies in its 'uri' attribute, the Base URI at which the ALTO 1553 Server can be reached. An ALTO Client uses this URI (e.g., 1554 'http://alto.example.com:6671/') as a prefix placed before URI 1555 Paths when querying an ALTO Server. More than one 'alto-server' 1556 element may be present for load balancing, and an ALTO Client can 1557 choose any one at random. 1559 o specifies a cost metric supported by the ALTO Server. It MUST 1560 have a 'type' attribute indicating the name of the metric, and 1561 MUST have a 'units' attribute indicating the measurement units. 1562 If the metric does not have any units, then the units attribute 1563 must have the value 'none'. unit. If the no 'cost' element is 1564 present, then the ALTO Server is assumed to support the default 1565 'routingcost' Cost metric. Multiple 'cost' elements MAY be 1566 included, but a single Cost Type MUST NOT appear more than once. 1568 o specifies whether the ALTO Server supports Cost constraints in the 1569 Path Cost Lookup Query Section 6.3.4. This element MUST contain a 1570 'value' attribute with value either 'true' or 'false'. The 1571 'constraint-support' element MUST NOT appear more than once. If 1572 the 'constraint-support' element is not present, the ALTO Client 1573 MUST assume that the ALTO Server does not support Cost 1574 constraints. 1576 B.2. Endpoint 1578 An Endpoint is represented by the XML element 'endpoint'. The 1579 following attributes are REQUIRED: 1581 name: Indicates the name of the Endpoint. The value of this 1582 attribute MUST be formatted according to Appendix A.1. 1584 The 'endpoint' element MAY contain additional attributes indicating 1585 endpoint properties and their values. In this case, the attribute 1586 name is the property name, and the attribute value is the value of 1587 the property. Note that 'name' is not a valid property name. 1589 B.3. Endpoint List 1591 A list of Endpoints is represented by the XML element 'endpoints'. 1592 The following attributes are REQUIRED: 1594 size: Specifies the number of endpoints contained in the list as a 1595 non-negative integer. 1597 The 'endpoints' element MAY contain child elements. The following 1598 elements are allowed: 1600 element: Specifies a single endpoint in the list. The number of 1601 'endpoint' elements MUST equal the value of the 'size' attribute 1602 for the containing 'endpoints' element. 1604 B.4. PID 1606 TBD. 1608 B.5. PID List 1610 TBD. 1612 B.6. Cost Map Specification 1614 TBD. 1616 B.7. Cost Row 1618 TBD. 1620 B.8. Cost Map 1622 TBD. 1624 Appendix C. Additional Protocol Message Examples 1626 C.1. Endpoint Property Lookup 1628 POST /endpoint/m?prop=pid HTTP/1.1 1629 Host: alto.example.com 1630 Content-Type: application/alto 1631 Content-Length: [...] 1633 1634 1635 1636 1637 1638 1639 1640 1642 HTTP/1.1 200 OK 1643 Date: Fri, 31 Dec 1999 23:59:59 GMT 1644 Content-Type: application/alto 1645 Content-Length: [...] 1647 1648 1649 1650 1651 1652 1653 1654 1656 Example Query for Multiple Endpoints 1658 C.2. Reverse Property Lookup 1660 GET /prop/pid/ HTTP/1.1 1661 Host: alto.example.com 1663 HTTP/1.1 200 OK 1664 Date: Fri, 31 Dec 1999 23:59:59 GMT 1665 Content-Type: application/alto 1666 Content-Length: [...] 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1686 Example Query for All PIDs 1688 POST /prop/pid/m HTTP/1.1 1689 Host: alto.example.com 1690 Content-Length: [...] 1692 1693 1694 1695 1696 1697 1699 HTTP/1.1 200 OK 1700 Date: Fri, 31 Dec 1999 23:59:59 GMT 1701 Content-Type: application/alto 1702 Content-Length: [...] 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1719 Example Query for Specific PIDs 1721 C.3. Path Cost Lookup 1723 GET /cost/row?srcendp=ipv4:128.36.22.1 HTTP/1.1 1724 Host: alto.example.com 1726 HTTP/1.1 200 OK 1727 Date: Fri, 31 Dec 1999 23:59:59 GMT 1728 Content-Type: application/alto 1729 Content-Length: [...] 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1743 Example Query for Cost Map from a Single Endpoint 1745 Appendix D. Contributors 1747 The people listed here should be viewed as co-authors of the 1748 document. Due to the limit of 5 authors per draft the co-authors 1749 were moved to the contributors section at this point. 1751 Obi Akonjang 1753 DT Labs/TU Berlin/ 1755 EMail: obi@net.t-labs.tu-berlin.de 1757 Richard Alimi 1759 Yale University 1761 EMail: richard.alimi@yale.edu 1762 Saumitra M. Das 1764 Qualcomm Inc. 1766 EMail: saumitra@qualcomm.com 1768 Syon Ding 1770 China Telecom 1772 EMail: syding@chinatelecom.com 1774 Doug Pasko 1776 Verizon 1778 EMail: pasko@verizon.com 1780 Laird Popkin 1782 Pando Networks 1784 EMail: laird@pando.com 1786 Stefano Previdi 1788 Cisco 1790 EMail: sprevidi@cisco.com 1792 Satish Raghunath 1794 Juniper Networks 1796 satishr@juniper.net 1797 Stanislav Shalunov 1799 BitTorrent 1801 EMail: shalunov@bittorrent.com 1803 Albert Tian 1805 Ericsson/Redback 1807 EMail: alberttian@gmail.com 1809 Yu-Shun Wang 1811 Microsoft Corp. 1813 yu-shun.wang@microsoft.com 1815 Richard Woundy 1817 Comcast 1819 Richard_Woundy@cable.comcast.com 1821 David Zhang 1823 PPLive 1825 davidzhang@pplive.com 1827 Yunfei Zhang 1829 China Mobile 1831 zhangyunfei@chinamobile.com 1833 Appendix E. Acknowledgements 1835 We would like to thank the following additional people who were 1836 involved in the projects that contributed to this merged document: 1837 Alex Gerber (AT&T), Chris Griffiths (Comcast), Ramit Hora (Pando 1838 Networks), Arvind Krishnamurthy (University of Washington), Marty 1839 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 1840 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T), 1841 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 1842 Damien Saucez (UCL) Thomas Scholl (AT&T), Emilio Sepulveda 1843 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 1844 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 1845 (Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia 1846 Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University), 1847 Haiyong Xie (Yale University). 1849 Authors' Addresses 1851 Reinaldo Penno (editor) 1852 Juniper Networks 1853 1194 N Mathilda Avenue 1854 Sunnyvale, CA 1855 USA 1857 Email: rpenno@juniper.net 1859 Y. Richard Yang (editor) 1860 Yale University 1862 Email: yry@cs.yale.edu