idnits 2.17.1 

draft-ietf-alto-deployments-10.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 222 has weird spacing: '...logical    ser...'

  == Line 249 has weird spacing: '...logical    ser...'

  -- The document date (July 3, 2014) is 3584 days in the past.  Is this
     intentional?

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '<CODE BEGINS>' and
     '<CODE ENDS>' lines.


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Outdated reference: A later version (-16) exists of
     draft-farrkingel-pce-abno-architecture-07

  == Outdated reference: A later version (-15) exists of
     draft-ietf-i2rs-architecture-04

  == Outdated reference: A later version (-13) exists of
     draft-ietf-idr-ls-distribution-05

  == Outdated reference: A later version (-10) exists of
     draft-seedorf-cdni-request-routing-alto-07

  == Outdated reference: A later version (-09) exists of
     draft-wu-alto-te-metrics-03


     Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	ALTO                                                      M. Stiemerling
3	Internet-Draft                                           NEC Europe Ltd.
4	Intended status: Informational                                 S. Kiesel
5	Expires: January 4, 2015                         University of Stuttgart
6	                                                              S. Previdi
7	                                                                   Cisco
8	                                                               M. Scharf
9	                                                Alcatel-Lucent Bell Labs
10	                                                            July 3, 2014

12	                     ALTO Deployment Considerations
13	                     draft-ietf-alto-deployments-10

15	Abstract

17	   Many Internet applications are used to access resources such as
18	   pieces of information or server processes that are available in
19	   several equivalent replicas on different hosts.  This includes, but
20	   is not limited to, peer-to-peer file sharing applications.  The goal
21	   of Application-Layer Traffic Optimization (ALTO) is to provide
22	   guidance to applications that have to select one or several hosts
23	   from a set of candidates, which are able to provide a desired
24	   resource.  This memo discusses deployment related issues of ALTO.  It
25	   addresses different use cases of ALTO such as peer-to-peer file
26	   sharing and CDNs and presents corresponding examples.  The document
27	   also includes recommendations for network administrators and
28	   application designers planning to deploy ALTO.

30	Status of This Memo

32	   This Internet-Draft is submitted in full conformance with the
33	   provisions of BCP 78 and BCP 79.

35	   Internet-Drafts are working documents of the Internet Engineering
36	   Task Force (IETF).  Note that other groups may also distribute
37	   working documents as Internet-Drafts.  The list of current Internet-
38	   Drafts is at http://datatracker.ietf.org/drafts/current/.

40	   Internet-Drafts are draft documents valid for a maximum of six months
41	   and may be updated, replaced, or obsoleted by other documents at any
42	   time.  It is inappropriate to use Internet-Drafts as reference
43	   material or to cite them other than as "work in progress."

45	   This Internet-Draft will expire on January 4, 2015.

47	Copyright Notice

49	   Copyright (c) 2014 IETF Trust and the persons identified as the
50	   document authors.  All rights reserved.

