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