idnits 2.17.1
draft-ietf-alto-protocol-15.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
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 :
----------------------------------------------------------------------------
-- The document has examples using IPv4 documentation addresses according
to RFC6890, but does not use any IPv6 documentation addresses. Maybe
there should be IPv6 examples, too?
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 1063 has weird spacing: '...ilities capa...'
== Line 1318 has weird spacing: '...ataType data...'
== Line 1323 has weird spacing: '... meta meta-...'
== Line 1325 has weird spacing: '... data the d...'
== Line 1605 has weird spacing: '...stModel cost-...'
== (6 more instances...)
-- The document date (May 8, 2013) is 4003 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)
== Missing Reference: 'RFC 6708' is mentioned on line 3014, but not defined
== Missing Reference: 'I-D.jennings-sip-hashcash' is mentioned on line
3051, but not defined
== Missing Reference: 'ATTP' is mentioned on line 3442, but not defined
-- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.2008'
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159)
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489)
** Downref: Normative reference to an Informational RFC: RFC 5693
** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525)
** Downref: Normative reference to an Informational RFC: RFC 6708
== Outdated reference: A later version (-16) exists of
draft-ietf-alto-deployments-06
== Outdated reference: A later version (-16) exists of
draft-ietf-alto-reqs-08
== Outdated reference: A later version (-10) exists of
draft-ietf-alto-server-discovery-08
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p2-semantics-22
Summary: 8 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 ALTO WG R. Alimi, Ed.
3 Internet-Draft Google
4 Intended status: Standards Track R. Penno, Ed.
5 Expires: November 9, 2013 Cisco Systems
6 Y. Yang, Ed.
7 Yale University
8 May 8, 2013
10 ALTO Protocol
11 draft-ietf-alto-protocol-15.txt
13 Abstract
15 Applications using the Internet already have access to topology
16 information of Internet Service Provider (ISP) networks. For
17 example, views to Internet routing tables at looking glass servers
18 are available and can be practically downloaded to many application
19 clients. What is missing is knowledge of the underlying network
20 topologies from the point of view of ISPs (henceforth referred as
21 Providers). In other words, what a Provider prefers in terms of
22 traffic optimization -- and a way to distribute it.
24 The Application-Layer Traffic Optimization (ALTO) Service provides
25 network information (e.g., basic network location structure and
26 preferences of network paths) with the goal of modifying network
27 resource consumption patterns while maintaining or improving
28 application performance. The basic information of ALTO is based on
29 abstract maps of a network. These maps provide a simplified view,
30 yet enough information about a network for applications to
31 effectively utilize them. Additional services are built on top of
32 the maps.
34 This document describes a protocol implementing the ALTO Service.
35 Although the ALTO Service would primarily be provided by the network
36 service providers (e.g., Internet service providers), content service
37 providers and third parties could also operate an ALTO service.
38 Applications that could use this service are those that have a choice
39 to which end points to connect. Examples of such applications are
40 peer-to-peer (P2P) and content delivery networks.
42 Requirements Language
44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
46 document are to be interpreted as described in RFC 2119 [RFC2119].
48 Status of this Memo
49 This Internet-Draft is submitted in full conformance with the
50 provisions of BCP 78 and BCP 79.
52 Internet-Drafts are working documents of the Internet Engineering
53 Task Force (IETF). Note that other groups may also distribute
54 working documents as Internet-Drafts. The list of current Internet-
55 Drafts is at http://datatracker.ietf.org/drafts/current/.
57 Internet-Drafts are draft documents valid for a maximum of six months
58 and may be updated, replaced, or obsoleted by other documents at any
59 time. It is inappropriate to use Internet-Drafts as reference
60 material or to cite them other than as "work in progress."
62 This Internet-Draft will expire on November 9, 2013.
64 Copyright Notice
66 Copyright (c) 2013 IETF Trust and the persons identified as the
67 document authors. All rights reserved.
69 This document is subject to BCP 78 and the IETF Trust's Legal
70 Provisions Relating to IETF Documents
71 (http://trustee.ietf.org/license-info) in effect on the date of
72 publication of this document. Please review these documents
73 carefully, as they describe your rights and restrictions with respect
74 to this document. Code Components extracted from this document must
75 include Simplified BSD License text as described in Section 4.e of
76 the Trust Legal Provisions and are provided without warranty as
77 described in the Simplified BSD License.
79 Table of Contents
81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
82 1.1. Background and Problem Statement . . . . . . . . . . . . . 6
83 1.2. Solution Benefits . . . . . . . . . . . . . . . . . . . . 6
84 1.2.1. Service Providers . . . . . . . . . . . . . . . . . . 6
85 1.2.2. Applications . . . . . . . . . . . . . . . . . . . . . 7
86 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
87 2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . 7
88 2.2. Endpoint Address . . . . . . . . . . . . . . . . . . . . . 7
89 2.3. ASN . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
90 2.4. Network Location . . . . . . . . . . . . . . . . . . . . . 8
91 2.5. ALTO Information . . . . . . . . . . . . . . . . . . . . . 8
92 2.6. ALTO Information Base . . . . . . . . . . . . . . . . . . 8
93 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 8
94 3.1. ALTO Service and Protocol Scope . . . . . . . . . . . . . 8
95 3.2. ALTO Information Reuse and Redistribution . . . . . . . . 10
96 4. ALTO Information Service Framework . . . . . . . . . . . . . . 10
97 4.1. ALTO Information Services . . . . . . . . . . . . . . . . 11
98 4.1.1. Map Service . . . . . . . . . . . . . . . . . . . . . 11
99 4.1.2. Map Filtering Service . . . . . . . . . . . . . . . . 11
100 4.1.3. Endpoint Property Service . . . . . . . . . . . . . . 12
101 4.1.4. Endpoint Cost Service . . . . . . . . . . . . . . . . 12
102 5. Network Map . . . . . . . . . . . . . . . . . . . . . . . . . 12
103 5.1. Provider-defined Identifier (PID) . . . . . . . . . . . . 12
104 5.2. Endpoint Addresses . . . . . . . . . . . . . . . . . . . . 13
105 5.2.1. IP Addresses . . . . . . . . . . . . . . . . . . . . . 13
106 5.3. Example Network Map . . . . . . . . . . . . . . . . . . . 13
107 6. Cost Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
108 6.1. Cost Types . . . . . . . . . . . . . . . . . . . . . . . . 15
109 6.1.1. Cost Metric . . . . . . . . . . . . . . . . . . . . . 15
110 6.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 15
111 6.2. Cost Map Structure . . . . . . . . . . . . . . . . . . . . 16
112 6.3. Network Map and Cost Map Dependency . . . . . . . . . . . 17
113 7. Endpoint Properties . . . . . . . . . . . . . . . . . . . . . 17
114 7.1. Endpoint Property Type . . . . . . . . . . . . . . . . . . 17
115 7.1.1. Endpoint Property Type: pid . . . . . . . . . . . . . 18
116 8. Protocol Specification: General Processing . . . . . . . . . . 18
117 8.1. Overall Design . . . . . . . . . . . . . . . . . . . . . . 18
118 8.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 18
119 8.3. Basic Operation . . . . . . . . . . . . . . . . . . . . . 19
120 8.3.1. Client Discovering Information Resources . . . . . . . 19
121 8.3.2. Client Requesting Information Resources . . . . . . . 20
122 8.3.3. Server Responding to IR Request . . . . . . . . . . . 20
123 8.3.4. Client Handling Server Response . . . . . . . . . . . 21
124 8.3.5. Authentication and Encryption . . . . . . . . . . . . 21
125 8.3.6. HTTP Cookies . . . . . . . . . . . . . . . . . . . . . 21
126 8.3.7. Parsing . . . . . . . . . . . . . . . . . . . . . . . 22
128 8.4. Information Resource: Attributes . . . . . . . . . . . . . 22
129 8.4.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 22
130 8.4.2. Capabilities . . . . . . . . . . . . . . . . . . . . . 22
131 8.4.3. Accepts Input Parameters . . . . . . . . . . . . . . . 22
132 8.5. Information Resource Directory . . . . . . . . . . . . . . 22
133 8.5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 23
134 8.5.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . 23
135 8.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 24
136 8.5.4. Multiple Choices and OPTIONS . . . . . . . . . . . . . 26
137 8.5.5. Usage Considerations . . . . . . . . . . . . . . . . . 29
138 8.6. Information Resource: Content Encoding . . . . . . . . . . 29
139 8.6.1. Meta Information . . . . . . . . . . . . . . . . . . . 30
140 8.6.2. Data Information . . . . . . . . . . . . . . . . . . . 30
141 8.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 30
142 8.7. Protocol Errors . . . . . . . . . . . . . . . . . . . . . 30
143 8.7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 31
144 8.7.2. Resource Format and Error Codes . . . . . . . . . . . 31
145 8.7.3. Overload Conditions and Server Unavailability . . . . 32
146 9. Protocol Specification: Basic ALTO Data Types . . . . . . . . 32
147 9.1. PID Name . . . . . . . . . . . . . . . . . . . . . . . . . 32
148 9.2. Version Tag . . . . . . . . . . . . . . . . . . . . . . . 32
149 9.3. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 33
150 9.3.1. Address Type . . . . . . . . . . . . . . . . . . . . . 33
151 9.3.2. Endpoint Address . . . . . . . . . . . . . . . . . . . 33
152 9.3.3. Endpoint Prefixes . . . . . . . . . . . . . . . . . . 34
153 9.3.4. Endpoint Address Group . . . . . . . . . . . . . . . . 34
154 9.4. Cost Mode . . . . . . . . . . . . . . . . . . . . . . . . 35
155 9.5. Cost Metric . . . . . . . . . . . . . . . . . . . . . . . 35
156 9.6. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . 36
157 9.7. Endpoint Property . . . . . . . . . . . . . . . . . . . . 36
158 10. Protocol Specification: Service Information Resources . . . . 36
159 10.1. Map Service . . . . . . . . . . . . . . . . . . . . . . . 37
160 10.1.1. Network Map . . . . . . . . . . . . . . . . . . . . . 37
161 10.1.2. Cost Map . . . . . . . . . . . . . . . . . . . . . . . 39
162 10.2. Map Filtering Service . . . . . . . . . . . . . . . . . . 42
163 10.2.1. Filtered Network Map . . . . . . . . . . . . . . . . . 42
164 10.2.2. Filtered Cost Map . . . . . . . . . . . . . . . . . . 44
165 10.3. Endpoint Property Service . . . . . . . . . . . . . . . . 48
166 10.3.1. Endpoint Property . . . . . . . . . . . . . . . . . . 48
167 10.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 51
168 10.4.1. Endpoint Cost . . . . . . . . . . . . . . . . . . . . 51
169 11. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 54
170 11.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 55
171 11.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 56
172 11.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 57
173 12. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 58
174 12.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 58
175 12.2. Hosts with Multiple Endpoint Addresses . . . . . . . . . . 59
176 12.3. Network Address Translation Considerations . . . . . . . . 59
177 12.4. Endpoint and Path Properties . . . . . . . . . . . . . . . 60
178 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
179 13.1. application/alto-* Media Types . . . . . . . . . . . . . . 60
180 13.2. ALTO Cost Metric Registry . . . . . . . . . . . . . . . . 61
181 13.3. ALTO Endpoint Property Type Registry . . . . . . . . . . . 63
182 13.4. ALTO Address Type Registry . . . . . . . . . . . . . . . . 63
183 13.5. ALTO Error Code Registry . . . . . . . . . . . . . . . . . 64
184 14. Security Considerations . . . . . . . . . . . . . . . . . . . 65
185 14.1. Authenticity and Integrity of ALTO Information . . . . . . 65
186 14.1.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 65
187 14.1.2. Protection Strategies . . . . . . . . . . . . . . . . 65
188 14.1.3. Limitations . . . . . . . . . . . . . . . . . . . . . 66
189 14.2. Potential Undesirable Guidance from Authenticated ALTO
190 Information . . . . . . . . . . . . . . . . . . . . . . . 66
191 14.2.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 66
192 14.2.2. Protection Strategies . . . . . . . . . . . . . . . . 66
193 14.3. Confidentiality of ALTO Information . . . . . . . . . . . 67
194 14.3.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 67
195 14.3.2. Protection Strategies . . . . . . . . . . . . . . . . 67
196 14.3.3. Limitations . . . . . . . . . . . . . . . . . . . . . 68
197 14.4. Privacy for ALTO Users . . . . . . . . . . . . . . . . . . 68
198 14.4.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 68
199 14.4.2. Protection Strategies . . . . . . . . . . . . . . . . 68
200 14.5. Availability of ALTO Service . . . . . . . . . . . . . . . 69
201 14.5.1. Risk Scenarios . . . . . . . . . . . . . . . . . . . . 69
202 14.5.2. Protection Strategies . . . . . . . . . . . . . . . . 69
203 15. Manageability Considerations . . . . . . . . . . . . . . . . . 69
204 15.1. Operations . . . . . . . . . . . . . . . . . . . . . . . . 69
205 15.1.1. Installation and Initial Setup . . . . . . . . . . . . 70
206 15.1.2. Migration Path . . . . . . . . . . . . . . . . . . . . 70
207 15.1.3. Requirements on Other Protocols and Functional
208 Components . . . . . . . . . . . . . . . . . . . . . . 70
209 15.1.4. Impact and Observation on Network Operation . . . . . 71
210 15.2. Management . . . . . . . . . . . . . . . . . . . . . . . . 71
211 15.2.1. Management Interoperability . . . . . . . . . . . . . 71
212 15.2.2. Management Information . . . . . . . . . . . . . . . . 72
213 15.2.3. Fault Management . . . . . . . . . . . . . . . . . . . 72
214 15.2.4. Configuration Management . . . . . . . . . . . . . . . 72
215 15.2.5. Performance Management . . . . . . . . . . . . . . . . 72
216 15.2.6. Security Management . . . . . . . . . . . . . . . . . 73
217 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73
218 16.1. Normative References . . . . . . . . . . . . . . . . . . . 73
219 16.2. Informative References . . . . . . . . . . . . . . . . . . 74
220 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 76
221 Appendix B. Design History and Merged Proposals . . . . . . . . . 77
222 Appendix C. Authors . . . . . . . . . . . . . . . . . . . . . . . 78
223 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78
225 1. Introduction
227 1.1. Background and Problem Statement
229 Today, network information available to applications is mostly from
230 the view of endhosts. There is no clear mechanism for a network to
231 convey to network applications its point of view on its network
232 topological structures and path preferences, forcing applications to
233 make approximations using data sources such as BGP Looking Glass
234 and/or applications' own measurements, which can be misleading or
235 inaccurate. On the other hand, modern network applications can be
236 adaptive, and hence become more network-efficient (e.g., reduce
237 network resource consumption) and achieve better application
238 performance (e.g., accelerated download rate), by leveraging better
239 network-provided information.
241 This document defines the ALTO protocol to implement the ALTO
242 Service, which provides a simple mechanism to convey useful network
243 information such as topological and path preference information to
244 applications from the underlying network Providers' points of view.
245 The ALTO protocol meets the ALTO requirements [I-D.ietf-alto-reqs],
246 and unifies multiple protocols previously designed with similar
247 intentions. See Appendix A for a list of people and Appendix B for a
248 list of proposals that have made significant contributions to this
249 effort.
251 The ALTO protocol uses a REST-ful design [Fielding-Thesis], and
252 encodes its requests and responses using JSON [RFC4627]. These
253 designs are chosen because of their flexibility and extensibility.
254 In addition, these designs make it possible for ALTO to be deployed
255 at scale by leveraging existing HTTP [RFC2616] implementations,
256 infrastructures and deployment experience.
258 1.2. Solution Benefits
260 At a high level, the ALTO Service allows a Service Provider (e.g., an
261 ISP) to publish network information such as network locations, costs
262 between them at configurable granularities, and endhost properties.
264 A mechanism to publish such information can benefit both Service
265 Providers (providers of the information) and Applications (consumers
266 of the information). We enumerate some benefits below.
268 1.2.1. Service Providers
270 A Service Provider that provides an ALTO Service can achieve better
271 utilization of its networking infrastructure. For example, by using
272 ALTO as a tool to interact with applications, a Service Provider is
273 able to provide network information to applications so that the
274 applications can better manage traffic on more expensive or difficult
275 to provision links such as long distance, transit or backup links.
277 1.2.2. Applications
279 Applications that use an ALTO Service can benefit from better
280 knowledge of the network to avoid network bottlenecks. For example,
281 a peer-to-peer overlay application can use information provided by an
282 ALTO Service to avoid selecting peers connected with low bandwidth
283 links. By using ALTO information, applications can reduce the
284 reliance on obtaining network information through third-party
285 databases; applications relying on measuring path performance metrics
286 themselves can reduce the measurement overhead by conducting only
287 fine-tuning or fault-tolerant measurements on top of ALTO
288 information.
290 2. Terminology
292 We use the following terms defined in [RFC5693]: Application, Overlay
293 Network, Peer, Resource, Resource Identifier, Resource Provider,
294 Resource Consumer, Resource Directory, Transport Address, Host
295 Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO
296 Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic,
297 Transit Traffic.
299 We also use the following additional terms: Endpoint Address,
300 Autonomous System Number (ASN), Network Location, ALTO Information,
301 and ALTO Information Base.
303 2.1. Endpoint
305 An Endpoint is an application or host that is capable of
306 communicating (sending and/or receiving messages) on a network.
308 An Endpoint is typically either a Resource Provider or Resource
309 Consumer.
311 2.2. Endpoint Address
313 An Endpoint Address represents the communication address of an
314 endpoint. Common forms of Endpoint Addresses include IP address, MAC
315 address, overlay ID, and phone number. An Endpoint Address can be
316 network-attachment based (e.g., IP address) or network-attachment
317 agnostic (e.g., MAC address).
319 Each Endpoint Address has an associated Address Type, which indicates
320 both its syntax and semantics.
322 2.3. ASN
324 An Autonomous System Number.
326 2.4. Network Location
328 Network Location is a generic term denoting a single Endpoint or a
329 group of Endpoints. For instance, it can be a single IPv4 or IPv6
330 address, an IPv4 or IPv6 prefix, or a set of prefixes.
332 2.5. ALTO Information
334 ALTO Information is a generic term referring to the network
335 information sent by an ALTO Server.
337 2.6. ALTO Information Base
339 Internal representation of the ALTO Information maintained by the
340 ALTO Server. Note that the structure of this internal representation
341 is not defined by this document.
343 3. Architecture
345 We now define the ALTO architecture and the ALTO Protocol's place in
346 the overall architecture.
348 3.1. ALTO Service and Protocol Scope
350 Each network region in the global Internet can provide its ALTO
351 Service, which conveys network information from the perspective of
352 that network region. A network region in this context can be an
353 Autonomous System (AS), an ISP, a region smaller than an AS or ISP,
354 or a set of ISPs. The specific network region that an ALTO Service
355 represents will depend on the ALTO deployment scenario and ALTO
356 service discovery mechanism.
358 Specifically, the ALTO Service of a network region defines network
359 Endpoints (and aggregations thereof) and generic costs amongst them
360 from the region's perspective. The network Endpoints may include all
361 Endpoints in the global Internet. Hence, we say that the network
362 information provided by the ALTO Service of a network region
363 represents the "my-Internet View" of the network region.
365 To better understand the ALTO Service and the role of the ALTO
366 Protocol, we show in Figure 1 the overall ALTO system architecture.
368 In this architecture, an ALTO Server prepares ALTO Information; an
369 ALTO Client uses ALTO Service Discovery to identify an appropriate
370 ALTO Server; and the ALTO Client requests available ALTO Information
371 from the ALTO Server using the ALTO Protocol.
373 The ALTO Information provided by the ALTO Server can be updated
374 dynamically based on network conditions, or can be seen as a policy
375 which is updated at a larger time-scale.
377 +-------------------------------------------------------------------+
378 | Network Region |
379 | |
380 | +-----------+ |
381 | | Routing | |
382 | +--------------+ | Protocols | |
383 | | Provisioning | +-----------+ |
384 | | Policy | | |
385 | +--------------+\ | |
386 | \ | |
387 | \ | |
388 | +-----------+ \+---------+ +--------+ |
389 | |Dynamic | | ALTO | ALTO Protocol | ALTO | |
390 | |Network |.......| Server | ==================== | Client | |
391 | |Information| +---------+ +--------+ |
392 | +-----------+ / / |
393 | / ALTO SD Query/Response / |
394 | / / |
395 | +----------+ +----------------+ |
396 | | External | | ALTO Service | |
397 | | Interface| | Discovery (SD) | |
398 | +----------+ +----------------+ |
399 | | |
400 +-------------------------------------------------------------------+
401 |
402 +------------------+
403 | Third Parties |
404 | |
405 | Content Providers|
406 +------------------+
408 Figure 1: Basic ALTO Architecture.
410 Figure 1 illustrates that the ALTO Information provided by an ALTO
411 Server may be influenced (at the service provider's discretion) by
412 other systems. In particular, the ALTO Server can aggregate
413 information from multiple systems to provide an abstract and unified
414 view that can be more useful to applications. Examples of other
415 systems include (but are not limited to) static network configuration
416 databases, dynamic network information, routing protocols,
417 provisioning policies, and interfaces to outside parties. These
418 components are shown in the figure for completeness but are outside
419 the scope of this specification. Recall that while the ALTO Protocol
420 may convey dynamic network information, it is not intended to replace
421 near-real-time congestion control protocols.
423 It may also be possible for an ALTO Server to exchange network
424 information with other ALTO Servers (either within the same
425 administrative domain or another administrative domain with the
426 consent of both parties) in order to adjust exported ALTO
427 Information. Such a protocol is also outside the scope of this
428 specification.
430 3.2. ALTO Information Reuse and Redistribution
432 ALTO Information may be useful to a large number of applications and
433 users. At the same time, distributing ALTO Information must be
434 efficient and not become a bottleneck.
436 The design of ALTO allows integration with the existing HTTP caching
437 infrastructure to redistribute ALTO Information. If caching or
438 redistribution is used, the response message to an ALTO Client may be
439 returned from a third-party.
441 Application-dependent mechanisms, such as P2P DHTs or P2P file-
442 sharing, may be used to cache and redistribute ALTO Information.
443 This document does not define particular mechanisms for such
444 redistribution.
446 Additional protocol mechanisms (e.g., expiration times and digital
447 signatures for returned ALTO information) are left for future
448 investigation.
450 4. ALTO Information Service Framework
452 The ALTO Protocol conveys network information through services, where
453 each service defines a set of related functionalities. An ALTO
454 Client can query each service individually. All of the services
455 defined in ALTO are said to form the ALTO service framework and are
456 provided through a common transport protocol, messaging structure and
457 encoding, and transaction model. Functionalities offered in
458 different services can overlap.
460 In this document, we focus on achieving the goal of conveying (1)
461 Network Locations, which denote the locations of Endpoints at a
462 network, (2) provider-defined costs for paths between pairs of
463 Network Locations, and (3) network related properties of endhosts.
464 We achieve the goal by defining the Map Service, which provides the
465 core ALTO information to clients, and three additional services: the
466 Map Filtering Service, Endpoint Property Service, and Endpoint Cost
467 Service. Additional services can be defined in companion documents.
468 Below we give an overview of the services. Details of the services
469 will be presented in the following sections.
471 .-----------------------------------------.
472 | ALTO Information Services |
473 | .-----------. .----------. .----------. |
474 | | Map | | Endpoint | | Endpoint | |
475 | | Filtering | | Property | | Cost | |
476 | | Service | | Service | | Service | |
477 | `-----------' `----------' `----------' |
478 | .-------------------------------------. |
479 | | Map Service | |
480 | | .-------------. .--------------. | |
481 | | | Network Map | | Cost Map | | |
482 | | `-------------' `--------------' | |
483 | `-------------------------------------' |
484 `-----------------------------------------'
486 Figure 2: ALTO Service Framework.
488 4.1. ALTO Information Services
490 4.1.1. Map Service
492 The Map Service provides batch information to ALTO Clients in the
493 form of Network Map and Cost Map. The Network Map (See Section 5)
494 provides the full set of Network Location groupings defined by the
495 ALTO Server and the Endpoints contained within each grouping. The
496 Cost Map (see Section 6) provides costs between the defined
497 groupings.
499 These two maps can be thought of (and implemented as) as simple files
500 with appropriate encoding provided by the ALTO Server.
502 4.1.2. Map Filtering Service
504 Resource constrained ALTO Clients may benefit from filtering of query
505 results at the ALTO Server. This avoids that an ALTO Client spends
506 network bandwidth and CPU cycles to collect results and then perform
507 client-side filtering. The Map Filtering Service allows ALTO Clients
508 to query for the ALTO Server Network Map and Cost Map based on
509 additional parameters.
511 4.1.3. Endpoint Property Service
513 This service allows ALTO Clients to look up properties for individual
514 Endpoints. An example property of an Endpoint is its Network
515 Location (i.e., its grouping defined by the ALTO Server). Another
516 example property is its connectivity type such as ADSL (Asymmetric
517 Digital Subscriber Line), Cable, or FTTH (Fiber To The Home).
519 4.1.4. Endpoint Cost Service
521 Some ALTO Clients may also benefit from querying for costs and
522 rankings based on Endpoints. The Endpoint Cost Service allows an
523 ALTO Server to return either numerical costs or ordinal costs
524 (rankings) directly amongst Endpoints.
526 5. Network Map
528 An ALTO Network Map defines a grouping of network endpoints. In this
529 document, we use Network Map to refer to the syntax and semantics of
530 how an ALTO Server distributes the grouping. This document does not
531 discuss the internal representation of this data structure within the
532 ALTO Server.
534 The definition of Network Map is based on the observation that in
535 reality, many endpoints are close by to one another in terms of
536 network connectivity. By treating a group of close-by endpoints
537 together as a single entity, an ALTO Server indicates aggregation of
538 these endpoints due to their proximity. This aggregation can also
539 lead to greater scalability without losing critical information when
540 conveying other network information (e.g., when defining Cost Map).
542 5.1. Provider-defined Identifier (PID)
544 One issue is that proximity varies depending on the granularity of
545 the ALTO information configured by the provider. In one deployment,
546 endpoints on the same subnet may be considered close; while in
547 another deployment, endpoints connected to the same Point of Presence
548 (PoP) may be considered close.
550 ALTO introduces provider-defined Network Location identifiers called
551 Provider-defined Identifiers (PIDs) to provide an indirect and
552 network-agnostic way to specify an aggregation of network endpoints
553 that may be treated similarly, based on network topology, type, or
554 other properties. Specifically, a PID is a US-ASCII string of type
555 PIDName (see Section 9.1) and its associated set of Endpoint
556 Addresses. As we discussed above, there can be many different ways
557 of grouping the endpoints and assigning PIDs. For example, a PID may
558 denote a subnet, a set of subnets, a metropolitan area, a PoP, an
559 autonomous system, or a set of autonomous systems.
561 A key use case of PIDs is to specify network preferences (costs)
562 between PIDs instead of individual endpoints. This allows cost
563 information to be more compactly represented and updated at a faster
564 time scale than the network aggregations themselves. For example, an
565 ISP may prefer that endpoints associated with the same PoP (Point-of-
566 Presence) in a P2P application communicate locally instead of
567 communicating with endpoints in other PoPs. The ISP may aggregate
568 endhosts within a PoP into a single PID in the Network Map. The cost
569 may be encoded to indicate that Network Locations within the same PID
570 are preferred; for example, cost(PID_i, PID_i) == c and cost(PID_i,
571 PID_j) > c for i != j. Section 6 provides further details on using
572 PIDs to represent costs in an ALTO Cost Map.
574 5.2. Endpoint Addresses
576 The endpoints aggregated into a PID are denoted by endpoint
577 addresses. There are many types of addresses, such as IP addresses,
578 MAC addresses, or overlay IDs. This specification only considers IP
579 addresses.
581 5.2.1. IP Addresses
583 When either an ALTO Client or ALTO Server needs to determine which
584 PID in a Network Map contains a particular IP address, longest-prefix
585 matching MUST be used.
587 A Network Map MUST define a PID for each possible address in the IP
588 address space for all of the address types contained in the map. A
589 RECOMMENDED way to satisfy this property is to define a PID with the
590 shortest enclosing prefix of the addresses provided in the map. For
591 a map with full IPv4 reachability, this would mean including the
592 0.0.0.0/0 prefix in a PID; for full IPv6 reachability, this would be
593 the ::/0 prefix.
595 Each endpoint MUST map into exactly one PID. Since longest-prefix
596 matching is used to map an endpoint to a PID, this can be
597 accomplished by ensuring that no two PIDs contain an identical IP
598 prefix.
600 5.3. Example Network Map
602 Figure 3 illustrates an example Network Map. PIDs are used to
603 identify network-agnostic aggregations.
605 .-----------------------------------------------------------.
606 | ALTO Network Map |
607 | |
608 | .-----------------------------------. .---------------. |
609 | | NetLoc: PID-1 | | NetLoc: PID-2 | |
610 | | .------------------------------. | | ... | |
611 | | | 192.0.2.0/24 | | `---------------` |
612 | | | .--------------------------. | | |
613 | | | | Endpoint: 192.0.2.34 | | | .---------------. |
614 | | | `--------------------------` | | | NetLoc: PID-3 | |
615 | | `------------------------------` | | ... | |
616 | | .------------------------------. | `---------------` |
617 | | | 198.51.100.0/25 | | |
618 | | | .--------------------------. | | .---------------. |
619 | | | | Endpoint: 198.51.100.100 | | | | NetLoc: PID-4 | |
620 | | | `--------------------------` | | | ... | |
621 | | `------------------------------` | `---------------` |
622 | `-----------------------------------` |
623 | |
624 `-----------------------------------------------------------`
626 Figure 3: Example Network Map.
628 6. Cost Map
630 An ALTO Server indicates preferences amongst network locations in the
631 form of Path Costs. Path Costs are generic costs and can be
632 internally computed by a network provider according to its own needs.
634 An ALTO Cost Map defines Path Costs pairwise amongst sets of source
635 and destination Network Locations defined by PIDs. Each Path Cost is
636 the end-to-end cost when a unit of traffic goes from the source to
637 the destination.
639 As cost is directional from the source to the destination, an
640 application, when using ALTO Information, may independently determine
641 how the Resource Consumer and Resource Provider are designated as the
642 source or destination in an ALTO query, and hence how to utilize the
643 Path Cost provided by ALTO Information. For example, if the cost is
644 expected to be correlated with throughput, a typical application
645 concerned with bulk data retrieval may use the Resource Provider as
646 the source, and Resource Consumer as the destination.
648 One advantage of separating ALTO information into a Network Map and a
649 Cost Map is that the two components can be updated at different time
650 scales. For example, Network Maps may be stable for a longer time
651 while Cost Maps may be updated to reflect dynamic network conditions.
653 As used in this document, the Cost Map refers to the syntax and
654 semantics of the information distributed by the ALTO Server. This
655 document does not discuss the internal representation of this data
656 structure within the ALTO Server.
658 6.1. Cost Types
660 Path Costs have attributes:
662 o Metric: identifies what the costs represent;
664 o Mode: identifies how the costs should be interpreted.
666 The combination of a metric and a mode defines a Cost Type. Certain
667 queries for Cost Maps allow the ALTO Client to indicate the desired
668 Cost Type.
670 6.1.1. Cost Metric
672 The Metric attribute indicates what the cost represents. For
673 example, an ALTO Server could define costs representing air-miles,
674 hop-counts, or generic routing costs.
676 Cost metrics are indicated in protocol messages as strings.
678 6.1.1.1. Cost Metric: routingcost
680 An ALTO Server MUST offer the 'routingcost' Cost Metric.
682 This Cost Metric conveys a generic measure for the cost of routing
683 traffic from a source to a destination. Lower values indicate a
684 higher preference for traffic to be sent from a source to a
685 destination.
687 Note that an ISP may internally compute routing cost using any method
688 it chooses (e.g., air-miles or hop-count) as long as it conforms to
689 these semantics.
691 6.1.2. Cost Mode
693 The Mode attribute indicates how costs should be interpreted.
694 Specifically, the Mode attribute indicates whether returned costs
695 should be interpreted as numerical values or ordinal rankings.
697 It is important to communicate such information to ALTO Clients, as
698 certain operations may not be valid on certain costs returned by an
699 ALTO Server. For example, it is possible for an ALTO Server to
700 return a set of IP addresses with costs indicating a ranking of the
701 IP addresses. Arithmetic operations that would make sense for
702 numerical values, do not make sense for ordinal rankings. ALTO
703 Clients may handle such costs differently.
705 Cost Modes are indicated in protocol messages as strings.
707 An ALTO Server MUST support at least one of 'numerical' and 'ordinal'
708 modes. An ALTO Client SHOULD be cognizant of operations when a
709 desired Cost Mode is not supported. For example, an ALTO Client
710 desiring numerical costs may adjust its behaviors if only the ordinal
711 Cost Mode is available. Alternatively, an ALTO Client desiring
712 ordinal costs may construct ordinal costs given numerical values if
713 only the numerical Cost Mode is available.
715 6.1.2.1. Cost Mode: numerical
717 This Cost Mode is indicated by the string 'numerical'. This mode
718 indicates that it is safe to perform numerical operations (e.g.
719 normalization or computing ratios for weighted load-balancing) on the
720 returned costs. The values are floating-point numbers.
722 6.1.2.2. Cost Mode: ordinal
724 This Cost Mode is indicated by the string 'ordinal'. This mode
725 indicates that the costs values in a Cost Map are a ranking (relative
726 to all other values in a Cost Map), with lower values indicating a
727 higher preference. The values are non-negative integers. Ordinal
728 cost values in a Cost Map need not be unique nor contiguous. In
729 particular, it is possible that two entries in a map have an
730 identical rank (ordinal cost value). This document does not specify
731 any behavior by an ALTO Client in this case; an ALTO Client may
732 decide to break ties by random selection, other application
733 knowledge, or some other means.
735 It is important to note that the values in the Cost Map provided with
736 the ordinal Cost Mode are not necessarily the actual cost known to
737 the ALTO Server.
739 6.2. Cost Map Structure
741 A query for a Cost Map either explicitly or implicitly includes a
742 list of Source Network Locations and a list of Destination Network
743 Locations. (Recall that a Network Location can be an endpoint
744 address or a PID.)
746 Specifically, assume that a query has a list of multiple Source
747 Network Locations, say [Src_1, Src_2, ..., Src_m], and a list of
748 multiple Destination Network Locations, say [Dst_1, Dst_2, ...,
749 Dst_n].
751 The ALTO Server will return the Path Cost for each of the m*n
752 communicating pairs (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ...,
753 Src_m -> Dst_1, ..., Src_m -> Dst_n). If the ALTO Server does not
754 define a Path Cost for a particular pair, it may be omitted. We
755 refer to this structure as a Cost Map.
757 If the Cost Mode is 'ordinal', the Path Cost of each communicating
758 pair is relative to the m*n entries.
760 6.3. Network Map and Cost Map Dependency
762 If a Cost Map contains PIDs in the list of Source Network Locations
763 or the list of Destination Network Locations, the Path Costs are
764 generated based on a particular Network Map (which defines the PIDs).
765 Version Tags are introduced to ensure that ALTO Clients are able to
766 use consistent information even though the information is provided in
767 two maps.
769 A Version Tag is an opaque string associated with a Network Map
770 maintained by the ALTO Server. Two Version Tags match only if their
771 strings are the same. Whenever the content of the Network Map
772 maintained by the ALTO Server changes, the Version Tag MUST also be
773 changed. Possibilities for generating a Version Tag include the
774 last-modified timestamp for the Network Map, or a hash of its
775 contents, where the collision probability is considered zero in
776 practical deployment scenarios.
778 A Network Map distributed by the ALTO Server includes its Version
779 Tag. A Cost Map referring to PIDs also includes the Version Tag of
780 the Network Map on which it is based.
782 7. Endpoint Properties
784 An endpoint property defines a network-aware property of an endpoint.
786 7.1. Endpoint Property Type
788 For each endpoint and an endpoint property type, there can be a value
789 for the property. The type of an Endpoint property is indicated in
790 protocol messages as a string. The value depends on the specific
791 property. For example, for a property such as whether an endpoint is
792 metered, the value is a true or false value.
794 7.1.1. Endpoint Property Type: pid
796 An ALTO Server MUST define the 'pid' Endpoint Property Type, which
797 provides the PID of an endpoint. Since the PID of an endpoint
798 depends on the Network Map, Version Tag of the Network Map used to
799 return the pid property MUST be included.
801 8. Protocol Specification: General Processing
803 This section first specifies general client and server processing.
804 The details of specific services will be covered in the following
805 sections.
807 8.1. Overall Design
809 The ALTO Protocol uses a REST-ful design. There are two primary
810 components to this design:
812 o Information Resources: Each service provides network information
813 as a set of information resources, which are distinguished by
814 their media types [RFC2046]. An ALTO Client may construct an HTTP
815 request for a particular information resource (including any
816 parameters, if necessary), and an ALTO Server returns the
817 requested information resource in an HTTP response.
819 o Information Resource Directory (IRD): An ALTO Server provides to
820 ALTO Clients a list of available information resources and the URI
821 at which each is provided. This document refers to this list as
822 the Information Resource Directory. ALTO Clients consult the
823 directory to determine the services provided by an ALTO Server.
825 8.2. Notation
827 This document uses 'JSONString', 'JSONNumber', 'JSONBool' to indicate
828 the JSON string, number, and boolean types, respectively. The type
829 'JSONValue' indicates a JSON value, as specified in Section 2.1 of
830 [RFC4627].
832 We use an adaptation of the C-style struct notation to define the
833 members (names/values) of JSON objects. An optional member is
834 enclosed by [ ], and an array is indicated by two numbers, m and n,
835 where m indicates the minimal number of values, and n is the maximum.
836 When we write .. for n, it means no upper bound. In the definitions,
837 the JSON names of the members are case sensitive.
839 For example, the definition below defines a new type Type4, with
840 three members named "name1", "name2", and "name3" respectively. The
841 member named "name3" is optional, and the member named "name2" is an
842 array of at least one value.
844 object {
845 Type1 name1;
846 Type2 name2<1..*>;
847 [Type3 name3;]
848 } Type4;
850 We also define dictionary maps (or maps for short) from strings to
851 JSON values. For example, the definition below defines a Type3
852 object as a map. Type1 must be defined as string, and Type2 can be
853 any type.
855 object-map {
856 Type1 -> Type2;
857 } Type3;
859 Note that despite the notation, no standard, machine-readable
860 interface definition or schema is provided. Extension documents may
861 document these as necessary.
863 8.3. Basic Operation
865 The ALTO Protocol employs standard HTTP [RFC2616]. It is used for
866 discovering available Information Resources at an ALTO Server and
867 retrieving Information Resources. ALTO Clients and ALTO Servers use
868 HTTP requests and responses carrying ALTO-specific content with
869 encoding as specified in this document, and MUST be compliant with
870 [RFC2616].
872 8.3.1. Client Discovering Information Resources
874 To discover available Information Resources, an ALTO Client requests
875 the Information Resource Directory, which an ALTO Server provides at
876 the URI found by the ALTO Discovery protocol.
878 Informally, an Information Resource Directory enumerates URIs at
879 which an ALTO Server offers Information Resources. Each entry in the
880 directory indicates a URI at which an ALTO Server accepts requests,
881 and returns either the requested Information Resource or an
882 Information Resource Directory that references additional Information
883 Resources. See Section 8.5 for a detailed specification.
885 8.3.2. Client Requesting Information Resources
887 Through the retrieved Information Resource Directories, an ALTO
888 Client can determine whether an ALTO Server supports the desired
889 Information Resource, and if it is supported, the URI at which it is
890 available.
892 Where possible, the ALTO Protocol uses the HTTP GET method to request
893 resources. However, some ALTO services provide Information Resources
894 that are the function of one or more input parameters. Input
895 parameters are encoded in the HTTP request's entity body, and the
896 ALTO Client MUST use the HTTP POST method to send the parameters.
898 When requesting an ALTO Information Resource that requires input
899 parameters specified in a HTTP POST request, an ALTO Client MUST set
900 the Content-Type HTTP header to the media type corresponding to the
901 format of the supplied input parameters.
903 8.3.3. Server Responding to IR Request
905 Upon receiving a request for an Information Resource that the ALTO
906 Server can provide, the ALTO server MUST return the requested
907 Information Resource. In other cases, to be more informative
908 ([I-D.ietf-httpbis-p2-semantics]), the ALTO server MAY provide the
909 ALTO Client with an Information Resource Directory indicating how to
910 reach the desired information resource, or return an ALTO error
911 object; see Section 8.7 for more details on ALTO error handling.
913 It is possible for an ALTO Server to leverage caching HTTP
914 intermediaries to respond to both GET and POST requests by including
915 explicit freshness information (see Section 14 of [RFC2616]).
916 Caching of POST requests is not widely implemented by HTTP
917 intermediaries, however an alternative approach is for an ALTO
918 Server, in response to POST requests, to return an HTTP 303 status
919 code ("See Other") indicating to the ALTO Client that the resulting
920 Information Resource is available via a GET request to an alternate
921 URL. HTTP intermediaries that do not support caching of POST
922 requests could then cache the response to the GET request from the
923 ALTO Client following the alternate URL in the 303 response if the
924 response to the subsequent GET request contains explicit freshness
925 information.
927 The ALTO server MUST indicate the type of its response using a media
928 type (i.e., the Content-Type HTTP header of the response).
930 8.3.4. Client Handling Server Response
932 8.3.4.1. Using Information Resources
934 This specification does not indicate any required actions taken by
935 ALTO Clients upon successfully receiving an Information Resource from
936 an ALTO Server. Although ALTO Clients are suggested to interpret the
937 received ALTO Information and adapt application behavior, ALTO
938 Clients are not required to do so.
940 8.3.4.2. Handling IRD as a Response
942 After receiving an Information Resource Directory, the Client can
943 consult it to determine if any of the offered URIs contain the
944 desired Information Resource. Note that it is possible for an ALTO
945 Client to receive an Information Resource Directory from an ALTO
946 Server as a response to its request for a specific Information
947 Resource. In this case, the ALTO Client may ignore the response or
948 still parse the response. To indicate that an ALTO Client will
949 always check if a response is an Information Resource Directory, the
950 ALTO Client can indicate in the "Accept" header of a HTTP request
951 that it can accept Information Resource Directory; see Section 8.5
952 for the media type.
954 8.3.4.3. Handling Error Conditions
956 If an ALTO Client does not successfully receive a desired Information
957 Resource from a particular ALTO Server (i.e., server response
958 indicates error or there is no response), the Client can either
959 choose another server (if one is available) or fall back to a default
960 behavior (e.g., perform peer selection without the use of ALTO
961 information, when used in a peer-to-peer system).
963 8.3.5. Authentication and Encryption
965 When server and/or client authentication, encryption, and/or
966 integrity protection are required, an ALTO Server MUST support SSL/
967 TLS [RFC5246] as a mechanism. For cases such as a public ALTO
968 service or deployment scenarios where there is an implicit trust
969 relationship between the client and the server and the network
970 infrastructure connecting them is secure, SSL/TLS may not be
971 necessary. See [RFC6125] for considerations regarding verification
972 of server identity.
974 8.3.6. HTTP Cookies
976 If cookies are included in an HTTP request received by an ALTO
977 Server, they MUST be ignored.
979 8.3.7. Parsing
981 This document only details object members used by this specification.
982 Extensions may include additional members within JSON objects defined
983 in this document. ALTO implementations MUST ignore such unknown
984 fields when processing ALTO messages.
986 8.4. Information Resource: Attributes
988 An Information Resource encodes the ALTO Information desired by an
989 ALTO Client. This document specifies multiple Information Resources
990 that can be provided by an ALTO Server.
992 Each Information Resource has certain attributes associated with it,
993 including its data format, its capabilities, and its accepted input
994 parameters. These attributes are published by an ALTO Server in its
995 Information Resource Directory.
997 8.4.1. Media Type
999 A Media Type [RFC2046] uniquely indicates a data format used to
1000 encode the content of an Information Resource that an ALTO Server
1001 returns to an ALTO Client in the HTTP entity body.
1003 8.4.2. Capabilities
1005 The Capabilities associated with an Information Resource announced by
1006 an ALTO Server indicates specific capabilities that the server can
1007 provide. For example, if an ALTO Server allows an ALTO Client to
1008 specify cost constraints when the Client requests a Cost Map
1009 Information Resource, the Server advertises the cost-constraints
1010 capability for its Cost Map Information Resource.
1012 8.4.3. Accepts Input Parameters
1014 An ALTO Server may allow an ALTO Client to supply input parameters
1015 when requesting certain Information Resources. The associated
1016 accepts attribute of an Information Resource is a Media Type, which
1017 indicates how the Client specifies the input parameters as contained
1018 in the entity body of the HTTP POST request.
1020 8.5. Information Resource Directory
1022 An ALTO Server uses Information Resource Directory to publish
1023 available Information Resources and their aforementioned attributes.
1024 Since resource selection happens after consumption of the Information
1025 Resource Directory, the format of the Information Resource Directory
1026 is designed to be simple with the intention of future ALTO Protocol
1027 versions maintaining backwards compatibility. Future extensions or
1028 versions of the ALTO Protocol SHOULD be accomplished by extending
1029 existing media types or adding new media types, but retaining the
1030 same format for the Information Resource Directory.
1032 An ALTO Server MUST make an Information Resource Directory available
1033 via the HTTP GET method to a URI discoverable by an ALTO Client.
1034 Discovery of this URI is out of scope of this document, but could be
1035 accomplished by manual configuration or by returning the URI of an
1036 Information Resource Directory from the ALTO Discovery Protocol
1037 [I-D.ietf-alto-server-discovery]. For recommendations on how the URI
1038 may look like, see [I-D.ietf-alto-server-discovery].
1040 8.5.1. Media Type
1042 The media type to indicate an information directory is "application/
1043 alto-directory+json".
1045 8.5.2. Encoding
1047 An Information Resource Directory is a JSON object of type
1048 InfoResourceDirectory:
1050 object {
1051 IRDMeta meta;
1052 IRDResourceEntry resources<0..*>;
1053 } InfoResourceDirectory;
1055 object-map {
1056 JSONString -> JSONValue;
1057 } IRDMeta;
1059 object {
1060 JSONString uri;
1061 JSONString media-types<1..*>;
1062 [JSONString accepts<0..*>;]
1063 [Capabilities capabilities;]
1064 } IRDResourceEntry;
1066 object {
1067 ...
1068 } Capabilities;
1070 where the "meta" member provides definitions related with the IRD
1071 itself, or can be used when defining multiple individual Information
1072 resources;
1073 the "resources" array indicates a list of Information Resources
1074 provided by an ALTO Server. Note that the list of available
1075 resources is enclosed in a JSON object for extensibility; future
1076 protocol versions may specify additional members in the
1077 InfoResourceDirectory object.
1079 Each entry specifies:
1081 uri A URI at which the ALTO Server provides one or more Information
1082 Resources, or an Information Resource Directory indicating
1083 additional Information Resources. URIs can be relative and MUST
1084 be resolved according to Section 5 of [RFC3986].
1086 media-types The list of all media types of Information Resources
1087 (see Section 8.4.1) available via GET or POST requests to the
1088 corresponding URI or URIs discoverable via the URI.
1090 accepts The list of all media types of input parameters (see
1091 Section 8.4.3) accepted by POST requests to the corresponding URI
1092 or URIs discoverable via the URI. If this member is not present,
1093 it MUST be assumed to be an empty array.
1095 capabilities A JSON Object enumerating capabilities of an ALTO
1096 Server in providing the Information Resource at the corresponding
1097 URI and Information Resources discoverable via the URI. If this
1098 member is not present, it MUST be assumed to be an empty object.
1099 If a capability for one of the offered Information Resources is
1100 not explicitly listed here, an ALTO Client may either issue an
1101 OPTIONS HTTP request to the corresponding URI to determine if the
1102 capability is supported, or assume its default value documented in
1103 this specification or an extension document describing the
1104 capability.
1106 If an entry has an empty list for "accepts", then the corresponding
1107 URI MUST support GET requests. If an entry has a non-empty list for
1108 "accepts", then the corresponding URI MUST support POST requests. If
1109 an ALTO Server wishes to support both GET and POST on a single URI,
1110 it MUST specify two entries in the Information Resource Directory.
1112 8.5.3. Example
1114 The following is an example Information Resource Directory returned
1115 by an ALTO Server.
1117 GET /directory HTTP/1.1
1118 Host: alto.example.com
1119 Accept: application/alto-directory+json,application/alto-error+json
1120 HTTP/1.1 200 OK
1121 Content-Length: TBA
1122 Content-Type: application/alto-directory+json
1124 {
1125 "meta" : {
1126 "cost-types": {
1127 "num-routing": {"cost-mode" : "numerical",
1128 "cost-metric": "routingcost",
1129 "description": "My default"},
1130 "num-hop": {"cost-mode" : "numerical",
1131 "cost-metric": "hopcount"}
1132 "ord-routing": {"cost-mode" : "ordinal",
1133 "cost-metric": "routingcost"},
1134 "ord-hop": {"cost-mode" : "ordinal",
1135 "cost-metric": "hopcount"}
1136 }
1137 },
1138 "resources" : [
1139 {
1140 "uri" : "http://alto.example.com/networkmap",
1141 "media-types" : [ "application/alto-networkmap+json" ]
1142 }, {
1143 "uri" : "http://alto.example.com/costmap/num/routingcost",
1144 "media-types" : [ "application/alto-costmap+json" ],
1145 "capabilities" : {
1146 "cost-type-names" : [ "num-routing" ]
1147 }
1148 }, {
1149 "uri" : "http://alto.example.com/costmap/num/hopcount",
1150 "media-types" : [ "application/alto-costmap+json" ],
1151 "capabilities" : {
1152 "cost-type-names" : [ "num-hop" ]
1153 }
1154 }, {
1155 "uri" : "http://custom.alto.example.com/maps",
1156 "media-types" : [
1157 "application/alto-networkmap+json",
1158 "application/alto-costmap+json"
1159 ],
1160 "accepts" : [
1161 "application/alto-networkmapfilter+json",
1162 "application/alto-costmapfilter+json"
1163 ]
1164 }, {
1165 "uri" : "http://alto.example.com/endpointprop/lookup",
1166 "media-types" : [ "application/alto-endpointprop+json" ],
1167 "accepts" : [ "application/alto-endpointpropparams+json" ],
1168 "capabilities" : {
1169 "prop-types" : [ "pid" ]
1170 }
1171 }, {
1172 "uri" : "http://alto.example.com/endpointcost/lookup",
1173 "media-types" : [ "application/alto-endpointcost+json" ],
1174 "accepts" : [ "application/alto-endpointcostparams+json" ],
1175 "capabilities" : {
1176 "cost-constraints" : true,
1177 "cost-type-names" : [ "num-routing", "num-hop",
1178 "ord-routing", "ord-hop"]
1179 }
1180 }
1181 ]
1182 }
1184 Specifically, the "meta" member of the example IRD defines four cost
1185 types so that each Information Resource can use them.
1187 The "resources" array of the example IRD defines six Information
1188 Resources. For example, the last entry is to provide the Endpoint
1189 Cost Service, which is indicated by the media-type "application/
1190 alto-endpointcost+json". An ALTO Client should use uri
1191 "http://alto.example.com/endpointcost/lookup" to access the service.
1192 The ALTO Client should format its request body to be the
1193 "application/alto-endpointcostparams+json" media type, as specified
1194 by the "accepts" attribute of the Information Resource. The "cost-
1195 type-names" member of the "capabilities" attribute of the Information
1196 Resource includes 4 defined cost types from the "meta" member of the
1197 IRD. Hence, one can verify that the Endpoint Cost Information
1198 Resource supports both Cost Metrics 'routingcost' and 'hopcount',
1199 each available for both 'numerical' and 'ordinal'. When requesting
1200 the Information Resource, an ALTO Client can specify cost
1201 constraints, as indicated by the "cost-constraints" member of the
1202 "capabilities" attribute.
1204 8.5.4. Multiple Choices and OPTIONS
1206 ALTO Information Resource Directory provides flexibility to an ALTO
1207 Server (e.g., delegation) so that it MAY indicate multiple
1208 Information Resources using one URI endpoint. In the example above,
1209 the ALTO Server provides additional Network and Cost Maps via a
1210 separate subdomain, "custom.alto.example.com". In particular, the
1211 maps available via this subdomain are Filtered Network and Cost Maps
1212 as well as pre-generated maps for the "hopcount" and "routingcost"
1213 Cost Metrics in the "ordinal" Cost Mode.
1215 If an ALTO Client requests one URI that provides multiple Information
1216 Resources, the ALTO Server replies with an HTTP 300 status code
1217 ("Multiple Choices"). The ALTO Client can discover the specific
1218 Information Resources indicated by the URI using an OPTIONS request.
1219 The ALTO Server SHOULD use the Information Resource Directory format
1220 in its reply to an OPTIONS request.
1222 Consider the preceding example. The ALTO Client can discover the
1223 maps available at "custom.alto.example.com" by successfully
1224 performing an OPTIONS request to
1225 "http://custom.alto.example.com/maps":
1227 OPTIONS /maps HTTP/1.1
1228 Host: custom.alto.example.com
1229 Accept: application/alto-directory+json,application/alto-error+json
1230 HTTP/1.1 200 OK
1231 Content-Length: TBA
1232 Content-Type: application/alto-directory+json
1234 {
1235 "meta" : {
1236 "cost-types": {
1237 "num-routing": {"cost-mode" : "numerical",
1238 "cost-metric": "routingcost",
1239 "description": "My default"},
1240 "num-hop": {"cost-mode" : "numerical",
1241 "cost-metric": "hopcount"}
1242 "ord-routing": {"cost-mode" : "ordinal",
1243 "cost-metric": "routingcost"},
1244 "ord-hop": {"cost-mode" : "ordinal",
1245 "cost-metric": "hopcount"}
1246 }
1247 },
1248 "resources" : [
1249 {
1250 "uri" : "http://custom.alto.example.com/networkmap/filtered",
1251 "media-types" : [ "application/alto-networkmap+json" ],
1252 "accepts" : [ "application/alto-networkmapfilter+json" ]
1253 }, {
1254 "uri" : "http://custom.alto.example.com/costmap/filtered",
1255 "media-types" : [ "application/alto-costmap+json" ],
1256 "accepts" : [ "application/alto-costmapfilter+json" ],
1257 "capabilities" : {
1258 "cost-constraints" : true,
1259 "cost-type-names" : [ "num-routing", "num-hop",
1260 "ord-routing", "ord-hop" ]
1261 }
1262 }, {
1263 "uri" : "http://custom.alto.example.com/ord/routingcost",
1264 "media-types" : [ "application/alto-costmap+json" ],
1265 "capabilities" : {
1266 "cost-type-names" : [ "ord-routing" ]
1267 }
1268 }, {
1269 "uri" : "http://custom.alto.example.com/ord/hopcount",
1270 "media-types" : [ "application/alto-costmap+json" ],
1271 "capabilities" : {
1272 "cost-type-names" : [ "ord-hop" ],
1273 }
1274 }
1275 ]
1276 }
1278 8.5.5. Usage Considerations
1280 8.5.5.1. ALTO Client
1282 This document specifies no requirements or constraints on ALTO
1283 Clients with regards to how they process an Information Resource
1284 Directory to identify the URI corresponding to a desired Information
1285 Resource. However, some advice is provided for implementors.
1287 It is possible that multiple entries in the directory match a desired
1288 Information Resource. For instance, in the example in Section 8.5.3,
1289 a full Cost Map with "numerical" Cost Mode and "routingcost" Cost
1290 Metric could be retrieved via a GET request to
1291 "http://alto.example.com/costmap/num/routingcost", or via a POST
1292 request to "http://custom.alto.example.com/costmap/filtered".
1294 In general, it is preferred for ALTO Clients to use GET requests
1295 where appropriate, since it is more likely for responses to be
1296 cachable.
1298 8.5.5.2. ALTO Server
1300 This document indicates that an ALTO Server may or may not provide
1301 the Information Resources specified in the Map Filtering Service. If
1302 these resources are not provided, it is indicated to an ALTO Client
1303 by the absence of a Network Map or Cost Map with any media types
1304 listed under "accepts".
1306 8.6. Information Resource: Content Encoding
1308 Though each Information Resource may have a distinct syntax and hence
1309 its unique Media Type, they are designed to have a common structure
1310 containing generic ALTO-layer metadata about the resource, as well as
1311 data itself.
1313 Specifically, each Information Resource has a single top-level JSON
1314 object of type InfoResourceEntity:
1316 object {
1317 InfoResourceMeta meta;
1318 InfoResourceDataType data;
1319 } InfoResourceEntity;
1321 with members:
1323 meta meta-information pertaining to the Information Resource;
1325 data the data contained in the Information Resource.
1327 8.6.1. Meta Information
1329 Meta information is encoded as a JSON object. This document does not
1330 specify any members, but it is defined here as a standard container
1331 for extensibility. Specifically, InfoResourceMetaData is defined as:
1333 object-map {
1334 JSONString -> JSONValue
1335 } InfoResourceMetaData;
1337 8.6.2. Data Information
1339 The "data" member of the InfoResourceEntity encodes the resource-
1340 specific data. In this document, we define four specific
1341 InfoResourceDataType: InfoResourceNetworkMap, InfoResourceCostMap,
1342 InfoResourceEndpointProperty, and InfoResourceEndpointCostMap, whose
1343 structures will be detailed below.
1345 8.6.3. Example
1347 The following is an example of the encoding for an Information
1348 Resource:
1350 HTTP/1.1 200 OK
1351 Content-Length: 40
1352 Content-Type: application/alto-costmap+json
1354 {
1355 "meta" : {},
1356 "data" : {
1357 ...
1358 }
1359 }
1361 8.7. Protocol Errors
1363 If there is an error processing a request, an ALTO Server SHOULD
1364 return additional ALTO-layer information, if it is available, in the
1365 form of an ALTO Error Resource encoded in the HTTP response' entity
1366 body. If no ALTO-layer information is available, an ALTO Server may
1367 omit an ALTO Error resource from the response.
1369 With or without additional ALTO-layer error information, an ALTO
1370 Server MUST set an appropriate HTTP status code. It is important to
1371 note that the HTTP Status Code and ALTO Error Resource have distinct
1372 roles. An ALTO Error Resource provides detailed information about
1373 why a particular request for an ALTO Resource was not successful.
1374 The HTTP status code indicates to HTTP processing elements (e.g.,
1375 intermediaries and clients) how the response should be treated.
1377 8.7.1. Media Type
1379 The media type for an ALTO Error Resource is "application/
1380 alto-error+json".
1382 8.7.2. Resource Format and Error Codes
1384 An ALTO Error Resource has the format:
1386 object {
1387 JSONString code;
1388 } ErrorResourceEntity;
1390 where:
1392 code An ALTO Error Code defined in Table 1. Note that the ALTO
1393 Error Codes defined in Table 1 are limited to support the error
1394 conditions needed for purposes of this document. Additional
1395 status codes may be defined in companion or extension documents.
1397 +-------------------------+-----------------------------------------+
1398 | ALTO Error Code | Description |
1399 +-------------------------+-----------------------------------------+
1400 | E_SYNTAX | Parsing error in request (including |
1401 | | identifiers) |
1402 | E_JSON_FIELD_MISSING | Required field missing |
1403 | E_JSON_VALUE_TYPE | JSON Value of unexpected type |
1404 | E_INVALID_COST_MODE | Invalid cost mode |
1405 | E_INVALID_COST_METRIC | Invalid cost metric |
1406 | E_INVALID_PROPERTY_TYPE | Invalid property type |
1407 +-------------------------+-----------------------------------------+
1409 Table 1: Defined ALTO Error Codes.
1411 If multiple errors are present in a single request (e.g., a request
1412 uses a JSONString when a JSONNumber is expected and a required field
1413 is missing), then the ALTO Server MUST return exactly one of the
1414 detected errors. However, the reported error is implementation
1415 defined, since specifying a particular order for message processing
1416 encroaches needlessly on implementation technique.
1418 8.7.3. Overload Conditions and Server Unavailability
1420 If an ALTO Server detects that it cannot handle a request from an
1421 ALTO Client due to excessive load, technical problems, or system
1422 maintenance, it SHOULD do one of the following:
1424 o Return an HTTP 503 ("Service Unavailable") status code to the ALTO
1425 Client. As indicated by [RFC2616], a the Retry-After HTTP header
1426 may be used to indicate when the ALTO Client should retry the
1427 request.
1429 o Return an HTTP 307 ("Temporary Redirect") status code indicating
1430 an alternate ALTO Server that may be able to satisfy the request.
1432 The ALTO Server MAY also terminate the connection with the ALTO
1433 Client.
1435 The particular policy applied by an ALTO Server to determine that it
1436 cannot service a request is outside of the scope of this document.
1438 9. Protocol Specification: Basic ALTO Data Types
1440 This section details the format for particular data values used in
1441 the ALTO Protocol.
1443 9.1. PID Name
1445 A PID Name is encoded as a US-ASCII string. The string MUST be no
1446 more than 64 characters, and MUST NOT contain any ASCII character
1447 below 0x21 or above 0x7E or the '.' separator (0x2E). The '.'
1448 separator is reserved for future use and MUST NOT be used unless
1449 specifically indicated by a companion or extension document.
1451 The type 'PIDName' is used in this document to indicate a string of
1452 this format.
1454 9.2. Version Tag
1456 A Version Tag is encoded as a case-sensitive US-ASCII string. The
1457 string MUST be no more than 64 characters, and MUST NOT contain any
1458 ASCII character below 0x21 or above 0x7E.
1460 The type 'VersionTag' is used in this document to indicate a string
1461 of this type. Two tags are the same if and only if they are byte for
1462 byte equal.
1464 9.3. Endpoints
1466 This section defines formats used to encode addresses for Endpoints.
1467 In a case that multiple textual representations encode the same
1468 Endpoint address or prefix (within the guidelines outlined in this
1469 document), the ALTO Protocol does not require ALTO Clients or ALTO
1470 Servers to use a particular textual representation, nor does it
1471 require that ALTO Servers reply to requests using the same textual
1472 representation used by requesting ALTO Clients. ALTO Clients must be
1473 cognizant of this.
1475 9.3.1. Address Type
1477 Address Types are encoded as US-ASCII strings consisting of only
1478 alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, and 0x61-
1479 0x7A). This document defines the address type 'ipv4' to refer to
1480 IPv4 addresses, and 'ipv6' to refer to IPv6 addresses. All Address
1481 Type identifiers appearing in an HTTP request or response with an
1482 'application/alto-*' media type MUST be registered in the ALTO
1483 Address Type registry (see Section 13.4).
1485 The type 'AddressType' is used in this document to indicate a string
1486 of this format.
1488 9.3.2. Endpoint Address
1490 Endpoint Addresses are encoded as US-ASCII strings. The exact
1491 characters and format depend on the type of endpoint address.
1493 The type 'EndpointAddr' is used in this document to indicate a string
1494 of this format.
1496 9.3.2.1. IPv4
1498 IPv4 Endpoint Addresses are encoded as specified by the 'IPv4address'
1499 rule in Section 3.2.2 of [RFC3986].
1501 9.3.2.2. IPv6
1503 IPv6 Endpoint Addresses are encoded as specified in Section 4 of
1504 [RFC5952].
1506 9.3.2.3. Typed Endpoint Addresses
1508 When an Endpoint Address is used, an ALTO implementation must be able
1509 to determine its type. For this purpose, the ALTO Protocol allows
1510 endpoint addresses to also explicitly indicate their type.
1512 Typed Endpoint Addresses are encoded as US-ASCII strings of the
1513 format 'AddressType:EndpointAddr' (with the ':' character as a
1514 separator). The type 'TypedEndpointAddr' is used to indicate a
1515 string of this format.
1517 9.3.3. Endpoint Prefixes
1519 For efficiency, it is useful to denote a set of Endpoint Addresses
1520 using a special notation (if one exists). This specification makes
1521 use of the prefix notations for both IPv4 and IPv6 for this purpose.
1523 Endpoint Prefixes are encoded as US-ASCII strings. The exact
1524 characters and format depend on the type of endpoint address.
1526 The type 'EndpointPrefix' is used in this document to indicate a
1527 string of this format.
1529 9.3.3.1. IPv4
1531 IPv4 Endpoint Prefixes are encoded as specified in Section 3.1 of
1532 [RFC4632].
1534 9.3.3.2. IPv6
1536 IPv6 Endpoint Prefixes are encoded as specified in Section 7 of
1537 [RFC5952].
1539 9.3.4. Endpoint Address Group
1541 The ALTO Protocol includes messages that specify potentially large
1542 sets of endpoint addresses. Endpoint Address Groups provide a more
1543 efficient way to encode such sets, even when the set contains
1544 endpoint addresses of different types.
1546 An Endpoint Address Group is defined as:
1548 object-map {
1549 AddressType -> EndpointPrefix<0..*>;
1550 } EndpointAddrGroup;
1551 In particular, an Endpoint Address Group is a JSON object
1552 representing a map, where each key is the string corresponding to an
1553 address type, and the corresponding value is an array listing
1554 prefixes of addresses of that type.
1556 The following is an example with both IPv4 and IPv6 endpoint
1557 addresses:
1559 {
1560 "ipv4": [
1561 "192.0.2.0/24",
1562 "198.51.100.0/25"
1563 ],
1564 "ipv6": [
1565 "2001:db8:0:1::/64",
1566 "2001:db8:0:2::/64"
1567 ]
1568 }
1570 9.4. Cost Mode
1572 A Cost Mode is encoded as a US-ASCII string. The string MUST either
1573 have the value 'numerical' or 'ordinal'.
1575 The type 'CostMode' is used in this document to indicate a string of
1576 this format.
1578 9.5. Cost Metric
1580 A Cost Metric is encoded as a US-ASCII string. The string MUST be no
1581 more than 32 characters, and MUST NOT contain characters other than
1582 alphanumeric characters (code points 0x30-0x39, 0x41-0x5A, and 0x61-
1583 0x7A), the hyphen ('-', code point 0x2D), or the colon (':', code
1584 point 0x3A).
1586 Identifiers prefixed with 'priv:' are reserved for Private Use
1587 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for
1588 Experimental use. For an identifier with the 'priv:' or 'exp:'
1589 prefix, an additional string (e.g., company identifier or random
1590 string) MUST follow to reduce potential collisions. For example, a
1591 short string after 'exp:' to indicate the starting time of a specific
1592 experiment is recommended. All other identifiers appearing in an
1593 HTTP request or response with an 'application/alto-*' media type MUST
1594 be registered in the ALTO Cost Metrics registry Section 13.2.
1596 The type 'CostMetric' is used in this document to indicate a string
1597 of this format.
1599 9.6. Cost Type
1601 The combinaton of CostType and a CostMode defines a CostType:
1603 object {
1604 CostMetric cost-metric;
1605 CostModel cost-mode;
1606 [JSONString description;]
1607 } CostType;
1609 'description', if present, MUST contain a US-ASCII string with a
1610 human-readable description of the cost-metric and cost-mode. The
1611 field SHOULD NOT be interpreted by an ALTO Client.
1613 9.7. Endpoint Property
1615 An Endpoint Property is encoded as a US-ASCII string. The string
1616 MUST be no more than 32 characters, and MUST NOT contain characters
1617 other than alphanumeric characters (code points 0x30-0x39, 0x41-0x5A,
1618 and 0x61-0x7A), the hyphen ('-', code point 0x2D), or the colon (':',
1619 code point 0x3A).
1621 Identifiers prefixed with 'priv:' are reserved for Private Use
1622 [RFC5226]. Identifiers prefixed with 'exp:' are reserved for
1623 Experimental use. For an identifier with the 'priv:' or 'exp:'
1624 prefix, an additional string (e.g., company identifier or random
1625 string) MUST follow to reduce potential collisions. For example, a
1626 short string after 'exp:' to indicate the starting time of a specific
1627 experiment is recommended. All other identifiers appearing in an
1628 HTTP request or response with an 'application/alto-*' media type MUST
1629 be registered in the ALTO Endpoint Property registry Section 13.3.
1631 The type 'EndpointPropertyType' is used in this document to indicate
1632 a string of this format.
1634 10. Protocol Specification: Service Information Resources
1636 This section documents the individual Information Resources defined
1637 to provide the services define in this document.
1639 10.1. Map Service
1641 The Map Service provides batch information to ALTO Clients in the
1642 form of two types of maps: a Network Map and Cost Map.
1644 10.1.1. Network Map
1646 The Network Map Information Resource lists for each PID, the network
1647 locations (endpoints) within the PID. It MUST be provided by an ALTO
1648 Server.
1650 10.1.1.1. Media Type
1652 The media type of Network Map is "application/alto-networkmap+json".
1654 10.1.1.2. HTTP Method
1656 The Network Map resource is requested using the HTTP GET method.
1658 10.1.1.3. Accept Input Parameters
1660 None.
1662 10.1.1.4. Capabilities
1664 None.
1666 10.1.1.5. Response
1668 The "data" member of the returned InfoResourceEntity for a Network
1669 Map is an object of type InfoResourceNetworkMap:
1671 object {
1672 VersionTag map-vtag;
1673 NetworkMapData map;
1674 } InfoResourceNetworkMap;
1676 object-map {
1677 PIDName -> EndpointAddrGroup;
1678 } NetworkMapData;
1680 with members:
1682 map-vtag The Version Tag (Section 6.3) of the Network Map.
1684 map The Network Map data itself.
1686 NetworkMapData is a JSON object representing a dictionary map with
1687 each key representing a single PID, and the value the associated set
1688 of endpoint addresses.
1690 The returned Network Map MUST include all PIDs known to the ALTO
1691 Server.
1693 10.1.1.6. Example
1695 GET /networkmap HTTP/1.1
1696 Host: alto.example.com
1697 Accept: application/alto-networkmap+json,application/alto-error+json
1698 HTTP/1.1 200 OK
1699 Content-Length: 370
1700 Content-Type: application/alto-networkmap+json
1702 {
1703 "meta" : {},
1704 "data" : {
1705 "map-vtag" : "1266506139",
1706 "map" : {
1707 "PID1" : {
1708 "ipv4" : [
1709 "192.0.2.0/24",
1710 "198.51.100.0/25"
1711 ]
1712 },
1713 "PID2" : {
1714 "ipv4" : [
1715 "198.51.100.128/25"
1716 ]
1717 },
1718 "PID3" : {
1719 "ipv4" : [
1720 "0.0.0.0/0"
1721 ],
1722 "ipv6" : [
1723 "::/0"
1724 ]
1725 }
1726 }
1727 }
1728 }
1730 The encodings were chosen for readability and compactness. If lookup
1731 efficiency at runtime is crucial, then the returned Network Map and
1732 Cost Map can be transformed into data structures offering more
1733 efficient lookup, such as transforming the Network Map into a IP trie
1734 for longest-prefix matching and the Cost Map into a matrix.
1736 10.1.2. Cost Map
1738 The Cost Map resource lists the Path Cost for each pair of source/
1739 destination PID defined by the ALTO Server for a given Cost Metric
1740 and Cost Mode. This resource MUST be provided for at least the
1741 'routingcost' Cost Metric.
1743 10.1.2.1. Media Type
1745 The media type of Cost Map is "application/alto-costmap+json".
1747 10.1.2.2. HTTP Method
1749 The Cost Map resource is requested using the HTTP GET method.
1751 10.1.2.3. Accept Input Parameters
1753 None.
1755 10.1.2.4. Capabilities
1757 The capabilities of an ALTO Server URI providing an unfiltered cost
1758 map is a JSON Object of type CostMapCapabilities:
1760 object {
1761 JSONString cost-type-names<1..*>;
1762 } CostMapCapabilities;
1764 with member:
1766 cost-type-names A sequence of CostType names defined in "cost-types"
1767 of the "meta" member of an IRD. These represent the Cost Types
1768 that are supported via the corresponding URI in the IRD. If there
1769 is more than one Cost Type in this list, then the ALTO Server
1770 SHOULD return an IRD to the client to lead it towards the URIs for
1771 the corresponding Cost Maps. Since an unfiltered Cost Map is
1772 requested via an HTTP GET that accepts no input parameters, an
1773 ALTO Client MUST be led towards a resource that has a single
1774 element in the 'cost-type-names' list.
1776 10.1.2.5. Response
1778 The "data" member of the returned InfoResourceEntity for a Cost Map
1779 is an object of type InfoResourceCostMap:
1781 object {
1782 CostType cost-type;
1783 VersionTag map-vtag;
1784 CostMapData map;
1785 } InfoResourceCostMap;
1787 object-map {
1788 PIDName -> DstCosts;
1789 } CostMapData;
1791 object-map {
1792 PIDName -> JSONValue;
1793 } DstCosts;
1795 with members:
1797 cost-type Cost Type (Section 9.6) used in the Cost Map.
1799 map-vtag The Version Tag (Section 6.3) of the Network Map used to
1800 generate the Cost Map.
1802 map The Cost Map data itself.
1804 CostMapData is a dictionary map object, with each key being the
1805 PIDName string identifying the corresponding Source PID, and value
1806 being a type of DstCosts, which denotes the associated costs from the
1807 Source PID to a set of destination PIDs ( Section 6.2). An
1808 implementation of the protocol in this document SHOULD assume that
1809 the cost is a JSONNumber and fail to parse if it is not, unless the
1810 implementation is using an extension to this document that indicates
1811 when and how costs of other data types are signaled.
1813 The returned Cost Map MUST include the Path Cost for each (Source
1814 PID, Destination PID) pair for which a Path Cost is defined. An ALTO
1815 Server MAY omit entries for which a Path Cost is not defined (e.g.,
1816 both the Source and Destination PIDs contain addresses outside of the
1817 Network Provider's administrative domain).
1819 10.1.2.6. Example
1821 GET /costmap/num/routingcost HTTP/1.1
1822 Host: alto.example.com
1823 Accept: application/alto-costmap+json,application/alto-error+json
1824 HTTP/1.1 200 OK
1825 Content-Length: TBA
1826 Content-Type: application/alto-costmap+json
1828 {
1829 "meta" : {},
1830 "data" : {
1831 "cost-type" : {"cost-mode" : "numerical",
1832 "cost-metric": "routingcost"},
1833 "map-vtag" : "1266506139",
1834 "map" : {
1835 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 },
1836 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 },
1837 "PID3": { "PID1": 20, "PID2": 15 }
1838 }
1839 }
1840 }
1842 Similar to the Network Map case, we considered array-based encoding
1843 for "map", but chose the current encoding for clarity.
1845 10.2. Map Filtering Service
1847 The Map Filtering Service allows ALTO Clients to specify filtering
1848 criteria to return a subset of the full maps available in the Map
1849 Service.
1851 10.2.1. Filtered Network Map
1853 A Filtered Network Map is a Network Map Information Resource
1854 (Section 10.1.1) for which an ALTO Client may supply a list of PIDs
1855 to be included. A Filtered Network Map MAY be provided by an ALTO
1856 Server.
1858 10.2.1.1. Media Type
1860 As a Filtered Network Map is a Network Map, it uses the media type
1861 defined for Network Map at Section 10.1.1.1.
1863 10.2.1.2. HTTP Method
1865 A Filtered Network Map is requested using the HTTP POST method.
1867 10.2.1.3. Accept Input Parameters
1869 An ALTO Client supplies filtering parameters by specifying media type
1870 "application/alto-networkmapfilter+json" with HTTP POST body
1871 containing a JSON Object of type ReqFilteredNetworkMap, where:
1873 object {
1874 PIDName pids<0..*>;
1875 AddressType address-types<0..*>;
1876 } ReqFilteredNetworkMap;
1878 with members:
1880 pids Specifies list of PIDs to be included in the returned Filtered
1881 Network Map. If the list of PIDs is empty, the ALTO Server MUST
1882 interpret the list as if it contained a list of all currently-
1883 defined PIDs. The ALTO Server MUST interpret entries appearing
1884 multiple times as if they appeared only once.
1886 address-types Specifies list of address types to be included in the
1887 returned Filtered Network Map. If the list of address types is
1888 empty, the ALTO Server MUST interpret the list as if it contained
1889 a list of all address types known to the ALTO Server. The ALTO
1890 Server MUST interpret entries appearing multiple times as if they
1891 appeared only once.
1893 10.2.1.4. Capabilities
1895 None.
1897 10.2.1.5. Response
1899 See Section 10.1.1.5 for the format.
1901 The ALTO Server MUST only include PIDs in the response that were
1902 specified (implicitly or explicitly) in the request. If the input
1903 parameters contain a PID name that is not currently defined by the
1904 ALTO Server, the ALTO Server MUST behave as if the PID did not appear
1905 in the input parameters. Similarly, the ALTO Server MUST only
1906 enumerate addresses within each PID that have types which were
1907 specified (implicitly or explicitly) in the request. If the input
1908 parameters contain an address type that is not currently known to the
1909 ALTO Server, the ALTO Server MUST behave as if the address type did
1910 not appear in the input parameters.
1912 10.2.1.6. Example
1914 POST /networkmap/filtered HTTP/1.1
1915 Host: custom.alto.example.com
1916 Content-Length: 27
1917 Content-Type: application/alto-networkmapfilter+json
1918 Accept: application/alto-networkmap+json,application/alto-error+json
1920 {
1921 "pids": [ "PID1", "PID2" ]
1922 }
1924 HTTP/1.1 200 OK
1925 Content-Length: 255
1926 Content-Type: application/alto-networkmap+json
1928 {
1929 "meta" : {},
1930 "data" : {
1931 "map-vtag" : "1266506139",
1932 "map" : {
1933 "PID1" : {
1934 "ipv4" : [
1935 "192.0.2.0/24",
1936 "198.51.100.0/24"
1937 ]
1938 },
1939 "PID2" : {
1940 "ipv4": [
1941 "198.51.100.128/24"
1942 ]
1943 }
1944 }
1945 }
1946 }
1948 10.2.2. Filtered Cost Map
1950 A Filtered Cost Map is a Cost Map Information Resource
1951 (Section 10.1.2) for which an ALTO Client may supply additional
1952 parameters limiting the scope of the resulting Cost Map. A Filtered
1953 Cost Map MAY be provided by an ALTO Server.
1955 10.2.2.1. Media Type
1957 As a Filtered Cost Map is a Cost Map, it uses the media type defined
1958 for Cost Map at Section 10.1.2.1.
1960 10.2.2.2. HTTP Method
1962 A Filtered Cost Map is requested using the HTTP POST method.
1964 10.2.2.3. Accept Input Parameters
1966 The input parameters for a Filtered Map are supplied in the entity
1967 body of the POST request. This document specifies the input
1968 parameters with a data format indicated by the media type
1969 "application/alto-costmapfilter+json", which is a JSON Object of type
1970 ReqFilteredCostMap, where:
1972 object {
1973 CostType cost-type;
1974 [JSONString constraints<0..*>;]
1975 [PIDFilter pids;]
1976 } ReqFilteredCostMap;
1978 object {
1979 PIDName srcs<0..*>;
1980 PIDName dsts<0..*>;
1981 } PIDFilter;
1983 with members:
1985 cost-type The CostType (Section 9.6) for the returned costs. This
1986 MUST be one of the supported Cost Types indicated in this
1987 resource's capabilities ( Section 10.2.2.4).
1989 constraints Defines a list of additional constraints on which
1990 elements of the Cost Map are returned. This parameter MUST NOT be
1991 specified if this resource's capabilities ( Section 10.2.2.4)
1992 indicate that constraint support is not available. A constraint
1993 contains two entities separated by whitespace: (1) an operator,
1994 'gt' for greater than, 'lt' for less than, 'ge' for greater than
1995 or equal to, 'le' for less than or equal to, or 'eq' for equal to;
1996 (2) a target cost value. The cost value is a number that MUST be
1997 defined in the same units as the Cost Metric indicated by the
1998 cost-metric parameter. ALTO Servers SHOULD use at least IEEE 754
1999 double-precision floating point [IEEE.754.2008] to store the cost
2000 value, and SHOULD perform internal computations using double-
2001 precision floating-point arithmetic. If multiple 'constraint'
2002 parameters are specified, they are interpreted as being related to
2003 each other with a logical AND.
2005 pids A list of Source PIDs and a list of Destination PIDs for which
2006 Path Costs are to be returned. If a list is empty, the ALTO
2007 Server MUST interpret it as the full set of currently-defined
2008 PIDs. The ALTO Server MUST interpret entries appearing in a list
2009 multiple times as if they appeared only once. If the "pids"
2010 member is not present, both lists MUST be interpreted by the ALTO
2011 Server as containing the full set of currently-defined PIDs.
2013 10.2.2.4. Capabilities
2015 The URI providing this resource supports all capabilities documented
2016 in Section 10.1.2.4 (with identical semantics), plus additional
2017 capabilities. In particular, the capabilities are defined by a JSON
2018 object of type FilteredCostMapCapabilities:
2020 object {
2021 JSONString cost-type-names<1..*>;
2022 JSONBool cost-constraints;
2023 } FilteredCostMapCapabilities;
2025 with members:
2027 cost-type-names See Section 10.1.2.4 and note that the array can
2028 have 1 to many cost types.
2030 cost-constraints If true, then the ALTO Server allows cost
2031 constraints to be included in requests to the corresponding URI.
2032 If not present, this member MUST be interpreted as if it specified
2033 false. ALTO Clients should be aware that constraints may not have
2034 the intended effect for cost maps with the 'ordinal' Cost Mode
2035 since ordinal costs are not restricted to being sequential
2036 integers.
2038 10.2.2.5. Response
2040 See Section 10.1.2.5 for the format.
2042 The returned Cost Map MUST contain only source/destination pairs that
2043 have been indicated (implicitly or explicitly) in the input
2044 parameters. If the input parameters contain a PID name that is not
2045 currently defined by the ALTO Server, the ALTO Server MUST behave as
2046 if the PID did not appear in the input parameters.
2048 If any constraints are specified, Source/Destination pairs for which
2049 the Path Costs do not meet the constraints MUST NOT be included in
2050 the returned Cost Map. If no constraints were specified, then all
2051 Path Costs are assumed to meet the constraints.
2053 Note that ALTO Clients should verify that the Version Tag included in
2054 the response is consistent with the Version Tag of the Network Map
2055 used to generate the request (if applicable). If it is not, the ALTO
2056 Client may wish to request an updated Network Map, identify changes,
2057 and consider requesting a new Filtered Cost Map.
2059 10.2.2.6. Example
2061 POST /costmap/filtered HTTP/1.1
2062 Host: custom.alto.example.com
2063 Content-Type: application/alto-costmapfilter+json
2064 Accept: application/alto-costmap+json,application/alto-error+json
2066 {
2067 "cost-type" : {"cost-mode": "numerical",
2068 "cost-metric": "routingcost"},
2069 "pids" : {
2070 "srcs" : [ "PID1" ],
2071 "dsts" : [ "PID1", "PID2", "PID3" ]
2072 }
2073 }
2075 HTTP/1.1 200 OK
2076 Content-Length: 177
2077 Content-Type: application/alto-costmap+json
2079 {
2080 "meta" : {},
2081 "data" : {
2082 "cost-type": {"cost-mode" : "numerical",
2083 "cost-metric" : "routingcost"},
2084 "map-vtag" : "1266506139",
2085 "map" : {
2086 "PID1": { "PID1": 0, "PID2": 1, "PID3": 2 }
2087 }
2088 }
2089 }
2091 10.3. Endpoint Property Service
2093 The Endpoint Property Service provides information about Endpoint
2094 properties to ALTO Clients.
2096 10.3.1. Endpoint Property
2098 The Endpoint Property resource provides information about properties
2099 for individual endpoints. It MAY be provided by an ALTO Server. If
2100 an ALTO Server provides one or more Endpoint Property resources, then
2101 at least one MUST provide the 'pid' property.
2103 10.3.1.1. Media Type
2105 The media type of Endpoint Property is "application/
2106 alto-endpointprop+json".
2108 10.3.1.2. HTTP Method
2110 The Endpoint Property resource is requested using the HTTP POST
2111 method.
2113 10.3.1.3. Accept Input Parameters
2115 An ALTO Client supplies the endpoint properties to be queried through
2116 a media type "application/alto-endpointpropparams+json", and
2117 specifies in the HTTP POST entity body a JSON Object of type
2118 ReqEndpointProp:
2120 object {
2121 EndpointPropertyType properties<1..*>;
2122 TypedEndpointAddr endpoints<1..*>;
2123 } ReqEndpointProp;
2125 with members:
2127 properties List of endpoint properties to be returned for each
2128 endpoint. Each specified property MUST be included in the list of
2129 supported properties indicated by this resource's capabilities
2130 (Section 10.3.1.4). The ALTO Server MUST interpret entries
2131 appearing multiple times as if they appeared only once.
2133 endpoints List of endpoint addresses for which the specified
2134 properties are to be returned. The ALTO Server MUST interpret
2135 entries appearing multiple times as if they appeared only once.
2137 10.3.1.4. Capabilities
2139 This resource may be defined across multiple types of endpoint
2140 properties. The capabilities of an ALTO Server URI providing
2141 Endpoint Properties are defined by a JSON Object of type
2142 EndpointPropertyCapabilities:
2144 object {
2145 EndpointPropertyType prop-types<0..*>;
2146 } EndpointPropertyCapabilities;
2148 with members:
2150 prop-types The Endpoint Properties (see Section 9.7) supported by
2151 the corresponding URI. If not present, this member MUST be
2152 interpreted as an empty array.
2154 10.3.1.5. Response
2156 The returned InfoResourceEntity object has "data" member of type
2157 InfoResourceEndpointProperty, where:
2159 object {
2160 VersionTag map-vtag; [DEPEND ON PROPERTIES]
2161 EndpointPropertyMapData map;
2162 } InfoResourceEndpointProperty;
2164 object-map {
2165 TypedEndpointAddr -> EndpointProps;
2166 } EndpointPropertyMapData;
2168 object {
2169 EndpointPropertyType -> JSONValue;
2170 } EndpointProps;
2172 EndpointPropertyMapData has one member for each endpoint indicated in
2173 the input parameters (with the name being the endpoint encoded as a
2174 TypedEndpointAddr). The requested properties for each endpoint are
2175 encoded in a corresponding EndpointProps object, which encodes one
2176 name/value pair for each requested property, where the property names
2177 are encoded as strings of type EndpointPropertyType. An
2178 implementation of the protocol in this document SHOULD assume that
2179 the property value is a JSONString and fail to parse if it is not,
2180 unless the implementation is using an extension to this document that
2181 indicates when and how property values of other data types are
2182 signaled.
2184 The ALTO Server returns the value for each of the requested endpoint
2185 properties for each of the endpoints listed in the input parameters.
2187 If the ALTO Server does not define a requested property's value for a
2188 particular endpoint, then it MUST omit that property from the
2189 response for only that endpoint.
2191 The ALTO Server MAY include the Version Tag (Section 6.3) of the
2192 Network Map used to generate the response (if desired and applicable)
2193 as the 'map-vtag' member in the response. If the 'pid' property is
2194 returned for any endpoints in the response, the 'map-vtag' member is
2195 REQUIRED. Otherwise, it is OPTIONAL.
2197 10.3.1.6. Example
2199 POST /endpointprop/lookup HTTP/1.1
2200 Host: alto.example.com
2201 Content-Length: 96
2202 Content-Type: application/alto-endpointpropparams+json
2203 Accept: application/alto-endpointprop+json,application/alto-error+json
2205 {
2206 "properties" : [ "pid", "example-prop" ],
2207 "endpoints" : [ "ipv4:192.0.2.34", "ipv4:203.0.113.129" ]
2208 }
2210 HTTP/1.1 200 OK
2211 Content-Length: 149
2212 Content-Type: application/alto-endpointprop+json
2214 {
2215 "meta" : {},
2216 "data": {
2217 "map-vtag" : "1266506139",
2218 "map" : {
2219 "ipv4:192.0.2.34" : { "pid": "PID1", "example-prop": "1" },
2220 "ipv4:203.0.113.129" : { "pid": "PID3" }
2221 }
2222 }
2223 }
2225 10.4. Endpoint Cost Service
2227 The Endpoint Cost Service provides information about costs between
2228 individual endpoints.
2230 In particular, this service allows lists of Endpoint prefixes (and
2231 addresses, as a special case) to be ranked (ordered) by an ALTO
2232 Server.
2234 10.4.1. Endpoint Cost
2236 The Endpoint Cost resource provides information about costs between
2237 individual endpoints. It MAY be provided by an ALTO Server.
2239 It is important to note that although this resource allows an ALTO
2240 Server to reveal costs between individual endpoints, an ALTO Server
2241 is not required to do so. A simple alternative would be to compute
2242 the cost between two endpoints as the cost between the PIDs
2243 corresponding to the endpoints. See Section 14.3 for additional
2244 details.
2246 10.4.1.1. Media Type
2248 The media type of Endpoint Cost is "application/
2249 alto-endpointcost+json".
2251 10.4.1.2. HTTP Method
2253 The Endpoint Cost resource is requested using the HTTP POST method.
2255 10.4.1.3. Accept Input Parameters
2257 An ALTO Client supplies the endpoint cost parameters through a media
2258 type "application/alto-endpointcostparams+json", with an HTTP POST
2259 entity body of a JSON Object of type ReqEndpointCostMap:
2261 object {
2262 CostType cost-type;
2263 [JSONString constraints<0..*>;]
2264 EndpointFilter endpoints;
2265 } ReqEndpointCostMap;
2267 object {
2268 [TypedEndpointAddr srcs<0..*>;]
2269 TypedEndpointAddr dsts<1..*>;
2270 } EndpointFilter;
2271 with members:
2273 cost-type The Cost Type ( Section 9.6) to use for returned costs.
2274 This MUST be one of the CostType indicated in this resource's
2275 capabilities ( Section 10.4.1.4).
2277 constraints Defined equivalently to the "constraints" input
2278 parameter of a Filtered Cost Map (see Section 10.2.2).
2280 endpoints A list of Source Endpoints and Destination Endpoints for
2281 which Path Costs are to be returned. If the list of Source
2282 Endpoints is empty (or not included), the ALTO Server MUST
2283 interpret it as if it contained the Endpoint Address corresponding
2284 to the client IP address from the incoming connection (see
2285 Section 12.3 for discussion and considerations regarding this
2286 mode). The list of destination Endpoints MUST NOT be empty. The
2287 ALTO Server MUST interpret entries appearing multiple times in a
2288 list as if they appeared only once.
2290 10.4.1.4. Capabilities
2292 In this document, we define EndpointCostCapabilities the same as
2293 FilteredCostMapCapabilities. See Section 10.2.2.4.
2295 10.4.1.5. Response
2297 The returned InfoResourceEntity object has "data" member equal to
2298 InfoResourceEndpointCostMap, where:
2300 object {
2301 CostType cost-type;
2302 EndpointCostMapData map;
2303 } InfoResourceEndpointCostMap;
2305 object-map {
2306 TypedEndpointAddr -> EndpointDstCosts;
2307 } EndpointCostMapData;
2309 object-map {
2310 TypedEndpointAddr -> JSONValue;
2311 } EndpointDstCosts;
2313 InfoResourceEndpointCostMap has members:
2315 cost-type The Cost Type used in the returned Cost Map.
2317 map The Endpoint Cost Map data itself.
2319 EndpointCostMapData is a dictionary map object with each key
2320 representing a TypedEndpointAddr string identifying the Source
2321 Endpoint specified in the input parameters; the name for a member is.
2322 For each Source Endpoint, a EndpointDstCosts dictionary map object
2323 denotes the associated cost to each Destination Endpoint specified in
2324 input parameters. An implementation of the protocol in this document
2325 SHOULD assume that the cost value is a JSONNumber and fail to parse
2326 if it is not, unless the implementation is using an extension to this
2327 document that indicates when and how costs of other data types are
2328 signaled. If the ALTO Server does not define a cost value from a
2329 Source Endpoint to a particular Destination Endpoint, it MAY be
2330 omitted from the response.
2332 10.4.1.6. Example
2334 POST /endpointcost/lookup HTTP/1.1
2335 Host: alto.example.com
2336 Content-Length: 195
2337 Content-Type: application/alto-endpointcostparams+json
2338 Accept: application/alto-endpointcost+json,application/alto-error+json
2340 {
2341 "cost-type": {"cost-mode" : "ordinal",
2342 "cost-metric" : "routingcost"},
2343 "endpoints" : {
2344 "srcs": [ "ipv4:192.0.2.2" ],
2345 "dsts": [
2346 "ipv4:192.0.2.89",
2347 "ipv4:198.51.100.34",
2348 "ipv4:203.0.113.45"
2349 ]
2350 }
2351 }
2353 HTTP/1.1 200 OK
2354 Content-Length: 231
2355 Content-Type: application/alto-endpointcost+json
2357 {
2358 "meta" : {},
2359 "data" : {
2360 "cost-type": {"cost-mode" : "ordinal",
2361 "cost-metric" : "routingcost"},
2362 "map" : {
2363 "ipv4:192.0.2.2": {
2364 "ipv4:192.0.2.89" : 1,
2365 "ipv4:198.51.100.34" : 2,
2366 "ipv4:203.0.113.45" : 3
2367 }
2368 }
2369 }
2370 }
2372 11. Use Cases
2374 The sections below depict typical use cases. While these use cases
2375 focus on peer-to-peer applications, ALTO can be applied to other
2376 environments such as CDNs [I-D.jenkins-alto-cdn-use-cases].
2378 11.1. ALTO Client Embedded in P2P Tracker
2380 Many currently-deployed P2P systems use a Tracker to manage swarms
2381 and perform peer selection. Such a P2P Tracker can already use a
2382 variety of information to perform peer selection to meet application-
2383 specific goals. By acting as an ALTO Client, the P2P Tracker can use
2384 ALTO information as an additional information source to enable more
2385 network-efficient traffic patterns and improve application
2386 performance.
2388 A particular requirement of many P2P trackers is that they must
2389 handle a large number of P2P clients. A P2P tracker can obtain and
2390 locally store ALTO information (the Network Map and Cost Map) from
2391 the ISPs containing the P2P clients, and benefit from the same
2392 aggregation of network locations done by ALTO Servers.
2394 .---------. (1) Get Network Map .---------------.
2395 | | <----------------------> | |
2396 | ALTO | | P2P Tracker |
2397 | Server | (2) Get Cost Map | (ALTO Client) |
2398 | | <----------------------> | |
2399 `---------' `---------------'
2400 ^ |
2401 (3) Get Peers | | (4) Selected Peer
2402 | v List
2403 .---------. .-----------.
2404 | Peer 1 | <-------------- | P2P |
2405 `---------' | Client |
2406 . (5) Connect to `-----------'
2407 . Selected Peers /
2408 .---------. /
2409 | Peer 50 | <------------------
2410 `---------'
2412 Figure 4: ALTO Client Embedded in P2P Tracker
2414 Figure 4 shows an example use case where a P2P tracker is an ALTO
2415 Client and applies ALTO information when selecting peers for its P2P
2416 clients. The example proceeds as follows:
2418 1. The P2P Tracker requests from the ALTO Server using the Network
2419 Map query the Network Map covering all PIDs. The Network Map
2420 includes the IP prefixes contained in each PID, allowing the P2P
2421 tracker to locally map P2P clients into PIDs.
2423 2. The P2P Tracker requests from the ALTO Server the Cost Map
2424 amongst all PIDs identified in the preceding step.
2426 3. A P2P Client joins the swarm, and requests a peer list from the
2427 P2P Tracker.
2429 4. The P2P Tracker returns a peer list to the P2P client. The
2430 returned peer list is computed based on the Network Map and Cost
2431 Map returned by the ALTO Server, and possibly other information
2432 sources. Note that it is possible that a tracker may use only
2433 the Network Map to implement hierarchical peer selection by
2434 preferring peers within the same PID and ISP.
2436 5. The P2P Client connects to the selected peers.
2438 Note that the P2P tracker may provide peer lists to P2P clients
2439 distributed across multiple ISPs. In such a case, the P2P tracker
2440 may communicate with multiple ALTO Servers.
2442 11.2. ALTO Client Embedded in P2P Client: Numerical Costs
2444 P2P clients may also utilize ALTO information themselves when
2445 selecting from available peers. It is important to note that not all
2446 P2P systems use a P2P tracker for peer discovery and selection.
2447 Furthermore, even when a P2P tracker is used, the P2P clients may
2448 rely on other sources, such as peer exchange and DHTs, to discover
2449 peers.
2451 When an P2P Client uses ALTO information, it typically queries only
2452 the ALTO Server servicing its own ISP. The my-Internet view provided
2453 by its ISP's ALTO Server can include preferences to all potential
2454 peers.
2456 .---------. (1) Get Network Map .---------------.
2457 | | <----------------------> | |
2458 | ALTO | | P2P Client |
2459 | Server | (2) Get Cost Map | (ALTO Client) |
2460 | | <----------------------> | | .---------.
2461 `---------' `---------------' <- | P2P |
2462 .---------. / | ^ ^ | Tracker |
2463 | Peer 1 | <-------------- | | \ `---------'
2464 `---------' | (3) Gather Peers
2465 . (4) Select Peers | | \
2466 . and Connect / .--------. .--------.
2467 .---------. / | P2P | | DHT |
2468 | Peer 50 | <---------------- | Client | `--------'
2469 `---------' | (PEX) |
2470 `--------'
2472 Figure 5: ALTO Client Embedded in P2P Client
2474 Figure 5 shows an example use case where a P2P Client locally applies
2475 ALTO information to select peers. The use case proceeds as follows:
2477 1. The P2P Client requests the Network Map covering all PIDs from
2478 the ALTO Server servicing its own ISP.
2480 2. The P2P Client requests the Cost Map amongst all PIDs from the
2481 ALTO Server. The Cost Map by default specifies numerical costs.
2483 3. The P2P Client discovers peers from sources such as Peer Exchange
2484 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and
2485 P2P Trackers.
2487 4. The P2P Client uses ALTO information as part of the algorithm for
2488 selecting new peers, and connects to the selected peers.
2490 11.3. ALTO Client Embedded in P2P Client: Ranking
2492 It is also possible for a P2P Client to offload the selection and
2493 ranking process to an ALTO Server. In this use case, the ALTO Client
2494 gathers a list of known peers in the swarm, and asks the ALTO Server
2495 to rank them.
2497 As in the use case using numerical costs, the P2P Client typically
2498 only queries the ALTO Server servicing its own ISP.
2500 .---------. .---------------.
2501 | | | |
2502 | ALTO | (2) Get Endpoint Ranking | P2P Client |
2503 | Server | <----------------------> | (ALTO Client) |
2504 | | | | .---------.
2505 `---------' `---------------' <- | P2P |
2506 .---------. / | ^ ^ | Tracker |
2507 | Peer 1 | <-------------- | | \ `---------'
2508 `---------' | (1) Gather Peers
2509 . (3) Connect to | | \
2510 . Selected Peers / .--------. .--------.
2511 .---------. / | P2P | | DHT |
2512 | Peer 50 | <---------------- | Client | `--------'
2513 `---------' | (PEX) |
2514 `--------'
2516 Figure 6: ALTO Client Embedded in P2P Client: Ranking
2518 Figure 6 shows an example of this scenario. The use case proceeds as
2519 follows:
2521 1. The P2P Client discovers peers from sources such as Peer Exchange
2522 (PEX) from other P2P Clients, Distributed Hash Tables (DHT), and
2523 P2P Trackers.
2525 2. The P2P Client queries the ALTO Server's Ranking Service,
2526 including discovered peers as the set of Destination Endpoints,
2527 and indicates the 'ordinal' Cost Mode. The response indicates
2528 the ranking of the candidate peers.
2530 3. The P2P Client connects to the peers in the order specified in
2531 the ranking.
2533 12. Discussions
2535 12.1. Discovery
2537 The discovery mechanism by which an ALTO Client locates an
2538 appropriate ALTO Server is out of scope for this document. This
2539 document assumes that an ALTO Client can discover an appropriate ALTO
2540 Server. Once it has done so, the ALTO Client may use the Information
2541 Resource Directory (see Section 8.5) to locate an Information
2542 Resource with the desired ALTO Information.
2544 12.2. Hosts with Multiple Endpoint Addresses
2546 In practical deployments, a particular host can be reachable using
2547 multiple addresses (e.g., a wireless IPv4 connection, a wireline IPv4
2548 connection, and a wireline IPv6 connection). In general, the
2549 particular network path followed when sending packets to the host
2550 will depend on the address that is used. Network providers may
2551 prefer one path over another. An additional consideration may be how
2552 to handle private address spaces (e.g., behind carrier-grade NATs).
2554 To support such behavior, this document allows multiple endpoint
2555 addresses and address types. With this support, the ALTO Protocol
2556 allows an ALTO Service Provider the flexibility to indicate
2557 preferences for paths from an endpoint address of one type to an
2558 endpoint address of a different type.
2560 12.3. Network Address Translation Considerations
2562 At this day and age of NAT v4<->v4, v4<->v6 [RFC6144], and possibly
2563 v6<->v6[I-D.mrw-nat66], a protocol should strive to be NAT friendly
2564 and minimize carrying IP addresses in the payload, or provide a mode
2565 of operation where the source IP address provide the information
2566 necessary to the server.
2568 The protocol specified in this document provides a mode of operation
2569 where the source network location is computed by the ALTO Server
2570 (i.e., the the Endpoint Cost Service) from the source IP address
2571 found in the ALTO Client query packets. This is similar to how some
2572 P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS
2573 Protocol" in [BitTorrent]) operate.
2575 There may be cases where an ALTO Client needs to determine its own IP
2576 address, such as when specifying a source Endpoint Address in the
2577 Endpoint Cost Service. It is possible that an ALTO Client has
2578 multiple network interface addresses, and that some or all of them
2579 may require NAT for connectivity to the public Internet.
2581 If a public IP address is required for a network interface, the ALTO
2582 client SHOULD use the Session Traversal Utilities for NAT (STUN)
2583 [RFC5389]. If using this method, the host MUST use the "Binding
2584 Request" message and the resulting "XOR-MAPPED-ADDRESS" parameter
2585 that is returned in the response. Using STUN requires cooperation
2586 from a publicly accessible STUN server. Thus, the ALTO client also
2587 requires configuration information that identifies the STUN server,
2588 or a domain name that can be used for STUN server discovery. To be
2589 selected for this purpose, the STUN server needs to provide the
2590 public reflexive transport address of the host.
2592 ALTO Clients should be cognizant that the network path between
2593 Endpoints can depend on multiple factors, e.g., source address, and
2594 destination address used for communication. An ALTO Server provides
2595 information based on Endpoint Addresses (more generally, Network
2596 Locations), but the mechanisms used for determining existence of
2597 connectivity or usage of NAT between Endpoints are out of scope of
2598 this document.
2600 12.4. Endpoint and Path Properties
2602 An ALTO Server could make available many properties about Endpoints
2603 beyond their network location or grouping. For example, connection
2604 type, geographical location, and others may be useful to
2605 applications. This specification focuses on network location and
2606 grouping, but the protocol may be extended to handle other Endpoint
2607 properties.
2609 13. IANA Considerations
2611 13.1. application/alto-* Media Types
2613 This document requests the registration of multiple media types,
2614 listed in Table 2.
2616 +-------------+------------------------------+----------------+
2617 | Type | Subtype | Specification |
2618 +-------------+------------------------------+----------------+
2619 | application | alto-directory+json | Section 8.5 |
2620 | application | alto-networkmap+json | Section 10.1.1 |
2621 | application | alto-networkmapfilter+json | Section 10.2.1 |
2622 | application | alto-costmap+json | Section 10.1.2 |
2623 | application | alto-costmapfilter+json | Section 10.2.2 |
2624 | application | alto-endpointprop+json | Section 10.3.1 |
2625 | application | alto-endpointpropparams+json | Section 10.3.1 |
2626 | application | alto-endpointcost+json | Section 10.4.1 |
2627 | application | alto-endpointcostparams+json | Section 10.4.1 |
2628 | application | alto-error+json | Section 8.7 |
2629 +-------------+------------------------------+----------------+
2631 Table 2: ALTO Protocol Media Types.
2633 Type name: application
2635 Subtype name: This documents requests the registration of multiple
2636 subtypes, as listed in Table 2.
2638 Required parameters: n/a
2640 Optional parameters: n/a
2642 Encoding considerations: Encoding considerations are identical to
2643 those specified for the 'application/json' media type. See
2644 [RFC4627].
2646 Security considerations: Security considerations relating to the
2647 generation and consumption of ALTO protocol messages are discussed
2648 in Section 14.
2650 Interoperability considerations: This document specifies format of
2651 conforming messages and the interpretation thereof.
2653 Published specification: This document is the specification for
2654 these media types; see Table 2 for the section documenting each
2655 media type.
2657 Applications that use this media type: ALTO Servers and ALTO Clients
2658 either standalone or embedded within other applications.
2660 Additional information:
2662 Magic number(s): n/a
2664 File extension(s): This document uses the mime type to refer to
2665 protocol messages and thus does not require a file extension.
2667 Macintosh file type code(s): n/a
2669 Person & email address to contact for further information: See
2670 "Authors' Addresses" section.
2672 Intended usage: COMMON
2674 Restrictions on usage: n/a
2676 Author: See "Authors' Addresses" section.
2678 Change controller: Internet Engineering Task Force
2679 (mailto:iesg@ietf.org).
2681 13.2. ALTO Cost Metric Registry
2683 This document requests the creation of an ALTO Cost Metric registry,
2684 listed in Table 3, to be maintained by IANA.
2686 +-------------+---------------------+
2687 | Identifier | Intended Semantics |
2688 +-------------+---------------------+
2689 | routingcost | See Section 6.1.1.1 |
2690 | priv: | Private use |
2691 | exp: | Experimental use |
2692 +-------------+---------------------+
2694 Table 3: ALTO Cost Metrics.
2696 This registry serves two purposes. First, it ensures uniqueness of
2697 identifiers referring to ALTO Cost Metrics. Second, it provides
2698 references to particular semantics of allocated Cost Metrics to be
2699 applied by both ALTO Servers and applications utilizing ALTO Clients.
2701 New ALTO Cost Metrics are assigned after Expert Review [RFC5226].
2702 The Expert Reviewer will generally consult the ALTO Working Group or
2703 its successor. Expert Review is used to ensure that proper
2704 documentation regarding ALTO Cost Metric semantics and security
2705 considerations has been provided. The provided documentation should
2706 be detailed enough to provide guidance to both ALTO Service Providers
2707 and applications utilizing ALTO Clients as to how values of the
2708 registered ALTO Cost Metric should be interpreted. Updates and
2709 deletions of ALTO Cost Metrics follow the same procedure.
2711 Registered ALTO Cost Metric identifiers MUST conform to the
2712 syntactical requirements specified in Section 9.5. Identifiers are
2713 to be recorded and displayed as ASCII strings.
2715 Identifiers prefixed with 'priv:' are reserved for Private Use.
2716 Identifiers prefixed with 'exp:' are reserved for Experimental use.
2718 Requests to add a new value to the registry MUST include the
2719 following information:
2721 o Identifier: The name of the desired ALTO Cost Metric.
2723 o Intended Semantics: ALTO Costs carry with them semantics to guide
2724 their usage by ALTO Clients. For example, if a value refers to a
2725 measurement, the measurement units must be documented. For proper
2726 implementation of the ordinal Cost Mode (e.g., by a third-party
2727 service), it should be documented whether higher or lower values
2728 of the cost are more preferred.
2730 o Security Considerations: ALTO Costs expose information to ALTO
2731 Clients. As such, proper usage of a particular Cost Metric may
2732 require certain information to be exposed by an ALTO Service
2733 Provider. Since network information is frequently regarded as
2734 proprietary or confidential, ALTO Service Providers should be made
2735 aware of the security ramifications related to usage of a Cost
2736 Metric.
2738 This specification requests registration of the identifier
2739 'routingcost'. Semantics for the this Cost Metric are documented in
2740 Section 6.1.1.1, and security considerations are documented in
2741 Section 14.3.
2743 13.3. ALTO Endpoint Property Type Registry
2745 This document requests the creation of an ALTO Endpoint Property
2746 Types registry, listed in Table 4, to be maintained by IANA.
2748 +------------+--------------------+
2749 | Identifier | Intended Semantics |
2750 +------------+--------------------+
2751 | pid | See Section 7.1.1 |
2752 | priv: | Private use |
2753 | exp: | Experimental use |
2754 +------------+--------------------+
2756 Table 4: ALTO Endpoint Property Types.
2758 The maintenance of this registry is similar to that of the preceding
2759 ALTO Cost Metrics.
2761 13.4. ALTO Address Type Registry
2763 This document requests the creation of an ALTO Address Type registry,
2764 listed in Table 5, to be maintained by IANA.
2766 +------------+----------------+----------------+--------------------+
2767 | Identifier | Address | Prefix | Mapping to/from |
2768 | | Encoding | Encoding | IPv4/v6 |
2769 +------------+----------------+----------------+--------------------+
2770 | ipv4 | See | See | Direct mapping to |
2771 | | Section 9.3.2 | Section 9.3.3 | IPv4 |
2772 | ipv6 | See | See | Direct mapping to |
2773 | | Section 9.3.2 | Section 9.3.3 | IPv6 |
2774 +------------+----------------+----------------+--------------------+
2776 Table 5: ALTO Address Types.
2778 This registry serves two purposes. First, it ensures uniqueness of
2779 identifiers referring to ALTO Address Types. Second, it states the
2780 requirements for allocated Address Type identifiers.
2782 New ALTO Address Types are assigned after Expert Review [RFC5226].
2783 The Expert Reviewer will generally consult the ALTO Working Group or
2784 its successor. Expert Review is used to ensure that proper
2785 documentation regarding the new ALTO Address Types and their security
2786 considerations has been provided. The provided documentation should
2787 indicate how an address of a registered type is encoded as an
2788 EndpointAddr and, if possible, a compact method (e.g., IPv4 and IPv6
2789 prefixes) for encoding a set of addresses as an EndpointPrefix.
2790 Updates and deletions of ALTO Address Types follow the same
2791 procedure.
2793 Registered ALTO Address Type identifiers MUST conform to the
2794 syntactical requirements specified in Section 9.3.1. Identifiers are
2795 to be recorded and displayed as ASCII strings.
2797 Requests to add a new value to the registry MUST include the
2798 following information:
2800 o Identifier: The name of the desired ALTO Address Type.
2802 o Endpoint Address Encoding: The procedure for encoding an address
2803 of the registered type as an EndpointAddr (see Section 9.3.2).
2805 o Endpoint Prefix Encoding: The procedure for encoding a set of
2806 addresses of the registered type as an EndpointPrefix (see
2807 Section 9.3.3). If no such compact encoding is available, the
2808 same encoding used for a singular address may be used. In such a
2809 case, it must be documented that sets of addresses of this type
2810 always have exactly one element.
2812 o Mapping to/from IPv4/IPv6 Addresses: If possible, a mechanism to
2813 map addresses of the registered type to and from IPv4 or IPv6
2814 addresses should be specified.
2816 o Security Considerations: In some usage scenarios, Endpoint
2817 Addresses carried in ALTO Protocol messages may reveal information
2818 about an ALTO Client or an ALTO Service Provider. Applications
2819 and ALTO Service Providers using addresses of the registered type
2820 should be made aware of how (or if) the addressing scheme relates
2821 to private information and network proximity.
2823 This specification requests registration of the identifiers 'ipv4'
2824 and 'ipv6', as shown in Table 5.
2826 13.5. ALTO Error Code Registry
2828 This document requests the creation of an ALTO Error Code registry,
2829 listed in Table 1, to be maintained by IANA.
2831 14. Security Considerations
2833 Some environments and use cases of ALTO require consideration of
2834 security attacks on ALTO Servers and Clients. In order to support
2835 those environments interoperably, the ALTO requirements document
2836 outlines minimum-to-implement authentication
2837 and other security requirements. Below we consider the threats and
2838 protection strategies.
2840 14.1. Authenticity and Integrity of ALTO Information
2842 14.1.1. Risk Scenarios
2844 An attacker may want to provide false or modified ALTO Information
2845 Resources or Information Resource Directory to ALTO Clients to
2846 achieve certain malicious goals. As an example, an attacker may
2847 provide false endpoint properties. For example, suppose that a
2848 network supports an endpoint property named hasQuota which reports if
2849 the endpoint has usage quota. An attacker may want to generate a
2850 false reply to lead to unexpected charges to the endpoint. An attack
2851 may also want to provide false Cost Map. For example, by faking a
2852 Cost Map that highly prefers a small address range or a single
2853 address, the attacker may be able to turn a distributed application
2854 into a Distributed Denial of Service (DDoS) tool.
2856 Depending on the network scenario, an attacker can attack
2857 authenticity and integrity of ALTO Information Resources using
2858 various techniques, including, but not limited to, sending forged
2859 DHCP replies in an Ethernet, DNS poisoning, and installing a
2860 transparent HTTP proxy that does some modifications.
2862 14.1.2. Protection Strategies
2864 ALTO protects the authenticity and integrity of ALTO Information
2865 (both Information Directory and individual Information Resources) by
2866 leveraging the authenticity and integrity mechanisms in TLS. In
2867 particular, the ALTO Protocol requires that HTTP over TLS MUST be supported, when protecting the
2869 authenticity and integrity of ALTO Information is required. The
2870 rules in for a client to verify server
2871 identity using server certificates MUST be supported. ALTO Providers
2872 who request server certificates and certification authorities who
2873 issue ALTO-specific certificates SHOULD consider the recommendations
2874 and guidelines defined in .
2876 Software engineers developing and service providers deploying ALTO
2877 with should make themselves familar with up-to-date Best Current
2878 Practices on configuring HTTP over TLS.
2880 14.1.3. Limitations
2882 The protection of HTTP over TLS for ALTO depends on that the domain
2883 name in the URI for the Information Resources is not comprised. This
2884 will depend on the protection implemented by service discovery.
2886 A deployment scenario may require redistribution of ALTO information
2887 to improve scalability. When authenticity and integrity of ALTO
2888 information are still required, then ALTO Clients obtaining ALTO
2889 information through redistribution must be able to validate the
2890 received ALTO information. Support for this validation is not
2891 provided in this document, but may be provided by extension
2892 documents.
2894 14.2. Potential Undesirable Guidance from Authenticated ALTO
2895 Information
2897 14.2.1. Risk Scenarios
2899 The ALTO Service makes it possible for an ALTO Provider to influence
2900 the behavior of network applications. An ALTO Provider may be
2901 hostile to some applications and hence try to use ALTO Information
2902 Resources to achieve certain goals :
2903 "redirecting applications to corrupted mediators providing malicious
2904 content, or applying policies in computing Cost Map based on criteria
2905 other than network efficiency." See for additional discussions on faked ALTO Guidance.
2908 A related scenario is that an ALTO Server could unintentionally give
2909 "bad" guidance. For example, if many ALTO Clients follow the Cost
2910 Map or Endpoint Cost guidance without doing additional sanity checks
2911 or adaptation, more preferable hosts and/or links could get
2912 overloaded while less preferable ones remain idle; see AR-14 of
2913 [RFC6708] for related application considerations.
2915 14.2.2. Protection Strategies
2917 To protect applications from undesirable ALTO Information Resources,
2918 it is important to note that there is no protocol mechanism to
2919 require conforming behaviors on how applications use ALTO Information
2920 Resources. An application using ALTO may consider including a
2921 mechanism to detect misleading or undesirable results from using ALTO
2922 Information Resources. For example, if throughput measurements do
2923 not show "better-than-random" results when using the Cost Map to
2924 select resource providers, the application may want to disable ALTO
2925 usage or switch to an external ALTO Server provided by an
2926 "independent organization" (see AR-20 and AR-21 in [RFC 6708]). If
2927 the first ALTO server is provided by the access network service
2928 provider and the access network service provider tries to redirect
2929 access to the external ALTO Server back to the provider's ALTO Server
2930 or try to tamper with the responses, the preceding authentication and
2931 integrity protection can detect such a behavior.
2933 14.3. Confidentiality of ALTO Information
2935 14.3.1. Risk Scenarios
2937 Although in many cases ALTO Information Resources may be regarded as
2938 non-confidential information, there are deployment cases where ALTO
2939 Information Resources can be sensitive information that can pose
2940 risks if exposed to unauthorized parties. We discuss the risks and
2941 protection strategies for such deployment scenarios.
2943 For example, an attacker may infer details regarding the topology,
2944 status, and operational policies of a network through the Network and
2945 Cost Maps. As a result, a sophisticated attacker may be able to
2946 infer more fine-graind topology information than an ISP hosting an
2947 ALTO server intends to disclose. The attacker can leverage the
2948 information to mount effective attacks such as focusing on high-cost
2949 links.
2951 Revealing some endpoint properties may also reveal additional
2952 information than the Provider intended. For example, when adding the
2953 line bitrate as one endpoint property, such information may be
2954 potentially linked to the income of the habitants at the network
2955 location of an endpoint.
2957 In Section 5.2.1, three types of risks
2958 associated with the confidentiality of ALTO Information Resources are
2959 identified: risk type (1) Excess disclosure of the ALTO service
2960 provider's data to an authorized ALTO client; risk type (2)
2961 Disclosure of the ALTO service provider's data (e.g., network
2962 topology information) to an unauthorized third party; and risk type
2963 (3) Excess retrieval of the ALTO service provider's data by
2964 collaborating ALTO clients. Section 10 of also discusses information leakage from ALTO.
2967 14.3.2. Protection Strategies
2969 To address risk type (1), the Provider of an ALTO Server must be
2970 cognizant that the network topology and provisioning information
2971 provided through ALTO may lead to attacks. ALTO does not require any
2972 particular level of details of information disclosure, and hence the
2973 Provider should evaluate how much information is revealed and the
2974 associated risks.
2976 To address risk type (2), the ALTO Protocol need confidentiality.
2977 Since ALTO requires that HTTP over TLS MUST be supported, the
2978 confidentiality mechanism is provided by HTTP over TLS.
2980 For deployment scenarios where client authentication is desired to
2981 address risk type (2), ALTO requires that HTTP Digestion
2982 Authentication MUST be supported to achieve ALTO Client
2983 Authentication to limit the parties with whom ALTO information is
2984 directly shared. Depending on the use-case and scenario, an ALTO
2985 server may apply other access control techniques to restrict access
2986 to its services. Access control can also help to prevent Denial-of-
2987 Service attacks by arbitrary hosts from the Internet. See for a more detailed discussion
2989 on this issue.
2991 14.3.3. Limitations
2993 ALTO Information Providers should be cognizant that encryption only
2994 protects ALTO information until it is decrypted by the intended ALTO
2995 Client. Digital Rights Management (DRM) techniques and legal
2996 agreements protecting ALTO information are outside of the scope of
2997 this document.
2999 14.4. Privacy for ALTO Users
3001 14.4.1. Risk Scenarios
3003 The ALTO Protocol provides mechanisms in which the ALTO Client
3004 serving a user can send messages containing Network Location
3005 Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server.
3006 This is particularly true for the Endpoint Property, Endpoint Cost,
3007 and fine-grained Filtered Map services. The ALTO Server or a third-
3008 party who is able to intercept such messages can store and process
3009 obtained information in order to analyze user behaviors and
3010 communication patterns. The analysis may correlate information
3011 collected from multiple clients to deduce additional application/
3012 content information. Such analysis can lead to privacy risks. For a
3013 more comprehensive classification of related risk scenarios, see
3014 cases 4, 5, and 6 in [RFC 6708], Section 5.2.
3016 14.4.2. Protection Strategies
3018 To protect user privacy, an ALTO Client should be cognizant about
3019 potential ALTO Server tracking through client queries. An ALTO
3020 Client may consider the possibility of relying only on Network Map
3021 for PIDs and Cost Map amongst PIDs to avoid passing IP addresses of
3022 other endpoints (e.g., peers) to the ALTO Server. When specific IP
3023 addresses are needed (e.g., when using the Endpoint Cost Service), an
3024 ALTO Client may consider obfuscation techniques such as specifying a
3025 broader address range (i.e., a shorter prefix length) or by zeroing
3026 out or randomizing the last few bits of IP addresses. Note that
3027 obfuscation may yield less accurate results.
3029 14.5. Availability of ALTO Service
3031 14.5.1. Risk Scenarios
3033 An attacker may want to disable ALTO Service as a way to disable
3034 network guidance to large scale applications.In particular, queries
3035 which can be generated with low effort but result in expensive
3036 workloads at the ALTO Server could be exploited for Denial-of-Service
3037 attacks. For instance, a simple ALTO query with n Source Network
3038 Locations and m Destination Network Locations can be generated fairly
3039 easily but results in the computation of n*m Path Costs between pairs
3040 by the ALTO Server (see Section 5.2).
3042 14.5.2. Protection Strategies
3044 ALTO Provider should be cognizant of the workload at the ALTO Server
3045 generated by certain ALTO Queries, such as certain queries to the Map
3046 Service, the Map Filtering Service and the Endpoint Cost (Ranking)
3047 Service. One way to limit Denial-of-Service attacks is to employ
3048 access control to the ALTO Server. The ALTO Server can also indicate
3049 overload and reject repeated requests that can cause availability
3050 problems. More advanced protection schemes such as computational
3051 puzzles [I-D.jennings-sip-hashcash] may be considered in an extension
3052 document.
3054 An ALTO Provider should also leverage the fact that the Map Service
3055 allows ALTO Servers to pre-generate maps that can be distributed to
3056 many ALTO Clients.
3058 15. Manageability Considerations
3060 This section details operations and management considerations based
3061 on existing deployments and discussions during protocol development.
3062 It also indicates where extension documents are expected to provide
3063 appropriate functionality discussed in [RFC5706] as additional
3064 deployment experience becomes available.
3066 15.1. Operations
3067 15.1.1. Installation and Initial Setup
3069 The ALTO Protocol is based on HTTP. Thus, configuring an ALTO Server
3070 may require configuring the underlying HTTP server implementation to
3071 define appropriate security policies, caching policies, performance
3072 settings, etc.
3074 Additionally, an ALTO Service Provider will need to configure the
3075 ALTO information to be provided by the ALTO Server. The granularity
3076 of the topological map and the cost map is left to the specific
3077 policies of the ALTO Service Provider. However, a reasonable default
3078 may include two PIDs, one to hold the endpoints in the provider's
3079 network and the second PID to represent full IPv4 and IPv6
3080 reachability (see Section 5.2.1), with the cost between each source/
3081 destination PID set to 1. Another operational issue that the ALTO
3082 Service Provider needs to consider is that the filtering service can
3083 degenerate into a full map service when the filtering input is empty.
3084 Although this choice as the degeneration behavior provides
3085 continuity, the operational impact should be considered.
3087 Implementers employing an ALTO Client should attempt to automatically
3088 discover an appropriate ALTO Server. Manual configuration of the
3089 ALTO Server location may be used where automatic discovery is not
3090 appropriate. Methods for automatic discovery and manual
3091 configuration are discussed in [I-D.ietf-alto-server-discovery].
3093 Specifications for underlying protocols (e.g., TCP, HTTP, SSL/TLS)
3094 should be consulted for their available settings and proposed default
3095 configurations.
3097 15.1.2. Migration Path
3099 This document does not detail a migration path for ALTO Servers since
3100 there is no previous standard protocol providing the similar
3101 functionality.
3103 There are existing applications making use of network information
3104 discovered from other entities such as whois, geo-location databases,
3105 or round-trip time measurements, etc. Such applications should
3106 consider using ALTO as an additional source of information; ALTO need
3107 not be the sole source of network information.
3109 15.1.3. Requirements on Other Protocols and Functional Components
3111 The ALTO Protocol assumes that HTTP client and server implementations
3112 exist. It also assumes that JSON encoder and decoder implementations
3113 exist.
3115 An ALTO Server assumes that it can gather sufficient information to
3116 populate Network and Cost maps. "Sufficient information" is
3117 dependent on the information being exposed, but likely includes
3118 information gathered from protocols such as IGP and EGP Routing
3119 Information Bases (see Figure 1). Specific mechanisms have been
3120 proposed (e.g., [I-D.medved-alto-svr-apis]) and are expected to be
3121 provided in extension documents.
3123 15.1.4. Impact and Observation on Network Operation
3125 ALTO presents a new opportunity for managing network traffic by
3126 providing additional information to clients. The potential impact to
3127 network operation is large.
3129 Deployment of an ALTO Server may shift network traffic patterns.
3130 Thus, an ALTO Service Provider should consider impacts on (or
3131 integration with) traffic engineering and the deployment of a
3132 monitoring service to observe the effects of ALTO operations. Note
3133 that ALTO-specific monitoring and metrics are discussed in 6.3 of
3134 [I-D.ietf-alto-deployments] and future versions of that document. In
3135 particular, an ALTO Service Provider may observe that ALTO Clients
3136 are not bound to ALTO Server guidance as ALTO is only one source of
3137 information.
3139 An ALTO Service Provider should ensure that appropriate information
3140 is being exposed. Privacy implications for ISPs are discussed in
3141 Section 14.3. Both ALTO Service Providers and those using ALTO
3142 Clients should be aware of the impact of incorrect or faked guidance
3143 (see Section 10.3 of [I-D.ietf-alto-deployments] and future versions
3144 of that document).
3146 15.2. Management
3148 15.2.1. Management Interoperability
3150 A common management API would be desirable given that ALTO Servers
3151 may typically be configured with dynamic data from various sources,
3152 and ALTO Servers are intended to scale horizontally for fault-
3153 tolerance and reliability. A specific API or protocol is outside the
3154 scope of this document, but may be provided by an extension document.
3156 Logging is an important functionality for ALTO Servers and, depending
3157 on the deployment, ALTO Clients. Logging should be done via syslog
3158 [RFC5424].
3160 15.2.2. Management Information
3162 A Management Information Model (see Section 3.2 of [RFC5706] is not
3163 provided by this document, but should be included or referenced by
3164 any extension documenting an ALTO-related management API or protocol.
3166 15.2.3. Fault Management
3168 Monitoring ALTO Servers and Clients is described in Section 6.3 of
3169 [I-D.ietf-alto-deployments] and future versions of that document.
3171 15.2.4. Configuration Management
3173 Standardized approaches and protocols to configuration management for
3174 ALTO are outside the scope of this document, but this document does
3175 outline high-level principles suggested for future standardization
3176 efforts.
3178 An ALTO Server requires at least the following logical inputs:
3180 o Data sources from which ALTO Information is derived. This can
3181 either be raw network information (e.g., from routing elements) or
3182 pre-processed ALTO-level information in the form of a Network Map,
3183 Cost Map, etc.
3185 o Algorithms for computing the ALTO information returned to clients.
3186 These could either return information from a database, or
3187 information customized for each client.
3189 o Security policies mapping potential clients to the information
3190 that they have privilege to access.
3192 Multiple ALTO Servers can be deployed for scalability. A centralized
3193 configuration database may be used to ensure they are providing the
3194 desired ALTO information with appropriate security controls. The
3195 ALTO information (e.g., Network Maps and Cost Maps) being served by
3196 each ALTO Server, as well as security policies (HTTP authentication,
3197 SSL/TLS client and server authentication, SSL/TLS encryption
3198 parameters) intended to serve the same information should be
3199 monitored for consistency.
3201 15.2.5. Performance Management
3203 An exhaustive list of desirable performance information from a ALTO
3204 Servers and ALTO Clients are outside of the scope of this document.
3205 The following is a list of suggested ALTO-specific to be monitored
3206 based on the existing deployment and protocol development experience:
3208 o Requests and responses for each service listed in a Information
3209 Directory (total counts and size in bytes).
3211 o CPU and memory utilization
3213 o ALTO map updates
3215 o Number of PIDs
3217 o ALTO map sizes (in-memory size, encoded size, number of entries)
3219 15.2.6. Security Management
3221 Section 14 documents ALTO-specific security considerations.
3222 Operators should configure security policies with those in mind.
3223 Readers should refer to HTTP [RFC2616] and SSL/TLS [RFC5246] and
3224 related documents for mechanisms available for configuring security
3225 policies. Other appropriate security mechanisms (e.g., physical
3226 security, firewalls, etc) should also be considered.
3228 16. References
3230 16.1. Normative References
3232 [IEEE.754.2008]
3233 Institute of Electrical and Electronics Engineers,
3234 "Standard for Binary Floating-Point Arithmetic", IEEE
3235 Standard 754, August 2008.
3237 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
3238 Extensions (MIME) Part Two: Media Types", RFC 2046,
3239 November 1996.
3241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3242 Requirement Levels", BCP 14, RFC 2119, March 1997.
3244 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
3245 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
3246 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
3248 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
3249 Resource Identifier (URI): Generic Syntax", STD 66,
3250 RFC 3986, January 2005.
3252 [RFC4627] Crockford, D., "The application/json Media Type for
3253 JavaScript Object Notation (JSON)", RFC 4627, July 2006.
3255 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
3256 (CIDR): The Internet Address Assignment and Aggregation
3257 Plan", BCP 122, RFC 4632, August 2006.
3259 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
3260 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
3261 May 2008.
3263 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
3264 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
3266 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
3267 "Session Traversal Utilities for NAT (STUN)", RFC 5389,
3268 October 2008.
3270 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
3272 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
3273 Optimization (ALTO) Problem Statement", RFC 5693,
3274 October 2009.
3276 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
3277 Address Text Representation", RFC 5952, August 2010.
3279 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
3280 Verification of Domain-Based Application Service Identity
3281 within Internet Public Key Infrastructure Using X.509
3282 (PKIX) Certificates in the Context of Transport Layer
3283 Security (TLS)", RFC 6125, March 2011.
3285 [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
3286 Y. Yang, "Application-Layer Traffic Optimization (ALTO)
3287 Requirements", RFC 6708, September 2012.
3289 16.2. Informative References
3291 [BitTorrent]
3292 "Bittorrent Protocol Specification v1.0",
3293 .
3295 [Fielding-Thesis]
3296 Fielding, R., "Architectural Styles and the Design of
3297 Network-based Software Architectures", University of
3298 California, Irvine, Dissertation 2000, 2000.
3300 [I-D.akonjang-alto-proxidor]
3301 Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D.
3302 Saucez, "The PROXIDOR Service",
3303 draft-akonjang-alto-proxidor-00 (work in progress),
3304 March 2009.
3306 [I-D.ietf-alto-deployments]
3307 Stiemerling, M., Kiesel, S., and S. Previdi, "ALTO
3308 Deployment Considerations", draft-ietf-alto-deployments-06
3309 (work in progress), February 2013.
3311 [I-D.ietf-alto-reqs]
3312 Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang,
3313 "Application-Layer Traffic Optimization (ALTO)
3314 Requirements", draft-ietf-alto-reqs-08 (work in progress),
3315 March 2011.
3317 [I-D.ietf-alto-server-discovery]
3318 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
3319 S. Yongchao, "ALTO Server Discovery",
3320 draft-ietf-alto-server-discovery-08 (work in progress),
3321 March 2013.
3323 [I-D.ietf-httpbis-p2-semantics]
3324 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
3325 (HTTP/1.1): Semantics and Content",
3326 draft-ietf-httpbis-p2-semantics-22 (work in progress),
3327 February 2013.
3329 [I-D.jenkins-alto-cdn-use-cases]
3330 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and
3331 S. Previdi, "Use Cases for ALTO within CDNs",
3332 draft-jenkins-alto-cdn-use-cases-03 (work in progress),
3333 June 2012.
3335 [I-D.medved-alto-svr-apis]
3336 Medved, J., Ward, D., Peterson, J., Woundy, R., and D.
3337 McDysan, "ALTO Network-Server and Server-Server APIs",
3338 draft-medved-alto-svr-apis-00 (work in progress),
3339 March 2011.
3341 [I-D.mrw-nat66]
3342 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
3343 Translation", draft-mrw-nat66-16 (work in progress),
3344 April 2011.
3346 [I-D.p4p-framework]
3347 Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang,
3348 "P4P: Provider Portal for P2P Applications",
3349 draft-p4p-framework-00 (work in progress), November 2008.
3351 [I-D.saumitra-alto-multi-ps]
3352 Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi
3353 Dimensional Peer Selection Problem",
3354 draft-saumitra-alto-multi-ps-00 (work in progress),
3355 October 2008.
3357 [I-D.saumitra-alto-queryresponse]
3358 Das, S. and V. Narayanan, "A Client to Service Query
3359 Response Protocol for ALTO",
3360 draft-saumitra-alto-queryresponse-00 (work in progress),
3361 March 2009.
3363 [I-D.shalunov-alto-infoexport]
3364 Shalunov, S., Penno, R., and R. Woundy, "ALTO Information
3365 Export Service", draft-shalunov-alto-infoexport-00 (work
3366 in progress), October 2008.
3368 [I-D.wang-alto-p4p-specification]
3369 Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang,
3370 "P4P Protocol Specification",
3371 draft-wang-alto-p4p-specification-00 (work in progress),
3372 March 2009.
3374 [P4P-SIGCOMM08]
3375 Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A.
3376 Silberschatz, "P4P: Provider Portal for (P2P)
3377 Applications", SIGCOMM 2008, August 2008.
3379 [RFC5706] Harrington, D., "Guidelines for Considering Operations and
3380 Management of New Protocols and Protocol Extensions",
3381 RFC 5706, November 2009.
3383 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
3384 IPv4/IPv6 Translation", RFC 6144, April 2011.
3386 Appendix A. Acknowledgments
3388 Thank you to Jan Seedorf and Sebastian Kiesel for contributions to
3389 the Security Considerations section. Ben Niven-Jenkins, Wendy Roome
3390 and Michael Scharf gave substantial feedback and suggestions on the
3391 protocol design.
3393 We would like to thank the following people whose input and
3394 involvement was indispensable in achieving this merged proposal:
3396 Obi Akonjang (DT Labs/TU Berlin),
3397 Saumitra M. Das (Qualcomm Inc.),
3399 Syon Ding (China Telecom),
3401 Doug Pasko (Verizon),
3403 Laird Popkin (Pando Networks),
3405 Satish Raghunath (Juniper Networks),
3407 Albert Tian (Ericsson/Redback),
3409 Yu-Shun Wang (Microsoft),
3411 David Zhang (PPLive),
3413 Yunfei Zhang (China Mobile).
3415 We would also like to thank the following additional people who were
3416 involved in the projects that contributed to this merged document:
3417 Alex Gerber (ATT), Chris Griffiths (Comcast), Ramit Hora (Pando
3418 Networks), Arvind Krishnamurthy (University of Washington), Marty
3419 Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace
3420 Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (ATT),
3421 Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks),
3422 Damien Saucez (UCL) Thomas Scholl (ATT), Emilio Sepulveda
3423 (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell
3424 Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song
3425 (Huawei), Oliver Spatscheck (ATT), See-Mong Tang (Microsoft), Jia
3426 Wang (ATT), Hao Wang (Yale University), Ye Wang (Yale University),
3427 Haiyong Xie (Yale University).
3429 Appendix B. Design History and Merged Proposals
3431 The ALTO Protocol specified in this document consists of
3432 contributions from
3434 o P4P [I-D.p4p-framework], [P4P-SIGCOMM08],
3435 [I-D.wang-alto-p4p-specification];
3437 o ALTO Info-Export [I-D.shalunov-alto-infoexport];
3439 o Query/Response [I-D.saumitra-alto-queryresponse],
3440 [I-D.saumitra-alto-multi-ps];
3442 o ATTP [ATTP]; and
3443 o Proxidor [I-D.akonjang-alto-proxidor].
3445 Appendix C. Authors
3447 [[CmtAuthors: RFC Editor: Please move information in this section to
3448 the Authors' Addresses section at publication time.]]
3450 Stefano Previdi
3451 Cisco
3453 Email: sprevidi@cisco.com
3455 Stanislav Shalunov
3456 BitTorrent
3458 Email: shalunov@bittorrent.com
3460 Richard Woundy
3461 Comcast
3463 Richard_Woundy@cable.comcast.com
3465 Authors' Addresses
3467 Richard Alimi (editor)
3468 Google
3469 1600 Amphitheatre Parkway
3470 Mountain View CA
3471 USA
3473 Email: ralimi@google.com
3475 Reinaldo Penno (editor)
3476 Cisco Systems
3477 170 West Tasman Dr
3478 San Jose CA
3479 USA
3481 Email: repenno@cisco.com
3482 Y. Richard Yang (editor)
3483 Yale University
3484 51 Prospect St
3485 New Haven CT
3486 USA
3488 Email: yry@cs.yale.edu