52	   This document is subject to BCP 78 and the IETF Trust's Legal
53	   Provisions Relating to IETF Documents
54	   (http://trustee.ietf.org/license-info) in effect on the date of
55	   publication of this document.  Please review these documents
56	   carefully, as they describe your rights and restrictions with respect
57	   to this document.  Code Components extracted from this document must
58	   include Simplified BSD License text as described in Section 4.e of
59	   the Trust Legal Provisions and are provided without warranty as
60	   described in the Simplified BSD License.

62	Table of Contents

64	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
65	   2.  General Considerations  . . . . . . . . . . . . . . . . . . .   4
66	     2.1.  ALTO Entities . . . . . . . . . . . . . . . . . . . . . .   4
67	       2.1.1.  Baseline Scenario . . . . . . . . . . . . . . . . . .   4
68	       2.1.2.  Placement of ALTO Entities  . . . . . . . . . . . . .   5
69	     2.2.  Classification of Deployment Scenarios  . . . . . . . . .   6
70	       2.2.1.  Deployment Degrees of Freedom . . . . . . . . . . . .   6
71	       2.2.2.  Information Exposure  . . . . . . . . . . . . . . . .   8
72	       2.2.3.  More Advanced Deployments . . . . . . . . . . . . . .   8
73	   3.  Deployment Considerations by ISPs . . . . . . . . . . . . . .  10
74	     3.1.  Objectives for the Guidance to Applications . . . . . . .  11
75	       3.1.1.  General Objectives for Traffic Optimization . . . . .  11
76	       3.1.2.  Inter-Network Traffic Localization  . . . . . . . . .  12
77	       3.1.3.  Intra-Network Traffic Localization  . . . . . . . . .  13
78	       3.1.4.  Network Off-Loading . . . . . . . . . . . . . . . . .  15
79	       3.1.5.  Application Tuning  . . . . . . . . . . . . . . . . .  16
80	     3.2.  Provisioning of ALTO Maps . . . . . . . . . . . . . . . .  16
81	       3.2.1.  Data Sources  . . . . . . . . . . . . . . . . . . . .  16
82	       3.2.2.  Privacy Requirements  . . . . . . . . . . . . . . . .  18
83	       3.2.3.  Partitioning and Grouping of IP Address Ranges  . . .  19
84	       3.2.4.  Rating Criteria and/or Cost Calculation . . . . . . .  19
85	     3.3.  Known Limitations of ALTO . . . . . . . . . . . . . . . .  22
86	       3.3.1.  Limitations of Map-based Approaches . . . . . . . . .  22
87	       3.3.2.  Limitiations of Non-Map-based Approaches  . . . . . .  24
88	     3.4.  Monitoring ALTO . . . . . . . . . . . . . . . . . . . . .  25
89	       3.4.1.  Impact and Observation on Network Operation . . . . .  25
90	       3.4.2.  Measurement of the Impact . . . . . . . . . . . . . .  26
91	       3.4.3.  System and Service Performance  . . . . . . . . . . .  27
92	       3.4.4.  Monitoring Infrastructures  . . . . . . . . . . . . .  27
93	     3.5.  Map Examples for Different Types of ISPs  . . . . . . . .  28
94	       3.5.1.  Small ISP with Single Internet Uplink . . . . . . . .  28
95	       3.5.2.  ISP with Several Fixed Access Networks  . . . . . . .  31
96	       3.5.3.  ISP with Fixed and Mobile Network . . . . . . . . . .  32
97	     3.6.  Deployment Experiences  . . . . . . . . . . . . . . . . .  33
98	   4.  Using ALTO for P2P Traffic Optimization . . . . . . . . . . .  34
99	     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  34
100	       4.1.1.  Usage Scenario  . . . . . . . . . . . . . . . . . . .  34
101	       4.1.2.  Applicability of ALTO . . . . . . . . . . . . . . . .  34
102	     4.2.  Deployment Recommendations  . . . . . . . . . . . . . . .  37
103	       4.2.1.  ALTO Services . . . . . . . . . . . . . . . . . . . .  37
104	       4.2.2.  Guidance Considerations . . . . . . . . . . . . . . .  38
105	   5.  Using ALTO for CDNs . . . . . . . . . . . . . . . . . . . . .  40
106	     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  40
107	       5.1.1.  Usage Scenario  . . . . . . . . . . . . . . . . . . .  40
108	       5.1.2.  Applicability of ALTO . . . . . . . . . . . . . . . .  42
109	     5.2.  Deployment Recommendations  . . . . . . . . . . . . . . .  43
110	       5.2.1.  ALTO Services . . . . . . . . . . . . . . . . . . . .  43
111	       5.2.2.  Guidance Considerations . . . . . . . . . . . . . . .  44
112	   6.  Other Use Cases . . . . . . . . . . . . . . . . . . . . . . .  45
113	     6.1.  Application Guidance in Virtual Private Networks (VPNs) .  45
114	     6.2.  In-Network Caching  . . . . . . . . . . . . . . . . . . .  48
115	   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  49
116	     7.1.  Information Leakage from the ALTO Server  . . . . . . . .  49
117	     7.2.  ALTO Server Access  . . . . . . . . . . . . . . . . . . .  50
118	     7.3.  Faking ALTO Guidance  . . . . . . . . . . . . . . . . . .  51
119	   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  51
120	   9.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  51
121	   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  51
122	     10.1.  Normative References . . . . . . . . . . . . . . . . . .  51
123	     10.2.  Informative References . . . . . . . . . . . . . . . . .  52
124	   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  54
125	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  54

127	1.  Introduction

129	   Many Internet applications are used to access resources such as
130	   pieces of information or server processes that are available in
131	   several equivalent replicas on different hosts.  This includes, but
132	   is not limited to, peer-to-peer (P2P) file sharing applications and
133	   Content Delivery Networks (CDNs).  The goal of Application-Layer
134	   Traffic Optimization (ALTO) is to provide guidance to applications
135	   that have to select one or several hosts from a set of candidates,
136	   which are able to provide a desired resource.  The basic ideas and
137	   problem space of ALTO is described in [RFC5693] and the set of
138	   requirements is discussed in [RFC6708].  The ALTO protocol is
139	   specified in [I-D.ietf-alto-protocol].

141	   This document discusses use cases and operational issues that can be
142	   expected when ALTO gets deployed.  This includes, but is not limited
143	   to, location of the ALTO server, imposed load to the ALTO server, or
144	   from whom the queries are performed.  The document also provides
145	   guidance which ALTO services to use, and it summarized known
146	   challenges.  It thereby complements the management considerations in
147	   the protocol specification [I-D.ietf-alto-protocol], which are
148	   independent of any specific use of ALTO.

150	2.  General Considerations

152	2.1.  ALTO Entities

154	2.1.1.  Baseline Scenario

156	   The ALTO protocol [I-D.ietf-alto-protocol] is a client/server
157	   protocol, operating between a number of ALTO clients and an ALTO
158	   server, as sketched in Figure 1.

160	                 +----------+
161	                 |  ALTO    |
162	                 |  Server  |
163	                 +----------+
164	                       ^
165	                _.-----|------.
166	            ,-''       |       `--.
167	          ,'           |           `.
168	         (     Network |             )
169	          `.           |           ,'
170	            `--.       |       _.-'
171	                `------|-----''
172	                       v
173	    +----------+  +----------+   +----------+
174	    |  ALTO    |  |  ALTO    |...|  ALTO    |
175	    |  Client  |  |  Client  |   |  Client  |
176	    +----------+  +----------+   +----------+

178	        Figure 1: Baseline deployment scenario of the ALTO protocol

180	   This document uses the terminology introduced in [RFC5693].  In
181	   particular, the following terms are defined by [RFC5693]:

183	   o  ALTO Service: Several resource providers may be able to provide
184	      the same resource.  The ALTO service gives guidance to a resource
185	      consumer and/or resource directory about which resource
186	      provider(s) to select in order to optimize the client's
187	      performance or quality of experience, while improving resource
188	      consumption in the underlying network infrastructure.

190	   o  ALTO Server: A logical entity that provides interfaces to the
191	      queries to the ALTO service.

193	   o  ALTO Client: The logical entity that sends ALTO queries.
194	      Depending on the architecture of the application, one may embed it
195	      in the resource consumer and/or in the resource directory.

197	   According to that definition, both an ALTO server and an ALTO client
198	   are logical entities.  An ALTO service may be offered by more than
199	   one ALTO servers.  In ALTO deployments, the functionality of an ALTO
200	   server can therefore be realized by several server instances, e.g.,
201	   by using load balancing between different physical servers.  The term
202	   ALTO server should not be confused with use of a single physical
203	   server.

205	2.1.2.  Placement of ALTO Entities

207	   The ALTO server and ALTO clients can be situated at various entities
208	   in a network deployment.  The first differentiation is whether the
209	   ALTO client is located on the actual host that runs the application,
210	   as shown in Figure 2, or if the ALTO client is located on a resource
211	   directory, as shown in Figure 3.

213	                                                  +-----+
214	                                             =====|     |**
215	                                         ====     +-----+  *
216	                                     ====            *     *
217	                                 ====                *     *
218	        +-----+     +------+=====                 +-----+  *
219	        |     |.....|      |======================|     |  *
220	        +-----+     +------+=====                 +-----+  *
221	      Source of      ALTO        ====                *     *
222	      topological    service         ====            *     *
223	      information                        ====     +-----+  *
224	                                             =====|     |**
225	                                                  +-----+
226	      Legend:
227	      === ALTO client protocol
228	      *** Application protocol
229	      ... Provisioning protocol

231	     Figure 2: Overview of protocol interaction between ALTO elements
232	                       without a resource directory

234	   Figure 2 shows the operational model for an ALTO client running at
235	   endpoints.  An example would be a peer-to-peer file sharing
236	   application that does not use a tracker, such as edonkey.  In
237	   addition, ALTO clients at peers could also be used in a similar way
238	   even if there is a tracker, as further discussed in Section 4.1.2.

240	                                                  +-----+
241	                                                **|     |**
242	                                              **  +-----+  *
243	                                            **       *     *
244	                                          **         *     *
245	        +-----+     +------+     +-----+**        +-----+  *
246	        |     |.....|      |=====|     |**********|     |  *
247	        +-----+     +------+     +-----+**        +-----+  *
248	      Source of      ALTO        Resource **         *     *
249	      topological    service     directory  **       *     *
250	      information                             **  +-----+  *
251	                                                **|     |**
252	                                                  +-----+

254	      Legend:
255	      === ALTO client protocol
256	      *** Application protocol
257	      ... Provisioning protocol

259	   Figure 3: Overview of protocol interaction between ALTO elements with
260	                           a resource directory

262	   In Figure 3, a use case with a resource directory is illustrated,
263	   e.g., a tracker in peer-to-peer filesharing.  Both deployment
264	   scenarios may differ in the number of ALTO clients that access an
265	   ALTO service: If ALTO clients are implemented in a resource
266	   directory, ALTO servers may be accessed by a limited and less dynamic
267	   set of clients, whereas in the general case any host could be an ALTO
268	   client.  This use case is further detailed in Section 4.

270	   Using ALTO in CDNs may be similar to a resource directory
271	   [I-D.jenkins-alto-cdn-use-cases].  The ALTO server can also be
272	   queried by CDN entities to get guidance about where the a particular
273	   client accessing data in the CDN is exactly located in the ISP's
274	   network, as discussed in Section 5.

276	2.2.  Classification of Deployment Scenarios

278	2.2.1.  Deployment Degrees of Freedom

280	   ALTO is a general-purpose protocol and it is intended to be used by a
281	   wide range of applications.  This implies that there are different
282	   possibilities where the ALTO entities are actually located, i.e., if
283	   the ALTO clients and the ALTO server are in the same ISP's domain, or
284	   if the clients and the ALTO server are managed/owned/located in
285	   different domains.

287	   ALTO deployments can be differentiated e.g. according to the
288	   following aspects:

290	   1.  Applicable trust model: The deployment of ALTO can differ
291	       depending on whether ALTO client and ALTO server are operated
292	       within the same organization and/or network, or not.  This
293	       affects a lot of constraints, because the trust model is very
294	       different.  For instance, as discussed later in this memo, the
295	       level-of-detail of maps can depend on who the involved parties
296	       actually are.

298	   2.  Size of user group: The main use case of ALTO is to provide
299	       guidance to any Internet application.  However, an operator of an
300	       ALTO server could also decide to only offer guidance to a set of
301	       well-known ALTO clients, e. g., after authentication and
302	       authorization.  In the peer-to-peer application use case, this
303	       could imply that only selected trackers are allowed to access the
304	       ALTO server.  The security implications of using ALTO in closed
305	       groups differ from the public Internet.

307	   3.  Covered destinations: In general, an ALTO server has to be able
308	       to provide guidance for all potential destinations.  Yet, in
309	       practice a given ALTO client may only be interested in a subset
310	       of destinations, e.g., only in the network cost between a limited
311	       set of resource providers.  For instance, CDN optimization may
312	       not need the full ALTO cost maps, because traffic between
313	       individual residential users is not in scope.  This may imply
314	       that an ALTO server only has to provide the costs that matter for
315	       a given user, e. g., by customized maps.

317	   The following sections enumerate different classes of use cases for
318	   ALTO, and they discuss deployment implications of each of them.  An
319	   ALTO server can in principle be operated by any organization, and
320	   there is no requirement that an ALTO server is deployed and operated
321	   by an Internet Service Provider (ISP).  Yet, since the ALTO solution
322	   is designed for ISPs, most examples in this document assume that the
323	   operator of an ALTO server is a network operator (e.g., an ISP or the
324	   network department in a large enterprise) that offers ALTO guidance
325	   in particular to users if this network.

327	   It must be emphasized that any application using ALTO must also work
328	   if no ALTO servers can be found or if no responses to ALTO queries
329	   are received, e.g., due to connectivity problems or overload
330	   situations (see also [RFC6708]).

332	2.2.2.  Information Exposure

334	   An ALTO server stores information about preferences (e.g., for IP
335	   address ranges) and ALTO clients can retrieve these preferences.
336	   There are basically two different approaches on where the preferences
337	   are actually processed:

339	   1.  The ALTO server has a list of preferences and clients can
340	       retrieve this list via the ALTO protocol.  This preference list
341	       can partially be updated by the server.  The actual processing of
342	       the data is done on the client and thus there is no data of the
343	       client's operation revealed to the ALTO server.

345	   2.  The ALTO server has a list of preferences or preferences
346	       calculated during runtime and the ALTO client is sending
347	       information of its operation (e.g., a list of IP addresses) to
348	       the server.  The server is using this operational information to
349	       determine its preferences and returns these preferences (e.g., a
350	       sorted list of the IP addresses) back to the ALTO client.

352	   Approach 1 has the advantage (seen from the client) that all
353	   operational information stays within the client and is not revealed
354	   to the provider of the server.  On the other hand, approach 1
355	   requires that the provider of the ALTO server, i.e., the network
356	   operator, reveals information about its network structure (e.g., IP
357	   ranges or topology information in general) to the ALTO client.  The
358	   ALTO protocol supports this scheme by the Network and Cost Map
359	   Service.

361	   Approach 2 has the advantage (seen from the operator) that all
362	   operational information stays with the ALTO server and is not
363	   revealed to the ALTO client.  On the other hand, approach 2 requires
364	   that the clients send their operational information to the server.
365	   This approach is realized by the ALTO Endpoint Cost Service (ECS).

367	   Both approaches have their pros and cons, as further detailed in
368	   Section 3.3.

370	2.2.3.  More Advanced Deployments

372	   From an ALTO client's perspective, there are different ways to use
373	   ALTO:

375	   1.  Single service instance with single metric guidance: An ALTO
376	       client only obtains guidance regarding a single metric from a
377	       single ALTO service, e.g., an ALTO server that is offered by the
378	       network service provider of the corresponding access network.
379	       Corresponding ALTO server instances can be discovered e.g. by
380	       ALTO server discovery [I-D.ietf-alto-server-discovery]
381	       [I-D.kist-alto-3pdisc].  Being a REST-ful protocol, an ALTO
382	       service can use known methods to balance the load between
383	       different server instances or between clusters of servers, i.e.,
384	       an ALTO server can be realized by many instances with a load
385	       balancing scheme.  The ALTO protocol also supports the use of
386	       different URIs for different ALTO features.

388	   2.  Single service instance with multiple metric guidance: An ALTO
389	       client could also query an ALTO service for different kinds of
390	       information, e.g., cost maps with different metrics.  The ALTO
391	       protocol is extensible and permits such operation.  However, ALTO
392	       does not define how a client shall deal with different forms of
393	       guidance, and it is up to the client to determine what provided
394	       information may indeed be useful.

396	   3.  Multiple service offers: An ALTO client can also decide to access
397	       multiple ALTO servers providing guidance, possibly from different
398	       operators or organisations.  Each of these services may only
399	       offer partial guidance, e.g., for a certain network partition.
400	       In that case, it may be difficult for an ALTO client to compare
401	       the guidance from different services.  Different organization may
402	       use different methods to determine maps, and they may also have
403	       different (possibly even contradicting or competing) guidance
404	       objectives.  How to discover multiple ALTO servers and how to
405	       deal with conflicting guidance is an open issue.

407	   There are also different options regarding the guidance offered by an
408	   ALTO service:

410	   1.  Authoritative servers: An ALTO server instance can provide
411	       guidance for all destinations for all kinds of ALTO clients.

413	   2.  Cascaded servers: An ALTO server may itself include an ALTO
414	       client and query other ALTO servers, e.g., for certain
415	       destinations.  This results is a cascaded deployment of ALTO
416	       servers, as further explained below.

418	   3.  Inter-server synchronization: Different ALTO servers my
419	       communicate by other means.  This approach is not further
420	       discussed in this document.

422	   An assumption of the ALTO design is that ISP operate ALTO servers
423	   independently, irrespectively of other ISPs.  This may true for most
424	   envisioned deployments of ALTO but there may be certain deployments
425	   that may have different settings.  Figure 4 shows such setting with a
426	   university network that is connected to two upstream providers.  NREN
427	   is a National Research and Education Network and ISP is a commercial
428	   upstream provider to this university network.  The university, as
429	   well as ISP, are operating their own ALTO server.  The ALTO clients,
430	   located on the peers will contact the ALTO server located at the
431	   university.

433	         +-----------+
434	         |    ISP    |
435	         |   ALTO    |
436	         |  Server   |
437	         +----------=+
438	            ,-------=            ,------.
439	         ,-'        =`-.      ,-'         `-.
440	        /   Upstream=   \    /   Upstream    \
441	       (       ISP  =    )  (       NREN      )
442	        \           =   /    \               /
443	         `-.        =,-'      `-.         ,-'
444	            `---+---=            `+------'
445	                |   =             |
446	                |   =======================
447	                |,-------------.  |       =
448	              ,-+               `-+    +-----------+
449	            ,'      University     `.  |University |
450	           (        Network          ) |   ALTO    |
451	            `.  =======================|  Server   |
452	              `-=               +-'    +-----------+
453	                =`+------------'|
454	                = |             |
455	         +--------+-+         +-+--------+
456	         |   Peer1  |         |   PeerN  |
457	         +----------+         +----------+

459	                Figure 4: Example of a cascaded ALTO server

461	   In this setting all "destinations" useful for the peers within NREN
462	   are free-of-charge for the peers located in the university network
463	   (i.e., they are preferred in the rating of the ALTO server).
464	   However, all traffic that is not towards NREN will be handled by the
465	   ISP upstream provider.  Therefore, the ALTO server at the university
466	   may also include the guidance given by the ISP ALTO server in its
467	   replies to the ALTO clients.  This is an example for cascaded ALTO
468	   servers.

470	3.  Deployment Considerations by ISPs
471	3.1.  Objectives for the Guidance to Applications

473	3.1.1.  General Objectives for Traffic Optimization

475	   The Internet consists of many networks.  The networks are operated by
476	   Network Service Providers (NSP), Internet Service Providers (named
477	   ISP in this memo), which also include e.g. universities, enterprises,
478	   or other organizations.  The Internet provides network connectivity
479	   e.g. by access networks, such as cable networks, xDSL networks, 3G/4G
480	   mobile networks, etc.  Network operators need to manage, to control
481	   and to audit the traffic.  Therefore, it is important to understand
482	   how to deploy an ALTO service and its expected impact.

484	   The general objective of ALTO is to give guidance to applications on
485	   what endpoints (e.g., IP addresses or IP prefixes) are to be
486	   preferred according to the operator of the ALTO server.  The ALTO
487	   protocol gives means to let the ALTO server operator express its
488	   preference, whatever this preference is.

490	   ALTO enables ISPs to support application-level traffic engineering by
491	   influencing application resource selections.  This traffic
492	   engineering can have different objectives:

494	   1.  Inter-network traffic localization: ALTO can help to reduce
495	       inter-domain traffic.  The networks of ISPs are connected through
496	       peering points.  From a business view, the inter-network
497	       settlement is needed for exchanging traffic between these
498	       networks.  These peering agreements can be costly.  To reduce
499	       these costs, a simple objective is to decrease the traffic
500	       exchange across the peering points and thus keep the traffic in
501	       the own network or Autonomous System (AS) as far as possible.

503	   2.  Intra-network traffic localization: In case of large ISPs, the
504	       network may be grouped into several networks, domains, or
505	       Autonomous Systems (ASs).  The core network includes one or
506	       several backbone networks, which are connected to multiple
507	       aggregation, metro, and access networks.  If traffic can be
508	       limited to certain areas such as access networks, this decreases
509	       the usage of backbone and thus helps to save resources and costs.

511	   3.  Network off-loading: Compared to fixed networks, mobile networks
512	       have some special characteristics, including smaller link
513	       bandwidth, high cost, limited radio frequency resource, and
514	       limited terminal battery.  In mobile networks, wireless links
515	       should be used efficiently.  For example, in the case of a P2P
516	       service, it is likely that hosts in fixed networks should avoid
517	       retrieving data from hosts in mobile networks, and hosts in
518	       mobile networks should prefer retrieval of data from hosts in
519	       fixed networks.

521	   4.  Application tuning: ALTO is also a tool to optimize the
522	       performance of applications that depend on the network and
523	       perform resource selection decisions among network endpoints.
524	       And example is the network-aware selection of Content Delivery
525	       Network (CDN) caches.

527	   In the following, these objectives are explained in more detail with
528	   examples.

530	3.1.2.  Inter-Network Traffic Localization

532	   ALTO guidance can be used to keep traffic local in a network.  An
533	   ALTO server can let applications prefer other hosts within the same
534	   network operator's network instead of randomly connecting to other
535	   hosts that are located in another operator's network.  Here, a
536	   network operator would always express its preference for hosts in its
537	   own network, while hosts located outside its own network are to be
538	   avoided (i.e., they are undesired to be considered by the
539	   applications).  Figure 5 shows such a scenario where hosts prefer
540	   hosts in the same network (e.g., Host 1 and Host 2 in ISP1 and Host 3
541	   and Host 4 in ISP2).

543	                            ,-------.         +-----------+
544	          ,---.          ,-'         `-.      |   Host 1  |
545	       ,-'     `-.      /     ISP 1   ########|ALTO Client|
546	      /           \    /              #  \    +-----------+
547	     /    ISP X    \   |              #  |    +-----------+
548	    /               \  \              ########|   Host 2  |
549	   ;             +----------------------------|ALTO Client|
550	   |             |   |   `-.         ,-'      +-----------+
551	   |             |   |      `-------'
552	   |             |   |      ,-------.         +-----------+
553	   :             |   ;   ,-'         `########|   Host 3  |
554	    \            |  /   /     ISP 2   # \     |ALTO Client|
555	     \           | /   /              #  \    +-----------+
556	      \          +---------+          #  |    +-----------+
557	       `-.     ,-'     \   |          ########|   Host 4  |
558	          `---'         \  +------------------|ALTO Client|
559	                         `-.         ,-'      +-----------+
560	                            `-------'

562	       Legend:
563	       ### preferred "connections"
564	       --- non-preferred "connections"

566	               Figure 5: Inter-network traffic localization

568	   Examples for corresponding ALTO maps can be found in Section 3.5.
569	   Depending on the application characteristics, it may not be possible
570	   or even not be desirable to completely localize all traffic.

572	3.1.3.  Intra-Network Traffic Localization

574	   The above sections described the results of the ALTO guidance on an
575	   inter-network level.  However, ALTO can also be used for intra-
576	   network localization.  In this case, ALTO provides guidance which
577	   internal hosts are to be preferred inside a single network or, e.g.,
578	   one AS.  Figure 6 shows such a scenario where Host 1 and Host 2 are
579	   located in Net 2 of ISP1 and connect via a low capacity link to the
580	   core (Net 1) of the same ISP1.  If Host 1 and Host 2 exchange their
581	   data with remote hosts, they would probably congest the bottleneck
582	   link.

584	                               ,-------.         +-----------+
585	          ,---.             ,-'         `-.      |   Host 1  |
586	       ,-'     `-.         /     ISP 1  #########|ALTO Client|
587	      /           \       /      Net 2  #   \    +-----------+
588	     /    ISP 1    \      |     #########   |    +-----------+
589	    /     Net 1     \     \     #           /    |   Host 2  |
590	   ;             ###;      \    #      ##########|ALTO Client|
591	   |               X~~~~~~~~~~~~X#######,-'      +-----------+
592	   |             ### |  ^      `-------'
593	   |                 |  |
594	   :                 ;  |
595	    \               /  Bottleneck
596	     \             /
597	      \           /
598	       `-.     ,-'
599	          `---'
600	       Legend:
601	       ### peer "connections"
602	       ~~~ bottleneck link

604	         Figure 6: Without intra-network ALTO traffic localization

606	   The operator can guide the hosts in such a situation to try first
607	   local hosts in the same network islands, avoiding or at least
608	   lowering the effect on the bottleneck link, as shown in Figure 7.

610	                               ,-------.         +-----------+
611	          ,---.             ,-'         `-.      |   Peer 1  |
612	       ,-'     `-.         /     ISP 1  #########|ALTO Client|
613	      /           \       /      Net 2  #   \    +-----------+
614	     /    ISP 1    \      |             #   |    +-----------+
615	    /     Net 1     \     \             #########|   Peer 2  |
616	   ;                ;      \           ##########|ALTO Client|
617	   |                #~~~~~~~~~~~########,-'      +-----------+
618	   |             ### |  ^      `-------'
619	   |                 |  |
620	   :                 ;  |
621	    \               /  Bottleneck
622	     \             /
623	      \           /
624	       `-.     ,-'
625	          `---'
626	       Legend:
627	       ### peer "connections"
628	       ~~~ bottleneck link

630	          Figure 7: With intra-network ALTO traffic localization

632	   The objective here is to avoid bottlenecks by optimized endpoint
633	   selection at application level.  ALTO is not a method to deal with
634	   the congestion at the bottleneck.

636	3.1.4.  Network Off-Loading

638	   Another scenario is off-loading traffic from networks.  This use of
639	   ALTO can be beneficial in particular in mobile networks.  The network
640	   operator may have the desire to guide hosts in its own network to use
641	   hosts in remote networks.  One reason can be that the wireless
642	   network is not made for the load cause by, e.g., peer-to-peer
643	   applications, and the operator has the need that peers fetch their
644	   data from remote peers in other parts of the Internet.

646	                            ,-------.         +-----------+
647	          ,---.          ,-'         `-.      |   Host 1  |
648	       ,-'     `-.      /     ISP 1   +-------|ALTO Client|
649	      /           \    /              |  \    +-----------+
650	     /    ISP X    \   |              |  |    +-----------+
651	    /               \  \              +-------|   Host 2  |
652	   ;             #-###########################|ALTO Client|
653	   |             #   |   `-.         ,-'      +-----------+
654	   |             #   |      `-------'
655	   |             #   |      ,-------.         +-----------+
656	   :             #   ;   ,-'         `+-------|   Host 3  |
657	    \            #  /   /     ISP 2   | \     |ALTO Client|
658	     \           # /   /              |  \    +-----------+
659	      \          ###########          |  |    +-----------+
660	       `-.     ,-'     \   #          +-------|   Host 4  |
661	          `---'         \  ###################|ALTO Client|
662	                         `-.         ,-'      +-----------+
663	                            `-------'

665	       Legend:
666	       === preferred "connections"
667	       --- non-preferred "connections"

669	              Figure 8: ALTO traffic network de-localization

671	   Figure 8 shows the result of such a guidance process where Host 2
672	   prefers a connection with Host 4 instead of Host 1, as shown in
673	   Figure 5.

675	   A realization of this scenario may have certain limitations and may
676	   not be possible in all cases.  For instance, it may require that the
677	   ALTO server can distinguish mobile and non-mobile hosts, e.g., based
678	   on their IP address.  This may depend on mobility solutions and may
679	   not be possible or accurate.  In general, ALTO is not intended as a
680	   fine-grained traffic engineering solution for individual hosts.
681	   Instead, it typically works on aggregates (e.g., if it is known that
682	   certain IP prefixes are often assigned to mobile users).

684	3.1.5.  Application Tuning

686	   ALTO can also provide guidance to optimize the application-level
687	   topology of networked applications, e.g., by exposing network
688	   performance information.  Applications can often run own measurements
689	   to determine network performance, e.g., by active delay measurements
690	   or bandwidth probing, but such measurements result in overhead and
691	   complexity.  Accessing an ALTO server can be a simpler alternative.
692	   In addition, an ALTO server may also expose network information that
693	   applications cannot easily measure or reverse-engineer.

695	3.2.  Provisioning of ALTO Maps

697	3.2.1.  Data Sources

699	   An ALTO server collects topological information from a variety of
700	   sources in the network and provides a cohesive, abstracted view of
701	   the network topology to applications using an ALTO client.  The ALTO
702	   server builds an ALTO-specific network topology that represents the
703	   network as it should be understood and utilized by applications at
704	   endpoints.

706	   ALTO abstract network topologies can be automatically generated from
707	   the physical or logical topology of the network.  The generation
708	   would typically be based on policies and rules set by the network
709	   operator.  The maps and the guidance can significantly differ
710	   depending on the use case, the network architecture, and the trust
711	   relationship between ALTO server and ALTO client, etc.  Besides the
712	   security requirements that consist of not delivering any confidential
713	   or critical information about the infrastructure, there are
714	   efficiency requirements in terms of what aspects of the network are
715	   visible and required by the given use case and/or application.

717	   The ALTO server builds topology (for either Map and ECS services)
718	   based on multiple sources that may include routing protocols, network
719	   policies, state and performance information, geo-location, etc.  The
720	   network topology information is controlled and managed by the ALTO
721	   server.  In all cases, the operators have to ensure that the ALTO
722	   topology does not contain any details that would endanger the network
723	   integrity and security.  For instance, ALTO is not intended to leak
724	   raw Interior Gateway Protocol (IGP) or Border gateway Protocol (BGP)
725	   databases to ALTO clients.

727	          +--------+     +--------+
728	          | Client |     | Client |
729	          +--------+     +--------+
730	                  ^       ^
731	                  |       | ALTO protocol
732	                 +---------+
733	                 |  ALTO   |
734	                 | Server  |
735	                 +---------+
736	                  ^   ^   ^    Potential
737	                  |   |   |  data sources
738	         +--------+   |   +--------+
739	         |            |            |
740	    +---------+  +---------+  +---------+
741	    |   BGP   |  |   I2RS  |  |   NMS   |
742	    | Speaker |  |  Client |  |   OSS   |
743	    +---------+  +---------+  +---------+
744	         ^            ^            ^
745	         |            |            |
746	    Link-State      I2RS      SNMP/NETCONF,
747	     NLRI for       data      traffic statistics,
748	     IGP/BGP                  IPFIX, etc.

750	                 Figure 9: Potential data sources for ALTO

752	   As illustrated in Figure 9, the topology data used by an ALTO server
753	   can originate from different data sources:

755	   o  The document [I-D.ietf-idr-ls-distribution] describes a mechanism
756	      by which links state and traffic engineering information can be
757	      collected from networks and shared with external components using
758	      the BGP routing protocol.  This is achieved using a new BGP
759	      Network Layer Reachability Information (NLRI) encoding format.
760	      The mechanism is applicable to physical and virtual IGP links and
761	      can also include Traffic Engineering (TE) data.  For instance,
762	      prefix data can be carried and originated in BGP, while TE data is
763	      originated and carried in an IGP.  The mechanism described is
764	      subject to policy control.  An ALTO Server can also use other
765	      mechanisms to get network data, for example, peering with multiple
766	      IGP and BGP speakers.

768	   o  The Interface to the Routing System (I2RS) is a solution for state
769	      transfer in and out of the Internet's routing system
770	      [I-D.ietf-i2rs-architecture].  An ALTO server could use an I2RS
771	      client to observe routing-related information.

773	   o  An ALTO server can also leverage a Network Management System (NMS)
774	      or an Operations Support System (OSS) as data sources.  NMS or OSS
775	      solutions are used to control, operate, and manage a network,
776	      e.g., using the Simple Network Management Protocol (SNMP) or
777	      NETCONF.  As explained for instance in
778	      [I-D.farrkingel-pce-abno-architecture], the NMS and OSS can be
779	      consumers of network events reported and can act on these reports
780	      as well as displaying them to users and raising alarms.  The NMS
781	      and OSS can also access the Traffic Engineering Database (TED) and
782	      Label Switched Path Database (LSP-DB) to show the users the
783	      current state of the network.  In addition, NMS and OSS systems
784	      may have access to IGP/BGP routing information, network inventory
785	      data (e.g., links, nodes, or link properties not visible to
786	      routing protocols, such as Shared Risk Link Groups), statistics
787	      collection system that provides traffic information, such as
788	      traffic demands or link utilizations obtained from IP Flow
789	      Information Export (IPFIX), as well as other Operations,
790	      Administration, and Maintenance (OAM) information (e.g., syslog).
791	      NMS or OSS systems also may have functions to correlate and
792	      orchestrate information originating from other data sources.  For
793	      instance, it could be required to correlate IP prefixes with
794	      routers (Provider, Provider Edge, Customer Edge, etc.), IGP areas,
795	      VLAN IDs, or policies.

797	3.2.2.  Privacy Requirements

799	   Providing ALTO guidance results in a win-win situation both for
800	   network providers and users of the ALTO information.  Applications
801	   possibly get a better performance, while the the network provider has
802	   means to optimize the traffic engineering and thus its costs.

804	   Still, ISPs may have other important requirements when deploying
805	   ALTO.  In particular, an ISP may not be willing to expose sensitive
806	   operational details of its network.  The topology abstraction of ALTO
807	   enables an ISP to expose the network topology at a desired
808	   granularity only, determined by security policies.

810	   With the ALTO Endpoint Cost Service, the ALTO client does not to have
811	   to implement any specific algorithm or mechanism in order to
812	   retrieve, maintain and process network topology information (of any
813	   kind).  The complexity of the network topology (computation,
814	   maintenance and distribution) is kept in the ALTO server and ECS is
815	   delivered on demand.  This allows the ALTO server to enhance and
816	   modify the way the topology information sources are used and
817	   combined.  This simplifies the enforcement of privacy policies of the
818	   ISP.

820	   The ALTO Network Map and Cost Map service expose an abstracted view
821	   on the ISP network topology.  Therefore, in this case care is needed
822	   when constructing those maps, as further discussed in Section 3.2.3.

824	3.2.3.  Partitioning and Grouping of IP Address Ranges

826	   Host group descriptors are used in the ALTO client protocol to
827	   describe the location of a host in the network topology.  These
828	   identifiers are called Partition ID (PID) and e.g. expand to a set of
829	   IP address ranges (CIDR).  A PID is characterized by a string
830	   identifier.  If an ALTO server offers the Map Service, corresponding
831	   identifiers have to be configured.

833	   An automated ALTO implementation may use dynamic algorithms to
834	   aggregate network topology.  However, it is often desirable to have a
835	   mechanism through which the network operator can control the level
836	   and details of network aggregation based on a set of requirements and
837	   constraints.  This will typically be governed by policies that
838	   enforce a certain level of abstraction and prevent leakage of
839	   sensitive operational data.

841	   For instance, an ALTO server may leverage BGP information that is
842	   available in a networks service provider network layer and compute
843	   the group of prefix.  An example are BGP communities, which are used
844	   in MPLS/IP networks as a common mechanism to aggregate and group
845	   prefixes.  A BGP community is an attribute used to tag a prefix to
846	   group prefixes based on mostly any criteria (as an example, most ISP
847	   networks originate BGP prefixes with communities identifying the
848	   Point of Presence (PoP) where the prefix has been originated).  These
849	   BGP communities could be used to map IP address ranges to PIDs.  By
850	   an additional policy, the ALTO server operator may decide an
851	   arbitrary cost defined between groups.  Alternatively, there are
852	   algorithms that allow a dynamic computation of cost between groups.
853	   The ALTO protocol itself is independent of such algorithms and
854	   policies.

856	3.2.4.  Rating Criteria and/or Cost Calculation

858	   Rating criteria are used in the ALTO protocol to express topology- or
859	   connectivity-related properties, which are evaluated in order to
860	   generate the ALTO guidance.  The ALTO protocol specification defines
861	   as basic set of rating criteria the "routingcost" metric, which has
862	   to be supported by all implementations.  It is up to the ALTO server
863	   how that metric is calculated.

865	   There is also an extension procedure for adding new criteria and
866	   metrics.  The following list gives an overview on further rating
867	   criteria that have been proposed or which are in use by ALTO-related
868	   prototype implementations.  This list is not intended as normative
869	   text; a formal definition of metrics can be found in
870	   [I-D.wu-alto-te-metrics].  Instead, the only purpose of the following
871	   list is to document the rating criteria that have been proposed so
872	   far.  It can also depend on the use case of ALTO whether such rating
873	   criteria are useful, and whether the corresponding information would
874	   indeed be made available by ISPs.

876	   Distance-related rating criteria:

878	   o  Relative topological distance: The term relative means that a
879	      larger numerical value means greater distance, but it is up to the
880	      ALTO service how to compute the values, and the ALTO client will
881	      not be informed about the nature of the information.  One way of
882	      generating this kind of information may be counting AS hops, but
883	      when querying this parameter, the ALTO client must not assume that
884	      the numbers actually are AS hops.  In addition to the AS path, a
885	      relative cost value could also be calculated taking into account
886	      other routing protocol parameters, such as BGP local preference or
887	      multi-exit discriminator (MED) attributes.

889	   o  Absolute topological distance, expressed in the number of
890	      traversed autonomous systems (AS).

892	   o  Absolute topological distance, expressed in the number of router
893	      hops (i.e., how much the TTL value of an IP packet will be
894	      decreased during transit).

896	   o  Absolute physical distance, based on knowledge of the approximate
897	      geolocation (e.g., continent, country) of an IP address.

899	   Performance-related rating criteria:

901	   o  The minimum achievable throughput between the resource consumer
902	      and the candidate resource provider, which is considered useful by
903	      the application (only in ALTO queries).

905	   o  An arbitrary upper bound for the throughput from/to the candidate
906	      resource provider (only in ALTO responses).  This may be, but is
907	      not necessarily the provisioned access bandwidth of the candidate
908	      resource provider.

910	   o  The maximum round-trip time (RTT) between resource consumer and
911	      the candidate resource provider, which is acceptable for the
912	      application for useful communication with the candidate resource
913	      provider (only in ALTO queries).

915	   o  An arbitrary lower bound for the RTT between resource consumer and
916	      the candidate resource provider (only in ALTO responses).  This
917	      may be, for example, based on measurements of the propagation
918	      delay in a completely unloaded network.

920	   Charging-related rating criteria:

922	   o  Traffic volume caps, in case the Internet access of the resource
923	      consumer is not charged by "flat rate".  For each candidate
924	      resource provider, the ALTO service could indicate the amount of
925	      data that may be transferred from/to this resource provider until
926	      a given point in time, and how much of this amount has already
927	      been consumed.  Furthermore, it would have to be indicated how
928	      excess traffic would be handled (e.g., blocked, throttled, or
929	      charged separately at an indicated price).  The interaction of
930	      several applications running on a host, out of which some use this
931	      criterion while others don't, as well as the evaluation of this
932	      criterion in resource directories, which issue ALTO queries on
933	      behalf of other peers, are for further study.

935	   o  Other metrics representing an abstract cost, e.g., determined by
936	      policies that distinguish "cheap" from "expensive" IP subnet
937	      ranges, e.g., without detailing the cost function.

939	   These rating criteria are subject to the remarks below:

941	   The ALTO client must be aware that with high probability the actual
942	   performance values differs from whatever an ALTO server exposes.  In
943	   particular, an ALTO client must not consider a throughput parameter
944	   as a permission to send data at the indicated rate without using
945	   congestion control mechanisms.

947	   The discrepancies are due to various reasons, including, but not
948	   limited to the facts that

950	   o  the ALTO service is not an admission control system

952	   o  the ALTO service may not know the instantaneous congestion status
953	      of the network

955	   o  the ALTO service may not know all link bandwidths, i.e., where the
956	      bottleneck really is, and there may be shared bottlenecks

958	   o  the ALTO service may not have all information about the actual
959	      routing

961	   o  the ALTO service may not know whether the candidate peer itself is
962	      overloaded

964	   o  the ALTO service may not know whether the candidate peer throttles
965	      the bandwidth it devotes for the considered application

967	   o  the ALTO service may not know whether the candidate peer will
968	      throttle the data it sends to us (e.g., because of some fairness
969	      algorithm, such as tit-for-tat).

971	   Because of these inaccuracies and the lack of complete, instantaneous
972	   state information, which are inherent to the ALTO service, the
973	   application must use other mechanisms (such as passive measurements
974	   on actual data transmissions) to assess the currently achievable
975	   throughput, and it must use appropriate congestion control mechanisms
976	   in order to avoid a congestion collapse.  Nevertheless, these rating
977	   criteria may provide a useful shortcut for quickly excluding
978	   candidate resource providers from such probing, if it is known in
979	   advance that connectivity is in any case worse than what is
980	   considered the minimum useful value by the respective application.

982	   Rating criteria that should not be defined for and used by the ALTO
983	   service include:

985	   o  Performance metrics that are closely related to the instantaneous
986	      congestion status.  The definition of alternate approaches for
987	      congestion control is explicitly out of the scope of ALTO.
988	      Instead, other appropriate means, such as using TCP based
989	      transport, have to be used to avoid congestion.

991	   o  Performance metrics that raise privacy concerns.  For instance, it
992	      has been questioned whether an ALTO service could publicly expose
993	      the provisioned access bandwidth, e.g. of cable / DSL customers,
994	      because this could enables identification of "premium" customers.

996	3.3.  Known Limitations of ALTO

998	3.3.1.  Limitations of Map-based Approaches

1000	   The specification of the Map Service in the ALTO protocol
1001	   [I-D.ietf-alto-protocol] is based on the concept of network maps.
1002	   The network map approach uses host group descriptors that group one
1003	   or multiple subnetworks (i.e., IP prefixes) to a single aggregate.  A
1004	   set of IP prefixes is called partition and the associated Host Group
1005	   Descriptor is called Partition ID (PID).  The "costs" between the
1006	   various partition IDs is stored in a second map, the cost map.  Map-
1007	   based approaches lower the signaling load on the server as maps have
1008	   to be retrieved only if they change.

1010	   One main assumption for map-based approaches is that the information
1011	   provided in these maps is static for a longer period of time.  This
1012	   assumption is fine as long as the network operator does not change
1013	   any parameter, e.g., routing within the network and to the upstream
1014	   peers, IP address assignment stays stable (and thus the mapping to
1015	   the partitions).  However, there are several cases where this
1016	   assumption is not valid:

1018	   1.  ISPs reallocate IP subnets from time to time;

1020	   2.  ISPs reallocate IP subnets on short notice;

1022	   3.  IP prefix blocks may be assigned to a router that serves a
1023	       variety of access networks;

1025	   4.  Network costs between IP prefixes may change depending on the
1026	       ISP's routing and traffic engineering.

1028	   These effects can be explained as follows:

1030	   Case 1: ISPs may reallocate IPv4 subnets within their infrastructure
1031	   from time to time, partly to ensure the efficient usage of IPv4
1032	   addresses (a scarce resource), and partly to enable efficient route
1033	   tables within their network routers.  The frequency of these
1034	   "renumbering events" depend on the growth in number of subscribers
1035	   and the availability of address space within the ISP.  As a result, a
1036	   subscriber's household device could retain an IPv4 address for as
1037	   short as a few minutes, or for months at a time or even longer.

1039	   It has been suggested that ISPs providing ALTO services could sub-
1040	   divide their subscribers' devices into different IPv4 subnets (or
1041	   certain IPv4 address ranges) based on the purchased service tier, as
1042	   well as based on the location in the network topology.  The problem
1043	   is that this sub-allocation of IPv4 subnets tends to decrease the
1044	   efficiency of IPv4 address allocation.  A growing ISP that needs to
1045	   maintain high efficiency of IPv4 address utilization may be reluctant
1046	   to jeopardize their future acquisition of IPv4 address space.

