idnits 2.17.1 draft-penno-alto-protocol-02.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 5372 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 -- Looks like a reference, but probably isn't: 'Proxidor' on line 201 ** 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 (==), 3 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-02.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 [Proxidor]. 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. 1157 5. The P2P Client connects to the selected peers. 1159 Note that the P2P tracker may provide peer lists to P2P clients 1160 distributed across multiple ISPs. In such a case, the P2P tracker 1161 may communicate with multiple ALTO Servers. 1163 7.2. ALTO Client Embedded in P2P Client: Numerical Costs 1165 P2P clients may also utilize ALTO information themselves when 1166 selecting from available peers. It is important to note that not all 1167 P2P systems use a P2P tracker for peer discovery and selection. 1168 Furthermore, even when a P2P tracker is used, the P2P clients may 1169 rely on other sources, such as peer exchange and DHTs, to discover 1170 peers. 1172 When an P2P Client uses ALTO information, it typically queries only 1173 the ALTO Server servicing its own ISP. The my-Internet view provided 1174 by its ISP's ALTO Server can include preferences to all potential 1175 peers. 1177 .---------. (1) Get Network Map .---------------. 1178 | | <----------------------> | | 1179 | ALTO | | P2P Client | 1180 | Server | (2) Get Cost Map | (ALTO Client) | 1181 | | <----------------------> | | .---------. 1182 `---------' `---------------' <- | P2P | 1183 .---------. / | ^ ^ | Tracker | 1184 | Peer 1 | <-------------- | | \ `---------' 1185 `---------' | (3) Gather Peers 1186 . (4) Select Peers | | \ 1187 . and Connect / .--------. .--------. 1188 .---------. / | P2P | | DHT | 1189 | Peer 50 | <---------------- | Client | `--------' 1190 `---------' | (PEX) | 1191 `--------' 1193 Figure 3: ALTO Client Embedded in P2P Client 1195 Figure 3 shows an example use case where a P2P Client locally applies 1196 ALTO information to select peers. The use case proceeds as follows: 1198 1. The P2P Client requests the Network Map covering all PIDs from 1199 the ALTO Server servicing its own ISP. 1201 2. The P2P Client requests the Cost Map amongst all PIDs from the 1202 ALTO Server. The Cost Map by default specifies numerical costs. 1204 3. The P2P Client discovers peers from sources such as Peer Exchange 1205 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 1206 P2P Trackers. 1208 4. The P2P Client uses ALTO information as part of the algorithm for 1209 selecting new peers, and connects to the selected peers. 1211 7.3. ALTO Client Embedded in P2P Client: Ranking 1213 It is also possible for a P2P Client to offload the selection and 1214 ranking process to an ALTO Server. In this use case, the ALTO Client 1215 gathers a list of known peers in the swarm, and asks the ALTO Server 1216 to rank them. 1218 As in the use case using numerical costs, the P2P Client typically 1219 only queries the ALTO Server servicing its own ISP. 1221 .---------. .---------------. 1222 | | | | 1223 | ALTO | (2) Get Path Ranking | P2P Client | 1224 | Server | <----------------------> | (ALTO Client) | 1225 | | | | .---------. 1226 `---------' `---------------' <- | P2P | 1227 .---------. / | ^ ^ | Tracker | 1228 | Peer 1 | <-------------- | | \ `---------' 1229 `---------' | (1) Gather Peers 1230 . (3) Connect to | | \ 1231 . Selected Peers / .--------. .--------. 1232 .---------. / | P2P | | DHT | 1233 | Peer 50 | <---------------- | Client | `--------' 1234 `---------' | (PEX) | 1235 `--------' 1237 Figure 4: ALTO Client Embedded in P2P Client: Ranking 1239 Figure 4 shows an example of this scenario. The use case proceeds as 1240 follows: 1242 1. The P2P Client discovers peers from sources such as Peer Exchange 1243 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and 1244 P2P Trackers. 1246 2. The P2P Client queries its ALTO Server, including discovered 1247 peers as the set of Destination Network Locations, and indicates 1248 the 'ordinal' Cost Mode. The returned Cost Map indicates the 1249 ranking of the candidate peers. 1251 3. The P2P Client connects to the peers in the order specified in 1252 the ranking. 1254 8. Discussions 1256 8.1. Discovery 1258 The particular mechanism by which an ALTO Client discovers its ALTO 1259 Server is an important component to the ALTO architecture and 1260 numerous techniques have been discussed [13] [14]. However, the 1261 discovery mechanism is out of scope for this document. 1263 Some ISPs have proposed the possibility of delegation, in which an 1264 ISP provides information for customer networks which do not wish to 1265 run Portal Servers themselves. A consideration for delegation is 1266 that customer networks may wish to explicitly configure such 1267 delegation. 1269 8.2. Network Address Translation Considerations 1271 At this day and age of NAT v4<->v4, v4<->v6 [15], and possibly 1272 v6<->v6[16], a protocol should strive to be NAT friendly and minimize 1273 carrying IP addresses in the payload, or provide a mode of operation 1274 where the source IP address provide the information necessary to the 1275 server. 1277 The protocol specified in this document provides a mode of operation 1278 (the GetCostMap-Source interface) where the source NL-ID is computed 1279 by the ALTO Server (via the Endpoint Property Lookup interface) from 1280 the source IP address found in the ALTO Client query packets. This 1281 is similar to how some P2P Trackers (e.g., BitTorrent Trackers - see 1282 "Tracker HTTP/HTTPS Protocol" in [17]). 1284 The ALTO client SHOULD use the Session Traversal Utilities for NAT 1285 (STUN) [4] to determine a public IP address to use as a source NL-ID. 1286 If using this method, the host MUST the "Binding Request" message and 1287 the resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the 1288 response. Using STUN requires cooperation from a publicly accessible 1289 STUN server. Thus, the ALTO client also requires configuration 1290 information that identifies the STUN server, or a domain name that 1291 can be used for STUN server discovery. To be selected for this 1292 purpose, the STUN server needs to provide the public reflexive 1293 transport address of the host. 1295 8.3. Mapping IPs to ASNs 1297 It may be desired for the ALTO Protocol to provide ALTO information 1298 including ASNs. Thus, ALTO Clients may need to identify the ASN for 1299 a Resource Provider to determine the cost to that Resource Provider. 1301 Applications can already map IPs to ASNs using information from a BGP 1302 Looking Glass. To do so, they must download a file of about 1.5MB 1303 when compressed (as of October 2008, with all information not needed 1304 for IP to ASN mapping removed) and periodically (perhaps monthly) 1305 refresh it. 1307 Alternatively, Reverse Property Lookup query defined in this document 1308 could be extended to map ASNs into a set of IP prefixes. The 1309 mappings provided by the ISP would be both smaller and more 1310 authoritative. 1312 For simplicity of implementation, it's highly desirable that clients 1313 only have to implement exactly one mechanism of mapping IPs to ASNs. 1315 8.4. Endpoint and Path Properties 1317 An ALTO Server could make available many properties about Endpoints 1318 beyond their network location or grouping. For example, connection 1319 type, geographical location, and others may be useful to 1320 applications. The current draft focuses on network location and 1321 grouping, but the protocol may be extended to handle other Endpoint 1322 properties. 1324 8.5. P2P Peer Selection 1326 This section discusses possible approaches to peer selection using 1327 ALTO information (Network Location Identifiers and associated Costs) 1328 from an ALTO Server. Specifically, the application must select which 1329 peers to use based on this and other sources of information. With 1330 this in mind, the usage of ALTO Costs is intentionally flexible, 1331 because: 1333 Different applications may use the information differently. For 1334 example, an application that connects to just one address may have 1335 a different algorithm for selecting it than an application that 1336 connects to many. 1338 Though initial experiments have been conducted [18], more 1339 investigation is needed to identify other methods. 1341 In addition, the application might account for robustness, perhaps 1342 using randomized exploration to determine if it performs better 1343 without ALTO information. 1345 8.5.1. Client-based Peer Selection 1347 One possibility is for peer selection using ALTO costs to be done 1348 entirely by a P2P client. The following are some techniques have 1349 been proposed and/or used: 1351 o Prefer network locations with lower ordinal rankings (i.e., higher 1352 priority) [19] [8]. 1354 o Optimistically unchoking low-cost peers with higher probability 1355 [8]. 1357 8.5.2. Server-based Peer Selection 1359 Another possibility is for ALTO costs to be used by an Application 1360 Tracker (e.g., BitTorrent Tracker) when returning peer lists. The 1361 following are techniques that have been proposed and/or used: 1363 o Using bandwidth matching (e.g., at an Application Tracker) and 1364 choosing solution (within bound of optimal) with minimal network 1365 cost [18]. 1367 9. IANA Considerations 1369 This document request the registration of a new media type: 1370 "application/alto" 1372 10. Security Considerations 1374 10.1. ISPs 1376 ISPs must be cognizant of the network topology and provisioning 1377 information provided through ALTO Interfaces. ISPs should evaluate 1378 how much information is revealed and the associated risks. In 1379 particular, providing overly fine-grained information may make it 1380 easier for attackers to infer network topology. On the other hand, 1381 revealing overly coarse-grained information may not provide benefits 1382 to network efficiency or performance improvements to ALTO Clients. 1384 10.2. ALTO Clients 1386 Applications using the information must be cognizant of the 1387 possibility that the information is malformed or incorrect. Even 1388 when it is correct, its use might harm the performance. When an 1389 application concludes that it would get better performance 1390 disregarding the ALTO information, the decision to discontinue the 1391 use of ALTO information is likely best left to the user. 1393 ALTO Clients should also be cognizant of revealing Network Location 1394 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, 1395 as doing so may allow the ALTO Server to infer communication 1396 patterns. One possibility is for the ALTO Client to only rely on 1397 Network Map for PIDs and Cost Map amongst PIDs to avoid passing IP 1398 addresses of their peers to the ALTO Server. 1400 The use of SSL/TLS can make it easier for clients to verify the 1401 origin of ALTO information. 1403 10.3. ALTO Information 1405 An ALTO Server may optionally use authentication and encryption to 1406 protect ALTO information. Authentication and encryption may be 1407 provided using HTTP Basic or Digest Authentication and/or SSL/TLS. 1409 10.4. ALTO Information Redistribution 1411 It is possible for applications to redistribute ALTO information to 1412 improve scalability. Even with such a distribution scheme, ALTO 1413 Clients obtaining ALTO information must be able to validate the 1414 received ALTO information to ensure that it was actually generated by 1415 the correct ALTO Server. Further, to prevent the ALTO Server from 1416 being a target of attack, the verification scheme must not require 1417 ALTO Clients to contact the ALTO Server. 1419 To fulfill these requirements, ALTO Information meant to be 1420 redistributable contains a digital signature which includes a hash of 1421 the ALTO information encrypted by the ALTO Server's private key. The 1422 corresponding public key should either be part of the ALTO 1423 information itself, or it could be included in the interface 1424 descriptor. The public key SHOULD include the hostname of the ALTO 1425 Server and it SHOULD be signed by a trusted authority. 1427 11. References 1429 11.1. Normative References 1431 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1432 Levels", BCP 14, RFC 2119, March 1997. 1434 [2] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1435 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1437 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1438 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1439 HTTP/1.1", RFC 2616, June 1999. 1441 [4] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 1442 Traversal Utilities for (NAT) (STUN)", 1443 draft-ietf-behave-rfc3489bis-18 (work in progress), July 2008. 1445 11.2. Informative References 1447 [5] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, 1448 "Application-Layer Traffic Optimization (ALTO) Requirements", 1449 draft-kiesel-alto-reqs-01 (work in progress), November 2008. 1451 [6] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, "P4P: 1452 Provider Portal for P2P Applications", draft-p4p-framework-00 1453 (work in progress), November 2008. 1455 [7] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, "P4P 1456 Protocol Specification", draft-wang-alto-p4p-specification-00 1457 (work in progress), March 2009. 1459 [8] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 1460 Export Service", draft-shalunov-alto-infoexport-00 (work in 1461 progress), October 2008. 1463 [9] Das, S. and V. Narayanan, "A Client to Service Query Response 1464 Protocol for ALTO", draft-saumitra-alto-queryresponse-00 (work 1465 in progress), March 2009. 1467 [10] Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi 1468 Dimensional Peer Selection Problem", 1469 draft-saumitra-alto-multi-ps-00 (work in progress), 1470 October 2008. 1472 [11] Seedorf, J. and E. Burger, "Application-Layer Traffic 1473 Optimization (ALTO) Problem Statement", 1474 draft-marocco-alto-problem-statement-04 (work in progress), 1475 February 2009. 1477 [12] Yang, Y., Popkin, L., Penno, R., and S. Shalunov, "An 1478 Architecture of ALTO for P2P Applications", 1479 draft-yang-alto-architecture-00 (work in progress), March 2009. 1481 [13] Garcia, G., Tomsu, M., and Y. Wang, "ALTO Discovery Protocols", 1482 draft-wang-alto-discovery-00 (work in progress), March 2009. 1484 [14] Song, H., Even, R., Pascual, V., and Y. Zhang, "Application- 1485 Layer Traffic Optimization (ALTO): Discover ALTO Servers", 1486 draft-song-alto-server-discovery-00 (work in progress), 1487 March 2009. 1489 [15] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 1490 Translation", draft-baker-behave-v4v6-framework-02 (work in 1491 progress), February 2009. 1493 [16] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address 1494 Translation (NAT66)", draft-mrw-behave-nat66-02 (work in 1495 progress), March 2009. 1497 [17] "Bittorrent Protocol Specification v1.0", 1498 http://wiki.theory.org/BitTorrentSpecification, 2009. 1500 [18] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A. 1501 Silberschatz., "P4P: Provider Portal for (P2P) Applications", 1502 In SIGCOMM 2008. 1504 [19] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 1505 Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00 1506 (work in progress), March 2009. 1508 Appendix A. Data Types 1510 A.1. Endpoint Name 1512 TBD. 1514 A.2. PID Name 1516 TBD. 1518 A.3. Property Name 1520 TBD. 1522 A.4. IP Prefix 1524 TBD. 1526 A.5. Cost Type 1528 TBD. 1530 A.6. Cost Mode 1532 TBD. 1534 A.7. Constraint 1536 TBD. 1538 Appendix B. XML Encoding 1540 B.1. Server Configuration 1542 The Response contains a 'configuration' XML element which contains 1543 the configuration information for an ALTO. service. The 1544 'configuration' element MUST have the following attributes: 1546 o name of the ALTO service 1548 The 'configuration' element MAY contain the following child elements: 1550 o specifies in its 'uri' attribute, the Base URI at which the ALTO 1551 Server can be reached. An ALTO Client uses this URI (e.g., 1552 'http://alto.example.com:6671/') as a prefix placed before URI 1553 Paths when querying an ALTO Server. More than one 'alto-server' 1554 element may be present for load balancing, and an ALTO Client can 1555 choose any one at random. 1557 o specifies a cost metric supported by the ALTO Server. It MUST 1558 have a 'type' attribute indicating the name of the metric, and 1559 MUST have a 'units' attribute indicating the measurement units. 1560 If the metric does not have any units, then the units attribute 1561 must have the value 'none'. unit. If the no 'cost' element is 1562 present, then the ALTO Server is assumed to support the default 1563 'routingcost' Cost metric. Multiple 'cost' elements MAY be 1564 included, but a single Cost Type MUST NOT appear more than once. 1566 o specifies whether the ALTO Server supports Cost constraints in the 1567 Path Cost Lookup Query Section 6.3.4. This element MUST contain a 1568 'value' attribute with value either 'true' or 'false'. The 1569 'constraint-support' element MUST NOT appear more than once. If 1570 the 'constraint-support' element is not present, the ALTO Client 1571 MUST assume that the ALTO Server does not support Cost 1572 constraints. 1574 B.2. Endpoint 1576 An Endpoint is represented by the XML element 'endpoint'. The 1577 following attributes are REQUIRED: 1579 name: Indicates the name of the Endpoint. The value of this 1580 attribute MUST be formatted according to Appendix A.1. 1582 The 'endpoint' element MAY contain additional attributes indicating 1583 endpoint properties and their values. In this case, the attribute 1584 name is the property name, and the attribute value is the value of 1585 the property. Note that 'name' is not a valid property name. 1587 B.3. Endpoint List 1589 A list of Endpoints is represented by the XML element 'endpoints'. 1590 The following attributes are REQUIRED: 1592 size: Specifies the number of endpoints contained in the list as a 1593 non-negative integer. 1595 The 'endpoints' element MAY contain child elements. The following 1596 elements are allowed: 1598 element: Specifies a single endpoint in the list. The number of 1599 'endpoint' elements MUST equal the value of the 'size' attribute 1600 for the containing 'endpoints' element. 1602 B.4. PID 1604 TBD. 1606 B.5. PID List 1608 TBD. 1610 B.6. Cost Map Specification 1612 TBD. 1614 B.7. Cost Row 1616 TBD. 1618 B.8. Cost Map 1620 TBD. 1622 Appendix C. Additional Protocol Message Examples 1624 C.1. Endpoint Property Lookup 1626 POST /endpoint/m?prop=pid HTTP/1.1 1627 Host: alto.example.com 1628 Content-Type: application/alto 1629 Content-Length: [...] 1631 1632 1633 1634 1635 1636 1637 1638 1640 HTTP/1.1 200 OK 1641 Date: Fri, 31 Dec 1999 23:59:59 GMT 1642 Content-Type: application/alto 1643 Content-Length: [...] 1645 1646 1647 1648 1649 1650 1651 1652 1654 Example Query for Multiple Endpoints 1656 C.2. Reverse Property Lookup 1658 GET /prop/pid/ HTTP/1.1 1659 Host: alto.example.com 1661 HTTP/1.1 200 OK 1662 Date: Fri, 31 Dec 1999 23:59:59 GMT 1663 Content-Type: application/alto 1664 Content-Length: [...] 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1684 Example Query for All PIDs 1686 POST /prop/pid/m HTTP/1.1 1687 Host: alto.example.com 1688 Content-Length: [...] 1690 1691 1692 1693 1694 1695 1697 HTTP/1.1 200 OK 1698 Date: Fri, 31 Dec 1999 23:59:59 GMT 1699 Content-Type: application/alto 1700 Content-Length: [...] 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1717 Example Query for Specific PIDs 1719 C.3. Path Cost Lookup 1721 GET /cost/row?srcendp=ipv4:128.36.22.1 HTTP/1.1 1722 Host: alto.example.com 1724 HTTP/1.1 200 OK 1725 Date: Fri, 31 Dec 1999 23:59:59 GMT 1726 Content-Type: application/alto 1727 Content-Length: [...] 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1741 Example Query for Cost Map from a Single Endpoint 1743 Appendix D. Contributors 1745 The people listed here should be viewed as co-authors of the 1746 document. Due to the limit of 5 authors per draft the co-authors 1747 were moved to the contributors section at this point. 1749 Obi Akonjang 1751 DT Labs/TU Berlin/ 1753 EMail: obi@net.t-labs.tu-berlin.de 1755 Richard Alimi 1757 Yale University 1759 EMail: richard.alimi@yale.edu 1760 Saumitra M. Das 1762 Qualcomm Inc. 1764 EMail: saumitra@qualcomm.com 1766 Syon Ding 1768 China Telecom 1770 EMail: syding@chinatelecom.com 1772 Doug Pasko 1774 Verizon 1776 EMail: pasko@verizon.com 1778 Laird Popkin 1780 Pando Networks 1782 EMail: laird@pando.com 1784 Stefano Previdi 1786 Cisco 1788 EMail: sprevidi@cisco.com 1790 Satish Raghunath 1792 Juniper Networks 1794 satishr@juniper.net 1795 Stanislav Shalunov 1797 BitTorrent 1799 EMail: shalunov@bittorrent.com 1801 Albert Tian 1803 Ericsson/Redback 1805 EMail: alberttian@gmail.com 1807 Yu-Shun Wang 1809 Microsoft Corp. 1811 yu-shun.wang@microsoft.com 1813 Richard Woundy 1815 Comcast 1817 Richard_Woundy@cable.comcast.com 1819 David Zhang 1821 PPLive 1823 davidzhang@pplive.com 1825 Yunfei Zhang 1827 China Mobile 1829 zhangyunfei@chinamobile.com 1831 Appendix E. Acknowledgements 1833 We would like to thank the following additional people who were 1834 involved in the projects that contributed to this merged document: 1835 Alex Gerber (AT&T), Chris Griffiths (Comcast), Ramit Hora (Pando 1836 Networks), Arvind Krishnamurthy (University of Washington), Marty 1837 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace 1838 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T), 1839 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), 1840 Damien Saucez (UCL) Thomas Scholl (AT&T), Emilio Sepulveda 1841 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell 1842 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song 1843 (Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia 1844 Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University), 1845 Haiyong Xie (Yale University). 1847 Authors' Addresses 1849 Reinaldo Penno (editor) 1850 Juniper Networks 1851 1194 N Mathilda Avenue 1852 Sunnyvale, CA 1853 USA 1855 Email: rpenno@juniper.net 1857 Y. Richard Yang (editor) 1858 Yale University 1860 Email: yry@cs.yale.edu