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