1048	   However, this is not an issue for map-based approaches if changes are
1049	   applied in the order of days.

1051	   Case 2: ISPs can use techniques that allow the reallocation of IP
1052	   prefixes on very short notice, i.e., within minutes.  An IP prefix
1053	   that has no IP address assignment to a host anymore can be
1054	   reallocated to areas where there is currently a high demand for IP
1055	   addresses.

1057	   Case 3: In residential access networks (e.g., DSL, cable), IP
1058	   prefixes are assigned to broadband gateways, which are the first IP-
1059	   hop in the access-network between the Customer Premises Equipment
1060	   (CPE) and the Internet.  The access-network between CPE and broadband
1061	   gateway (called aggregation network) can have varying characteristics
1062	   (and thus associated costs), but still using the same IP prefix.  For
1063	   instance one IP addresses IP11 out of a IP prefix IP1 can be assigned
1064	   to a VDSL (e.g., 2 MBit/s uplink) access line while the subsequent IP
1065	   address IP12 is assigned to a slow ADSL line (e.g., 128 kbit/s
1066	   uplink).  These IP addresses are assigned on a first come first
1067	   served basis, i.e., a single IP address out of the same IP prefix can
1068	   change its associated costs quite fast.  This may not be an issue
1069	   with respect to the used upstream provider (thus the cross ISP
1070	   traffic) but depending on the capacity of the aggregation-network
1071	   this may raise to an issue.

