idnits 2.17.1 draft-penno-alto-protocol-01.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 2 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 (March 09, 2009) is 5499 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) ** Obsolete normative reference: RFC 4566 (ref. '2') (Obsoleted by RFC 8866) ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '3') ** Obsolete normative reference: RFC 2616 (ref. '4') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-03) exists of draft-song-alto-server-discovery-00 == Outdated reference: A later version (-02) exists of draft-mrw-behave-nat66-01 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: September 10, 2009 Yale University 6 March 09, 2009 8 ALTO Protocol 9 draft-penno-alto-protocol-01.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 September 5, 2009. 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 The ALTO Service enables an Internet Service Provider (ISP) to convey 48 cost preferences to network applications in order to modify network 49 resource consumption patterns while maintaining or improving 50 application performance. Applications that could use this service 51 are those that have a choice in connection endpoints. Examples of 52 such applications are peer-to-peer (P2P) and content delivery 53 networks. 55 Applications already have access to great amount of underlying 56 topology information. For example, views of the Internet routing 57 table are easily available at looking glass servers and entirely 58 practical to download to every client. What is missing is the cost 59 information -- what does an ISP or Content Provider actually prefer? 61 This document describes a very simple protocol that allows a ISP to 62 convey such information to applications. While such service would 63 primarily be provided by the network (i.e., the local ISP). Content 64 Provider and third parties could also operate this service. 66 Requirements Language 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC 2119 [1]. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 6 77 2. ALTO Network Information . . . . . . . . . . . . . . . . . . . 8 78 2.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 8 79 2.2. Cost Map . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 2.3. Version Tag . . . . . . . . . . . . . . . . . . . . . . . 8 81 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 82 3.1. Example Scenario . . . . . . . . . . . . . . . . . . . . . 9 83 3.2. Design Approach . . . . . . . . . . . . . . . . . . . . . 9 84 3.2.1. Key Features . . . . . . . . . . . . . . . . . . . . . 9 85 3.2.2. Use of HTTP . . . . . . . . . . . . . . . . . . . . . 10 86 3.2.3. ALTO Information Reuse . . . . . . . . . . . . . . . . 10 87 3.2.4. ALTO Interfaces . . . . . . . . . . . . . . . . . . . 10 88 4. ALTO Messages . . . . . . . . . . . . . . . . . . . . . . . . 11 89 4.1. Basic Syntax . . . . . . . . . . . . . . . . . . . . . . . 11 90 4.1.1. Protocol Version (v=) . . . . . . . . . . . . . . . . 12 91 4.1.2. Transaction Identifier (t=) . . . . . . . . . . . . . 12 92 4.1.3. Query Type (q=) . . . . . . . . . . . . . . . . . . . 12 93 4.1.4. Response (r=) . . . . . . . . . . . . . . . . . . . . 13 94 4.1.5. Originator (o=) . . . . . . . . . . . . . . . . . . . 13 95 4.1.6. Cost (c=) . . . . . . . . . . . . . . . . . . . . . . 13 96 4.1.7. Network Locations (n=) . . . . . . . . . . . . . . . . 13 97 4.1.8. Network Map (m=) . . . . . . . . . . . . . . . . . . . 14 98 4.1.9. Interface Definition (i=) . . . . . . . . . . . . . . 14 99 4.2. Message Syntax . . . . . . . . . . . . . . . . . . . . . . 14 100 4.2.1. getcost . . . . . . . . . . . . . . . . . . . . . . . 14 101 4.2.2. getnetworkidentifier . . . . . . . . . . . . . . . . . 16 102 4.2.3. getnetworkmap . . . . . . . . . . . . . . . . . . . . 16 103 4.3. ALTO Server Message Processing . . . . . . . . . . . . . . 17 104 4.3.1. Exception Handling . . . . . . . . . . . . . . . . . . 17 105 4.3.2. Successful Responses . . . . . . . . . . . . . . . . . 17 106 4.3.3. Invalid Query Format . . . . . . . . . . . . . . . . . 18 107 4.3.4. Unsupported Query . . . . . . . . . . . . . . . . . . 18 108 5. ALTO Interfaces . . . . . . . . . . . . . . . . . . . . . . . 18 109 5.1. Interface Descriptor . . . . . . . . . . . . . . . . . . . 19 110 5.2. Cost Map Interfaces . . . . . . . . . . . . . . . . . . . 20 111 5.2.1. GetCost . . . . . . . . . . . . . . . . . . . . . . . 20 112 5.2.2. GetCost-Source . . . . . . . . . . . . . . . . . . . . 20 113 5.2.3. GetCost-Complete . . . . . . . . . . . . . . . . . . . 20 114 5.3. Network Map Interfaces . . . . . . . . . . . . . . . . . . 21 115 5.3.1. GetNetworkIdentifier . . . . . . . . . . . . . . . . . 21 116 5.3.2. GetNetworkMap . . . . . . . . . . . . . . . . . . . . 21 117 5.3.3. GetNetworkMap-Source . . . . . . . . . . . . . . . . . 22 118 5.3.4. GetNetworkMap-Complete . . . . . . . . . . . . . . . . 22 119 5.4. Example Usage . . . . . . . . . . . . . . . . . . . . . . 22 121 6. ALTO Costs . . . . . . . . . . . . . . . . . . . . . . . . . . 23 122 6.1. Type Attribute . . . . . . . . . . . . . . . . . . . . . . 23 123 6.2. Mode Attribute . . . . . . . . . . . . . . . . . . . . . . 23 124 6.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 24 125 7. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 24 126 7.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 24 127 7.2. Network Address Translation Considerations . . . . . . . . 24 128 7.3. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . 25 129 7.4. P2P Peer Selection . . . . . . . . . . . . . . . . . . . . 25 130 7.4.1. Client-based Peer Selection . . . . . . . . . . . . . 26 131 7.4.2. Server-based Peer Selection . . . . . . . . . . . . . 26 132 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 133 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 134 9.1. ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 135 9.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 27 136 9.3. ALTO Information . . . . . . . . . . . . . . . . . . . . . 27 137 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 138 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 139 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 140 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 29 141 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 30 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 144 1. Introduction 146 Today, information available to applications is mostly from the view 147 of endhosts. Using this view, they currently employ a variety of 148 methods to improve performance. However, there is no clear mechanism 149 to convey information about the network's preferences to 150 applications. By better leveraging network-provided information, 151 applications can become more network-efficient and acheive better 152 performance. For example, peer-to-peer applications have been 153 successful in achieving a good level of service for bulk-transfer 154 applications. By also considering network preferences, downloads can 155 be accelerated and network resource consumption can be reduced. The 156 ALTO service intends to provide a simple way to convey ISP 157 preferences to applications. 159 This document describes a simple protocol that allows an ISP to 160 convey such information to applications. The protocol specified here 161 is a merge between two other designs, ALTO Info-Export [5] and P4P 162 [6] [7]. The goal is to provide a simple, unified protocol that 163 meets the ALTO requirements [8], provides a migration path for ISPs, 164 Content Providers, and clients that have deployed the above mentioned 165 protocols. This document is a work in progress and will be updated 166 with further developments. 168 1.1. Terminology 170 We use the following terms defined in [9]: Application, Overlay 171 Network, Peer, Resource, Resource Identifier, Resource Provider, 172 Resource Consumer, Resource Directory, Transport Address, Host 173 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO 174 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, 175 Transit Traffic. 177 The terminology introduced in this document is listed below: 179 o Network Location Identifier (NL-ID): identifier indicating a 180 particular host or group of hosts. Currently-defined types of 181 Network Location Identifiers are IP Address, IP Prefix, Autonomous 182 System, PID, Geographical Location. Others may be defined. 184 o PID (Partition ID): identifier providing an indirect and network- 185 agnostic way to specify a group of NL-IDs. For example, a PID may 186 be defined (by a network operator) to denote a subnet, set of 187 subnets, autonomous system, PoP, or metropolitan area. 188 Aggregation into PIDs can improve scalablity. In particular, 189 network preferences (costs) may be specified between PIDs, 190 allowing cost information to be more compact and updated at a 191 smaller time scale than the network locations themselves. 193 o Top-Level NL-ID: NL-ID that is either a PID, or a NL-ID not 194 contained within another PID. For example, if a PID 'pid1' 195 containing the NL-IDs '1.2.0.0/16' and 'AS29', then 'pid1' is a 196 Top-Level NL-ID, but '1.2.0.0/16' and 'AS29' are not. 198 o Cost: indicates the preference of a NL-ID from the point of view 199 of another NL-ID. Costs have attributes indicating their type 200 (e.g., routing cost, hop-count, air-miles), and mode (numerical or 201 ordinal interpretation). 203 o ALTO Message: Single message (either request or response) carried 204 between an ALTO Server and ALTO Client. 206 o ALTO Interface: Endpoint offered by an ALTO Server for accepting 207 ALTO Messages. 209 o Source Grouping: A group of ALTO Clients which can have similar 210 costs to other network locations. See [10] for further 211 discussion. This current document assumes that Source Groups ar 212 denoted as top-level PIDs. 214 1.2. Architecture 216 Each network region can choose to support the ALTO service. A 217 network region in this context is an Autonomous System, an ISP, or 218 perhaps a smaller region; the details depend on the discovery 219 mechanism. 221 An illustration of the overall system architecture is presented in 222 the following figure. 224 +-------------------------------------------------------------------+ 225 | ISP | 226 | | 227 | +---------+ | 228 | | Routing | | 229 | +--------------+ | Policy | | 230 | | Provisioning | +---------+ | 231 | | Policy | | | 232 | +--------------+\ | | 233 | \ | | 234 | \ | | 235 | +-----------+ \+---------+ +--------+ | 236 | |Dynamic | | ALTO | ALTO Query/Response | ALTO | | 237 | |Network |.......| Server | -------------------- | Client | | 238 | |Information| +---------+ +--------+ | 239 | +-----------+ / / | 240 | / ALTO SD Query/Response / | 241 | / / | 242 | +----------+ +--------------+ | 243 | | External | | ALTO Service | | 244 | | Interface| | Discovery | | 245 | +----------+ +--------------+ | 246 | | | 247 | | Figure 1: Basic ALTO Architecture. | 248 | | | 249 +-------------------------------------------------------------------+ 250 | 251 +------------------+ 252 | Third Parties | 253 | | 254 | Content Providers| 255 +------------------+ 257 ALTO Architecture 259 The network information provided by an ALTO Server may be influenced 260 (at the operator's discretion) by other systems. Examples include 261 (but are not limited to) dynamic network information, routing 262 policies, provisioning policies, and interfaces to outside parties. 263 These components are outside the scope of this document. 265 After using ALTO Service Discovery to identify an appropriate ALTO 266 Server, an ALTO Client may then request available network information 267 from the ALTO Server. This document specifies a protocol through 268 which this network information is made available. 270 2. ALTO Network Information 272 An ISP prepares the ALTO information constituting the ISP's "my- 273 Internet View" [10]. The ALTO information provided by the ALTO 274 Server can be updated dynamically based on network conditions, or can 275 be seen as a policy which is updated at a larger time-scale. 277 In a simple case, the ALTO information maps, for a particular Source 278 Group, a cost for IP prefixes and AS numbers as viewed from that 279 group. 281 ALTO information is comprised of two sets of information: the Network 282 Map and Cost Map. Separating ALTO information into a Network Map and 283 Cost Map as the two components can be updated at different time 284 scales. For example, Network Maps may be stable for a longer time 285 while Cost Maps may be updated to reflect dynamic network conditions. 286 Version Tags are introduced to ensure that ALTO Clients are able to 287 use consistent information even though the information is provided in 288 two sets. 290 2.1. Network Map 292 The Network Map defines a set of network locations (NL-IDs) within 293 the network. Network locations may also be logically grouped into 294 PIDs. 296 The GetNetworkMap and GetNetworkIdentifier interfaces allow ALTO 297 Clients to query the Network Map. 299 2.2. Cost Map 301 The Cost Map defines the network costs, or preferences, between 302 network locations. Note that the network costs may be dependent on 303 the specific network locations and groupings defined in the Network 304 Map. Thus, we say that a particular Cost Map is generated based on a 305 particular Network Map. 307 The GetCost interfaces allow ALTO Clients to query the Cost Map. 309 2.3. Version Tag 311 When an ALTO Client retrieves cost information in the ALTO Server's 312 current Cost Map, it must ensure that the cost information is 313 consistent with any locally-stored Network Map information. If the 314 ALTO Server had recently updated its Network Map (perhaps causing 315 changes in the Cost Map), the ALTO Client must be able to detect that 316 the new costs pertain to a Network Map different than the one 317 currently stored. The ALTO Client can then refresh the Network Map 318 information from the ALTO Server. 320 Version Tags allow ALTO Clients to detect this case. The Network Map 321 maintained by the ALTO Server has an associated opaque identifier 322 called a Version Tag. When the Network Map is modified, its Version 323 Tag is changed. A simple way to implement the Version Tag is as an 324 integer that incremented (wrapping around to 0 as necessary) when the 325 Network Map changes. 327 When ALTO information (either generated from the Network Map or Cost 328 Map) is returned by the ALTO Server, the Version Tag is included in 329 the response message. Specifically, if the returned information is 330 from the Network Map, the Network Map's Version Tag is included. If 331 the returned information is from the Cost Map, the Version Tag of the 332 Network Map used to generate the Cost Map is included. 334 3. Protocol Overview 336 3.1. Example Scenario 338 The ALTO service may operate as follows: 340 1. The ISP prepares ALTO information as discussed in Section 2. 342 2. An application (ALTO Client), running on a given host, discovers 343 the ALTO Server and fetches the ALTO information (Section 4.2). 345 3. The application may integrate ALTO information into its decision 346 making process, possibly by making use of network locations with 347 lower cost. See Section 6 for further discussion on semantics of 348 network costs. 350 3.2. Design Approach 352 3.2.1. Key Features 354 The ALTO Protocol design borrows ideas from the Session Description 355 Protocol [2] with the goal of leveraging current HTTP [3] [4] 356 implementations and infrastructure. An ALTO information exchange is 357 carried within HTTP similarly to how SDP is carried within SIP. ALTO 358 messages are denoted with HTTP Content-Type "application/alto". The 359 ALTO Protocol described in this document has several features: 361 o Leverages the huge installed base of HTTP infrastructure, 362 including HTTP caches 364 o Leverages mature software implementations for both HTTP and SDP 366 o Leverages the fact that many P2P clients already have an embedded 367 HTTP client 369 o Makes protocol easy to understand and debug 371 o Allows the protocol to evolve separately from HTTP; Leaves HTTP 372 free of proprietary headers ("X-") 374 o Allows the ALTO protocol to be carried by other protocols other 375 than HTTP in the future, such as SIP. 377 o Allows flexible ALTO Server implementation strategies. 379 The rest of this section elaborates on the key design considerations 380 use in the protocol. 382 3.2.2. Use of HTTP 384 An important design consideration for the ALTO Protocol is easy 385 integration with existing applications and infrastructure. As 386 outlined above, HTTP is a natural choice. The message formats 387 themselves, however, remain independent of HTTP to allow flexibility 388 and transition to other transport protocols. 390 3.2.3. ALTO Information Reuse 392 ALTO information may be useful to a large number of applications and 393 users. Distributing ALTO information must be efficient and not 394 become a bottleneck. Therefore, the ALTO Protocol specified in this 395 document integrates with existing HTTP caching infrastructure to 396 allow reuse of ALTO information by ALTO Clients and reduce load on 397 ALTO servers. ALTO information may also be cached using application- 398 dependent mechanisms, such as P2P DHTs. 400 For example, a Cost Map may be reused by all ALTO Clients within a 401 particular Source Grouping [10]. A full Network Map may be reused by 402 all ALTO Clients using the ALTO Server. 404 3.2.4. ALTO Interfaces 406 Three basic interfaces are provided by the ALTO Protocol, which allow 407 ALTO Clients to request specific information: GetNetworkIdentifier, 408 GetNetworkMap, and GetCost. An ALTO Server additionally defines 409 instances of the GetNetworkMap and GetCost interfaces that provide 410 the full Network Map and Cost Map, or only the subset pertaining to 411 the Source Grouping containing the ALTO Client. 413 Each ISP may have different infrastructure and services which produce 414 and update the ALTO information, and may provide ALTO information 415 using any number of implementation strategies. The ALTO Protocol 416 specified in this document uses a single endpoint URI (e.g., 417 discovered via ALTO Service Discovery), and offers ALTO interfaces 418 using URI endpoints advertised by the ALTO Server. Using distinct 419 URIs for each ALTO Interface provides the following benefits: 421 o Flexible implementation strategies for ALTO Server (e.g., flat 422 files, database-backed CGI script, dedicated server, etc) 424 o Allows ALTO information to be provided using existing, mature 425 software (e.g., web servers) 427 o Integration with HTTP Caching while reducing dependence of 428 messaging format on HTTP. 430 Further details are provided in Section 5. 432 ALTO Interfaces and their URIs are provided to an ALTO Client via an 433 Interface Descriptor. A Interface Descriptor is expected to be 434 stable for a long period of time, so an ALTO Client may cache it 435 locally and possibly share amongst many ALTO clients running on the 436 same physical machine. 438 4. ALTO Messages 440 4.1. Basic Syntax 442 This section describes the basic components of an ALTO Protocol 443 message. The ALTO Protocol borrows its message encoding syntax from 444 SDP [2], but necessary definitions are included here. 446 An ALTO Information description consists of a number of lines of text 447 of the form: = where MUST be exactly one case- 448 significant character and is structured text whose format 449 depends on . In general, is either a number of fields 450 delimited by a single space character or a free format string, and is 451 case-significant unless a specific field defines otherwise. 452 Whitespace MUST NOT be used on either side of the "=" sign. 454 Some lines in each description are REQUIRED and some are OPTIONAL, 455 but all MUST appear in exactly the order given here (the fixed order 456 greatly enhances error detection and allows for a simple parser). 457 OPTIONAL items are marked with a "*". 459 ALTO Messages use lowercase names to distinguish them from the names 460 of their corresponding ALTO Interfaces. 462 The textual encoding of a particular NL-ID indicates its type (IP 463 prefix, AS number, PID, etc). 465 ALTO Protocol messages use the following types: 467 v=(Protocol Version) 469 t=(Transaction Identifier) 471 q=(Query) 473 r=(Response) 475 o=(Originator) 477 c=(Cost) 479 n=(Network Location) 481 m=(Network Map) 483 i=(Interface Description) 485 4.1.1. Protocol Version (v=) 487 v=1 489 The line defines the protocol version. The version specified in this 490 document is 1. 492 4.1.2. Transaction Identifier (t=) 494 t= 496 This allows transactions and demultiplexing of messages at the 497 application level. It is possible that response for queries are not 498 received in order (e.g., if a transport other than HTTP is used), so 499 a mechanism is needed to match responses to queries. 501 4.1.3. Query Type (q=) 503 q= [SRC | complete] 505 The query type can be 'getcost', 'getnetworkidentifier', 506 'getnetworkmap' or 'getstatus'. Certain queries allow either 507 complete ALTO information to be requested, or only a subset of ALTO 508 information. 510 4.1.4. Response (r=) 512 r= [ | [ ]] 513 [] [COST ] 515 This line is used by the Server in a response to a previous query. 516 Success and failures codes are based on HTTP's status codes but 517 specific to the ALTO Protocol, so semantically different from those 518 of HTTP or other protocol serving as transport. For example, if ALTO 519 protocol is carried within HTTP, the HTTP status code can be "200 520 OK", but the ALTO status code can be "400 Bad Request". 522 The map version tag is used when the query type is 523 'getnetworkidentifier', 'getnetworkmap', or 'getcost'. It tells the 524 client which version of the Network Map was used to generated 525 response data. 527 The type and mode of costs returned is indicated in the 'getcost' 528 response. See Section 6 for details about costs as well as the type 529 and mode attributes. 531 4.1.5. Originator (o=) 533 o= | 535 This line identifies the originator of cost information, which is not 536 necessarily related to the source IP address of the message. 538 4.1.6. Cost (c=) 540 c=SRC [DEST ] 542 The cost is a generic measure of network preference. 544 4.1.7. Network Locations (n=) 546 n=SRC [DEST ] 548 The network location line can be used in the 'getcost', 549 'getnetworkmap', and 'getnetworkidentifier' messages to indicate 550 specific mappings that are needed. 552 The following network location types are specified in this document: 554 o 'ASN': Autonomous System Number 556 o 'IPV4': IP Protocol version 4 558 o 'IPV6': IP Protocol version 6 560 o 'PID': Partition ID 562 4.1.8. Network Map (m=) 564 m= [ ... ] 566 The network map line is sent by server in a 'getnetworkmap' or 567 'getnetworkidentifier' response message. It conveys which Network 568 Location Identifiers are mapped to particular Top-Level NL-IDs 569 (PIDs). 571 4.1.9. Interface Definition (i=) 573 i= 575 The interface definition line is sent by a server in a 576 'getinterfaces' response. It identifies an interface available from 577 an ALTO Server. See Section 5 for details. 579 4.2. Message Syntax 581 ALTO queries (requests) MUST have the following lines: 583 v=(version) 584 t=(transaction identifier) 585 q=(query type) 587 ALTO responses MUST have: 589 v=(version) 590 t=(transaction identifier) 591 r=(response) 593 4.2.1. getcost 595 This message instructs the server to return costs amongst Network 596 Location Identifiers. 598 4.2.1.1. Query 600 q=getcost [SRC ] | complete 601 [COST ] 602 n=SRC [DEST ] 603 n=SRC [DEST ] 604 ... 606 If the request does not specify either the Source NL-ID or the 607 'complete' token, the server assumes that the requesting IP addresses 608 indicates the Source NL-ID. 610 If the request does not specify the desired cost type and mode, then 611 the server assumes the type to be 'routingcost' and the mode to be 612 'numerical'. 614 If the 'complete' token is specified, costs between each pair of Top- 615 level NL-IDs are returned. Otherwise, the costs from Source NL-ID to 616 all Top-Level NL-IDs is returned. 618 4.2.1.2. Response 620 The server may reply with a message enumerating pairs of Network 621 Location Identifiers and associated costs: 623 r=getcost [ | [ ]] 624 COST 625 c=SRC DEST 626 c=SRC DEST 627 ... 629 If the server replies with multiple costs from a particular Source 630 NL-ID to multiple Destination NL-IDs, a more efficient encoding may 631 be used: 633 r=getcost [ | [ ]] 634 COST 635 c=SRC 636 637 638 ... 639 c=SRC 640 641 642 ... 644 If the server for any reason cannot compute the cost between a 645 certain SRC-DEST pair contained in the request, it may omit the pair 646 from the response. 648 4.2.2. getnetworkidentifier 650 This message requests the server to map a requested Network Location 651 Identifier into its corresponding Top-Level NL-ID. The default query 652 (with no parameters listed) can be used to discover the Source Group 653 for a particular ALTO Client. 655 4.2.2.1. Query 657 q=getnetworkidentifier [SRC ] 658 n=SRC 660 If the request does not specify any Source NL-IDs, the server assumes 661 that the requesting IP addresses indicates the Source NL-ID. 663 4.2.2.2. Response 665 r=getnetworkidentifier [ | [ 666 ]] 667 m= [ ... ] 668 m= [ ... ] 669 ... 671 The response includes the corresponding Top-Level NL-IDs for the 672 requested list of Source NL-IDs. 674 If the server for any reason cannot compute the Top-Level NL-ID for a 675 particular Source NL-ID, it may omit the Source NL-ID in the 676 response. 678 For example, if the query is for IP address 1.2.3.4 (in PID1), 679 1.2.3.5 (in PID1) and 128.1.1.2 (in PID2) the response would be: 681 r=getnetworkidentifier 200 1 682 m=PID1 IPV4:1.2.3.4 IPV4:1.2.3.5 683 m=PID2 IPV4:128.1.1.2 685 4.2.3. getnetworkmap 687 This message instructs the server to return the Network Location 688 Identifiers (e.g., IP Prefixes) contained within the specified Top- 689 Level NL-IDs (e.g., PIDs). By storing such a mapping, an ALTO Client 690 can locally map from IP addresses to PIDs without consulting the ALTO 691 Server. 693 4.2.3.1. Query 695 q=getnetworkmap [SRC ] | complete 696 n=SRC 697 n=SRC 698 ... 700 If the 'complete' token is specified, the server assumes the set of 701 Top-Level NL-IDs to be all Top-Level NL-IDs defined in the Network 702 Map. Otherwise, mappings for only the specified Top-Level NL-IDs are 703 queried. 705 4.2.3.2. Response 707 r=getnetworkmap [ | [ 708 | ]] 709 m= [ ... ] 710 m= [ ... ] 711 ... 713 Each line of the response indicates the NL-IDs contained within a 714 particular Top-Level NL-ID. 716 If the server for any reason cannot identify a particular Top-Level 717 NL-ID contained in the request, it may omit that Top-Level NL-ID from 718 the response. 720 4.3. ALTO Server Message Processing 722 This section specifies ALTO Server behavior when processing ALTO 723 queries. In general the ALTO protocol uses the same status codes as 724 HTTP. 726 4.3.1. Exception Handling 728 Standard HTTP status codes are returned by an ALTO Server in the 729 response (r=) line. 731 4.3.2. Successful Responses 733 An ALTO Server MUST use Status Code 200 when replying to an operation 734 that completed successfully. Note that this includes cases where the 735 ALTO Server responds with only a subset of the requested information. 736 The requesting application is expected to detect such cases if 737 necessary. 739 4.3.3. Invalid Query Format 741 If the Request Data is formatted incorrectly (i.e., it does not 742 follow the syntax in Section 6), the ALTO Server MUST return an 743 status code and reason of "400 Bad Request". 745 4.3.4. Unsupported Query 747 If an ALTO Server does not support a certain type of query, e.g., 748 cost for SRC-DEST pairs, a status code and reason of "501 Not 749 Implemented" might be returned in lieu of returning an invalid cost. 751 5. ALTO Interfaces 753 An ALTO Server exposes multiple interfaces to ALTO Clients, each of 754 which provides certain ALTO information to clients. Clients send 755 ALTO Messages (Section 4.2) to the ALTO Server interfaces to query 756 information, and receive ALTO Messages containing the requested 757 information. 759 Two sets of ALTO Interfaces are provided, corresponding to the two 760 sets of ALTO information: 762 o Network Map Interfaces: GetNetworkIdentifier, GetNetworkMap 764 o Cost Map Interfaces: GetCost 766 The GetNetworkMap and GetCost interfaces each define instances that 767 may reply with static messages as opposed to dynamically-constructed 768 responses. In particular: 770 o GetNetworkMap-Source, GetCost-Source: provide at least subset the 771 of the ALTO information reusable by all ALTO Clients within a 772 particular Source Grouping (e.g., PID). These interfaces are 773 expected to be used by ALTO Clients such as P2P clients which 774 primarily consider costs from themselves to other network 775 locations. 777 o GetNetworkMap-Complete, GetCost-Complete: provide the complete set 778 of ALTO information, which is reusable by all ALTO Clients. These 779 interfaces are expected to be used by ALTO Clients such as P2P 780 trackers which may require global information. 782 Note that it is possible for GetNetworkMap-Source and GetCost-Source 783 to return more than the subset specific to ALTO Clients within the 784 particular Source Group. In particular, they may be pointers to the 785 GetNetworkMap-Complete and GetCost-Complete interfaces. However, 786 this approach is only recommended if the total amount ALTO 787 information returned is small. 789 Each ALTO Interface has a corresponding URI. Using separate URIs for 790 each interface allows for implementation flexibility, the ability to 791 reuse common ALTO information based on the request URI (e.g., 792 existing HTTP cache servers), and avoids defining the protocol to 793 explicitly duplicate request parameters in HTTP headers or query- 794 string parameters. 796 This section defines the ALTO Interfaces provided by the ALTO Server 797 and messages that may be sent to each interface's URI: 799 o Accepted Query: query type for messages allowed to be sent to the 800 interface. The ALTO Server MUST indicate an error if the query 801 type does not match the expected query type. 803 o Accepted Parameters: expected query parameters in request message. 804 The ALTO Server MUST indicate an error if the supplied parameters 805 do not meet these preconditions. 807 5.1. Interface Descriptor 809 The URI for each interface exposed by an ALTO Server is listed in the 810 Interface Descriptor given to an ALTO Client. 812 The URIs for the GetNetworkMap-Source and GetCost-Source interfaces 813 MAY include the string '', which is replaced by ALTO Clients 814 with the Network Location Identifier denoting a particular Source 815 Group. 817 An ALTO Server accepts the 'getinterfaces' query at a well-known URI. 818 This URI could either be discovered directly by the ALTO Discovery 819 mechanism, or be standardized (e.g., '/alto-interfaces') and appended 820 to a hostname and port discovered by the ALTO Discovery mechanism. 822 An ALTO Client requests the Interface Descriptor using the 823 'getinterfaces' query: 825 q=getinterfaces 827 The returned Interface Descriptor is encoded as: 829 r=getinterfaces 830 i= 831 ... 832 i= 834 If an ALTO Server does not provide a certain interface, it does not 835 appear in the Interface Descriptor. 837 5.2. Cost Map Interfaces 839 5.2.1. GetCost 841 This interface returns all or a subset of the Cost Map. It also 842 allows ALTO Clients to query for costs with Type or Mode different 843 from the ALTO Server's default cost Type and Mode. This interface 844 should only be used by ALTO Clients requiring customized cost 845 information. ALTO Clients should use the GetCost-Source and GetCost- 846 Complete where possible. 848 The GetCost interface MAY be provided by an ALTO Server. 850 Interface Specification: 852 o Accepted Query: getcost 854 o Accepted Parameters: Any 856 There are no guarantees about the reusability of successful requests 857 to this interface. Thus, the ALTO Server MUST indicate in the HTTP 858 response that it is not cacheable. 860 5.2.2. GetCost-Source 862 This interface returns a subset of the Cost Map containing only costs 863 from a particular Source Group to other network locations. 865 The GetCost-Source interface MAY be provided by an ALTO Server. 867 Interface Specification: 869 o Accepted Query: getcost 871 o Accepted Parameters: Indicate Source NL-ID consistent with URI. 873 Successful requests to this interface MUST generate a response 874 message that is independent of the querying ALTO Client. Thus, the 875 ALTO Server MAY indicate caching parameters in the HTTP response. 877 5.2.3. GetCost-Complete 879 This interface returns the complete Cost Map. 881 The GetCost-Complete interface MUST be provided by an ALTO Server. 883 Interface Specification: 885 o Accepted Query: getcost 887 o Accepted Parameters: Indicate 'complete' token 889 Successful requests to this interface MUST generate a response 890 message that is independent of the querying ALTO Client. Thus, the 891 ALTO Server MAY indicate caching parameters in the HTTP response. 893 5.3. Network Map Interfaces 895 5.3.1. GetNetworkIdentifier 897 This interface returns mappings between Network Location Identifiers 898 computed using the Network Map. Without any request parameters, it 899 returns the Source Group containing the requesting ALTO Client. 901 The GetNetworkIdentifier interface MUST be provided by an ALTO Server 902 for the case of replying with the Source Group for the requesting 903 ALTO Client. 905 Interface Specification: 907 o Accepted Query: getnetworkidentifier 909 o Accepted Parameters: Any 911 There are no guarantees about the reusability of successful requests 912 to this interface. Thus, the ALTO Server MUST indicate in the HTTP 913 response that it is not cacheable. 915 5.3.2. GetNetworkMap 917 This interface returns all or a subset of the Network Map. This 918 interface should only be used by ALTO Clients requiring specific 919 portions of the Network Map. ALTO Clients should use the 920 GetNetworkMap-Source and GetNetworkMap-Complete where possible. 922 The GetNetworkMap interface MAY be provided by an ALTO Server. 924 Interface Specification: 926 o Accepted Query: getnetworkmap 928 o Accepted Parameters: Any 930 There are no guarantees about the reusability of successful requests 931 to this interface. Thus, the ALTO Server MUST indicate in the HTTP 932 response that it is not cacheable. 934 5.3.3. GetNetworkMap-Source 936 This interface returns a subset of the Network Map containing at 937 least Network Locations used in the response to the GetCost-Source 938 interface. 940 The GetNetworkMap-Source interface MAY be provided by an ALTO Server. 942 Interface Specification: 944 o Accepted Query: getnetworkmap 946 o Accepted Parameters: Indicate Source NL-ID consistent with URI. 948 Successful requests to this interface MUST generate a response 949 message that is independent of the querying ALTO Client. Thus, the 950 ALTO Server MAY indicate caching parameters in the HTTP response. 952 5.3.4. GetNetworkMap-Complete 954 This interface returns the full Network Map. 956 The GetNetworkMap-Complete interface MUST be provided by an ALTO 957 Server. 959 Interface Specification: 961 o Accepted Query: getnetworkmap 963 o Accepted Parameters: Indicate 'complete' token 965 Successful requests to this interface MUST generate a response 966 message that is independent of the querying ALTO Client. Thus, the 967 ALTO Server MAY indicate caching parameters in the HTTP response. 969 5.4. Example Usage 971 An ALTO Client embedded in a P2P client (e.g., BitTorrent client) may 972 request an Interface Descriptor from its ALTO Server. The ALTO 973 Server may return the following Interface Descriptor: 975 GetNetworkIdentifier /alto/msg.cgi?query=getnetworkidentifier 976 GetNetworkMap /alto/msg.cgi?query=getnetworkmap 977 GetNetworkMap-Source /alto/networkmap-src-.txt 978 GetNetworkMap-Complete /alto/networkmap-complete.txt 979 GetCost /alto/msg.cgi?query=getcost 980 GetCost-Source /alto/costmap-src-.txt 981 GetCost-Complete /alto/costmap-complete.txt 983 Next, if any URI used by the client contains the '' token, 984 the P2P client queries GetNetworkIdentifier without any parameters to 985 obtain its Source Group. It then replaces the '' token in 986 the URI template. 988 Last, the client may then use the GetCost-Source interface with the 989 computed URI. 991 6. ALTO Costs 993 Preferences are communicated to ALTO Clients in the form of network 994 costs. ALTO Costs have two attributes: 996 o Type: identifies what the costs represent 998 o Mode: identifies how the costs should be interprested 1000 6.1. Type Attribute 1002 The Type attribute indicates what the cost represents. For example, 1003 an ALTO Server could define costs representing air-miles, hop-counts, 1004 ranking, or generic routing costs. 1006 Cost types are indicated in protocol messages as alphanumeric 1007 strings. An ALTO Server MUST at least define the routing cost type 1008 denoted by the string 'routingcost'. 1010 Note that an ISP may internally compute routing cost using any method 1011 it chooses (including air-miles or hop-count). 1013 If an ALTO Client requests a cost Type that is not available, the 1014 ALTO Server responds with an error as specified in Section 4.3.4. 1016 6.2. Mode Attribute 1018 The Mode attribute indicates how costs should be interpreted. For 1019 example, an ALTO Server could return costs that should be interpreted 1020 as numerical values or ordinal rankings. 1022 It is important to communicate such information to ALTO Clients, as 1023 certain operations may not be valid on certain costs returned by an 1024 ALTO Server. For example, it is possible for an ALTO Server to 1025 return a set of IP addresses with costs indicating a ranking of the 1026 IP addresses. Arithmetic operations, such as summation, that would 1027 make sense for numerical values, do not make sense for ordinal 1028 rankings. ALTO Clients may want to handle such costs differently. 1030 Cost Modes are indicated in protocol messages as alphanumeric 1031 strings. An ALTO Server MUST at least define the modes 'numerical' 1032 and 'ordinal'. 1034 If an ALTO Client requests a cost Mode that is not supported, the 1035 ALTO Server MUST reply with costs having Mode either 'numerical' or 1036 'ordinal'. Thus, an ALTO Server must implement at least one of 1037 'numerical' or 'ordinal' Costs, but it may choose which to support. 1038 ALTO Clients may choose how to handle such situations. Two 1039 particular possibilities are to use the returned costs as-is (e.g., 1040 treat numerical costs as ordinal rankings) or ignore the ALTO 1041 information altogether. 1043 6.3. Semantics 1045 Costs returned by an ALTO Server SHOULD be defined such that higher 1046 values indicate a lower preference, while smaller values indicate a 1047 higher preference. 1049 7. Discussions 1051 7.1. Discovery 1053 The particular mechanism by which an ALTO Client discovers its ALTO 1054 Server is an important component to the ALTO architecture and 1055 numerous techniques have been discussed [11] [12]. However, the 1056 discovery mechanism is out of scope for this document. 1058 Some ISPs have proposed the possibility of delegation, in which an 1059 ISP provides information for customer networks which do not wish to 1060 run Portal Servers themselves. A consideration for delegation is 1061 that customer networks may wish to explicitly configure such 1062 delegation. 1064 7.2. Network Address Translation Considerations 1066 At this day and age of v4<->v4, v4<->v6[13], and possibly v6<->v6[14] 1067 NATO's, a protocol should strive to be NAT friendly and minimize 1068 carrying IP addresses in the payload, or provide a mode of operation 1069 where the source IP address provide the information necessary to the 1070 server. 1072 The protocol specified in this document provides a mode of operation 1073 (the GetCost-Source interface) where the source NL-ID is computed by 1074 the ALTO Server (via the GetNetworkIdentifier interface) from the 1075 source IP address ALTO Client requests. This is similar to how some 1076 P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS 1077 Protocol" in [15]). 1079 7.3. Mapping IPs to ASNs 1081 The ALTO Protocol described in this document allows ISPs to provide 1082 ALTO information including ASNs. Thus, ALTO Clients may need to 1083 identify the ASN for a Resource Provider to determine the cost to 1084 that Resource Provider. 1086 Applications can already map IPs to ASNs using information from a BGP 1087 Looking Glass. To do so, they must download a file of about 1.5MB 1088 when compressed (as of October 2008, with all information not needed 1089 for IP to ASN mapping removed) and periodically (perhaps monthly) 1090 refresh it. 1092 Alternatively, the GetNetworkMap interface defined in this document 1093 could be extended to map ASNs into a set of IP prefixes. The 1094 mappings provided by the ISP would be both smaller and more 1095 authoritative. 1097 For simplicity of implementation, it's highly desirable that clients 1098 only have to implement exactly one mechanism of mapping IPs to ASNs. 1100 7.4. P2P Peer Selection 1102 This section discusses possible approaches to peer selection using 1103 ALTO information (Network Location Identifiers and associated Costs) 1104 from an ALTO Server. Specifically, the application must select which 1105 peers to use based on this and other sources of information. With 1106 this in mind, the usage of ALTO Costs is intentionally flexible, 1107 because: 1109 Different applications may use the information differently. For 1110 example, an application that connects to just one address may have 1111 a different algorithm for selecting it than an application that 1112 connects to many. 1114 Though initial experiments have been conducted [16], more 1115 investigation is needed to identify other methods. 1117 In addition, the application might account for robustness, perhaps 1118 using randomized exploration to determine if it performs better 1119 without ALTO information. 1121 7.4.1. Client-based Peer Selection 1123 One possibility is for peer selection using ALTO costs to be done 1124 entirely by a P2P client. The following are some techniques have 1125 been proposed and/or used: 1127 o Prefer network locations with lower ordinal rankings (i.e., higher 1128 priority) [17] [5]. 1130 o Optimistically unchoking low-cost peers with higher probability 1131 [5]. 1133 7.4.2. Server-based Peer Selection 1135 Another possibility is for ALTO costs to be used by an Application 1136 Tracker (e.g., BitTorrent Tracker) when returning peer lists. The 1137 following are techniques that have been proposed and/or used: 1139 o Using bandwidth matching (e.g., at an Application Tracker) and 1140 choosing solution (within bound of optimal) with minimal network 1141 cost [16]. 1143 8. IANA Considerations 1145 This document request the registration of a new media type: 1146 "application/alto" 1148 9. Security Considerations 1150 9.1. ISPs 1152 ISPs must be cognizant of the network topology and provisioning 1153 information provided through ALTO Interfaces. ISPs should evaluate 1154 how much information is revealed and the associated risks. In 1155 particular, providing overly fine-grained information may make it 1156 easier for attackers to infer network topology. On the other hand, 1157 revealing overly coarse-grained information may not provide benefits 1158 to network efficiency or performance improvements to ALTO Clients. 1160 9.2. ALTO Clients 1162 Applications using the information must be cognizant of the 1163 possibility that the information is malformed or incorrect. Even 1164 when it is correct, its use might harm the performance. When an 1165 application concludes that it would get better performance 1166 disregarding the ALTO information, the decision to discontinue the 1167 use of ALTO information is likely best left to the user. 1169 ALTO Clients should also be cognizant of revealing Network Location 1170 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, 1171 as doing so may allow the ALTO Server to infer communication 1172 patterns. One possibility is for the ALTO Client to only rely on the 1173 GetNetworkMap-Source/GetNetworkMap-Complete and GetCost-Source/ 1174 GetCost-Complete interfaces. 1176 The use of SSL/TLS can make it easier for clients to verify the 1177 origin of ALTO information. 1179 9.3. ALTO Information 1181 An ALTO Server may optionally use authentication and encryption to 1182 protect ALTO information. Authentication and encryption may be 1183 provided using HTTP Basic or Digest Authentication and/or SSL/TLS. 1185 10. References 1187 10.1. Normative References 1189 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1190 Levels", BCP 14, RFC 2119, March 1997. 1192 [2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1193 Description Protocol", RFC 4566, July 2006. 1195 [3] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1196 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1198 [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1199 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1200 HTTP/1.1", RFC 2616, June 1999. 1202 10.2. Informative References 1204 [5] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 1205 Export Service", draft-shalunov-alto-infoexport-00 (work in 1206 progress), October 2008. 1208 [6] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, "P4P: 1209 Provider Portal for P2P Applications", draft-p4p-framework-00 1210 (work in progress), November 2008. 1212 [7] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, "P4P 1213 Protocol Specification", draft-wang-alto-p4p-specification-00 1214 (work in progress), March 2009. 1216 [8] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, 1217 "Application-Layer Traffic Optimization (ALTO) Requirements", 1218 draft-kiesel-alto-reqs-02 (work in progress), March 2009. 1220 [9] Seedorf, J. and E. Burger, "Application-Layer Traffic 1221 Optimization (ALTO) Problem Statement", 1222 draft-marocco-alto-problem-statement-05 (work in progress), 1223 March 2009. 1225 [10] Yang, Y., Popkin, L., Penno, R., and S. Shalunov, "An 1226 Architecture of ALTO for P2P Applications", 1227 draft-yang-alto-architecture-00 (work in progress), March 2009. 1229 [11] Garcia, G., Tomsu, M., and Y. Wang, "ALTO Discovery Protocols", 1230 draft-wang-alto-discovery-00 (work in progress), March 2009. 1232 [12] Song, H., Even, R., Pascual, V., and Y. Zhang, "Application- 1233 Layer Traffic Optimization (ALTO): Discover ALTO Servers", 1234 draft-song-alto-server-discovery-00 (work in progress), 1235 March 2009. 1237 [13] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 1238 Translation", draft-baker-behave-v4v6-framework-02 (work in 1239 progress), February 2009. 1241 [14] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address 1242 Translation (NAT66)", draft-mrw-behave-nat66-01 (work in 1243 progress), November 2008. 1245 [15] "Bittorrent Protocol Specification v1.0", 1246 http://wiki.theory.org/BitTorrentSpecification, 2009. 1248 [16] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A. 1249 Silberschatz., "P4P: Provider Portal for (P2P) Applications", 1250 In SIGCOMM 2008. 1252 [17] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. 1253 Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00 1254 (work in progress), March 2009. 1256 Appendix A. Contributors 1258 The people listed here should be viewed as co-authors of the 1259 document. Due to the limit of 5 authors per draft the co-authors 1260 were moved to the contributors section at this point. 1262 Richard Alimi 1264 Yale University 1266 EMail: richard.alimi@yale.edu 1268 D. Pasko 1270 Verizon 1272 EMail: pasko@verizon.com 1274 L. Popkin 1276 Pando Networks 1278 EMail: laird@pando.com 1280 Satish Raghunath 1282 Juniper Networks 1284 satishr@juniper.net 1286 Stanislav Shalunov 1288 BitTorrent 1290 EMail: shalunov@bittorrent.com 1292 Yu-Shun Wang 1293 Microsoft Corp. 1295 yu-shun.wang@microsoft.com 1297 Richard Woundy 1299 Comcast 1301 Richard_Woundy@cable.comcast.com 1303 Appendix B. Acknowledgements 1305 We would like to thank the following additional people who were 1306 involved in either of the projects (P4P or ALTO Info-Export) that 1307 contributed to this merged document: Alex Gerber (AT&T), Chris 1308 Griffiths (Comcast), Ramit Hora (Pando Networks), Arvind 1309 Krishnamurthy (University of Washington), Marty Lafferty (DCIA), 1310 Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace Liu (IBM Watson), 1311 Jason Livingood (Comcast), Michael Merritt (AT&T), Stefano Previdi 1312 (Cisco), James Royalty (Pando Networks), Thomas Scholl (AT&T), Emilio 1313 Sepulveda (Telefonica), Avi Silberschatz (Yale University), Hassan 1314 Sipra (Bell Canada), Haibin Song (Huawei), Oliver Spatscheck (AT&T), 1315 See-Mong Tang (Microsoft), Jia Wang (AT&T), Hao Wang (Yale 1316 University), Ye Wang (Yale University), Haiyong Xie (Yale 1317 University), and David Zhang (PPLive). 1319 Authors' Addresses 1321 Reinaldo Penno (editor) 1322 Juniper Networks 1323 1194 N Mathilda Avenue 1324 Sunnyvale, CA 1325 USA 1327 Email: rpenno@juniper.net 1329 Y. Richard Yang (editor) 1330 Yale University 1332 Email: yry@cs.yale.edu