1073	   Case 4: The routing and traffic engineering inside an ISP network, as
1074	   well as the peering with other autonomous systems, can change
1075	   dynamically and affect the information exposed by an ALTO server.  As
1076	   a result, cost map and possibly also network maps can change.

1078	3.3.2.  Limitiations of Non-Map-based Approaches

1080	   The specification of the ALTO protocol [I-D.ietf-alto-protocol] also
1081	   includes the Endpoint Cost Service (ECS) mechanism.  ALTO clients can
1082	   ask guidance for specific IP addresses to the ALTO server, thereby
1083	   avoiding the need of processing maps.  This can mitigate some of the
1084	   problems mentioned in the previous section.

1086	   However, asking for IP addresses, asking with long lists of IP
1087	   addresses, and asking quite frequently may overload the ALTO server.
1088	   The server has to rank each received IP address, which causes load at
1089	   the server.  This may be amplified by the fact that not only a single
1090	   ALTO client is asking for guidance, but a larger number of them.  The
1091	   results of the ECS are also more difficult to cache than ALTO maps.
1092	   Therefore, the ALTO client may have to await the server response
1093	   before starting a communication, which results in an additional
1094	   delay.

1096	   Caching of IP addresses at the ALTO client or the usage of the H12
1097	   approach [I-D.kiesel-alto-h12] in conjunction with caching may lower
1098	   the query load on the ALTO server.

1100	   When ALTO server receives an ECS request, it may not have the most
1101	   appropriate topology information in order to accurately determine the
1102	   ranking.  [I-D.ietf-alto-protocol] generally assumes that a server
1103	   can always offer some guidance.  In such a case the ALTO server could
1104	   adopt one of the following strategies:

1106	   o  Reply with available information (best effort).

1108	   o  Query another ALTO server presumed to have better topology
1109	      information and return that response (cascaded servers).

1111	   o  Redirect the request to another ALTO server presumed to have
1112	      better topology information (redirection).

1114	   The protocol mechanisms and decision processes that would be used to
1115	   determine if redirection is necessary and which mode to use is out of
1116	   the scope of this document, since protocol extensions could be
1117	   required.

1119	3.4.  Monitoring ALTO

1121	3.4.1.  Impact and Observation on Network Operation

1123	   ALTO presents a new opportunity for managing network traffic by
1124	   providing additional information to clients.  In particular, the
1125	   deployment of an ALTO Server may shift network traffic patterns, and
1126	   the potential impact to network operation can be large.  An ISP
1127	   providing ALTO may want to assess the benefits of ALTO as part of the
1128	   management and operations (cf.  [I-D.ietf-alto-protocol]).  For
1129	   instance, the ISP might be interested in understanding whether the
1130	   provided ALTO maps are effective, and in order to decide whether an
1131	   adjustment of the ALTO configuration would be useful.  Such insight
1132	   can be obtained from a monitoring infrastructure.  An NSP offering
1133	   ALTO could consider the impact on (or integration with) traffic
1134	   engineering and the deployment of a monitoring service to observe the
1135	   effects of ALTO operations.  The measurement of impacts can be
1136	   challenging because ALTO-enabled applications may not provide related
1137	   information back to the ALTO Service Provider.

1139	   To construct an effective monitoring infrastructure, the ALTO Service
1140	   Provider should decide how to monitor the performance of ALTO and
1141	   identify and deploy data sources to collect data to compute the
1142	   performance metrics.  In certain trusted deployment environments, it
1143	   may be possible to collect information directly from ALTO clients.
1144	   It may also be possible to vary or selectively disable ALTO guidance
1145	   for a portion of ALTO clients either by time, geographical region, or
1146	   some other criteria to compare the network traffic characteristics
1147	   with and without ALTO.  Monitoring an ALTO service could also be
1148	   realized by third parties.  In this case, insight into ALTO data may
1149	   require a trust relationship between the monitoring system operator
1150	   and the network service provider offering an ALTO service.

1152	   The required monitoring depends on the network infrastructure and the
1153	   use of ALTO, and an exhaustive description is outside the scope of
1154	   this document.

1156	3.4.2.  Measurement of the Impact

1158	   ALTO realizes an interface between the network and applications.
1159	   This implies that an effective monitoring infrastructure may have to
1160	   deal with both network and application performance metrics.  This
1161	   document does not comprehensively list all performance metrics that
1162	   could be relevant, nor does it formally specify metrics.

1164	   The impact of ALTO can be classified regarding a number of different
1165	   criteria:

1167	   o  Total amount and distribution of traffic: ALTO enables ISPs to
1168	      influence and localize traffic of applications that use the ALTO
1169	      service.  An ISP may therefore be interested in analyzing the
1170	      impact on the traffic, i.e., whether network traffic patterns are
1171	      shifted.  For instance, if ALTO shall be used to reduce the inter-
1172	      domain P2P traffic, it makes sense to evaluate the total amount of
1173	      inter-domain traffic of an ISP.  Then, one possibility is to study
1174	      how the introduction of ALTO reduces the total inter-domain
1175	      traffic (inbound and/our outbound).  If the ISPs intention is to
1176	      localize the traffic inside his network, the network-internal
1177	      traffic distribution will be of interest.  Effectiveness of
1178	      localization can be quantified in different ways, e.g., by the
1179	      load on core routers and backbone links, or by considering more
1180	      advanced effects, such as the average number of hops that traffic
1181	      traverses inside a domain.

1183	   o  Application performance: The objective of ALTO is improve
1184	      application performance.  ALTO can be used by very different types
1185	      applications, with different communication characteristics and
1186	      requirements.  For instance, if ALTO guidance achieves traffic
1187	      localization, one would expect that applications achieve a higher
1188	      throughput and/or smaller delays to retrieve data.  If
1189	      application-specific performance characteristics (e.g., video or
1190	      audio quality) can be monitored, such metrics related to user
1191	      experience could also help to analyze the benefit of an ALTO
1192	      deployment.  If available, selected statistics from the TCP/IP
1193	      stack in hosts could be leveraged, too.

1195	   Of potential interest can also be the share of applications or
1196	   customers that actually use an offered ALTO service, i.e., the
1197	   adoption of the service.

1199	   Monitoring statistics can be aggregated, averaged, and normalized in
1200	   different ways.  This document does not mandate specific ways how to
1201	   calculate metrics.

1203	3.4.3.  System and Service Performance

1205	   A number of interesting parameters can be measured at the ALTO
1206	   server.  [I-D.ietf-alto-protocol] suggests certain ALTO-specific
1207	   metrics to be monitored:

1209	   o  Requests and responses for each service listed in a Information
1210	      Directory (total counts and size in bytes).

1212	   o  CPU and memory utilization

1214	   o  ALTO map updates

1216	   o  Number of PIDs

1218	   o  ALTO map sizes (in-memory size, encoded size, number of entries)

1220	   This data characterizes the workload, the system performance as well
1221	   as the map data.  Obviously, such data will depend on the
1222	   implementation and the actual deployment of the ALTO service.
1223	   Logging is also recommended in [I-D.ietf-alto-protocol].

1225	3.4.4.  Monitoring Infrastructures

1227	   Understanding the impact of ALTO may require interaction between
1228	   different systems, operating at different layers.  Some information
1229	   discussed in the preceding sections is only visible to an ISP, while
1230	   application-level performance can hardly be measured inside the
1231	   network.  It is possible that not all information of potential
1232	   interest can directly be measured, either because no corresponding
1233	   monitoring infrastructure or measurement method exists, or because it
1234	   is not easily accessible.

1236	   One way to quantify the benefit of deploying ALTO is to measure
1237	   before and after enabling the ALTO service.  In addition to passive
1238	   monitoring, some data could also be obtained by active measurements,
1239	   but due to the resulting overhead, the latter should be used with
1240	   care.  Yet, in all monitoring activities an ALTO service provider has
1241	   to take into account that ALTO clients are not bound to ALTO server
1242	   guidance as ALTO is only one source of information, and any
1243	   measurement result may thus be biased.

1245	   Potential sources for monitoring the use of ALTO include:

1247	   o  Network Operations, Administration, and Maintenance (OAM) systems:
1248	      Many ISPs deploy OAM systems to monitor the network traffic, which
1249	      may have insight into traffic volumes, network topology, and
1250	      bandwidth information inside the management area.  Data can be
1251	      obtained by SNMP, NETCONF, IP Flow Information Export (IPFIX),
1252	      syslog, etc.

1254	   o  Applications/clients: Relevant data could be obtained by
1255	      instrumentation of applications.

1257	   o  ALTO server: If available, log files or other statistics data
1258	      could be analyzed.

1260	   o  Other application entities: In several use cases, there are other
1261	      application entities that could provide data as well.  For
1262	      instance, there may be centralized log servers that collect data.

1264	   In many ALTO use cases some data sources are located within an ISP
1265	   network while some other data is gathered at application level.
1266	   Correlation of data could require a collaboration agreement between
1267	   the ISP and an application owner, including agreements of data
1268	   interchange formats, methods of delivery, etc.  In practice, such a
1269	   collaboration may not be possible in all use cases of ALTO, because
1270	   the monitoring data can be sensitive, and because the interacting
1271	   entities may have different priorities.  Details of how to build an
1272	   over-arching monitoring system for evaluating the benefits of ALTO
1273	   are outside the scope of this memo.

1275	3.5.  Map Examples for Different Types of ISPs

1277	3.5.1.  Small ISP with Single Internet Uplink

1279	   The ALTO protocol does not mandate how to determine costs between
1280	   endpoints and/or determine map data.  In complex usage scenarios this
1281	   can be a non-trivial problem.  In order to show the basic principle,
1282	   this and the following section explain for different deployment
1283	   scenarios how ALTO maps could be structured.

1285	   For a small ISP, the inter-domain traffic optimizing problem is how
1286	   to decrease the traffic exchanged with other ISPs, because of high
1287	   settlement costs.  By using the ALTO service to optimize traffic, a
1288	   small ISP can define two "optimization areas": one is its own
1289	   network; the other one consists of all other network destinations.
1290	   The cost map can be defined as follows: the cost of link between
1291	   clients of inner ISP's networks is lower than between clients of
1292	   outer ISP's networks and clients of inner ISP's network.  As a
1293	   result, a host with ALTO client inside the network of this ISP will
1294	   prefer retrieving data from hosts connected to the same ISP.

1296	   An example is given in Figure 10.  It is assumed that ISP A is a
1297	   small ISP only having one access network.  As operator of the ALTO
1298	   service, ISP A can define its network to be one optimization area,
1299	   named as PID1, and define other networks to be the other optimization
1300	   area, named as PID2.  C1 is denoted as the cost inside the network of
1301	   ISP A.  C2 is denoted as the cost from PID2 to PID1, and C3 from PID1
1302	   to PID2.  For the sake of simplifity, in the following C2=C3 is
1303	   assumed.  In order to keep traffic local inside ISP A, it makes sense
1304	   to define: C1<C2

1306	              -----------
1307	          ////           \\\\
1308	        //                   \\
1309	      //                       \\                  /-----------\
1310	     | +---------+               |             ////             \\\\
1311	     | | ALTO    |  ISP A        |    C2      |    Other Networks   |
1312	    |  | Service |  PID 1         <-----------     PID 2
1313	     | +---------+  C1           |----------->|                     |
1314	     |                           |  C3 (=C2)   \\\\             ////
1315	      \\                       //                  \-----------/
1316	        \\                   //
1317	          \\\\           ////
1318	              -----------

1320	             Figure 10: Example ALTO deployment in small ISPs

1322	   A simplified extract of the corresponding ALTO network and cost maps
1323	   is listed in Figure 11 and Figure 12, assuming that the network of
1324	   ISP A has the IPv4 address ranges 192.0.2.0/24 and 198.51.100.0/25.
1325	   In this example, the cost values C1 and C2 can be set to any number
1326	   C1<C2.

1328	      HTTP/1.1 200 OK
1329	      ...
1330	      Content-Type: application/alto-networkmap+json

1332	      {
1333	       ...
1334	        "network-map" : {
1335	          "PID1" : {
1336	            "ipv4" : [
1337	              "192.0.2.0/24",
1338	              "198.51.100.0/25"
1339	            ]
1340	          },
1341	          "PID2" : {
1342	            "ipv4" : [
1343	              "0.0.0.0/0"
1344	            ],
1345	            "ipv6" : [
1346	              "::/0"
1347	            ]
1348	          }
1349	        }
1350	      }

1352	                    Figure 11: Example ALTO network map

1354	      HTTP/1.1 200 OK
1355	      ...
1356	      Content-Type: application/alto-costmap+json

1358	      {
1359	          ...
1360	          "cost-type" : {"cost-mode"  : "numerical",
1361	                         "cost-metric": "routingcost"
1362	          }
1363	        },
1364	        "cost-map" : {
1365	          "PID1": { "PID1": C1,  "PID2": C2 },
1366	          "PID2": { "PID1": C2,  "PID2": 0 },
1367	        }
1368	      }

1370	                     Figure 12: Example ALTO cost map

1372	3.5.2.  ISP with Several Fixed Access Networks

1374	   This example discusses a P2P traffic optimization use case for a
1375	   lager ISP with a fixed network comprising several access networks and
1376	   a core network.  The traffic optimizing problems will include (1)
1377	   using the backbone network efficiently, (2) adjusting the traffic
1378	   balance in different access networks according to traffic conditions
1379	   and management policies, and (3) achieving a reduction of settlement
1380	   costs with other ISPs.

1382	   Such a large ISP deploying an ALTO service may want to optimize its
1383	   traffic according to the network topology of its access networks.
1384	   For example, each access network could be defined to be one
1385	   optimization area, i.e., traffic should be kept locally withing that
1386	   area if possible.  Then the costs between those access networks can
1387	   be defined according to a corresponding traffic optimizing
1388	   requirement by this ISP.  One example setup is further described
1389	   below and also shown in Figure 13.

1391	   In this example, ISP A has one backbone network and three access
1392	   networks, named as AN A, AN B, and AN C.  A P2P application is used
1393	   in this example.  For the traffic optimization, the first requirement
1394	   is to decrease the P2P traffic on the backbone network inside the
1395	   Autonomous System of ISP A; and the second requirement is to decrease
1396	   the P2P traffic to other ISPs, i.e., other Autonomous Systems.  The
1397	   second requirement can be assumed to have priority over the first
1398	   one.  Also, we assume that the settlement rate with ISP B is lower
1399	   than with other ISPs.  Then ISP A can deploy an ALTO service to meet
1400	   these traffic optimization requirements.  In the following, we will
1401	   give an example of an ALTO setting and configuration according to
1402	   these requirements.

1404	   In inner network of ISP A, we can define each access network to be
1405	   one optimization area, and assign one PID to each access network,
1406	   such as PID 1, PID 2, and PID 3.  Because of different peerings with
1407	   different outer ISPs, we define ISP B to be one optimization area,
1408	   and we assign PID 4 to it.  We define all other networks to be one
1409	   optimization area and assign PID 5 to it.

1411	   We assign costs (C1, C2, C3, C4, C5, C6, C7, C8) as shown in
1412	   Figure 13.  Cost C1 is denoted as the link cost in inner AN A (PID
1413	   1), and C2 and C3 are defined accordingly.  C4 is denoted as the link
1414	   cost from PID 1 to PID 2, and C5 is the corresponding cost from PID
1415	   3, which is assumed to have a similar value.  C6 is the cost between
1416	   PID 1 and PID 3.  For simplicity, we assume symmetrical costs between
1417	   the AN this example.  C7 is denoted as the link cost from the ISP B
1418	   to ISP A.  C8 is the link cost from other networks to ISP A.

1420	   According to previous discussion of the first requirement and the
1421	   second requirement, the relationship of these costs will be defined
1422	   as: (C1, C2, C3) < (C4, C5, C6) < (C7) < (C8)

1424	    +------------------------------------+         +----------------+
1425	    | ISP A   +---------------+          |         |                |
1426	    |         |    Backbone   |          |   C7    |      ISP B     |
1427	    |     +---+    Network    +----+     |<--------+      PID 4     |
1428	    |     |   +-------+-------+    |     |         |                |
1429	    |     |           |            |     |         |                |
1430	    |     |           |            |     |         +----------------+
1431	    | +---+--+     +--+---+     +--+---+ |
1432	    | |AN A  |  C4 |AN B  |  C5 |AN C  | |
1433	    | |PID 1 +<--->|PID 2 |<--->+PID 3 | |
1434	    | |C1    |     |C2    |     |C3    | |         +----------------+
1435	    | +---+--+     +------+     +--+---+ |         |                |
1436	    |     ^                        ^     |   C8    | Other Networks |
1437	    |     |                        |     |<--------+ PID 5          |
1438	    |     +------------------------+     |         |                |
1439	    |                  C6                |         |                |
1440	    +------------------------------------+         +----------------+

1442	    Figure 13: ALTO deployment in large ISPs with layered fixed network
1443	                                structures

1445	3.5.3.  ISP with Fixed and Mobile Network

1447	   An ISP with both mobile network and fixed network my focus on
1448	   optimizing the mobile traffic by keeping traffic in the fixed network
1449	   as far as possible, because wireless bandwidth is a scarce resource
1450	   and traffic is costly in mobile network.  In such a case, the main
1451	   requirement of traffic optimization could be decreasing the usage of
1452	   radio resources in the mobile network.  An ALTO service can be
1453	   deployed to meet these needs.

1455	   Figure 14 shows an example: ISP A operates one mobile network, which
1456	   is connected to a backbone network.  The ISP also runs two fixed
1457	   access networks AN A and AN B, which are also connected to the
1458	   backbone network.  In this network structure, the mobile network can
1459	   be defined as one optimization area, and PID 1 can be assigned to it.
1460	   Access networks AN A and B can also be defined as optimization areas,
1461	   and PID 2 and PID 3 can be assigned, respectively.  The cost values
1462	   are then defined as shown in Figure 14.

1464	   To decrease the usage of wireless link, the relationship of these
1465	   costs can be defined as follows:

1467	   From view of mobile network: C4 < C1.  This means that clients in
1468	   mobile network requiring data resource from other clients will prefer
1469	   clients in AN A to clients in the mobile network.  This policy can
1470	   decrease the usage of wireless link and power consumption in
1471	   terminals.

1473	   From view of AN A: C2 < C6, C5 = maximum cost.  This means that
1474	   clients in other optimization area will avoid retrieving data from
1475	   the mobile network.

1477	    +-----------------------------------------------------------------+
1478	    |                                                                 |
1479	    |  ISP A                 +-------------+                          |
1480	    |               +--------+   ALTO      +---------+                |
1481	    |               |        |   Service   |         |                |
1482	    |               |        +------+------+         |                |
1483	    |               |               |                |                |
1484	    |               |               |                |                |
1485	    |               |               |                |                |
1486	    |       +-------+-------+       | C6    +--------+------+         |
1487	    |       |     AN A      |<--------------|      AN B     |         |
1488	    |       |     PID 2     |   C7  |       |      PID 3    |         |
1489	    |       |     C2        |-------------->|      C3       |         |
1490	    |       +---------------+       |       +---------------+         |
1491	    |             ^    |            |              |     ^            |
1492	    |             |    |            |              |     |            |
1493	    |             |    |C4          |              |     |            |
1494	    |          C5 |    |            |              |     |            |
1495	    |             |    |   +--------+---------+    |     |            |
1496	    |             |    +-->|  Mobile Network  |<---+     |            |
1497	    |             |        |  PID 1           |          |            |
1498	    |             +------- |  C1              |----------+            |
1499	    |                      +------------------+                       |
1500	    +-----------------------------------------------------------------+

1502	          Figure 14: ALTO deployment in ISPs with mobile network

1504	   These examples show that for ALTO in particular the relations between
1505	   different costs matter; the operator of the server has several
1506	   degrees of freedom how to set the absolute values.

1508	3.6.  Deployment Experiences

1510	   The examples in the previous section are simple and do not consider
1511	   specific requirements inside access networks, such as different link
1512	   types.  Deploying an ALTO service in real network may require dealing
1513	   with further network conditions and requirements.  One real example
1514	   is described in greater detail in reference
1515	   [I-D.lee-alto-chinatelecom-trial].

1517	   Also, experiments have been conducted with ALTO-like deployments in
1518	   Internet Service Provider (ISP) networks.  For instance, NTT
1519	   performed tests with their HINT server implementation and dummy nodes
1520	   to gain insight on how an ALTO-like service influence peer-to-peer
1521	   systems [I-D.kamei-p2p-experiments-japan].  The results of an early
1522	   experiment conducted in the Comcast network are documented in
1523	   [RFC5632].

1525	4.  Using ALTO for P2P Traffic Optimization

1527	4.1.  Overview

1529	4.1.1.  Usage Scenario

1531	   Originally, peer-to-peer (P2P) applications have been the main driver
1532	   for the development of ALTO.  P2P systems can be build without and
1533	   with use of a centralized resource directory ("tracker").  The scope
1534	   of this section is the interaction of P2P applications with the ALTO
1535	   service, focusing on the use case with a centralized resource
1536	   directory.  In this scenario, the resource consumer ("peer") asks the
1537	   resource directory for a list of candidate resource providers, which
1538	   can provide the desired resource.

1540	   For efficiency reasons (i.e., message size), usually only a subset of
1541	   all resource providers known to the resource directory will be
1542	   returned to the resource consumer.  Some or all of these resource
1543	   providers, plus further resource providers learned by other means
1544	   such as direct communication between peers, will be contacted by the
1545	   resource consumer for accessing the resource.  The purpose of ALTO is
1546	   giving guidance on this peer selection, which is supposed to yield
1547	   better-than-random results.  The tracker response as well as the ALTO
1548	   guidance are most beneficial in the initial phase after the resource
1549	   consumer has decided to access a resource, as long as only few
1550	   resource providers are known.  Later, when the resource consumer has
1551	   already exchanged some data with other peers and measured the
1552	   transmission speed, the relative importance of ALTO may dwindle.

1554	4.1.2.  Applicability of ALTO

1556	   A tracker-based P2P application can leverage ALTO in different ways.
1557	   In the following, the different alternatives and their pros and cons
1558	   are discussed.

1560	                                 ,-------.
1561	          ,---.               ,-'         `-.   +-----------+
1562	       ,-'     `-.           /     ISP 1     \  |   Peer 1  |*****
1563	      /           \         / +-------------+ \ |           |    *
1564	     /    ISP X    \   +=====>| ALTO Server |  )+-----------+    *
1565	    /               \  =    \ +-------------+ / +-----------+    *
1566	   ; +-----------+   : =     \               /  |   Peer 2  |    *
1567	   | |  Tracker  |<====+      `-.         ,-'   |           |*****
1568	   | |ALTO Client|<====+         `-------'      +-----------+   **
1569	   | +-----------+   | =         ,-------.                      **
1570	   :        *        ; =      ,-'         `-.   +-----------+   **
1571	    \       *       /  =     /     ISP 2     \  |   Peer 3  |   **
1572	     \      *      /   =    / +-------------+ \ |           |*****
1573	      \     *     /    +=====>| ALTO Server |  )+-----------+  ***
1574	       `-.  *  ,-'          \ +-------------+ / +-----------+  ***
1575	          `-*-'              \               /  |   Peer 4  |*****
1576	            *                 `-.         ,-'   |           | ****
1577	            *                    `-------'      +-----------+ ****
1578	            *                                                 ****
1579	            *                                                 ****
1580	            ***********************************************<******
1581	       Legend:
1582	       === ALTO client protocol
1583	       *** Application protocol

1585	      Figure 15: Global tracker accessing ALTO server at various ISPs

1587	   Figure 15 depicts a tracker-based system in which the tracker embeds
1588	   the ALTO client.  The tracker itself is hosted and operated by an
1589	   entity different than the ISP hosting and operating the ALTO server.
1590	   A tracker outside the network of the ISP is the typical use case.
1591	   For instance, a tracker like Pirate Bay can serve Bittorrent peers
1592	   world-wide.  Initially, the tracker has to look-up the ALTO server in
1593	   charge for each peer where it receives a ALTO query for.  Therefore,
1594	   the ALTO server has to discover the handling ALTO server, as
1595	   described in [I-D.ietf-alto-server-discovery] [I-D.kist-alto-3pdisc].
1596	   However, the peers do not have any way to query the server
1597	   themselves.  This setting allows giving the peers a better selection
1598	   of candidate peers for their operation at an initial time, but does
1599	   not consider peers learned through direct peer-to-peer knowledge
1600	   exchange.  For instance, this is called peer exchange (PEX) in
1601	   bittorent.

1603	                            ,-------.         +-----------+
1604	          ,---.          ,-'         `-.  +==>|   Peer 1  |*****
1605	       ,-'     `-.      /     ISP 1     \ =   |ALTO Client|    *
1606	      /           \    / +-------------+<=+   +-----------+    *
1607	     /    ISP X    \   | + ALTO Server |<=+   +-----------+    *
1608	    /               \  \ +-------------+ /=   |   Peer 2  |    *
1609	   ;   +---------+   :  \               / +==>|ALTO Client|*****
1610	   |   | Global  |   |   `-.         ,-'      +-----------+   **
1611	   |   | Tracker |   |      `-------'                         **
1612	   |   +---------+   |      ,-------.         +-----------+   **
1613	   :        *        ;   ,-'         `-.  +==>|   Peer 3  |   **
1614	    \       *       /   /     ISP 2     \ =   |ALTO Client|*****
1615	     \      *      /   / +-------------+<=+   +-----------+  ***
1616	      \     *     /    | | ALTO Server |<=+   +-----------+  ***
1617	       `-.  *  ,-'     \ +-------------+ /=   |   Peer 4  |*****
1618	          `-*-'         \               / +==>|ALTO Client| ****
1619	            *            `-.         ,-'      +-----------+ ****
1620	            *               `-------'                       ****
1621	            *                                               ****
1622	            ***********************************************<****
1623	       Legend:
1624	       === ALTO client protocol
1625	       *** Application protocol

1627	             Figure 16: Global tracker and local ALTO servers

1629	   The scenario in Figure 16 lets the peers directly communicate with
1630	   their ISP's ALTO server (i.e., ALTO client embedded in the peers),
1631	   giving thus the peers the most control on which information they
1632	   query for, as they can integrate information received from trackers
1633	   and through direct peer-to-peer knowledge exchange.

1635	                             ,-------.         +-----------+
1636	           ,---.          ,-'  ISP 1  `-.  ***>|   Peer 1  |
1637	        ,-'     `-.      /+-------------+\ *   |           |
1638	       /           \    / +   Tracker   |<**   +-----------+
1639	      /    ISP X    \   | +-----===-----+<**   +-----------+
1640	     /               \  \ +-----===-----+ /*   |   Peer 2  |
1641	    ;   +---------+   :  \+ ALTO Server |/ ***>|           |
1642	    |   | Global  |   |   +-------------+      +-----------+
1643	    |   | Tracker |   |      `-------'
1644	    |   +---------+   |                        +-----------+
1645	    :          ^      ;      ,-------.         |   Peer 3  |
1646	     \         *     /    ,-'  ISP 2  `-.  ***>|           |
1647	      \        *    /    /+-------------+\ *   +-----------+
1648	       \       *   /    / +   Tracker   |<**   +-----------+
1649	        `-.    *,-'     | +-----===-----+ |    |   Peer 4  |<*
1650	           `---*        \ +-----===-----+ /    |           | *
1651	               *         \+ ALTO Server |/     +-----------+ *
1652	               *          +-------------+                    *
1653	               *             `-------'                       *
1654	               ***********************************************
1655	        Legend:
1656	        === ALTO client protocol
1657	        *** Application protocol

1659	     Figure 17: Local trackers and local ALTO servers (P4P approaach)

1661	   There are some attempts to let ISP's to deploy their own trackers, as
1662	   shown in Figure 17.  In this case, the client has no chance to get
1663	   guidance from the ALTO server, other than talking to the ISP's
1664	   tracker.  However, the peers would have still chance the contact
1665	   other trackers, deployed by entities other than the peer's ISP.

1667	4.2.  Deployment Recommendations

1669	4.2.1.  ALTO Services

1671	   The ALTO protocol specification [I-D.ietf-alto-protocol] details how
1672	   an ALTO client can query an ALTO server for guiding information and
1673	   receive the corresponding replies.  In case of peer-to-peer networks,
1674	   two different ALTO services can be used: The Cost Map Service is
1675	   often preferred as solution by peer-to-peer software implementors and
1676	   users, since it avoids disclosing peer IP addresses to a centralized
1677	   entity.  Different to that, network operators may have a preference
1678	   for the Endpoint Cost Service, since it does not require exposure of
1679	   the network topology.

1681	   For actual use of ALTO in P2P applications, both software vendors and
1682	   network operators have to agree which ALTO services to use.  The ALTO
1683	   protocol is flexible and supports both services.  Note that for other
1684	   use cases of ALTO, in particular in more controlled environments,
1685	   both the Cost Map Service as well as Endpoint Cost Service might be
1686	   feasible and it is more an engineering trade-off whether to use a
1687	   map-based or query-based ALTO service.

1689	4.2.2.  Guidance Considerations

1691	   As explained in Section 4.1.2, for a tracker-based P2P application
1692	   there are two fundamentally different possibilities where to place
1693	   the ALTO client:

1695	   1.  ALTO client in the resource consumer ("peer")

1697	   2.  ALTO client in the resource directory ("tracker")

1699	   Both approaches have advantages and drawbacks that have to be
1700	   considered.  If the ALTO client is in the resource consumer
1701	   (Figure 16), a potentially very large number of clients has to be
1702	   deployed.  Instead, when using an ALTO client in the resource
1703	   directory (Figure 15 and Figure 17), ostensibly peers do not have to
1704	   directly query the ALTO server.  In this case, an ALTO server could
1705	   even not permit access to peers.

1707	   However, it seems to be beneficial for all participants to let the
1708	   peers directly query the ALTO server.  Considering the plethora of
1709	   different applications that could use ALTO, e.g. multiple tracker or
1710	   non-tracker based P2P systems or other applications searching for
1711	   relays, this renders the ALTO service more useful.  The peers are
1712	   also the single point having all operational knowledge to decide
1713	   whether to use the ALTO guidance and how to use the ALTO guidance.
1714	   For a given peer one can also expect that an ALTO server of the
1715	   corresponding ISP provides useful guidance and can be discovered.

1717	   Yet, ALTO clients in the resource consumer also have drawbacks
1718	   compared to use in the resource directory.  In the following, both
1719	   scenarios are compared more in detail in order to explain the impact
1720	   on ALTO guidance and the need for third-party ALTO queries.

1722	   In the first scenario (see Figure 18), the resource consumer queries
1723	   the resource directory for the desired resource (F1).  The resource
1724	   directory returns a list of potential resource providers without
1725	   considering ALTO (F2).  It is then the duty of the resource consumer
1726	   to invoke ALTO (F3/F4), in order to solicit guidance regarding this
1727	   list.

1729	   Peer w. ALTO cli.            Tracker               ALTO Server
1730	   --------+--------       --------+--------       --------+--------
1731	           | F1 Tracker query      |                       |
1732	           |======================>|                       |
1733	           | F2 Tracker reply      |                       |
1734	           |<======================|                       |
1735	           | F3 ALTO client protocol query                 |
1736	           |---------------------------------------------->|
1737	           | F4 ALTO client protocol reply                 |
1738	           |<----------------------------------------------|
1739	           |                       |                       |

1741	   ====  Application protocol (i.e., tracker-based P2P app protocol)
1742	   ----  ALTO client protocol

1744	      Figure 18: Basic message sequence chart for resource consumer-
1745	                           initiated ALTO query

1747	   In the second scenario (see Figure 19), the resource directory has an
1748	   embedded ALTO client, which we will refer to as Resource Directory
1749	   ALTO Client (RDAC) in this document.  After receiving a query for a
1750	   given resource (F1) the resource directory invokes the RDAC to
1751	   evaluate all resource providers it knows (F2/F3).  Then it returns a,
1752	   possibly shortened, list containing the "best" resource providers to
1753	   the resource consumer (F4).

1755	         Peer               Tracker w. RDAC           ALTO Server
1756	   --------+--------       --------+--------       --------+--------
1757	           | F1 Tracker query      |                       |
1758	           |======================>|                       |
1759	           |                       | F2 ALTO cli. p. query |
1760	           |                       |---------------------->|
1761	           |                       | F3 ALTO cli. p. reply |
1762	           |                       |<----------------------|
1763	           | F4 Tracker reply      |                       |
1764	           |<======================|                       |
1765	           |                       |                       |

1767	   ====  Application protocol (i.e., tracker-based P2P app protocol)
1768	   ----  ALTO client protocol

1770	    Figure 19: Basic message sequence chart for third-party ALTO query

1772	   Note: The message sequences depicted in Figure 18 and Figure 19 may
1773	   occur both in the target-aware and the target-independent query mode
1774	   (cf.  [RFC6708]).  In the target-independent query mode no message
1775	   exchange with the ALTO server might be needed after the tracker
1776	   query, because the candidate resource providers could be evaluated
1777	   using a locally cached "map", which has been retrieved from the ALTO
1778	   server some time ago.

1780	   The first approach has the following problem: While the resource
1781	   directory might know thousands of peers taking part in a swarm, the
1782	   list returned to the resource consumer is usually shortened for
1783	   efficiency reasons.  Therefore, the "best" (in the sense of ALTO)
1784	   potential resource providers might not be contained in that list
1785	   anymore, even before ALTO can consider them.

1787	   Much better traffic optimization could be achieved if the tracker
1788	   would evaluate all known peers using ALTO.  This list would then
1789	   include a significantly higher fraction of "good" peers.  (If the
1790	   tracker returned "good" peers only, there might be a risk that the
1791	   swarm might disconnect and split into several disjunct partitions.
1792	   However, finding the right mix of ALTO-biased and random peer
1793	   selection is out of the scope of this document.)

1795	   Therefore, from an overall optimization perspective, the second
1796	   scenario with the ALTO client embedded in the resource directory is
1797	   advantageous, because it is ensured that the addresses of the "best"
1798	   resource providers are actually delivered to the resource consumer.
1799	   An architectural implication of this insight is that the ALTO server
1800	   discovery procedures must support third-party discovery.  That is, as
1801	   the tracker issues ALTO queries on behalf of the peer which contacted
1802	   the tracker, the tracker must be able to discover an ALTO server that
1803	   can give guidance suitable for that respective peer (see
1804	   [I-D.kist-alto-3pdisc]).

1806	5.  Using ALTO for CDNs

1808	5.1.  Overview

1810	5.1.1.  Usage Scenario

1812	   This section briefly introduces the usage of ALTO for Content
1813	   Delivery Networks (CDNs), as explained e.g. in
1814	   [I-D.jenkins-alto-cdn-use-cases].  CDNs are used in the delivery of
1815	   some Internet services (e.g. delivery of websites, software updates
1816	   and video delivery) from a location closer to the location of the
1817	   user.  A CDN typically consists of a network of servers often
1818	   attached to Network Service Provider (NSP) networks.  The point of
1819	   attachment is often as close to content consumers and peering points
1820	   as economically or operationally feasible in order to decrease
1821	   traffic load on the NSP backbone and to provide better user
1822	   experience measured by reduced latency and higher throughput.

1824	   CDNs use several techniques to redirect a client to a server
1825	   (surrogate).  A request routing function within a CDN is responsible
1826	   for receiving content requests from user agents, obtaining and
1827	   maintaining necessary information about a set of candidate
1828	   surrogates, and for selecting and redirecting the user agent to the
1829	   appropriate surrogate.  One common way is relying on the DNS system,
1830	   but there are many other ways, see [RFC3568].

1832	   In order to derive the optimal benefit from a CDN it is preferable to
1833	   deliver content from the servers (caches) that are "closest" to the
1834	   end user requesting the content. "closest" may be as simple as
1835	   geographical or IP topology distance, but it may also consider other
1836	   combinations of metrics and CDN or Network Service Provider (NSP)
1837	   policies.

1839	   User Agent                  Request Router                 Surrogate
1840	        |                             |                           |
1841	        |     F1 Initial Request      |                           |
1842	        +---------------------------->|                           |
1843	        |                             +--+                        |
1844	        |                             |  | F2 Surrogate Selection |
1845	        |                             |<-+       (using ALTO)     |
1846	        |   F3 Redirection Response   |                           |
1847	        |<----------------------------+                           |
1848	        |                             |                           |
1849	        |     F4 Content Request      |                           |
1850	        +-------------------------------------------------------->|
1851	        |                             |                           |
1852	        |                             |          F5 Content       |
1853	        |<--------------------------------------------------------+
1854	        |                             |                           |

1856	               Figure 20: Example of CDN surrogate selection

1858	   Figure 20 illustrates the interaction between a user agent, a request
1859	   router, and a surrogate for the delivery of content in a single CDN.
1860	   As explained in [I-D.jenkins-alto-cdn-use-cases], the user agent
1861	   makes an initial request to the CDN (F1).  This may be an
1862	   application-level request (e.g., HTTP) or a DNS request.  In the
1863	   second step (F2), the request router selects an appropriate surrogate
1864	   (or set of surrogates) based on the user agent's (or its proxy's) IP
1865	   address, the request router's knowledge of the network topology
1866	   (which can be obtained by ALTO) and reachability cost between CDN
1867	   caches and end users, and any additional CDN policies.  Then (F3),
1868	   the request router responds to the initial request with an
1869	   appropriate response containing a redirection to the selected cache,
1870	   for example by returning an appropriate DNS A/AAAA record, a HTTP 302
1871	   redirect, etc.  The user agent uses this information to connect
1872	   directly to the surrogate and request the desired content (F4), which
1873	   is then delivered (F5).

1875	5.1.2.  Applicability of ALTO

1877	   The most simple use case for ALTO in a CDN context is to improve the
1878	   selection of a CDN surrogate or origin.  In this case, the CDN makes
1879	   use of an ALTO server to choose a better CDN surrogate or origin than
1880	   would otherwise be the case.  Although it is possible to obtain raw
1881	   network map and cost information in other ways, for example passively
1882	   listening to the NSP's routing protocols or use of active probing,
1883	   the use of an ALTO service to expose that information may provide
1884	   additional control to the NSP over how their network map/cost is
1885	   exposed.  Additionally it may enable the NSP to maintain a functional
1886	   separation between their routing plane and network map computation
1887	   functions.  This may be attractive for a number of reasons, for
1888	   example:

1890	   o  The ALTO service could provide a filtered view of the network and/
1891	      or cost map that relates to CDN locations and their proximity to
1892	      end users, for example to allow the NSP to control the level of
1893	      topology detail they are willing to share with the CDN.

1895	   o  The ALTO service could apply additional policies to the network
1896	      map and cost information to provide a CDN-specific view of the
1897	      network map/cost, for example to allow the NSP to encourage the
1898	      CDN to use network links that would not ordinarily be preferred by
1899	      a Shortest Path First routing calculation.

1901	   o  The routing plane may be operated and controlled by a different
1902	      operational entity (even within a single NSP) to the CDN.
1903	      Therefore, the CDN may not be able to passively listen to routing
1904	      protocols, nor may it have access to other network topology data
1905	      (e.g., inventory databases).

1907	   When CDN servers are deployed outside of an NSP's network or in a
1908	   small number of central locations within an NSP's network, a
1909	   simplified view of the NSP's topology or an approximation of
1910	   proximity is typically sufficient to enable the CDN to serve end
1911	   users from the optimal server/location.  As CDN servers are deployed
1912	   deeper within NSP networks it becomes necessary for the CDN to have
1913	   more detailed knowledge of the underlying network topology and costs
1914	   between network locations in order to enable the CDN to serve end
1915	   users from the most optimal servers for the NSP.

1917	   The request router in a CDN will typically also take into account
1918	   criteria and constraints that are not related to network topology,
1919	   such as the current load of CDN surrogates, content owner policies,
1920	   end user subscriptions, etc.  This document only discusses use of
1921	   ALTO for network information.

1923	   A general issue for CDNs is that the CDN logic has to match the
1924	   client's IP address with the closest CDN surrogate, both for DNS or
1925	   HTTP redirect based approaches (see, for instance,
1926	   [I-D.penno-alto-cdn]).  This matching is not trivial, for instance,
1927	   in DNS based approaches, where the IP address of the DNS original
1928	   requester is unknown (see [I-D.vandergaast-edns-client-ip] for a
1929	   discussion of this and a solution approach).

1931	   In addition to use by a single CDN, ALTO can also be used in
1932	   scenarios that interconnect several CDNs.  This use case is detailed
1933	   in [I-D.seedorf-cdni-request-routing-alto].

1935	5.2.  Deployment Recommendations

1937	5.2.1.  ALTO Services

1939	   In its simplest form an ALTO server would provide an NSP with the
1940	   capability to offer a service to a CDN that provides network map and
1941	   cost information.  The CDN can use that data to enhance its surrogate
1942	   and/or origin selection.  If an NSP offers an ALTO network and cost
1943	   map service to expose a cost mapping/ranking between end user IP
1944	   subnets (within that NSP's network) and CDN surrogate IP subnets/
1945	   locations, periodic updates of the maps may be needed.  As introduced
1946	   in Section 3.3), it is common for broadband subscribers to obtain
1947	   their IP addresses dynamically and in many deployments the IP subnets
1948	   allocated to a particular network region can change relatively
1949	   frequently, even if the network topology itself is reasonably static.

1951	   An alternative would be to use the ALTO Endpoint Cost Service (ECS):
1952	   When an end user request a given content, the CDN request router
1953	   issues an ECS request with the endpoint address (IPv4/IPv6) of the
1954	   end user (content requester) and the set of endpoint addresses of the
1955	   surrogate (content targets).  The ALTO server receives the request
1956	   and ranks the list of content targets addresses based on their
1957	   distance from the content requester.  Once the request router
1958	   obtained from the ALTO Server the ranked list of locations (for the
1959	   specific user), it can incorporate this information into its
1960	   selection mechanisms in order to point the user to the most
1961	   appropriate surrogate.

1963	   Since CDNs operate in a controlled environment, the ALTO network/cost
1964	   map service and ECS have a similar level of security and
1965	   confidentiality of network-internal information.  However, the
1966	   network/cost map service and ECS differ in the way the ALTO service
1967	   is delivered and address a different set of requirements in terms of
1968	   topology information and network operations.

1970	   If a CDN already has means to model connectivity policies, the map-
1971	   based approaches could possibly be integrated into that.  If the ECS
1972	   service is preferred, a request router that uses ECS could cache the
1973	   results of ECS queries for later usage in order to address the
1974	   scalability limitations of ECS and to reduce the number of
1975	   transactions between CDN and ALTO server.  The ALTO server may
1976	   indicate in the reply message how long the content of the message is
1977	   to be considered reliable and insert a lifetime value that will be
1978	   used by the CDN in order to cache (and then flush or refresh) the
1979	   entry.

1981	5.2.2.  Guidance Considerations

1983	   In the following it is discussed how a CDN could make use of ALTO
1984	   services.

1986	   In one deployment scenario, ALTO could expose NSP end user
1987	   reachability to a CDN.  The request router needs to have information
1988	   which end user IP subnets are reachable via which networks or network
1989	   locations.  The network map services offered by ALTO could be used to
1990	   expose this topology information while avoiding routing plane peering
1991	   between the NSP and the CDN.  For example, if CDN surrogates are
1992	   deployed within the access or aggregation network, the NSP is likely
1993	   to want to utilize the surrogates deployed in the same access/
1994	   aggregation region in preference to surrogates deployed elsewhere, in
1995	   order to alleviate the cost and/or improve the user experience.

1997	   In addition, CDN surrogates could also use ALTO guidance, e.g., if
1998	   there is more than one upstream source of content or several origins.
1999	   In this case, ALTO could help a surrogate with the decision which
2000	   upstream source to use.  This specific variant of using ALTO is not
2001	   further detailed in this document.

2003	   If content can be provided by several CDNs, there may be a need to
2004	   interconnect these CDNs.  In this case, ALTO can be uses as interface
2005	   [I-D.seedorf-cdni-request-routing-alto], in particular for footprint
2006	   and capabilities advertisement interface.

2008	   Other and more advanced scenarios of deploying ALTO are also listed
2009	   in [I-D.jenkins-alto-cdn-use-cases] and [I-D.penno-alto-cdn].

2011	   The granularity of ALTO information required depends on the specific
2012	   deployment of the CDN.  For example, an over-the-top CDN whose
2013	   surrogates are deployed only within the Internet "backbone" may only
2014	   require knowledge of which end user IP subnets are reachable via
2015	   which NSPs' networks, whereas a CDN deployed within a particular
2016	   NSP's network requires a finer granularity of knowledge.

2018	   ALTO server ranks addresses based on topology information it acquires
2019	   from the network.  By default, according to [I-D.ietf-alto-protocol],
2020	   distance in ALTO represents an abstract routing cost that can be
2021	   computed from routing protocol information (e.g., OSPF, ISIS, BGP).
2022	   But an ALTO server may also take into consideration other routing
2023	   criteria such as MPLS-VPN (MP-BGP) and MPLS-TE (RSVP) information, or
2024	   other information sources for policy, state, and performance
2025	   information (e.g., geo-location), as explained in Section 3.2.1.

2027	   The different methods and algorithms through which the ALTO server
2028	   computes topology information and rankings is out of the scope of
2029	   this document.  However, if rankings are based on routing protocol
2030	   information, it is obvious that network events may impact the ranking
2031	   computation.  Due to internal redundancy and resilience mechanisms
2032	   inside current networks, most of the network events happening in the
2033	   infrastructure will be handled internally in the network, and they
2034	   should have limited impact on a CDN.  However, catastrophic events
2035	   such as main trunks failures or backbone partitioning will have to
2036	   take into account by the ALTO server to redirect traffic away from
2037	   the impacted area.

2039	   An ALTO server implementation may want to keep state about ALTO
2040	   clients so to inform and signal to these clients when a major network
2041	   event happened.  In a CDN/ALTO interworking architecture with few CDN
2042	   components interacting with the ALTO server there are less
2043	   scalability issues in maintaining state about clients in the ALTO
2044	   server, compared to ALTO guidance to any Internet user.  However,
2045	   such a notification mechanism requires a corresponding notification
2046	   mechanism in the ALTO protocol.

2048	6.  Other Use Cases

2050	   This section briefly surveys and references other use cases that have
2051	   been tested or suggested for ALTO deployments.

2053	6.1.  Application Guidance in Virtual Private Networks (VPNs)

2055	   Virtual Private Network (VPN) technology is widely used in public and
2056	   private networks to create groups of users that are separated from
2057	   other users of the network and allows these users to communicate
2058	   among them as if they were on a private network.  Network Service
2059	   Providers (NSPs) offer different types of VPNs.  [RFC4026]
2060	   distinguishes between Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN)
2061	   using different sub-types.  In the following, the term "VPN" is used
2062	   to refer to provider supplied virtual private networking.

2064	   From the perspective of an application at an endpoint, a VPN may not
2065	   be very different to any other IP connectivity solution, but there
2066	   are a number of specific applications that could benefit from ALTO
2067	   topology exposure and guidance in VPNs.  Similar like in the general
2068	   Internet, one advantage is that applications do not have to perform
2069	   excessive measurements on their own.  For instance, potential use
2070	   cases for ALTO application guidance in VPNs environments are:

2072	   o  Enterprise application optimization: Enterprise customers often
2073	      run distributed applications that exchange large amounts of data,
2074	      e.g., for synchronization of replicated data bases.  Both for
2075	      placement of replicas as well as for the scheduling of transfers
2076	      insight into network topology information could be useful.

2078	   o  Private cloud computing solution: An enterprise customer could run
2079	      own data centers at the four sites.  The cloud management system
2080	      could want to understand the network costs between different sites
2081	      for intelligent routing and placement decisions of Virtual
2082	      Machines (VMs) among the VPN sites.

2084	   o  Cloud-bursting: One or more VPN endpoints could be located in a
2085	      public cloud.  If an enterprise customer needs additional
2086	      resources, they could be provided by a public cloud, which is
2087	      accessed through the VPN.  Network topology awareness would help
2088	      to decide in which data center of the public cloud those resources
2089	      should be allocated.

2091	   These examples focus on enterprises, which are typical users of VPNs.
2092	   VPN customers typically have no insight into the network topology
2093	   that transports the VPN.  Similar like in other ALTO use cases,
2094	   better-than-random application-level decisions would be enabled by an
2095	   ALTO server offered by the NSP, as illustrated in Figure Figure 21.

2097	                       +---------------+
2098	                       |  Customer's   |
2099	                       |   management  |
2100	                       |  application  |.
2101	                       | (ALTO client) |  .
2102	                       +---------------+    .  VPN provisioning
2103	                               ^              . (out-of-scope)
2104	                               | ALTO           .
2105	                               V                  .
2106	                    +---------------------+       +----------------+
2107	                    |     ALTO server     |       | VPN portal/OSS |
2108	                    |   provided by NSP   |       | (out-of-scope) |
2109	                    +---------------------+       +----------------+
2110	                               ^ VPN network
2111	                               * and cost maps
2112	                               *
2113	                     /---------*---------\ Network service provider
2114	                     |         *         |
2115	        +-------+   _______________________   +-------+
2116	        | App a | ()_____. .________. .____() | App d |
2117	        +-------+    |   | |        | |  |    +-------+
2118	                     \---| |--------| |--/
2119	                         | |        | |
2120	                         |^|        |^| Customer VPN
2121	                          V          V
2122	                      +-------+  +-------+
2123	                      | App b |  | App c |
2124	                      +-------+  +-------+

2126	                       Figure 21: Using ALTO in VPNs

2128	   A common characteristic of these use cases is that applications will
2129	   not necessarily run in the public Internet, and that the relationship
2130	   between the provider and customer of the VPN is rather well-defined.
2131	   Since VPNs run often in a managed environment, an ALTO server may
2132	   have access to topology information (e.g., traffic engineering data)
2133	   that would not be available for the public Internet, and it may
2134	   expose it to the customer of the VPN only.

2136	   Also, a VPN will not necessarily be static.  The customer could
2137	   possibly modify the VPN and add new VPN sites by a Web portal,
2138	   network management systems, or other Operation Support Systems (OSS)
2139	   solutions.  Prior to adding a new VPN site, an application will not
2140	   be have connectivity to that site, i.e., an ALTO server could offer
2141	   access to information that an application cannot measure on its own
2142	   (e.g., expected delay to a new VPN site).

2144	   The VPN use cases, requirements, and solutions are further detailed
2145	   in [I-D.scharf-alto-vpn-service].

2147	6.2.  In-Network Caching

2149	   Deployment of intra-domain P2P caches has been proposed for a
2150	   cooperations between the network operator and the P2P service
2151	   providers, e.g., to reduce the bandwidth consumption in access
2152	   networks [I-D.deng-alto-p2pcache].

2154	      +--------------+                +------+
2155	      | ISP 1 network+----------------+Peer 1|
2156	      +-----+--------+                +------+
2157	      |
2158	   +--------+------------------------------------------------------+
2159	   |        |                                      ISP 2 network   |
2160	   |  +---------+                                                  |
2161	   |  |L1 Cache |                                                  |
2162	   |  +-----+---+                                                  |
2163	   |        +--------------------+----------------------+          |
2164	   |        |                    |                      |          |
2165	   | +------+------+      +------+-------+       +------+-------+  |
2166	   | | AN1         |      | AN2          |       | AN3          |  |
2167	   | | +---------+ |      | +----------+ |       |              |  |
2168	   | | |L2 Cache | |      | |L2 Cache  | |       |              |  |
2169	   | | +---------+ |      | +----------+ |       |              |  |
2170	   | +------+------+      +------+-------+       +------+-------+  |
2171	   |        |                                           |          |
2172	   |        +--------------------+                      |          |
2173	   |        |                    |                      |          |
2174	   | +------+------+      +------+-------+       +------+-------+  |
2175	   | | SUB-AN11    |      | SUB-AN12     |       | SUB-AN31     |  |
2176	   | | +---------+ |      |              |       |              |  |
2177	   | | |L3 Cache | |      |              |       |              |  |
2178	   | | +---------+ |      |              |       |              |  |
2179	   | +------+------+      +------+-------+       +------+-------+  |
2180	   |        |                    |                      |          |
2181	   +--------+--------------------+----------------------+----------+
2182	            |                    |                      |
2183	        +---+---+            +---+---+                  |
2184	        |       |            |       |                  |
2185	     +--+--+ +--+--+      +--+--+ +--+--+            +--+--+
2186	     |Peer2| |Peer3|      |Peer4| |Peer5|            |Peer6|
2187	     +-----+ +-----+      +-----+ +-----+            +-----+

2189	            Figure 22: General architecture of intra-ISP caches

2191	   Figure 22 depicts the overall architecture of a potential P2P cache
2192	   deployments inside an ISP 2 with various access network types.  As
2193	   shown in the figure, P2P caches may be deployed at various levels,
2194	   including the interworking gateway linking with other ISPs, internal
2195	   access network gateways linking with different types of accessing
2196	   networks (e.g.  WLAN, cellular and wired), and even within an
2197	   accessing network at the entries of individual WLAN sub-networks.
2198	   Moreover, depending on the network context and the operator's policy,
2199	   each cache can be a Forwarding Cache or a Bidirectional Cache
2200	   [I-D.deng-alto-p2pcache].

2202	   In such a cache architecture, the locations of caches could be used
2203	   as dividers of different PIDs to guide intra-ISP network abstraction
2204	   and mark costs among them according to the location and type of
2205	   relevant caches.

2207	   Further details and deployment considerations can be found in
2208	   [I-D.deng-alto-p2pcache].

2210	7.  Security Considerations

2212	   The ALTO protocol specification [I-D.ietf-alto-protocol] discusses
2213	   risk and protection strategies for the authenticity and integrity of
2214	   ALTO Information, a potential undesirable guidance from authenticated
2215	   ALTO information, the confidentiality of ALTO information, the
2216	   privacy of ALTO users, and the availability of the ALTO service.  All
2217	   those issues and potential countermeasures have to be taken into
2218	   account when deploying an ALTO service.

2220	   The following subsection further detail security issues resulting
2221	   from specific uses of ALTO as discussed in this document.

2223	7.1.  Information Leakage from the ALTO Server

2225	   The ALTO server will be provisioned with information about the ISP's
2226	   network and very likely also with information about neighboring ISPs.
2227	   This information (e.g., network topology, business relations, etc.)
2228	   is considered to be confidential to the ISP and can include very
2229	   sensitive information.

2231	   The ALTO server will naturally reveal parts of that information in
2232	   small doses to clients, as the guidance given will depend on the
2233	   above mentioned information.  This is seen beneficial for both
2234	   parties, i.e., the ISPs and the clients.  However, there is the
2235	   chance that one or multiple clients are querying an ALTO server with
2236	   the goal to gather information about network topology or any other
2237	   data considered confidential or at least sensitive.  It is unclear
2238	   whether this is a real technical security risk or whether this is
2239	   more a perceived security risk.  In controlled environments (e.g., in
2240	   the CDN use case) bilateral agreements could be used to reduce the
2241	   risk of abuse.

2243	   ALTO does not require any particular level of details of information
2244	   disclosure, and hence the provider should evaluate how much
2245	   information is revealed and the associated risks.

2247	7.2.  ALTO Server Access

2249	   Depending on the use case of ALTO, it may be desired to apply access
2250	   restrictions to an ALTO server, i.e., by requiring client
2251	   authentication.  According to [I-D.ietf-alto-protocol], ALTO requires
2252	   that HTTP Digestion Authentication is supported, in order to achieve
2253	   client authentication and possibly to limit the number of parties
2254	   with whom ALTO information is directly shared.  TLS Client
2255	   Authentication may also be supported.

2257	   For peer-to-peer applications, a potential deployment scenario is
2258	   that an ALTO server is solely accessible by peers from the ISP
2259	   network (as shown in Figure 16).  For instance, the source IP address
2260	   can be used to grant only access from that ISP network to the server.
2261	   This will "limit" the number of peers able to attack the server to
2262	   the user's of the ISP (however, including botnet computers).

2264	   If the ALTO server has to be accessible by parties not located in the
2265	   ISP's network (see Figure 15), e.g., by a third-party tracker or by a
2266	   CDN system outside the ISP's network, the access restrictions have to
2267	   be looser.  In the extreme case, i.e., no access restrictions, each
2268	   and every host in the Internet can access the ALTO server.  This
2269	   might no be the intention of the ISP, as the server is not only
2270	   subject to more possible attacks, but also the server load could
2271	   increase, since possibly more ALTO clients have to be served.

2273	   There are also use cases where the access to the ALTO server has to
2274	   be much more strictly controlled, i. e., where an authentication and
2275	   authorization of the ALTO client to the server may be needed.  For
2276	   instance, in case of CDN optimization the provider of an ALTO service
2277	   as well as potential users are possibly well-known.  Only CDN
2278	   entities may need ALTO access; access to the ALTO servers by
2279	   residential users may neither be necessary nor be desired.

2281	   Access control can also help to prevent Denial-of-Service attacks by
2282	   arbitrary hosts from the Internet.  Denial of Service (DoS) can both
2283	   affect an ALTO server and an ALTO client.  A server can get
2284	   overloaded if too many requests hit the server, or if the query load
2285	   of the server surpasses the maximum computing capacity.  An ALTO
2286	   client can get overloaded if the responses from the sever are, either
2287	   intentionally or due to an implementation mistake, too large to be
2288	   handled by that particular client.

2290	7.3.  Faking ALTO Guidance

2292	   It has not yet been investigated how a faked or wrong ALTO guidance
2293	   by an ALTO server can impact the operation of the network and also
2294	   the applications, e.g., a peer-to-peer applications.

2296	   Here is a list of examples how the ALTO guidance could be faked and
2297	   what possible consequences may arise:

2299	   Sorting:  An attacker could change to sorting order of the ALTO
2300	      guidance (given that the order is of importance, otherwise the
2301	      ranking mechanism is of interest), i.e., declaring peers located
2302	      outside the ISP as peers to be preferred.  This will not pose a
2303	      big risk to the network or peers, as it would mimic the "regular"
2304	      peer operation without traffic localization, apart from the
2305	      communication/processing overhead for ALTO.  However, it could
2306	      mean that ALTO is reaching the opposite goal of shuffling more
2307	      data across ISP boundaries, incurring more costs for the ISP.

2309	   Preference of a single peer:  A single IP address (thus a peer) could
2310	      be marked as to be preferred all over other peers.  This peer can
2311	      be located within the local ISP or also in other parts of the
2312	      Internet (e.g., a web server).  This could lead to the case that
2313	      quite a number of peers to trying to contact this IP address,
2314	      possibly causing a Denial of Service (DoS) attack.

2316	8.  IANA Considerations

2318	   This document makes no specific request to IANA.

2320	9.  Conclusion

2322	   This document discusses how the ALTO protocol can be deployed in
2323	   different use cases and provides corresponding guidance and
2324	   recommendations to network administrators and application developers.

2326	10.  References

2328	10.1.  Normative References

2330	   [I-D.ietf-alto-protocol]
2331	              Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-
2332	              ietf-alto-protocol-27 (work in progress), March 2014.

2334	   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
2335	              Optimization (ALTO) Problem Statement", RFC 5693, October
2336	              2009.

2338	   [RFC6708]  Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
2339	              Y. Yang, "Application-Layer Traffic Optimization (ALTO)
2340	              Requirements", RFC 6708, September 2012.

2342	10.2.  Informative References

2344	   [I-D.deng-alto-p2pcache]
2345	              Lingli, D., Chen, W., Yi, Q., and Y. Zhang,
2346	              "Considerations for ALTO with network-deployed P2P
2347	              caches", draft-deng-alto-p2pcache-03 (work in progress),
2348	              February 2014.

2350	   [I-D.farrkingel-pce-abno-architecture]
2351	              King, D. and A. Farrel, "A PCE-based Architecture for
2352	              Application-based Network Operations", draft-farrkingel-
2353	              pce-abno-architecture-07 (work in progress), February
2354	              2014.

2356	   [I-D.ietf-alto-server-discovery]
2357	              Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
2358	              S. Yongchao, "ALTO Server Discovery", draft-ietf-alto-
2359	              server-discovery-10 (work in progress), September 2013.

2361	   [I-D.ietf-i2rs-architecture]
2362	              Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
2363	              Nadeau, "An Architecture for the Interface to the Routing
2364	              System", draft-ietf-i2rs-architecture-04 (work in
2365	              progress), June 2014.

2367	   [I-D.ietf-idr-ls-distribution]
2368	              Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
2369	              Ray, "North-Bound Distribution of Link-State and TE
2370	              Information using BGP", draft-ietf-idr-ls-distribution-05
2371	              (work in progress), May 2014.

2373	   [I-D.jenkins-alto-cdn-use-cases]
2374	              Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and
2375	              S. Previdi, "Use Cases for ALTO within CDNs", draft-
2376	              jenkins-alto-cdn-use-cases-03 (work in progress), June
2377	              2012.

2379	   [I-D.kamei-p2p-experiments-japan]
2380	              Kamei, S., Momose, T., Inoue, T., and T. Nishitani, "ALTO-
2381	              Like Activities and Experiments in P2P Network Experiment
2382	              Council", draft-kamei-p2p-experiments-japan-09 (work in
2383	              progress), October 2012.

2385	   [I-D.kiesel-alto-h12]
2386	              Kiesel, S. and M. Stiemerling, "ALTO H12", draft-kiesel-
2387	              alto-h12-02 (work in progress), March 2010.

2389	   [I-D.kist-alto-3pdisc]
2390	              Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party
2391	              ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05
2392	              (work in progress), January 2014.

2394	   [I-D.lee-alto-chinatelecom-trial]
2395	              Li, K. and G. Jian, "ALTO and DECADE service trial within
2396	              China Telecom", draft-lee-alto-chinatelecom-trial-04 (work
2397	              in progress), March 2012.

2399	   [I-D.penno-alto-cdn]
2400	              Penno, R., Medved, J., Alimi, R., Yang, R., and S.
2401	              Previdi, "ALTO and Content Delivery Networks", draft-
2402	              penno-alto-cdn-03 (work in progress), March 2011.

2404	   [I-D.scharf-alto-vpn-service]
2405	              Scharf, M., Gurbani, V., Soprovich, G., and V. Hilt, "The
2406	              Virtual Private Network (VPN) Service in ALTO: Use Cases,
2407	              Requirements and Extensions", draft-scharf-alto-vpn-
2408	              service-02 (work in progress), February 2014.

2410	   [I-D.seedorf-cdni-request-routing-alto]
2411	              Seedorf, J., Yang, Y., and J. Peterson, "CDNI Footprint
2412	              and Capabilities Advertisement using ALTO", draft-seedorf-
2413	              cdni-request-routing-alto-07 (work in progress), June
2414	              2014.

2416	   [I-D.vandergaast-edns-client-ip]
2417	              Contavalli, C., Gaast, W., Leach, S., and D. Rodden,
2418	              "Client IP information in DNS requests", draft-
2419	              vandergaast-edns-client-ip-01 (work in progress), May
2420	              2010.

2422	   [I-D.wu-alto-te-metrics]
2423	              Wu, W., Yang, Y., Lee, Y., Dhody, D., and S. Randriamasy,
2424	              "ALTO Traffic Engineering Cost Metrics", draft-wu-alto-te-
2425	              metrics-03 (work in progress), June 2014.

2427	   [RFC3568]  Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
2428	              Content Network (CN) Request-Routing Mechanisms", RFC
2429	              3568, July 2003.

2431	   [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
2432	              Private Network (VPN) Terminology", RFC 4026, March 2005.

2434	   [RFC5632]  Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and
2435	              Y. Yang, "Comcast's ISP Experiences in a Proactive Network
2436	              Provider Participation for P2P (P4P) Technical Trial", RFC
2437	              5632, September 2009.

2439	Appendix A.  Acknowledgments

2441	   This memo is the result of contributions made by several people:

2443	   o  Xianghue Sun, Lee Kai, and Richard Yang contributed text on ISP
2444	      deployment requirements and monitoring.

2446	   o  Stefano Previdi contributed parts of the Section 5 on "Using ALTO
2447	      for CDNs".

2449	   o  Rich Woundy contributed text to Section 3.3.

2451	   o  Lingli Deng, Wei Chen, Qiuchao Yi, and Yan Zhang contributed
2452	      Section 6.2.

2454	   Thomas-Rolf Banniza, Vinayak Hegde, and Qin Wu provided very useful
2455	   comments and reviewed the document.

2457	   Martin Stiemerling is partially supported by the CHANGE project (
2458	   http://www.change-project.eu), a research project supported by the
2459	   European Commission under its 7th Framework Program (contract no.
2460	   257422).  The views and conclusions contained herein are those of the
2461	   authors and should not be interpreted as necessarily representing the
2462	   official policies or endorsements, either expressed or implied, of
2463	   the CHANGE project or the European Commission.

2465	Authors' Addresses
2466	   Martin Stiemerling
2467	   NEC Laboratories Europe
2468	   Kurfuerstenanlage 36
2469	   Heidelberg  69115
2470	   Germany

2472	   Phone: +49 6221 4342 113
2473	   Fax:   +49 6221 4342 155
2474	   Email: martin.stiemerling@neclab.eu
2475	   URI:   http://ietf.stiemerling.org

2477	   Sebastian Kiesel
2478	   University of Stuttgart, Computing Center
2479	   Allmandring 30
2480	   Stuttgart  70550
2481	   Germany

2483	   Email: ietf-alto@skiesel.de

2485	   Stefano Previdi
2486	   Cisco Systems, Inc.
2487	   Via Del Serafico 200
2488	   Rome  00191
2489	   Italy

2491	   Email: sprevidi@cisco.com

2493	   Michael Scharf
2494	   Alcatel-Lucent Bell Labs
2495	   Lorenzstrasse 10
2496	   Stuttgart  70435
2497	   Germany

2499	   Email: michael.scharf@alcatel-lucent.com