doc: Add RFC documents

1 files changed, 4315 insertions, 0 deletions

diff --git a/doc/rfc/rfc7971.txt b/doc/rfc/rfc7971.txt
new file mode 100644
index 0000000..7b4095e
--- /dev/null
+++ b/doc/rfc/rfc7971.txt
@@ -0,0 +1,4315 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    M. Stiemerling
+Request for Comments: 7971                          Hochschule Darmstadt
+Category: Informational                                        S. Kiesel
+ISSN: 2070-1721                                  University of Stuttgart
+                                                               M. Scharf
+                                                                   Nokia
+                                                               H. Seidel
+                                                                  BENOCS
+                                                              S. Previdi
+                                                                   Cisco
+                                                            October 2016
+
+
+Application-Layer Traffic Optimization (ALTO) Deployment Considerations
+
+Abstract
+
+   Many Internet applications are used to access resources such as
+   pieces of information or server processes that are available in
+   several equivalent replicas on different hosts.  This includes, but
+   is not limited to, peer-to-peer file sharing applications.  The goal
+   of Application-Layer Traffic Optimization (ALTO) is to provide
+   guidance to applications that have to select one or several hosts
+   from a set of candidates capable of providing a desired resource.
+   This memo discusses deployment-related issues of ALTO.  It addresses
+   different use cases of ALTO such as peer-to-peer file sharing and
+   Content Delivery Networks (CDNs) and presents corresponding examples.
+   The document also includes recommendations for network administrators
+   and application designers planning to deploy ALTO, such as
+   recommendations on how to generate ALTO map information.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7971.
+
+
+
+
+
+Stiemerling, et al.           Informational                     [Page 1]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. General Considerations ..........................................4
+      2.1. ALTO Entities ..............................................4
+           2.1.1. Baseline Scenario ...................................4
+           2.1.2. Placement of ALTO Entities ..........................6
+      2.2. Classification of Deployment Scenarios .....................8
+           2.2.1. Roles in ALTO Deployments ...........................8
+           2.2.2. Information Exposure ...............................11
+           2.2.3. More-Advanced Deployments ..........................12
+   3. Deployment Considerations by ISPs ..............................15
+      3.1. Objectives for the Guidance to Applications ...............15
+           3.1.1. General Objectives for Traffic Optimization ........15
+           3.1.2. Inter-Network Traffic Localization .................16
+           3.1.3. Intra-Network Traffic Localization .................17
+           3.1.4. Network Offloading .................................18
+           3.1.5. Application Tuning .................................19
+      3.2. Provisioning of ALTO Topology Data ........................20
+           3.2.1. High-Level Process and Requirements ................20
+           3.2.2. Data Collection from Data Sources ..................21
+           3.2.3. Partitioning and Grouping of IP Address Ranges .....24
+           3.2.4. Rating Criteria and/or Cost Calculation ............25
+      3.3. ALTO Focus and Scope ......................................29
+           3.3.1. Limitations of Using ALTO beyond Design
+                  Assumptions ........................................29
+           3.3.2. Limitations of Map-Based Services and
+                  Potential Solutions ................................30
+           3.3.3. Limitations of Non-Map-Based Services and
+                  Potential Solutions ................................32
+      3.4. Monitoring ALTO ...........................................33
+           3.4.1. Impact and Observation on Network Operation ........33
+           3.4.2. Measurement of the Impact ..........................33
+
+
+
+Stiemerling, et al.           Informational                     [Page 2]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+           3.4.3. System and Service Performance .....................34
+           3.4.4. Monitoring Infrastructures .........................35
+      3.5. Abstract Map Examples for Different Types of ISPs .........36
+           3.5.1. Small ISP with Single Internet Uplink ..............36
+           3.5.2. ISP with Several Fixed-Access Networks .............39
+           3.5.3. ISP with Fixed and Mobile Network ..................40
+      3.6. Comprehensive Example for Map Calculation .................42
+           3.6.1. Example Network ....................................42
+           3.6.2. Potential Input Data Processing and Storage ........44
+           3.6.3. Calculation of Network Map from the Input Data .....47
+           3.6.4. Calculation of Cost Map ............................49
+      3.7. Deployment Experiences ....................................50
+   4. Using ALTO for P2P Traffic Optimization ........................52
+      4.1. Overview ..................................................52
+           4.1.1. Usage Scenario .....................................52
+           4.1.2. Applicability of ALTO ..............................53
+      4.2. Deployment Recommendations ................................55
+           4.2.1. ALTO Services ......................................55
+           4.2.2. Guidance Considerations ............................56
+   5. Using ALTO for CDNs ............................................58
+      5.1. Overview ..................................................58
+           5.1.1. Usage Scenario .....................................58
+           5.1.2. Applicability of ALTO ..............................60
+      5.2. Deployment Recommendations ................................62
+           5.2.1. ALTO Services ......................................62
+           5.2.2. Guidance Considerations ............................63
+   6. Other Use Cases ................................................64
+      6.1. Application Guidance in Virtual Private Networks (VPNs) ...64
+      6.2. In-Network Caching ........................................66
+      6.3. Other Application-Based Network Operations ................68
+   7. Security Considerations ........................................68
+      7.1. ALTO as a Protocol Crossing Trust Boundaries ..............68
+      7.2. Information Leakage from the ALTO Server ..................69
+      7.3. ALTO Server Access ........................................70
+      7.4. Faking ALTO Guidance ......................................71
+   8. References .....................................................72
+      8.1. Normative References ......................................72
+      8.2. Informative References ....................................73
+   Acknowledgments ...................................................76
+   Authors' Addresses ................................................77
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                     [Page 3]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+1.  Introduction
+
+   Many Internet applications are used to access resources such as
+   pieces of information or server processes that are available in
+   several equivalent replicas on different hosts.  This includes, but
+   is not limited to, peer-to-peer (P2P) file sharing applications and
+   Content Delivery Networks (CDNs).  The goal of Application-Layer
+   Traffic Optimization (ALTO) is to provide guidance to applications
+   that have to select one or several hosts from a set of candidates
+   capable of providing a desired resource.  The basic ideas and problem
+   space of ALTO is described in [RFC5693] and the set of requirements
+   is discussed in [RFC6708].  The ALTO protocol is specified in
+   [RFC7285].  An ALTO server discovery procedure is defined in
+   [RFC7286].
+
+   This document discusses use cases and operational issues that can be
+   expected when ALTO gets deployed.  This includes, but is not limited
+   to, location of the ALTO server, imposed load to the ALTO server, and
+   who initiates the queries.  This document provides guidance on which
+   ALTO services to use, and it summarizes known challenges as well as
+   deployment experiences, including potential processes to generate
+   ALTO network and cost maps.  It thereby complements the management
+   considerations in the protocol specification [RFC7285], which are
+   independent of any specific use of ALTO.
+
+2.  General Considerations
+
+2.1.  ALTO Entities
+
+2.1.1.  Baseline Scenario
+
+   The ALTO protocol [RFC7285] is a client/server protocol, operating
+   between a number of ALTO clients and an ALTO server, as sketched in
+   Figure 1.  Below, the baseline deployment scenario for ALTO entities
+   is first reviewed independently of the actual use case.  Specific
+   examples are then discussed in the remainder of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                     [Page 4]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+                 +----------+
+                 |  ALTO    |
+                 |  Server  |
+                 +----------+
+                       ^
+                _.-----|------.
+            ,-''       |       `--.
+          ,'           |           `.
+         (     Network |             )
+          `.           |           ,'
+            `--.       |       _.-'
+                `------|-----''
+                       v
+    +----------+  +----------+   +----------+
+    |  ALTO    |  |  ALTO    |...|  ALTO    |
+    |  Client  |  |  Client  |   |  Client  |
+    +----------+  +----------+   +----------+
+
+   Figure 1: Baseline Deployment Scenario of the ALTO Protocol
+
+   This document uses the terminology introduced in [RFC5693].  In
+   particular, the following terms are defined by [RFC5693]:
+
+   o  ALTO Service: Several resource providers may be able to provide
+      the same resource.  The ALTO service gives guidance to a resource
+      consumer and/or resource directory about which resource
+      provider(s) to select in order to optimize the client's
+      performance or quality of experience, while improving resource
+      consumption in the underlying network infrastructure.
+
+   o  ALTO Server: A logical entity that provides interfaces to satisfy
+      the queries about a particular ALTO service.
+
+   o  ALTO Client: The logical entity that sends ALTO queries.
+      Depending on the architecture of the application, one may embed it
+      in the resource consumer and/or in the resource directory.
+
+   o  Resource Consumer: For P2P applications, a resource consumer is a
+      specific peer that needs to access resources.  For client-server
+      or hybrid applications, a consumer is a client that needs to
+      access resources.
+
+   o  Resource Directory: An entity that is logically separate from the
+      resource consumer and that assists the resource consumer to
+      identify a set of resource providers.  Some P2P applications refer
+      to the resource directory as a P2P tracker.
+
+
+
+
+
+Stiemerling, et al.           Informational                     [Page 5]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   We differentiate between an ALTO Client and a Resource Consumer as
+   follows: the resource consumer is specific instance of a software
+   ("process") running on a specific host.  It is a client instance of a
+   client/server application or a peer of a peer-to-peer application.
+   It is the given (constant) endpoint of the data transmissions to be
+   optimized using ALTO.  The optimization is done by wisely choosing
+   the other ends of these data flows (i.e., the server(s) in a client/
+   server application or the peers in a peer-to-peer application), using
+   guidance from ALTO and possibly other information.  An ALTO client is
+   a piece of software (e.g., a software library) that implements the
+   client entity of the ALTO protocol as specified in [RFC7285].  It
+   consists of data structures that are suitable for representing ALTO
+   queries, replies, network and cost maps, etc.  Furthermore, it has to
+   implement an HTTP client and a JSON encoder/decoder, or it has to
+   include other software libraries that provide these building blocks.
+   In the simplest case, this ALTO client library can be linked (or
+   otherwise incorporated) into the resource consumer, in order to
+   retrieve information from an ALTO server and thereby satisfy the
+   resource consumer's need for guidance.  However, other configurations
+   are possible as well, as discussed in Section 2.1.2 and other
+   sections of this document.
+
+   According to these definitions, both an ALTO server and an ALTO
+   client are logical entities.  A particular ALTO service may be
+   offered by more than one ALTO server.  In ALTO deployments, the
+   functionality of an ALTO server can therefore be realized by several
+   server instances, e.g., by using load balancing between different
+   physical servers.  The term ALTO server should not be confused with
+   use of a single physical server.
+
+   This document uses the term "Resource Directory" as defined in
+   [RFC5693].  This term and its meaning is not to be confused with the
+   "Information Resource Directory (IRD)" defined as a part of the ALTO
+   protocol [RFC7285], i.e., a list of available information resources
+   offered by a specific ALTO service and the URIs at which each can be
+   accessed.
+
+2.1.2.  Placement of ALTO Entities
+
+   The ALTO server and ALTO clients may be situated at various places in
+   a network topology.  An important differentiation is whether the ALTO
+   client is located on the host that is the endpoint of the data
+   transmissions to be optimized with ALTO (see Figure 2) or whether the
+   ALTO client is located on a resource directory, which assists peers
+   or clients in finding other peers or servers, respectively, but does
+   not directly take part in the data transmission (see Figure 3).
+
+
+
+
+
+Stiemerling, et al.           Informational                     [Page 6]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+                                              +--------------+
+                                              |     App      |
+                                              +-----------+  |
+                                          ===>|ALTO Client|  |****
+                                       ===    +-----------+--+   *
+                                    ===                    *     *
+                                 ===                       *     *
+      +-------+     +-------+<===             +--------------+   *
+      |       |     |       |                 |     App      |   *
+      |       |.....|       |<========        +-----------+  |   *
+      |       |     |       |        ========>|ALTO Client|  |   *
+      +-------+     +-------+<===             +-----------+--+   *
+      Source of       ALTO       ==                        *     *
+      topological    Server        ==                      *     *
+      information                    ==       +--------------+   *
+                                       ==     |     App      |   *
+                                         ==   +-----------+  |****
+                                           ==>|ALTO Client|  |
+                                              +-----------+--+
+                                                Application
+      Legend:
+      === ALTO protocol
+      *** Application protocol
+      ... Provisioning protocol
+
+     Figure 2: Overview of Protocol Interaction between ALTO Elements
+                       without a Resource Directory
+
+   Figure 2 shows the operational model for an ALTO client running at
+   endpoints.  An example would be a peer-to-peer file sharing
+   application that does not use a tracker, such as edonkey.  In
+   addition, ALTO clients at peers could also be used in a similar way
+   even if there is a tracker, as further discussed in Section 4.1.2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                     [Page 7]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+                                                       +-----+
+                                                     **| App |****
+                                                   **  +-----+   *
+                                                 **       *      *
+                                               **         *      *
+      +-------+     +-------+     +--------------+        *      *
+      |       |     |       |     |              |     +-----+   *
+      |       |.....|       |     +-----------+  |*****| App |   *
+      |       |     |       |<===>|ALTO Client|  |     +-----+   *
+      +-------+     +-------+     +-----------+--+        *      *
+      Source of       ALTO          Resource   **         *      *
+      topological    Server         directory    **       *      *
+      information                                  **  +-----+   *
+                                                     **| App |****
+                                                       +-----+
+                                                     Application
+      Legend:
+      === ALTO protocol
+      *** Application protocol
+      ... Provisioning protocol
+
+            Figure 3: Overview of Protocol Interaction between
+                  ALTO Elements with a Resource Directory
+
+   In Figure 3, a use case with a resource directory is illustrated,
+   e.g., a tracker in a peer-to-peer file-sharing application such as
+   BitTorrent.  Both deployment scenarios may differ in the number of
+   ALTO clients that access an ALTO service.  If an ALTO client is
+   implemented in a resource directory, an ALTO server may be accessed
+   by a limited and less dynamic set of clients, whereas in the general
+   case any host could be an ALTO client.  This use case is further
+   detailed in Section 4.
+
+   Using ALTO in CDNs may be similar to a resource directory [CDN-USE].
+   The ALTO server can also be queried by CDN entities to get guidance
+   about where a particular client accessing data in the CDN is located
+   in the Internet Service Provider's network, as discussed in
+   Section 5.
+
+2.2.  Classification of Deployment Scenarios
+
+2.2.1.  Roles in ALTO Deployments
+
+   ALTO is a general-purpose protocol and it is intended to be used by a
+   wide range of applications.  In different use cases, applications,
+   resource directories, etc., can correspond to different
+   functionality.  The use cases listed in this document are not meant
+   to be comprehensive.  This also implies that there are different
+
+
+
+Stiemerling, et al.           Informational                     [Page 8]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   possibilities where the ALTO entities are actually located, i.e., if
+   the ALTO clients and the ALTO server are in the same Internet Service
+   Provider (ISP) domain, or if the clients and the ALTO server are
+   managed/owned/located in different domains.
+
+   An ALTO deployment involves four kinds of entities:
+
+   1.  Source of topological information
+
+   2.  ALTO server
+
+   3.  ALTO client
+
+   4.  Resource consumer
+
+   Each of these entities corresponds to a certain role, which results
+   in requirements and constraints on the interaction between the
+   entities.
+
+   A key design objective of the ALTO service is that each of these four
+   roles can be separated, i.e., they can be realized by different
+   organizations or disjoint system components.  ALTO is inherently
+   designed for use in multi-domain environments.  Most importantly,
+   ALTO is designed to enable deployments in which the ALTO server and
+   the ALTO client are not located within the same administrative
+   domain.
+
+   As explained in [RFC5693], from this follows that at least three
+   different kinds of entities can operate an ALTO server:
+
+   1.  Network operators.  Network Service Providers (NSPs) such as ISPs
+       may have detailed knowledge of their network topology and
+       policies.  In this case, the source of the topology information
+       and the provider of the ALTO server may be part of the same
+       organization.
+
+   2.  Third parties.  Topology information could also be collected by
+       companies or organizations that are distinct from the network
+       operators, yet have arranged certain legal agreements with one or
+       more network operators, regarding access to their topology
+       information and/or doing measurements in their networks.
+       Examples of such entities could be CDN operators or companies
+       specialized in offering ALTO services on behalf of ISPs.
+
+   3.  User communities.  User communities could run distributed
+       measurements for estimating the topology of the Internet.  In
+       this case, the topology information may not originate from ISP
+       data.
+
+
+
+Stiemerling, et al.           Informational                     [Page 9]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   Regarding the interaction between ALTO server and client, ALTO
+   deployments can be differentiated according to the following aspects:
+
+   1.  Applicable trust model: The deployment of ALTO can differ
+       depending on whether or not the ALTO client and ALTO server are
+       operated within the same organization and/or network.  This
+       affects a number of constraints because the trust model is very
+       different.  For instance, as discussed later in this memo, the
+       level of detail of maps can depend on who the involved parties
+       actually are.
+
+   2.  Composition of the user group: The main use case of ALTO is to
+       provide guidance to any Internet application.  However, an
+       operator of an ALTO server could also decide to offer guidance
+       only to a set of well-known ALTO clients, e.g., after
+       authentication and authorization.  In the peer-to-peer
+       application use case, this could imply that only selected
+       trackers are allowed to access the ALTO server.  The security
+       implications of using ALTO in closed groups differ from the
+       public Internet.
+
+   3.  Covered destinations: In general, an ALTO server has to be able
+       to provide guidance for all potential destinations.  Yet, in
+       practice, a given ALTO client may only be interested in a subset
+       of destinations, e.g., only in the network cost between a limited
+       set of resource providers.  For instance, CDN optimization may
+       not need the full ALTO cost maps because traffic between
+       individual residential users is not in scope.  This may imply
+       that an ALTO server only has to provide the costs that matter for
+       a given user, e.g., by customized maps.
+
+   The following sections enumerate different classes of use cases for
+   ALTO, and they discuss deployment implications of each of them.  In
+   principle, an ALTO server can be operated by any organization, and
+   there is no requirement that an ALTO server be deployed and operated
+   by an ISP.  Yet, since the ALTO solution is designed for ISPs, most
+   examples in this document assume that the operator of an ALTO server
+   is a network operator (e.g., an ISP or the network department in a
+   large enterprise) that offers ALTO guidance in particular to users of
+   this network.
+
+   It must be emphasized that any application using ALTO must also work
+   if no ALTO servers can be found or if no responses to ALTO queries
+   are received, e.g., due to connectivity problems or overload
+   situations (see also [RFC6708]).
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 10]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+2.2.2.  Information Exposure
+
+   There are basically two different approaches to how an ALTO server
+   can provide network information and guidance:
+
+   1.  The ALTO server provides maps that contain provider-defined cost
+       values between network location groupings (e.g., sets of IP
+       prefixes).  These maps can be retrieved by clients via the ALTO
+       protocol, and the actual processing of the map data is done
+       inside the client.  Since the maps contain (aggregated) cost
+       information for all endpoints, the client does not have to reveal
+       any internal operational data, such as the IP addresses of
+       candidate resource providers.  The ALTO protocol supports this
+       mode of operation by the Network and Cost Map Service.
+
+   2.  The ALTO server provides a query interface that returns costs or
+       rankings for explicitly specified endpoints.  This means that the
+       query of the ALTO client has to include additional information
+       (e.g., a list of IP addresses).  The server then calculates and
+       returns costs or rankings for the endpoints specified in the
+       request (e.g., a sorted list of the IP addresses).  In ALTO, this
+       approach can be realized by the Endpoint Cost Service (ECS) and
+       other related services.
+
+   Both approaches have different privacy implications for the server
+   and client:
+
+   For the client, approach 1 has the advantage that all operational
+   information stays within the client and is not revealed to the
+   provider of the server.  However, this service implies that a network
+   operator providing an ALTO server has to expose a certain amount of
+   information about its network structure (e.g., IP prefixes or
+   topology information in general).
+
+   For the operator of a server, approach 2 has the advantage that the
+   query responses reveal less topology information to ALTO clients.
+   However, it should be noted that collaborating ALTO clients could
+   gather more information than expected by aggregating and correlating
+   responses to multiple queries sent to the ALTO server (see
+   Section 5.2.1, item (3) of [RFC6708]).  Furthermore, this method
+   requires that clients send internal operational information to the
+   server, such as the IP addresses of hosts also running the
+   application.  For clients, such data can be sensitive.
+
+   As a result, both approaches have their pros and cons, as further
+   detailed in Section 3.3.
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 11]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+2.2.3.  More-Advanced Deployments
+
+   From an ALTO client's perspective, there are different ways to use
+   ALTO:
+
+   1.  Single-service instance with single-metric guidance: An ALTO
+       client only obtains guidance regarding a single metric (e.g.,
+       "routingcost") from a single ALTO service, e.g., an ALTO server
+       that is offered by the network service provider of the
+       corresponding access network.  Corresponding ALTO server
+       instances can be discovered, e.g., by ALTO server discovery
+       [RFC7286] [XDOM-DISC].  Since the ALTO protocol is an HTTP-based,
+       REST-ful (Representational State Transfer) protocol, the operator
+       of an ALTO may use well-known techniques for serving large web
+       sites, such as load balancers, in order to serve a large number
+       of ALTO queries.  The ALTO protocol also supports the use of
+       different URIs for different ALTO features and thereby the
+       distribution of the service onto several servers.
+
+   2.  Single service instance with multiple metric guidance: An ALTO
+       client could also query an ALTO service for different kinds of
+       information, e.g., cost maps with different metrics.  The ALTO
+       protocol is extensible and permits such operation.  However, ALTO
+       does not define how a client shall deal with different forms of
+       guidance, and it is up to the client to interpret the received
+       information accordingly.
+
+   3.  Multiple service instances: An ALTO client can also decide to
+       access multiple ALTO servers providing guidance, possibly from
+       different operators or organizations.  Each of these services may
+       only offer partial guidance, e.g., for a certain network
+       partition.  In that case, it may be difficult for an ALTO client
+       to compare the guidance from different services.  Different
+       organization may use different methods to determine maps, and
+       they may also have different (possibly even contradicting or
+       competing) guidance objectives.  How to discover multiple ALTO
+       servers and how to deal with conflicting guidance is an open
+       issue.
+
+   There are also different options regarding the synchronization of
+   guidance offered by an ALTO service:
+
+   1.  Authoritative servers: An ALTO server instance can provide
+       guidance for all destinations for all kinds of ALTO clients.
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 12]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   2.  Cascaded servers: An ALTO server may itself include an ALTO
+       client and query other ALTO servers, e.g., for certain
+       destinations.  This results is a cascaded deployment of ALTO
+       servers, as further explained below.
+
+   3.  Inter-server synchronization: Different ALTO servers may
+       communicate by other means.  This approach is not further
+       discussed in this document.
+
+   An assumption of the ALTO design is that ISPs operate ALTO servers
+   independently, irrespective of other ISPs.  This may be true for most
+   envisioned deployments of ALTO, but there may be certain deployments
+   that may have different settings.  Figure 4 shows such a setting with
+   a university network that is connected to two upstream providers.
+   NREN is a National Research and Education Network, which provides
+   cheap high-speed connectivity to specific destinations, e.g., other
+   universities.  ISP is a commercial upstream provider from which the
+   university buys connectivity to all destinations that cannot be
+   reached via the NREN.  The university, as well as ISP, are operating
+   their own ALTO server.  The ALTO clients, located on the peers in the
+   university network will contact the ALTO server located at the
+   university.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 13]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+          +-----------+
+          |    ISP    |
+          |   ALTO    |<==========================++
+          |  Server   |                           ||
+          +-----------+                           ||
+            ,-------.            ,------.         ||
+         ,-'         `-.      ,-'         `-.     ||
+        /   Commercial  \    /               \    ||
+       (    Upstream     )  (       NREN      )   ||
+        \   ISP         /    \               /    ||
+         `-.         ,-'      `-.         ,-'     ||
+            `---+---'            `+------'        ||
+                |                 |               ||
+                |                 |               ||
+                |,-------------.  |               \/
+              ,-+               `-+          +-----------+
+            ,'      University     `.        |University |
+           (        Network          )       |   ALTO    |
+            `.                      /        |  Server   |
+              `-.               +--'         +-----------+
+                 `+------------'|              /\     /\
+                  |             |              ||     ||
+         +--------+-+         +-+--------+     ||     ||
+         |   Peer1  |         |   PeerN  |<====++     ||
+         +----------+         +----------+            ||
+              /\                                      ||
+              ||                                      ||
+              ++======================================++
+
+      Legend:
+      === ALTO protocol
+
+                Figure 4: Example of a Cascaded ALTO Server
+
+   In this setting, all destinations that can be reached via the NREN
+   are preferred in the rating of the university's ALTO server.  In
+   contrast, all traffic that is not routed via the NREN will be handled
+   by the commercial upstream ISP and is in general less preferred due
+   to the associated costs.  Yet, there may be significant differences
+   between various destinations reached via the ISP.  Therefore, the
+   ALTO server at the university may also include the guidance given by
+   the ISP ALTO server in its replies to the ALTO clients.  This is an
+   example for cascaded ALTO servers.
+
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 14]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+3.  Deployment Considerations by ISPs
+
+3.1.  Objectives for the Guidance to Applications
+
+3.1.1.  General Objectives for Traffic Optimization
+
+   The Internet consists of many networks.  The networks are owned and
+   managed by different network operators, such as commercial ISPs,
+   enterprise IT departments, universities, and other organizations.
+   These network operators provide network connectivity, e.g., by access
+   networks, such as cable networks, xDSL networks, 3G/4G mobile
+   networks, etc.  Network operators need to manage, control, and audit
+   the traffic.  Therefore, it is important to understand how to deploy
+   an ALTO service and what its expected impact might be.
+
+   The general objective of ALTO is to give guidance to applications on
+   what endpoints (e.g., IP addresses or IP prefixes) are to be
+   preferred according to the operator of the ALTO server.  The ALTO
+   protocol gives means to let the ALTO server operator express its
+   preference, whatever this preference is.
+
+   ALTO enables network operators to support application-level traffic
+   engineering by influencing application resource provider selection.
+   This traffic engineering can have different objectives:
+
+   1.  Inter-network traffic localization: ALTO can help to reduce
+       inter-domain traffic.  The networks of different network
+       operators are interconnected through peering points.  From a
+       business view, the inter-network settlement is needed for
+       exchanging traffic between these networks.  These peering
+       agreements can be costly.  To reduce these costs, a simple
+       objective is to decrease the traffic exchange across the peering
+       points and thus keep the traffic in the own network or Autonomous
+       System (AS) as far as possible.
+
+   2.  Intra-network traffic localization: In case of large network
+       operators, the network may be grouped into several networks,
+       domains, or ASes.  The core network includes one or several
+       backbone networks, which are connected to multiple aggregation,
+       metro, and access networks.  If traffic can be limited to certain
+       areas such as access networks, this decreases the usage of
+       backbone and thus helps to save resources and costs.
+
+   3.  Network offloading: Compared to fixed networks, mobile networks
+       have some special characteristics, including lower link
+       bandwidth, high cost, limited radio frequency resource, and
+       limited terminal battery.  In mobile networks, wireless links
+       should be used efficiently.  For example, in the case of a P2P
+
+
+
+Stiemerling, et al.           Informational                    [Page 15]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+       service, it is likely that hosts should prefer retrieving data
+       from hosts in fixed networks, and avoid retrieving data from
+       mobile hosts.
+
+   4.  Application tuning: ALTO is also a tool to optimize the
+       performance of applications that depend on the network and
+       perform resource provider selection decisions among network
+       endpoints; an example is the network-aware selection of CDN
+       caches.
+
+   In the following, these objectives are explained in more detail with
+   examples.
+
+3.1.2.  Inter-Network Traffic Localization
+
+   ALTO guidance can be used to keep traffic local in a network, for
+   instance, in order to reduce peering costs.  An ALTO server can let
+   applications prefer other hosts within the same network operator's
+   network instead of randomly connecting to other hosts that are
+   located in another operator's network.  Here, a network operator
+   would always express its preference for hosts in its own network,
+   while hosts located outside its own network are to be avoided (i.e.,
+   they are undesired to be considered by the applications).  Figure 5
+   shows such a scenario where hosts prefer hosts in the same network
+   (e.g., Host 1 and Host 2 in ISP1 and Host 3 and Host 4 in ISP2).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 16]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+                            ,-------.         +-----------+
+          ,---.          ,-'         `-.      |   Host 1  |
+       ,-'     `-.      /     ISP 1   ########|ALTO Client|
+      /           \    /              #  \    +-----------+
+     /    ISP X    \   |              #  |    +-----------+
+    /               \  \              ########|   Host 2  |
+   ;             +----------------------------|ALTO Client|
+   |             |   |   `-.         ,-'      +-----------+
+   |             |   |      `-------'
+   |     Inter-  |   |      ,-------.         +-----------+
+   :     network |   ;   ,-'         `########|   Host 3  |
+    \    traffic |  /   /     ISP 2   # \     |ALTO Client|
+     \           | /   /              #  \    +-----------+
+      \          |/    |              #  |    +-----------+
+       `-.     ,-|     \              ########|   Host 4  |
+          `---'  +----------------------------|ALTO Client|
+                         `-.         ,-'      +-----------+
+                            `-------'
+
+       Legend:
+       ### preferred "connections"
+       --- non-preferred "connections"
+
+               Figure 5: Inter-Network Traffic Localization
+
+   Examples for corresponding ALTO maps can be found in Section 3.5.
+   Depending on the application characteristics, it may not be possible
+   or even desirable to completely localize all traffic.
+
+3.1.3.  Intra-Network Traffic Localization
+
+   The previous section describes the results of the ALTO guidance on an
+   inter-network level.  In the same way, ALTO can also be used for
+   intra-network localization.  In this case, ALTO provides guidance on
+   which internal hosts are to be preferred inside a single network
+   (e.g., one AS).  This application-level traffic engineering can
+   reduce the capacity requirements in the core network of an ISP.
+   Figure 6 shows such a scenario where Host 1 and Host 2 are located in
+   an access net 1 of ISP 1 and connect via a low capacity link to the
+   core of the same ISP 1.  If Host 1 and Host 2 exchange their data
+   with remote hosts, they would probably congest the bottleneck link.
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 17]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+              Bottleneck    ,-------.         +-----------+
+          ,---.     |    ,-'         `-.      |   Host 1  |
+       ,-'     `-.  |   /     ISP 1   ########|ALTO Client|
+      /           \ |  /    (Access   #  \    +-----------+
+     /    ISP 1    \|  |     net 1)   #  |    +-----------+
+    /   (Core       V  \              ########|   Host 2  |
+   ;    network) +--X~~~X---------------------|ALTO Client|
+   |             |   |   `-.         ,-'      +-----------+
+   |             |   |      `-------'
+   |             |   |      ,-------.         +-----------+
+   :             |   ;   ,-'         `########|   Host 3  |
+    \            |  /   /     ISP 1   # \     |ALTO Client|
+     \           | /   /     (Access  #  \    +-----------+
+      \          |/    |      net 2)  #  |    +-----------+
+       `-.     ,-X     \              ########|   Host 4  |
+          `---'  ~~~~~~~X---------------------|ALTO Client|
+                   ^     `-.         ,-'      +-----------+
+                   |        `-------'
+                Bottleneck
+       Legend:
+       ### preferred "connections"
+       --- non-preferred "connections"
+
+               Figure 6: Intra-Network Traffic Localization
+
+   In such a situation, the operator can guide the hosts to try local
+   hosts in the same network islands first, avoiding or at least
+   lowering the effect on the bottleneck link, as shown in Figure 6.
+
+   The objective is to avoid bottlenecks by optimized endpoint selection
+   at the application level.  That said, it must be understood that ALTO
+   is not a general-purpose method to deal with the congestion at the
+   bottleneck.
+
+3.1.4.  Network Offloading
+
+   Another scenario is offloading traffic from networks.  This use of
+   ALTO can be beneficial in particular in mobile networks.  A network
+   operator may have the desire to guide hosts in its mobile network to
+   use hosts outside this mobile network.  One reason could be that the
+   wireless network or the mobile hosts were not designed for direct
+   peer-to-peer communications between mobile hosts, and therefore, it
+   makes sense for peers to fetch content from remote peers in other
+   parts of the Internet.
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 18]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+                            ,-------.         +-----------+
+          ,---.          ,-'         `-.      |   Host 1  |
+       ,-'     `-.      /     ISP 1   +-------|ALTO Client|
+      /           \    /    (Mobile   |  \    +-----------+
+     /    ISP X    \   |    network)  |  |    +-----------+
+    /               \  \              +-------|   Host 2  |
+   ;             #############################|ALTO Client|
+   |             #   |   `-.         ,-'      +-----------+
+   |             #   |      `-------'
+   |             #   |      ,-------.
+   :             #   ;   ,-'         `-.
+    \            #  /   /     ISP 2     \
+     \           # /   /     (Fixed      \
+      \          #/    |     network)    |    +-----------+
+       `-.     ,-#     \                 /    |   Host 3  |
+          `---'  #############################|ALTO Client|
+                         `-.         ,-'      +-----------+
+                            `-------'
+
+       Legend:
+       ### preferred "connections"
+       --- non-preferred "connections"
+
+              Figure 7: ALTO Traffic Network De-localization
+
+   Figure 7 shows the result of such a guidance process where Host 2
+   prefers a connection with Host 3 instead of Host 1, as shown in
+   Figure 5.
+
+   A realization of this scenario may have certain limitations and may
+   not be possible in all cases.  For instance, it may require the ALTO
+   server to distinguish mobile and non-mobile hosts based on their IP
+   address.  This may depend on mobility solutions and may not be
+   possible or accurate.  In general, ALTO is not intended as a fine-
+   grained traffic engineering solution for individual hosts.  Instead,
+   it typically works on aggregates (e.g., if it is known that certain
+   IP prefixes are often assigned to mobile users).
+
+3.1.5.  Application Tuning
+
+   ALTO can also provide guidance to optimize the application-level
+   topology of networked applications, e.g., by exposing network
+   performance information.  Applications can often run their own
+   measurements to determine network performance, e.g., by active delay
+   measurements or bandwidth probing, but such measurements result in
+   overhead and complexity.  Accessing an ALTO server can be a simpler
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 19]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   alternative.  In addition, an ALTO server may also expose network
+   information that applications cannot easily measure or reverse-
+   engineer.
+
+3.2.  Provisioning of ALTO Topology Data
+
+3.2.1.  High-Level Process and Requirements
+
+   A process to generate ALTO topology information typically comprises
+   several steps.  The first step is to gather information, which is
+   described in the following section.  The subsequent sections describe
+   how the gathered data can be processed and which methods can be
+   applied to generate the information exposed by ALTO, such as network
+   and cost maps.
+
+   Providing ALTO guidance can result in a win-win situation for network
+   providers and users of the ALTO information.  Applications possibly
+   get a better performance, while the network provider has means to
+   optimize the traffic engineering and thus its costs.  Yet, there can
+   be security concerns with exposing topology data.  Corresponding
+   limitations are discussed in Section 7.2.
+
+   ISPs may have important privacy requirements when deploying ALTO,
+   which have to be taken into account when processing ALTO topology
+   data.  In particular, an ISP may not be willing to expose sensitive
+   operational details of its network.  The topology abstraction of ALTO
+   enables an ISP to expose the network topology at a desired
+   granularity only, determined by security policies.
+
+   With the ECS, the ALTO client does not have to implement any specific
+   algorithm or mechanism in order to retrieve, maintain and process
+   network topology information (of any kind).  The complexity of the
+   network topology (computation, maintenance and distribution) is kept
+   in the ALTO server and ECS is delivered on demand.  This allows the
+   ALTO server to enhance and modify the way the topology information
+   sources are used and combined.  This simplifies the enforcement of
+   privacy policies of the ISP.
+
+   The ALTO Network and Cost Map Service expose an abstract view on the
+   ISP network topology.  Therefore, care is needed when constructing
+   those maps in order to take privacy policies into account, as further
+   discussed in Section 3.2.3.  The ALTO protocol also supports further
+   features such as endpoint properties, which could also be used to
+   expose topology guidance.  The privacy considerations for ALTO maps
+   also apply to such ALTO extensions.
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 20]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+3.2.2.  Data Collection from Data Sources
+
+   The first step in the process of generating ALTO information is to
+   gather the required information from the network.  An ALTO server can
+   collect topological information from a variety of sources in the
+   network and provides a cohesive, abstract view of the network
+   topology to applications using an ALTO client.  Topology data sources
+   may include routing protocols, network policies, state and
+   performance information, geolocation, etc.  An ALTO server requires
+   at least some topology and/or routing information, i.e., information
+   about existing endpoints and their interconnection.  With this
+   information, it is in principle possible to compute paths between all
+   known endpoints.  Based on such basic data, the ALTO server builds an
+   ALTO-specific network topology that represents the network as it
+   should be understood and utilized by applications (resource
+   consumers) at endpoints using ALTO services (e.g., Network and Cost
+   Map Service or ECS).  A basic dataset can be extended by many other
+   information obtainable from the network.
+
+   The ALTO protocol does not assume a specific network technology or
+   topology.  In principle, ALTO can be used with various types of
+   addresses (Endpoint Addresses).  [RFC7285] defines the use of IPv4/
+   IPv6 addresses or prefixes in ALTO, but further address types could
+   be added by extensions.  In this document, only the use of IPv4/IPv6
+   addresses is considered.
+
+   The exposure of network topology information is controlled and
+   managed by the ALTO server.  ALTO abstract network topologies can be
+   automatically generated from the physical or logical topology of the
+   network, e.g., using "live" network data.  The generation would
+   typically be based on policies and rules set by the network operator.
+   The maps and the guidance can significantly differ depending on the
+   use case, the network architecture, and the trust relationship
+   between ALTO server and ALTO client, etc.  Besides the security
+   requirements that consist of not delivering any confidential or
+   critical information about the infrastructure, there are efficiency
+   requirements in terms of what aspects of the network are visible and
+   required by the given use case and/or application.
+
+   The ALTO server operator has to ensure that the ALTO topology does
+   not reveal any details that would endanger the network integrity and
+   security.  For instance, ALTO is not intended to leak raw Interior
+   Gateway Protocol (IGP) or Border Gateway Protocol (BGP) databases to
+   ALTO clients.
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 21]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+                 +--------+   +--------+
+                 |  ALTO  |   |  ALTO  |
+                 | Client |   | Client |
+                 +--------+   +--------+
+                        /\     /\
+                        ||     || ALTO protocol
+                        ||     ||
+                        \/     \/
+                       +---------+
+                       |  ALTO   |
+                       | Server  |
+                       +---------+
+                        : :   : :
+                        : :   : :
+             +..........+ :   : +..........+ Provisioning
+             :            :   :            : protocol
+             :            :   :            :
+     +---------+ +---------+ +---------+ +---------+
+     |   BGP   | |   I2RS  | |   PCE   | |   NMS   | Potential
+     | Speaker | |  Client | |         | |   OSS   | data sources
+     +---------+ +---------+ +---------+ +---------+
+          ^           ^           ^           ^
+          |           |           |           |
+     Link-State     I2RS         TED     Topology and traffic-related
+      NLRI for      data         data    data from SNMP, NETCONF,
+      IGP/BGP                            RESTCONF, REST, IPFIX, etc.
+
+                 Figure 8: Potential Data Sources for ALTO
+
+   As illustrated in Figure 8, the topology data used by an ALTO server
+   can originate from different data sources:
+
+   o  Relevant information sources are IGPs or BGP.  An ALTO server
+      could get network routing information by listening to IGPs and/or
+      peering with BGP speakers.  For data collection, link-state
+      protocols are more suitable since every router propagates its
+      information throughout the whole network.  Hence, it is possible
+      to obtain information about all routers and their neighbors from
+      one single router in the network.  In contrast, distance-vector
+      protocols are less suitable since routing information is only
+      shared among neighbors.  To obtain the whole topology with
+      distance-vector routing protocols it is necessary to retrieve
+      routing information from every router in the network.
+
+   o  [RFC7752] describes a mechanism by which link-state and Traffic
+      Engineering (TE) information can be collected from networks and
+      shared with external components using the BGP routing protocol.
+      This is achieved using a new BGP Network Layer Reachability
+
+
+
+Stiemerling, et al.           Informational                    [Page 22]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+      Information (NLRI) encoding format.  The mechanism is applicable
+      to physical and virtual IGP links and can also include TE data.
+      For instance, prefix data can be carried and originated in BGP,
+      while TE data is originated and carried in an IGP.  The mechanism
+      described is subject to policy control.
+
+   o  The Interface to the Routing System (I2RS) is a solution for state
+      transfer in and out of the Internet's routing system [RFC7921].
+      An ALTO server could use an I2RS client to observe routing-related
+      information.  With the rise of Software-Defined Networking (SDN)
+      and a decoupling of network data and control plane, topology
+      information could also be fetched from an SDN controller.  If I2RS
+      is used, [RFC7922] provides traceability for these interactions.
+      This scenario is not further discussed in the remainder of this
+      document.
+
+   o  Another potential source of topology information could be a Path
+      Computation Element (PCE) [RFC4655].  Topology and traffic-related
+      information can be retrieved from the Traffic Engineering Database
+      (TED) and Label Switched Path Database (LSP-DB).  This scenario is
+      not further discussed in the remainder of this document.
+
+   o  An ALTO server can also leverage a Network Management System (NMS)
+      or an Operations Support System (OSS) as data sources.  NMS or OSS
+      solutions are used to control, operate, and manage a network,
+      e.g., using the Simple Network Management Protocol (SNMP) or
+      Network Configuration Protocol (NETCONF).  As explained for
+      instance in [RFC7491], the NMS and OSS can be consumers of network
+      events reported and can act on these reports as well as displaying
+      them to users and raising alarms.  In addition, NMS and OSS
+      systems may have access to routing information and network
+      inventory data (e.g., links, nodes, or link properties not visible
+      to routing protocols, such as Shared Risk Link Groups).
+      Furthermore, Operations, Administration, and Maintenance (OAM)
+      information can be leveraged, including traffic utilization
+      obtained from IP Flow Information Export (IPFIX), event
+      notifications (e.g., via syslog), liveness detection (e.g.,
+      bidirectional forwarding detection, BFD).  NMS or OSS systems also
+      may have functions to correlate and orchestrate information
+      originating from other data sources.  For instance, it could be
+      required to correlate IP prefixes with routers (Provider, Provider
+      Edge, Customer Edge, etc.), IGP areas, VLAN IDs, or policies.
+
+   In the context of the provisioning protocol, topology information
+   could be modeled in a YANG data model [NETWORK-TOPO].
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 23]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   The data sources mentioned so far are only a subset of potential
+   topology sources and protocols.  Depending on the network type,
+   (e.g., mobile, satellite network) different hardware and protocols
+   are in operation to form and maintain the network.
+
+   In general, it is challenging to gather detailed information about
+   the whole Internet, since the network consists of multiple domains
+   and in many cases it is not possible to collect information across
+   network borders.  Hence, potential information sources may be limited
+   to a certain domain.
+
+3.2.3.  Partitioning and Grouping of IP Address Ranges
+
+   ALTO introduces provider-defined network location identifiers called
+   Provider-defined Identifiers (PIDs) to aggregate network endpoints in
+   the Map Services.  Endpoints within one PID may be treated as single
+   entity, assuming proximity based on network topology or other
+   similarity.  A key use case of PIDs is to specify network preferences
+   (costs) between PIDs instead of individual endpoints.  It is up to
+   the operator of the ALTO server how to group endpoints and how to
+   assign PIDs.  For example, a PID may denote a subnet, a set of
+   subnets, a metropolitan area, a POP, an autonomous system, or a set
+   of autonomous systems.
+
+   This document only considers deployment scenarios in which PIDs
+   expand to a set of IP address ranges (CIDR).  A PID is characterized
+   by a string identifier and its associated set of endpoint addresses
+   [RFC7285].  If an ALTO server offers the Map Service, corresponding
+   identifiers have to be configured.
+
+   An automated ALTO implementation may use dynamic algorithms to
+   aggregate network topology.  However, it is often desirable to have a
+   mechanism through which the network operator can control the level
+   and details of network aggregation based on a set of requirements and
+   constraints.  This will typically be governed by policies that
+   enforce a certain level of abstraction and prevent leakage of
+   sensitive operational data.
+
+   For instance, an ALTO server may leverage BGP information that is
+   available in a network's service provider network layer and compute
+   the group of prefix.  An example being BGP communities, which are
+   used in MPLS/IP networks as a common mechanism to aggregate and group
+   prefixes.  A BGP community is an attribute used to tag a prefix to
+   group prefixes based on mostly any criteria (as an example, most ISP
+   networks originate BGP prefixes with communities identifying the
+   Point of Presence (PoP) where the prefix has been originated).  These
+   BGP communities could be used to map IP address ranges to PIDs.  By
+   an additional policy, the ALTO server operator may decide an
+
+
+
+Stiemerling, et al.           Informational                    [Page 24]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   arbitrary cost defined between groups.  Alternatively, there are
+   algorithms that allow the dynamic computation of costs between
+   groups.  The ALTO protocol itself is independent of such algorithms
+   and policies.
+
+3.2.4.  Rating Criteria and/or Cost Calculation
+
+   An ALTO server indicates preferences amongst network locations in the
+   form of abstract costs.  These costs are generic costs and can be
+   internally computed by the operator of the ALTO server according to
+   its own policy.  For a given ALTO network map, an ALTO cost map
+   defines directional costs pairwise amongst the set of source and
+   destination network locations defined by the PIDs.
+
+   The ALTO protocol permits the use of different cost types.  An ALTO
+   cost type is defined by the combination of a cost metric and a cost
+   mode.  The cost metric identifies what the costs represent.  The cost
+   mode identifies how the costs should be interpreted, i.e., whether
+   returned costs should be interpreted as numerical values or ordinal
+   rankings.  The ALTO protocol also allows the definition of additional
+   constraints defining which elements of a cost map shall be returned.
+
+   The ALTO protocol specification [RFC7285] defines the "routingcost"
+   cost metric as the basic set of rating criteria, which has to be
+   supported by all implementations.  This cost metric conveys a generic
+   measure for the cost of routing traffic from a source to a
+   destination.  A lower value indicates a higher preference for traffic
+   to be sent from a source to a destination.  How that metric is
+   calculated is up to the ALTO server.
+
+   It is possible to calculate the "routingcost" cost metric based on
+   actual routing protocol information.  Typically, IGPs provide details
+   about endpoints and links within a given network, while the BGP is
+   used to provide details about links to endpoints in other networks.
+   Besides topology and routing information, networks have a multitude
+   of other attributes about their state, condition, and operation that
+   comprises but is not limited to attributes like link utilization,
+   bandwidth and delay, ingress/egress points of data flows from/towards
+   endpoints outside of the network up to the location of nodes and
+   endpoints.
+
+   In order to enable use of extended information, there is a protocol
+   extension procedure to add new ALTO cost types.  The following list
+   gives an overview on further rating criteria that have been proposed
+   or that are in use by ALTO-related prototype implementations.  This
+   list is not intended as normative text.  Instead, its only purpose is
+   to document and discuss rating criteria that have been proposed so
+   far.  Whether such rating criteria are useful and whether the
+
+
+
+Stiemerling, et al.           Informational                    [Page 25]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   corresponding information would actually be made available by ISPs
+   can also depend on the use case of ALTO.  A list of rating criteria
+   for which normative specifications exist and which have successfully
+   passed the IETF review process can be found at IANA's "ALTO Cost
+   Metric Registry", available from [ALTO-REG].
+
+   Distance-related rating criteria:
+
+   o  Relative topological distance: The term relative means that a
+      larger numerical value means greater distance, but it is up to the
+      ALTO service how to compute the values, and the ALTO client will
+      not be informed about the nature of the computation.  One way to
+      determine relative topological distance may be counting AS hops,
+      but when querying this parameter, the ALTO client must not assume
+      that the numbers actually are AS hops.  In addition to the AS
+      path, a relative cost value could also be calculated taking into
+      account other routing protocol parameters, such as BGP local
+      preference or Multi-Exit Discriminator (MED) attributes.
+
+   o  Absolute topological distance, expressed in the number of
+      traversed autonomous systems.
+
+   o  Absolute topological distance, expressed in the number of router
+      hops (i.e., how much the TTL value of an IP packet will be
+      decreased during transit).
+
+   o  Absolute physical distance, based on knowledge of the approximate
+      geolocation (e.g., continent, country) of an IP address.
+
+   Performance-related rating criteria:
+
+   o  The minimum achievable throughput between the resource consumer
+      and the candidate resource provider, which is considered useful by
+      the application (only in ALTO queries).
+
+   o  An arbitrary upper bound for the throughput from/to the candidate
+      resource provider (only in ALTO responses).  This may be, but is
+      not necessarily, the provisioned access bandwidth of the candidate
+      resource provider.
+
+   o  The maximum Round-Trip Time (RTT) between resource consumer and
+      the candidate resource provider, which is acceptable for the
+      application for useful communication with the candidate resource
+      provider (only in ALTO queries).
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 26]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   o  An arbitrary lower bound for the RTT between resource consumer and
+      the candidate resource provider (only in ALTO responses).  This
+      may be, for example, based on measurements of the propagation
+      delay in a completely unloaded network.
+
+   Charging-related rating criteria:
+
+   o  Metrics representing an abstract cost, e.g., determined by
+      policies that distinguish "cheap" from "expensive" IP subnet
+      ranges without detailing the cost function.  According to
+      [RFC7285], the abstract metric "routingcost" is an example for a
+      metric for which the cost function does not have to be disclosed.
+
+   o  Traffic volume caps, in case the Internet access of the resource
+      consumer is not charged with a "flat rate".  For each candidate
+      resource location, the ALTO service could indicate the amount of
+      data or the bitrate that may be transferred from/to this resource
+      location until a given point in time, and how much of this amount
+      has already been consumed.  Furthermore, an ALTO server may have
+      to indicate how excess traffic would be handled (e.g., blocked,
+      throttled, or charged separately at an indicated price), e.g., by
+      a new endpoint property.  This is outside the scope of this
+      document.  Also, it is left for further study how several
+      applications would interact if only some of them use this
+      criterion.  Also left for further study is the use of such a
+      criterion in resource directories that issue ALTO queries on
+      behalf of other endpoints.
+
+   All the above-listed rating criteria are subject to the remarks
+   below:
+
+   The ALTO client must be aware that with high probability the actual
+   performance values will differ from whatever an ALTO server exposes.
+   In particular, an ALTO client must not consider a throughput
+   parameter as a permission to send data at the indicated rate without
+   using congestion control mechanisms.
+
+   The discrepancies are due to various reasons, including, but not
+   limited to the following facts:
+
+   o  The ALTO service is not an admission control system.
+
+   o  The ALTO service may not know the instantaneous congestion status
+      of the network.
+
+   o  The ALTO service may not know all link bandwidths, i.e., where the
+      bottleneck really is, and there may be shared bottlenecks.
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 27]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   o  The ALTO service may not have all information about the actual
+      routing.
+
+   o  The ALTO service may not know whether the candidate endpoint
+      itself is overloaded.
+
+   o  The ALTO service may not know whether the candidate endpoint
+      throttles the bandwidth it devotes for the considered application.
+
+   o  The ALTO service may not know whether the candidate endpoint will
+      throttle the data it sends to the client (e.g., because of some
+      fairness algorithm, such as tit for tat).
+
+   Because of these inaccuracies and the lack of complete, instantaneous
+   state information, which are inherent to the ALTO service, the
+   application must use other mechanisms (such as passive measurements
+   on actual data transmissions) to assess the currently achievable
+   throughput, and it must use appropriate congestion control mechanisms
+   in order to avoid a congestion collapse.  Nevertheless, the rating
+   criteria may provide a useful shortcut for quickly excluding
+   candidate resource providers from such probing, if it is known in
+   advance that connectivity is in any case worse than what is
+   considered the minimum useful value by the respective application.
+
+   Rating criteria that should not be defined for and used by the ALTO
+   service include:
+
+   o  Performance metrics that are closely related to the instantaneous
+      congestion status.  The definition of alternate approaches for
+      congestion control is explicitly out of the scope of ALTO.
+      Instead, other appropriate means, such as using TCP-based
+      transport, have to be used to avoid congestion.  In other words,
+      ALTO is a service to provide network and policy information, with
+      update intervals that are possibly several orders of magnitude
+      slower than congestion-control loops (e.g., in TCP) can react on
+      changes in network congestion state.  This clear separation of
+      responsibilities avoids traffic oscillations and can help for
+      network stability and cost optimization.
+
+   o  Performance metrics that raise privacy concerns.  For instance, it
+      has been questioned whether an ALTO service should publicly expose
+      the provisioned access bandwidth of cable/DSL customers, as this
+      could enable identification of "premium customers" of an ISP.
+
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 28]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+3.3.  ALTO Focus and Scope
+
+   The purpose of this section is ensure that administrators and users
+   of ALTO services are aware of the objectives of the ALTO protocol
+   design.  Using ALTO beyond this scope may limit its efficiency.
+   Likewise, Map-based and Endpoint-based ALTO Services may face certain
+   issues during deployment.  This section explains these limitations
+   and also outlines potential solutions.
+
+3.3.1.  Limitations of Using ALTO beyond Design Assumptions
+
+   ALTO is designed as a protocol between clients integrated in
+   applications and servers that provide network information and
+   guidance (e.g., basic network location structure and preferences of
+   network paths).  The objective is to modify network resource
+   consumption patterns at application level while maintaining or
+   improving application performance.  This design focus results in a
+   number of characteristics of ALTO:
+
+   o  Endpoint focus: In typical ALTO use cases, neither the consumer of
+      the topology information (i.e., the ALTO client) nor the
+      considered resources (e.g., files at endpoints) are part of the
+      network.  The ALTO server presents an abstract network topology
+      containing only information relevant to an application overlay for
+      better-than-random resource provider selection among its
+      endpoints.  The ALTO protocol specification [RFC7285] is not
+      designed to expose network internals such as routing tables or
+      configuration data that are not relevant for application-level
+      resource provider selection decisions in network endpoints.
+
+   o  Abstraction: The ALTO services such as the Network and Cost Map
+      Service or the ECS provide an abstract view of the network only.
+      The operator of the ALTO server has full control over the
+      granularity (e.g., by defining policies how to aggregate subnets
+      into PIDs) and the level of detail of the abstract network
+      representation (e.g., by deciding what cost types to support).
+
+   o  Multiple administrative domains: The ALTO protocol is designed for
+      use cases where the ALTO server and client can be located in
+      different organizations or trust domains.  ALTO assumes a loose
+      coupling between server and client.  In addition, ALTO does not
+      assume that an ALTO client has any a priori knowledge about the
+      ALTO server and its supported features.  An ALTO server can be
+      discovered automatically.
+
+   o  Read-only: ALTO is a query/response protocol to retrieve guidance
+      information.  Neither network/cost map queries nor queries to the
+      ECS are designed to affect state in the network.
+
+
+
+Stiemerling, et al.           Informational                    [Page 29]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   If ALTO shall be deployed for use cases beyond the scope defined by
+   these assumptions, the protocol design may result in limitations.
+
+   For instance, in an Application-Based Network Operations (ABNO)
+   environment, the application could issue an explicit service request
+   to the network [RFC7491].  In this case, the application would
+   require detailed knowledge about the internal network topology and
+   the actual state.  A network configuration would also require a
+   corresponding security solution for authentication and authorization.
+   ALTO is not designed for operations to control, operate, and manage a
+   network.
+
+   Such deployments could be addressed by network management solutions,
+   e.g., based on SNMP [RFC3411] or NETCONF [RFC6241] and YANG
+   [RFC6020], that are typically designed to manipulate configuration
+   state.  [RFC7491] contains a more detailed discussion of interfaces
+   between components such as Element Management System (EMS), Network
+   Management System (NMS), Operational Support System (OSS), Traffic
+   Engineering Database (TED), Label Switched Path Database (LSP-DB),
+   Path Computation Element (PCE), and other Operations, Administration,
+   and Maintenance (OAM) components.
+
+3.3.2.  Limitations of Map-Based Services and Potential Solutions
+
+   The specification of the Map Service in the ALTO protocol [RFC7285]
+   is based on the concept of network maps.  A network map partitions
+   the network into PIDs that group one or more endpoints (e.g.,
+   subnetworks) to a single aggregate.  The "costs" between the various
+   PIDs are stored in a cost map.  Map-based approaches such as the ALTO
+   Network and Cost Map Service lower the signaling load on the server
+   as maps have to be retrieved only if they change.
+
+   One main assumption for map-based approaches is that the information
+   provided in these maps is static for a long period of time.  This
+   assumption is fine as long as the network operator does not change
+   any parameter, e.g., routing within the network and to the upstream
+   peers, and IP address assignment stays stable (and thus the mapping
+   to the partitions).  However, there are several cases where this
+   assumption is not valid:
+
+   1.  ISPs reallocate IP subnets from time to time.
+
+   2.  ISPs reallocate IP subnets on short notice.
+
+   3.  IP prefix blocks may be assigned to a router that serves a
+       variety of access networks.
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 30]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   4.  Network costs between IP prefixes may change depending on the
+       ISP's routing and traffic engineering.
+
+   These effects can be explained as follows:
+
+   Case 1: ISPs may reallocate IP subnets within their infrastructure
+   from time to time, partly to ensure the efficient usage of IPv4
+   addresses (a scarce resource), and partly to enable efficient route
+   tables within their network routers.  The frequency of these
+   "renumbering events" depends on the growth in number of subscribers
+   and the availability of address space within the ISP.  As a result, a
+   subscriber's household device could retain an IP address for as short
+   as a few minutes or for months at a time or even longer.
+
+   It has been suggested that ISPs providing ALTO services could
+   subdivide their subscribers' devices into different IP subnets (or
+   certain IP address ranges) based on the purchased service tier, as
+   well as based on the location in the network topology.  The problem
+   is that this sub-allocation of IP subnets tends to decrease the
+   efficiency of IP address allocation, in particular for IPv4.  A
+   growing ISP that needs to maintain high efficiency of IP address
+   utilization may be reluctant to jeopardize their future acquisition
+   of IP address space.
+
+   However, this is not an issue for map-based approaches if changes are
+   applied in the order of days.
+
+   Case 2: ISPs can use techniques that allow the reallocation of IP
+   prefixes on very short notice, i.e., within minutes.  An IP prefix
+   that has no IP address assignment to a host anymore can be
+   reallocated to areas where there is currently a high demand for IP
+   addresses.
+
+   Case 3: In residential access networks (e.g., DSL, cable), IP
+   prefixes are assigned to broadband gateways, which are the first IP-
+   hop in the access-network between the Customer Premises Equipment
+   (CPE) and the Internet.  The access-network between CPE and broadband
+   gateway (called aggregation network) can have varying characteristics
+   (and thus associated costs), but still using the same IP prefix.  For
+   instance, one IP address IP1 out of a given CIDR prefix can be
+   assigned to a VDSL access line (e.g., 2 Mbit/s uplink) while another
+   IP address IP2 within the same given CIDR prefix is assigned to a
+   slow ADSL line (e.g., 128 kbit/s uplink).  These IP addresses may be
+   assigned on a first come first served basis, i.e., a single IP
+   address out of the same CIDR prefix can change its associated costs
+   quite fast.  This may not be an issue with respect to the used
+   upstream provider (thus the cross ISP traffic), but, depending on the
+   capacity of the aggregation network, this may raise to an issue.
+
+
+
+Stiemerling, et al.           Informational                    [Page 31]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   Case 4: The routing and traffic engineering inside an ISP network, as
+   well as the peering with other autonomous systems, can change
+   dynamically and affect the information exposed by an ALTO server.  As
+   a result, cost maps and possibly also network maps can change.
+
+   One solution to deal with map changes is to use incremental ALTO
+   updates [UPDATE-SSE].
+
+3.3.3.  Limitations of Non-Map-Based Services and Potential Solutions
+
+   The specification of the ALTO protocol [RFC7285] also includes the
+   ECS mechanism.  ALTO clients can ask the ALTO server for guidance for
+   specific IP addresses, thereby avoiding the need of processing maps.
+   This can mitigate some of the problems mentioned in the previous
+   section.
+
+   However, frequent requests, particularly with long lists of IP
+   addresses, may overload the ALTO server.  The server has to rank each
+   received IP address, which causes load at the server.  This may be
+   amplified when a large number of ALTO clients are asking for
+   guidance.  The results of the ECS are also more difficult to cache
+   than ALTO maps.  Therefore, the ALTO client may have to await the
+   server response before starting a communication, which results in an
+   additional delay.
+
+   Caching of IP addresses at the ALTO client or the use of the H12
+   approach [ALTO-H12] in conjunction with caching may lower the query
+   load on the ALTO server.
+
+   When an ALTO server receives an ECS request, it may not have the most
+   appropriate topology information in order to accurately determine the
+   ranking.  [RFC7285] generally assumes that a server can always offer
+   some guidance.  In such a case, the ALTO server could adopt one of
+   the following strategies:
+
+   o  Reply with available information (best effort).
+
+   o  Query another ALTO server presumed to have better topology
+      information and return that response (cascaded servers).
+
+   o  Redirect the request to another ALTO server presumed to have
+      better topology information (redirection).
+
+   The protocol mechanisms and decision processes that would be used to
+   determine if redirection is necessary and which mode to use is out of
+   the scope of this document, since protocol extensions could be
+   required.
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 32]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+3.4.  Monitoring ALTO
+
+3.4.1.  Impact and Observation on Network Operation
+
+   ALTO presents a new opportunity for managing network traffic by
+   providing additional information to clients.  In particular, the
+   deployment of an ALTO server may shift network traffic patterns, and
+   the potential impact to network operation can be large.  An ISP
+   providing ALTO may want to assess the benefits of ALTO as part of the
+   management and operations (cf.  [RFC7285]).  For instance, the ISP
+   might be interested in understanding whether the provided ALTO maps
+   are effective in order to decide whether an adjustment of the ALTO
+   configuration would be useful.  Such insight can be obtained from a
+   monitoring infrastructure.  An ISP offering ALTO could consider the
+   impact on (or integration with) traffic engineering and the
+   deployment of a monitoring service to observe the effects of ALTO
+   operations.  The measurement of impacts can be challenging because
+   ALTO-enabled applications may not provide related information back to
+   the ALTO service provider.
+
+   To construct an effective monitoring infrastructure, the ALTO service
+   provider should decide how to monitor the performance of ALTO and
+   identify and deploy data sources to collect data to compute the
+   performance metrics.  In certain trusted deployment environments, it
+   may be possible to collect information directly from ALTO clients.
+   It may also be possible to vary or selectively disable ALTO guidance
+   for a portion of ALTO clients either by time, geographical region, or
+   some other criteria to compare the network traffic characteristics
+   with and without ALTO.  Monitoring an ALTO service could also be
+   realized by third parties.  In this case, insight into ALTO data may
+   require a trust relationship between the monitoring system operator
+   and the network service provider offering an ALTO service.
+
+   The required monitoring depends on the network infrastructure and the
+   use of ALTO, and an exhaustive description is outside the scope of
+   this document.
+
+3.4.2.  Measurement of the Impact
+
+   ALTO realizes an interface between the network and applications.
+   This implies that an effective monitoring infrastructure may have to
+   deal with both network and application performance metrics.  This
+   document does not comprehensively list all performance metrics that
+   could be relevant, nor does it formally specify metrics.
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 33]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   The impact of ALTO can be classified regarding a number of different
+   criteria:
+
+   o  Total amount and distribution of traffic: ALTO enables ISPs to
+      influence and localize traffic of applications that use the ALTO
+      service.  Therefore, an ISP may be interested in analyzing the
+      impact on the traffic, i.e., whether network traffic patterns are
+      shifted.  For instance, if ALTO shall be used to reduce the inter-
+      domain P2P traffic, it makes sense to evaluate the total amount of
+      inter-domain traffic of an ISP.  Then, one possibility is to study
+      how the introduction of ALTO reduces the total inter-domain
+      traffic (inbound and/our outbound).  If the ISP's intention is to
+      localize the traffic inside his network, the network-internal
+      traffic distribution will be of interest.  Effectiveness of
+      localization can be quantified in different ways, e.g., by the
+      load on core routers and backbone links or by considering more-
+      advanced effects, such as the average number of hops that traffic
+      traverses inside a domain.
+
+   o  Application performance: The objective of ALTO is to improve
+      application performance.  ALTO can be used by very different types
+      of applications, with different communication characteristics and
+      requirements.  For instance, if ALTO guidance achieves traffic
+      localization, one would expect that applications achieve a higher
+      throughput and/or smaller delays to retrieve data.  If
+      application-specific performance characteristics (e.g., video or
+      audio quality) can be monitored, such metrics related to user
+      experience could also help to analyze the benefit of an ALTO
+      deployment.  If available, selected statistics from the TCP/IP
+      stack in hosts could be leveraged, too.
+
+   Of potential interest can also be the share of applications or
+   customers that actually use an offered ALTO service, i.e., the
+   adoption of the service.
+
+   Monitoring statistics can be aggregated, averaged, and normalized in
+   different ways.  This document does not mandate specific ways how to
+   calculate metrics.
+
+3.4.3.  System and Service Performance
+
+   A number of interesting parameters can be measured at the ALTO
+   server.  [RFC7285] suggests certain ALTO-specific metrics to be
+   monitored:
+
+   o  Requests and responses for each service listed in an Information
+      Directory (total counts and size in bytes).
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 34]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   o  CPU and memory utilization
+
+   o  ALTO map updates
+
+   o  Number of PIDs
+
+   o  ALTO map sizes (in-memory size, encoded size, number of entries)
+
+   This data characterizes the workload, the system performance as well
+   as the map data.  Obviously, such data will depend on the
+   implementation and the actual deployment of the ALTO service.
+   Logging is also recommended in [RFC7285].
+
+3.4.4.  Monitoring Infrastructures
+
+   Understanding the impact of ALTO may require interaction between
+   different systems operating at different layers.  Some information
+   discussed in the preceding sections is only visible to an ISP, while
+   application-level performance can hardly be measured inside the
+   network.  It is possible that not all information of potential
+   interest can directly be measured, either because no corresponding
+   monitoring infrastructure or measurement method exists or because it
+   is not easily accessible.
+
+   One way to quantify the benefit of deploying ALTO is to measure
+   before and after enabling the ALTO service.  In addition to passive
+   monitoring, some data could also be obtained by active measurements,
+   but due to the resulting overhead, the latter should be used with
+   care.  Yet, in all monitoring activities, an ALTO service provider
+   has to take into account that ALTO clients are not bound to ALTO
+   server guidance as ALTO is only one source of information, and any
+   measurement result may thus be biased.
+
+   Potential sources for monitoring the use of ALTO include:
+
+   o  Network monitoring and performance management systems: Many ISPs
+      deploy systems to monitor the network traffic, which may have
+      insight into traffic volumes, network topology, bandwidth
+      information inside the management area.  Data can be obtained by
+      SNMP, NETCONF, IP Flow Information Export (IPFIX), syslog, etc.
+      On-demand OAM tests (such as Ping or BDF) could also be used.
+
+   o  Applications/clients: Relevant data could be obtained by
+      instrumentation of applications.
+
+   o  ALTO server: If available, log files or other statistics data
+      could be analyzed.
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 35]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   o  Other application entities: In several use cases, there are other
+      application entities that could provide data as well.  For
+      instance, there may be centralized log servers that collect data.
+
+   In many ALTO use cases, some data sources are located within an ISP
+   network while some other data is gathered at the application level.
+   Correlation of data could require a collaboration agreement between
+   the ISP and an application owner, including agreements of data
+   interchange formats, methods of delivery, etc.  In practice, such a
+   collaboration may not be possible in all use cases of ALTO, because
+   the monitoring data can be sensitive and because the interacting
+   entities may have different priorities.  Details of how to build an
+   overarching monitoring system for evaluating the benefits of ALTO are
+   outside the scope of this memo.
+
+3.5.  Abstract Map Examples for Different Types of ISPs
+
+3.5.1.  Small ISP with Single Internet Uplink
+
+   The ALTO protocol does not mandate how to determine costs between
+   endpoints and/or determine map data.  In complex usage scenarios,
+   this can be a non-trivial problem.  In order to show the basic
+   principle, this and the following sections explain for different
+   deployment scenarios how ALTO maps could be structured.
+
+   For a small ISP, the inter-domain traffic optimizing problem is how
+   to decrease the traffic exchanged with other ISPs, because of high
+   settlement costs.  By using the ALTO service to optimize traffic, a
+   small ISP can define two "optimization areas": one is its own network
+   and the other one consists of all other network destinations.  The
+   cost map can be defined as follows: the cost of a link between
+   clients of the inner ISP's network is lower than between clients of
+   the outer ISP's network and clients of inner ISP's network.  As a
+   result, a host with an ALTO client inside the network of this ISP
+   will prefer retrieving data from hosts connected to the same ISP.
+
+   An example is given in Figure 9.  It is assumed that ISP A is a small
+   ISP only having one access network.  As operator of the ALTO service,
+   ISP A can define its network to be one optimization area, named as
+   PID1, and define other networks to be the other optimization area,
+   named as PID2.  C1 is denoted as the cost inside the network of ISP
+   A.  C2 is denoted as the cost from PID2 to PID1, and C3 from PID1 to
+   PID2.  In the following, C2=C3 is assumed for the sake of simplicity.
+   In order to keep traffic local inside ISP A, it makes sense to define
+   C1<C2.
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 36]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+              -----------
+          ////           \\\\
+        //                   \\
+      //                       \\                  /-----------\
+     | +---------+               |             ////             \\\\
+     | | ALTO    |  ISP A        |    C2      |    Other Networks   |
+    |  | Service |  PID 1         <-----------     PID 2
+     | +---------+  C1           |----------->|                     |
+     |                           |  C3 (=C2)   \\\\             ////
+      \\                       //                  \-----------/
+        \\                   //
+          \\\\           ////
+              -----------
+
+             Figure 9: Example ALTO Deployment for a Small ISP
+
+   A simplified extract of the corresponding ALTO network and cost maps
+   is listed in Figures 10 and 11, assuming that the network of ISP A
+   has the IPv4 address ranges 192.0.2.0/24 and 198.51.100.0/25, as well
+   as the IPv6 address range 2001:db8:100::/48.  In this example, the
+   cost values C1 and C2 can be set to any number C1<C2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 37]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+      HTTP/1.1 200 OK
+      ...
+      Content-Type: application/alto-networkmap+json
+
+      {
+       ...
+        "network-map" : {
+          "PID1" : {
+            "ipv4" : [
+              "192.0.2.0/24",
+              "198.51.100.0/25"
+            ],
+            "ipv6" : [
+              "2001:db8:100::/48"
+            ]
+          },
+          "PID2" : {
+            "ipv4" : [
+              "0.0.0.0/0"
+            ],
+            "ipv6" : [
+              "::/0"
+            ]
+          }
+        }
+      }
+
+                    Figure 10: Example ALTO Network Map
+
+      HTTP/1.1 200 OK
+      ...
+      Content-Type: application/alto-costmap+json
+
+      {
+          ...
+          "cost-type" : {"cost-mode"  : "numerical",
+                         "cost-metric": "routingcost"
+          }
+        },
+        "cost-map" : {
+          "PID1": { "PID1": C1,  "PID2": C2 },
+          "PID2": { "PID1": C2,  "PID2": 0 },
+        }
+      }
+
+                     Figure 11: Example ALTO Cost Map
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 38]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+3.5.2.  ISP with Several Fixed-Access Networks
+
+   This example discusses a P2P application traffic optimization use
+   case for a larger ISP with a fixed network comprising several access
+   networks and a core network.  The traffic optimizing objectives
+   include (1) using the backbone network efficiently, (2) adjusting the
+   traffic balance in different access networks according to traffic
+   conditions and management policies, and (3) achieving a reduction of
+   settlement costs with other ISPs.
+
+   Such a large ISP deploying an ALTO service may want to optimize its
+   traffic according to the network topology of its access networks.
+   For example, each access network could be defined to be one
+   optimization area, i.e., traffic should be kept local withing that
+   area if possible.  This can be achieved by mapping each area to a
+   PID.  Then, the costs between those access networks can be defined
+   according to a corresponding traffic optimizing requirement by this
+   ISP.  One example setup is further described below and also shown in
+   Figure 12.
+
+   In this example, ISP A has one backbone network and three access
+   networks, named as AN A, AN B, and AN C.  A P2P application is used
+   in this example.  For a reasonable application-level traffic
+   optimization, the first requirement could be a decrease of the P2P
+   traffic on the backbone network inside the AS of ISP A and the second
+   requirement could be a decrease of the P2P traffic to other ISPs,
+   i.e., other ASes.  The second requirement can be assumed to have
+   priority over the first one.  Also, we assume that the settlement
+   rate with ISP B is lower than with other ISPs.  ISP A can deploy an
+   ALTO service to meet these traffic distribution requirements.  In the
+   following, we will give an example of an ALTO setting and
+   configuration according to these requirements.
+
+   In the network of ISP A, the operator of the ALTO server can define
+   each access network to be one optimization area, and assign one PID
+   to each access network, such as PID 1, PID 2, and PID 3.  Because of
+   different peerings with different outer ISPs, one can define ISP B to
+   be one additional optimization area and assign PID 4 to it.  All
+   other networks can be added to a PID to be one further optimization
+   area (PID 5).
+
+   In the setup, costs (C1, C2, C3, C4, C5, C6, C7, C8) can be assigned
+   as shown in Figure 12.  Cost C1 is denoted as the link cost in inner
+   AN A (PID 1), and C2 and C3 are defined accordingly.  C4 is denoted
+   as the link cost from PID 1 to PID 2, and C5 is the corresponding
+   cost from PID 3, which is assumed to have a similar value.  C6 is the
+   cost between PID 1 and PID 3.  For simplicity, this scenario assumes
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 39]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   symmetrical costs between the AN this example.  C7 is denoted as the
+   link cost from the ISP B to ISP A.  C8 is the link cost from other
+   networks to ISP A.
+
+   According to previous discussion of the first requirement and the
+   second requirement, the relationship of these costs will be defined
+   as: (C1, C2, C3) < (C4, C5, C6) < (C7) < (C8)
+
+    +------------------------------------+         +----------------+
+    | ISP A   +---------------+          |         |                |
+    |         |    Backbone   |          |   C7    |      ISP B     |
+    |     +---+    Network    +----+     |<--------+      PID 4     |
+    |     |   +-------+-------+    |     |         |                |
+    |     |           |            |     |         |                |
+    |     |           |            |     |         +----------------+
+    | +---+--+     +--+---+     +--+---+ |
+    | |AN A  |  C4 |AN B  |  C5 |AN C  | |
+    | |PID 1 +<--->|PID 2 |<--->+PID 3 | |
+    | |C1    |     |C2    |     |C3    | |         +----------------+
+    | +---+--+     +------+     +--+---+ |         |                |
+    |     ^                        ^     |   C8    | Other Networks |
+    |     |                        |     |<--------+ PID 5          |
+    |     +------------------------+     |         |                |
+    |                  C6                |         |                |
+    +------------------------------------+         +----------------+
+
+           Figure 12: ALTO Deployment in Large ISPs with Layered
+                         Fixed-Network Structures
+
+3.5.3.  ISP with Fixed and Mobile Network
+
+   An ISP with both mobile network and fixed network may focus on
+   optimizing the mobile traffic by keeping traffic in the fixed network
+   as much as possible, because wireless bandwidth is a scarce resource
+   and traffic is costly in mobile network.  In such a case, the main
+   requirement of traffic optimization could be decreasing the usage of
+   radio resources in the mobile network.  An ALTO service can be
+   deployed to meet these needs.
+
+   Figure 13 shows an example: ISP A operates one mobile network, which
+   is connected to a backbone network.  The ISP also runs two fixed-
+   access networks AN A and AN B, which are also connected to the
+   backbone network.  In this network structure, the mobile network can
+   be defined as one optimization area, and PID 1 can be assigned to it.
+   Access networks AN A and B can also be defined as optimization areas,
+   and PID 2 and PID 3 can be assigned, respectively.  The cost values
+   are then defined as shown in Figure 13.
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 40]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   To decrease the usage of wireless link, the relationship of these
+   costs can be defined as follows:
+
+   From view of mobile network: C4 < C1 and C4 = C8.  This means that
+   clients in mobile network requiring data resources from other clients
+   will prefer clients in AN A or B to clients in the mobile network.
+   This policy can decrease the usage of wireless link and power
+   consumption in terminals.
+
+   From view of AN A: C2 < C6, C5 = maximum cost.  This means that
+   clients in other optimization area will avoid retrieving data from
+   the mobile network.
+
+   From view of AN B: Analog to the view of AN A, C3 < C8 and C9 =
+   maximum cost.
+
+   +-----------------------------------------------------------------+
+   |                                                                 |
+   |  ISP A                 +-------------+                          |
+   |               +--------+   ALTO      +---------+                |
+   |               |        |   Service   |         |                |
+   |               |        +------+------+         |                |
+   |               |               |                |                |
+   |               |               |                |                |
+   |               |               |                |                |
+   |       +-------+-------+       | C6    +--------+------+         |
+   |       |     AN A      |<--------------|      AN B     |         |
+   |       |     PID 2     |   C7  |       |      PID 3    |         |
+   |       |     C2        |-------------->|      C3       |         |
+   |       +---------------+       |       +---------------+         |
+   |             ^    |            |              |     ^            |
+   |             |    |            |              |     |            |
+   |             |    | C4         |           C8 |     |            |
+   |          C5 |    |            |              |     | C9         |
+   |             |    |   +--------+---------+    |     |            |
+   |             |    +-->|  Mobile Network  |<---+     |            |
+   |             |        |  PID 1           |          |            |
+   |             +------- |  C1              |----------+            |
+   |                      +------------------+                       |
+   +-----------------------------------------------------------------+
+
+          Figure 13: ALTO Deployment in ISPs with Mobile Network
+
+   These examples show that for ALTO in particular the relationships
+   between different costs matter; the operator of the server has
+   several degrees of freedom how to set the absolute values.
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 41]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+3.6.  Comprehensive Example for Map Calculation
+
+   In addition to the previous, abstract examples, this section presents
+   a more detailed scenario with a realistic IGP and BGP routing
+   protocol configuration.  This example was first described in
+   [MAP-CALC].
+
+3.6.1.  Example Network
+
+   Figure 14 depicts a network that is used to explain the steps carried
+   out in the course of this example.  The network consists of nine
+   routers (R1 to R9).  Two of them are border routers (R1 + R8)
+   connected to neighbored networks (AS 2 to AS 4).  Furthermore, AS 4
+   is not directly connected to the local network, but has AS 3 as
+   transit network.  The links between the routers are point-to-point
+   connections.  These connections also form the core network with the
+   2001:db8:1:0::/56 prefix.  This prefix is large enough to provide
+   addresses for all router interconnections.  In addition to the core
+   network, the local network also has five client networks attached to
+   five different routers (R2, R5, R6, R7 and R9).  Each client network
+   has a /56 prefix with 2001:db8:1:x00:: (x = [1..5]) as network
+   address.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 42]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   +-------------------+    +-----+    +-----+    +-------------------+
+   |2001:db8:1:200::/56+----+ R6  |    | R7  +----+2001:db8:1:300::/56|
+   +-------------------+    +--+--+    +--+--+    +-------------------+
+                               |          |
+   +---------------+           |          |
+   |      AS 2     |           |          |
+   |2001:db8:2::/48|           | 10       | 10
+   +------------+--+           |          |
+                |              |          |
+                |              |          |
+             +--+--+   15   +--+--+    +--+--+    +-------------------+
+             | R1  +--------+ R3  +----+ R5  |----+2001:db8:1:400::/56|
+             +--+--+        +--+--+ 5  +--+--+    +-------------------+
+                |   \      /   |          |
+                |    \    / 15 |          |
+                |     \  /     |          |           +---------------+
+                |      \/      |          |           |      AS 4     |
+                | 20   /\      | 5        | 10        |2001:db8:4::/48|
+                |     /  \     |          |           +-------+-------+
+                |    /    \ 20 |          |                   |
+                |   /      \   |          |                   |
+             +--+--+        +--+--+    +--+--+        +-------+-------+
+             | R2  |        | R4  |    | R8  +--------+      AS 3     |
+             +--+--+        +--+--+    +--+--+        |2001:db8:3::/48|
+                |              |          |           +---------------+
+                |              |          | 10
+                |              | 20       |
+   +------------+------+       |       +--+--+    +-------------------+
+   |2001:db8:1:100::/56|       +-------+ R9  +----+2001:db8:1:500::/56|
+   +-------------------+               +-----+    +-------------------+
+
+                        Figure 14: Example Network
+
+   The example network utilizes two different routing protocols, one for
+   IGP and another for EGP routing.  The used IGP is a link-state
+   protocol such as IS-IS.  The applied link weights are annotated in
+   the graph and additionally shown in Figure 15.  All links are
+   bidirectional and their weights are symmetric.  To obtain the
+   topology and routing information from the network, the topology data
+   source must be connected directly to one of the routers (R1...R9).
+   Furthermore, the topology data source must be enabled to communicate
+   with the router and vice versa.
+
+   The BGP is used in this scenario to route between autonomous systems.
+   External BGP is running on the two border routers R1 and R8.
+   Furthermore, internal BGP is used to propagate external as well as
+   internal prefixes within the network boundaries; it is running on
+   every router with an attached client network (R2, R5, R6, R7 and R9).
+
+
+
+Stiemerling, et al.           Informational                    [Page 43]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   Since no route reflector is present it is necessary to fetch routes
+   from each BGP router separately.
+
+              R1   R2   R3   R4   R5   R6   R7   R8   R9
+          R1   0   15   15   20    -    -    -    -    -
+          R2  15    0   20    -    -    -    -    -    -
+          R3  15   20    0    5    5   10    -    -    -
+          R4  20    -    5    0    5    -    -    -   20
+          R5   -    -    5    5    0    -   10   10    -
+          R6   -    -   10    -    -    0    -    -    -
+          R7   -    -    -    -   10    -    0    -    -
+          R8   -    -    -    -   10    -    -    0   10
+          R9   -    -    -   20    -    -    -   10    0
+
+                  Figure 15: Example Network Link Weights
+
+   For monitoring purposes, it is possible to enable, e.g., SNMP or
+   NETCONF on the routers within the network.  This way an ALTO server
+   may obtain several additional information about the state of the
+   network.  For example, utilization, latency, and bandwidth
+   information could be retrieved periodically from the network
+   components to get and keep an up-to-date view on the network
+   situation.
+
+   In the following, it is assumed that the listed attributes are
+   collected from the network:
+
+   o  IS-IS: topology, link weights
+
+   o  BGP: prefixes, AS numbers, AS distances, or other BGP metrics
+
+   o  SNMP: latency, utilization, bandwidth
+
+3.6.2.  Potential Input Data Processing and Storage
+
+   Due to the variety of data sources available in a network, it may be
+   necessary to aggregate the information and define a suitable data
+   model that can hold the information efficiently and easily
+   accessible.  One potential model is an annotated directed graph that
+   represents the topology.  The attributes can be annotated at the
+   corresponding positions in the graph.  The following shows how such a
+   topology graph could describe the example topology.
+
+   In the topology graph, a node represents a router in the network,
+   while the edges stand for the links that connect the routers.  Both
+   routers and links have a set of attributes that store information
+   gathered from the network.
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 44]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   Each router could be associated with a basic set of information, such
+   as:
+
+   o  ID: Unique ID within the network to identify the router.
+
+   o  Neighbor IDs: List of directly connected routers.
+
+   o  Endpoints: List of connected endpoints.  The endpoints may also
+      have further attributes themselves depending on the network and
+      address type.  Such potential attributes are costs for reaching
+      the endpoint from the router, AS numbers, or AS distances.
+
+   In addition to the basic set, many more attributes may be assigned to
+   router nodes.  This mainly depends on the utilized data sources.
+   Examples for such additional attributes are geographic location, host
+   name and/or interface types, just to name a few.
+
+   The example network shown in Figure 14 represents such an internal
+   network graph where the routers R1 to R9 represent the nodes and the
+   connections between them are the links.  For instance, R2 has one
+   directly attached IPv6 endpoint that belongs to its own AS, as shown
+   in Figure 16.
+
+      ID:  2
+
+      Neighbor IDs:  1,3 (R1, R3)
+
+      Endpoints:
+
+         Endpoint:  2001:db8:1:100::/56
+
+         Weight:  10 (e.g., the default IGP metric value)
+
+         ASNumber:  1 (our own AS)
+
+         ASDistance:  0
+
+      Host Name:  R2
+
+                       Figure 16: Example Router R2
+
+   Router R8 has two attached IPv6 endpoints, as explained in Figure 17.
+   The first one belongs to a directly neighbored AS with AS number 3.
+   The AS distance from our network to AS3 is 1.  The second endpoint
+   belongs to an AS (AS4) that is no direct neighbor but directly
+   connected to AS3.  To reach endpoints in AS4, it is necessary to
+   cross AS3, which increases the AS distance by one.
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 45]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+      ID:  8
+
+      Neighbor IDs:  5,9 (R5, R9)
+
+      Endpoints:
+
+         Endpoint:  2001:db8:3::/48
+
+         Weight:  100
+
+         ASNumber:  3
+
+         ASDistance:  1
+
+         Endpoint:  2001:db8:4::/48
+
+         Weight:  200
+
+         ASNumber:  4
+
+         ASDistance:  2
+
+      Host Name:  R8
+
+                       Figure 17: Example Router R8
+
+   A potential set of attributes for a link is described in the
+   following list:
+
+   o  Source ID: ID of the source router of the link.
+
+   o  Destination ID: ID of the destination router of the link.
+
+   o  Weight: The cost to cross the link, e.g., defined by the used IGP.
+
+   Additional attributes that provide technical details and state
+   information can be assigned to links as well.  The availability of
+   such additional attributes depends on the utilized data sources.
+   Such attributes can be characteristics like maximum bandwidth,
+   utilization, or latency on the link as well as the link type.
+
+   In the example, the link attributes are equal for all links and only
+   their values differ.  It is assumed that the attributes utilization,
+   bandwidth, and latency are collected, e.g., via SNMP or NETCONF.  In
+   the topology of Figure 14, the links between R1 and R2 would then
+   have the following link attributes explained in Figure 18:
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 46]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+      R1->R2:
+
+      Source ID:  1
+
+      Destination ID:  2
+
+      Weight:  15
+
+      Bandwidth:  10 Gbit/s
+
+      Utilization:  0.1
+
+      Latency:  2 ms
+
+      R2->R1:
+
+      Source ID:  2
+
+      Destination ID:  1
+
+      Weight:  15
+
+      Bandwidth:  10 Gbit/s
+
+      Utilization:  0.55
+
+      Latency:  5 ms
+
+                        Figure 18: Link Attributes
+
+   It has to be emphasized that values for utilization and latency can
+   be very volatile.
+
+3.6.3.  Calculation of Network Map from the Input Data
+
+   The goal of the ALTO map calculation process is to get from the graph
+   representation of the network to a coarser-grained and abstract
+   matrix representation.  The first step is to generate the network
+   map.  Only after the network map has been generated is it possible to
+   compute the cost map since it relies on the network map.
+
+   To generate an ALTO network map, a grouping function is required.  A
+   grouping function processes information from the network graph to
+   group endpoints into PIDs.  The way of grouping is manifold and
+   algorithms can utilize any information provided by the network graph
+   to perform the grouping.  The functions may omit certain endpoints in
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 47]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   order to simplify the map or in order to hide details about the
+   network that are not intended to be published in the resulting ALTO
+   network map.
+
+   For IP endpoints, which are either an IP (version 4 or version 6)
+   address or prefix, [RFC7285] requires the use of a longest-prefix
+   matching algorithm to map IPs to PIDs.  This requirement results in
+   the constraints that every IP must be mapped to a PID and the same
+   prefix or address not be mapped to more than one PID.  To meet the
+   first constraint, every calculated map must provide a default PID
+   that contains the prefixes 0.0.0.0/0 for IPv4 and ::/0 for IPv6.
+   Both prefixes cover their entire address space, and if no other PID
+   matches an IP endpoint, the default PID will.  The second constraint
+   must be met by the grouping function that assigns endpoints to PIDs.
+   In case of collision, the grouping function must decide to which PID
+   an endpoint is assigned.  These or other constraints may apply to
+   other endpoint types depending on the used matching algorithm.
+
+   A simple example for such grouping is to compose PIDs by host names.
+   For instance, each router's host name is selected as the name for a
+   PID and the attached endpoints are the member endpoints of the
+   corresponding PID.  Additionally, backbone prefixes should not appear
+   in the map so they are filtered out.  The following table in
+   Figure 19 shows the resulting ALTO network map, using the network in
+   Figure 14 as example:
+
+          PID  |  Endpoints
+      ---------+-----------------------------------
+           R1  |  2001:db8:2::/48
+           R2  |  2001:db8:1:100::/56
+           R5  |  2001:db8:1:400::/56
+           R6  |  2001:db8:1:200::/56
+           R7  |  2001:db8:1:300::/56
+           R8  |  2001:db8:3::/48, 2001:db8:4::/48
+           R9  |  2001:db8:1:500::/56
+       default |  0.0.0.0/0, ::/0
+
+                    Figure 19: Example ALTO Network Map
+
+   Since router R3 and R4 have no endpoints assigned, they are not
+   represented in the network map.  Furthermore, as previously
+   mentioned, the "default" PID was added to represent all endpoints
+   that are not part of the example network.
+
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 48]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+3.6.4.  Calculation of Cost Map
+
+   After successfully creating the network map, the typical next step is
+   to calculate the costs between the generated PIDs, which form the
+   cost map.  Those costs are calculated by cost functions.  A cost
+   function may calculate unidirectional values, which means it is
+   necessary to compute the costs from every PID to every PID.  In
+   general, it is possible to use all available information in the
+   network graph to compute the costs.  In case a PID contains more than
+   one IP address or prefix, the cost function may first calculate a set
+   of cost values for each source/destination IP pair.  In that case, a
+   tiebreaker function is required to decide the resulting cost value,
+   as [RFC7285] allows one cost value only between two PIDs.  Such a
+   tiebreaker can be a simple function such as minimum, maximum, or
+   average value.
+
+   No matter what metric the cost function uses, the path from source to
+   destination is usually defined by the path with minimum weight.  When
+   the link weight is represented by an additive metric, the path weight
+   is the sum of link weights of all traversed links.  The path may be
+   determined, for instance, with the Bellman-Ford or Dijkstra
+   algorithms.  The latter progressively builds the shortest path in
+   terms of cumulated link lengths.  In our example, the link lengths
+   are link weights with values illustrated in Figure 15.  Hence, the
+   cost function generally extracts the optimal path with respect to a
+   chosen metric, such as the IGP link weight.  It is also possible that
+   more than one path with the same minimum weight exists, which means
+   it is not entirely clear which path is going to be selected by the
+   network.  Hence, a tiebreaker similar to the one used to resolve
+   costs for PIDs with multiple endpoints is necessary.
+
+   An important note is that [RFC7285] does not require cost maps to
+   provide costs for every PID pair, so if no path cost can be
+   calculated for a certain pair, the corresponding field in the cost
+   map is left out.  Administrators may also not want to provide cost
+   values for some PID pairs due to various reasons.  Such pairs may be
+   defined before the cost calculation is performed.
+
+   Based on the network map example shown in the previous section, it is
+   possible to calculate the cost maps.  Figure 20 provides an example
+   where the selected metric for the cost map is the minimum number of
+   hops necessary to get from the endpoints in the source PID to
+   endpoints in the destination PID.  Our chosen tiebreaker selects the
+   minimum hop count when more than one value is returned by the cost
+   function.
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 49]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+         PID  | default | R1  | R2  | R5  | R6  | R7  | R8  | R9  |
+      --------+---------+-----+-----+-----+-----+-----+-----+-----|
+      default |    x    |  x  |  x  |  x  |  x  |  x  |  x  |  x  |
+         R1   |    x    |  0  |  2  |  3  |  3  |  4  |  4  |  3  |
+         R2   |    x    |  2  |  0  |  3  |  3  |  4  |  4  |  4  |
+         R5   |    x    |  3  |  3  |  0  |  3  |  2  |  2  |  3  |
+         R6   |    x    |  3  |  3  |  3  |  0  |  4  |  4  |  4  |
+         R7   |    x    |  4  |  4  |  2  |  4  |  0  |  3  |  4  |
+         R8   |    x    |  4  |  4  |  2  |  4  |  3  |  0  |  2  |
+         R9   |    x    |  3  |  4  |  3  |  4  |  4  |  2  |  0  |
+
+                Figure 20: Example ALTO Hop Count Cost Map
+
+   It should be mentioned that R1->R9 has several paths with equal path
+   weights.  The paths R1->R3->R5->R8->R9, R1->R3->R4->R9, and
+   R1->R4->R9 all have a path weight of 40.  Due to the minimum hop
+   count value tiebreaker, 3 hops is chosen as value for the path
+   R1->R4->R9.  Furthermore, since the "default" PID is, in a sense, a
+   virtual PID with no endpoints that are part of the example network,
+   no cost values are calculated for other PIDs from or towards it.
+
+3.7.  Deployment Experiences
+
+   There are multiple interoperable implementations of the ALTO
+   protocol.  Some experiences in implementing and using ALTO for large-
+   scale networks have been documented in [MAP-CALC] and are here
+   summarized:
+
+   o  Data collection: Retrieving topology information typically
+      requires implementing several protocols other than ALTO for data
+      collection.  For such other protocols, ALTO deployments faced
+      protocol behaviors that were different from what would be expected
+      from the specification of the corresponding protocol.  This
+      includes behavior caused by older versions of the protocol
+      specification, a lax interpretation on the remote side or simply
+      incompatibility with the corresponding standard.  This sort of
+      problems in collecting data can make an ALTO deployment more
+      complicated, even if it is unrelated to ALTO protocol itself.
+
+   o  Data processing: Processing network information can be very
+      complex and quite resource demanding.  Gathering information from
+      an autonomous system connected to the Internet may imply that a
+      server must store and process hundreds of thousands of prefixes,
+      several hundreds of megabytes of IPFIX/Netflow information per
+      minute, and information from hundreds of routers and attributes of
+      thousands of links.  A lot of disk memory, RAM, and CPU cycles as
+      well as efficient algorithms are required to process the
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 50]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+      information.  Operators of an ALTO server have to be aware that
+      significant compute resources are not only required for the ALTO
+      server, but also for the corresponding data collection.
+
+   o  Network map calculation: Large IP-based networks consist of
+      hundreds of thousands of prefixes that have to be mapped to PIDs
+      in the process of network map calculation.  As a result, network
+      maps get very large (up to tens of megabytes).  However, depending
+      on the design of the network and the chosen grouping function the
+      calculated network maps contains redundancy that can be removed.
+      There are at least two ways to reduce the size by removing
+      redundancy.  First, adjacent IP prefixes can be merged.  When a
+      PID has two adjacent prefix entries it can merge them together to
+      one larger prefix.  It is mandatory that both prefixes be in the
+      same PID.  However, the large prefix being assigned to another PID
+      cannot be ruled out.  This must be checked, and it is up to the
+      grouping function whether or not to merge the prefixes and remove
+      the larger prefix from the other PID.  A simple example, when a
+      PID comprises the prefixes 2001:db8:0:0::/64 and 2001:db8:0:1::/64
+      it can easily merge them to 2001:db8:0:0::/63.  Second, a prefix
+      and its next-longest-prefix match may be in the same PID.  In this
+      case, the smaller prefix can simply be removed since it is
+      redundant for obvious reasons.  A simple example, a PID comprises
+      the prefixes 2001:db8:0:0::/62 and 2001:db8:0:1::/64 and the /62
+      is the next-longer prefix match of the /64, the /64 prefix can
+      simply be removed.  In contrast, if another PID contains the
+      2001:db8:0:0::/63 prefix, the entry 2001:db8:0:1::/64 cannot be
+      removed since the next-longest prefix is not in the same PID
+      anymore.  Operators of an ALTO server thus have to analyze whether
+      their address assignment schemes allows such tuning.
+
+   o  Cost map calculation: One known implementation challenge with cost
+      map calculations is the vast amount of CPU cycles that may be
+      required to calculate the costs in large networks.  This is
+      particular problematic if costs are calculated between the
+      endpoints of each source-destination PID pair.  Very often several
+      to many endpoints of a PID are attached to the same node, so the
+      same path cost is calculated several times.  This is clearly
+      inefficient.  A remedy could be more sophisticated algorithms,
+      such as looking up the routers the endpoints of each PID are
+      connected to in our network graph and calculated cost map based on
+      the costs between the routers.  When deploying and configuring
+      ALTO servers, administrators should consider the impact of huge
+      cost maps and possibly ensure that map sizes do not get too large.
+
+   In addition, further deployment experiences have been documented.
+   One real example is described in greater detail in reference
+   [CHINA-TRIAL].
+
+
+
+Stiemerling, et al.           Informational                    [Page 51]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   Also, experiments have been conducted with ALTO-like deployments in
+   ISP networks.  For instance, NTT performed tests with their HINT
+   server implementation and dummy nodes to gain insight on how an ALTO-
+   like service can influence peer-to-peer systems [RFC6875].  The
+   results of an early experiment conducted in the Comcast network are
+   documented in [RFC5632].
+
+4.  Using ALTO for P2P Traffic Optimization
+
+4.1.  Overview
+
+4.1.1.  Usage Scenario
+
+   Originally, P2P applications were the main driver for the development
+   of ALTO.  In this use case, it is assumed that one party (usually the
+   operator of a "managed" IP network domain) will disclose information
+   about the network through ALTO.  The application overlay will query
+   this information and optimize its behavior in order to improve
+   performance or Quality of Experience in the application while
+   reducing the utilization of the underlying network infrastructure.
+   The resulting win-win situation is assumed to be the incentive for
+   both parties to provide or consume the ALTO information,
+   respectively.
+
+   P2P systems can be built with or without use of a centralized
+   resource directory ("tracker").  The scope of this section is the
+   interaction of P2P applications with the ALTO service.  In this
+   scenario, the resource consumer ("peer") asks the resource directory
+   for a list of candidates that can provide the desired resource.
+   There are different options for how ALTO can be deployed in such use
+   cases with a centralized resource directory.
+
+   For efficiency reasons (i.e., message size), only a subset of all
+   resource providers known to the resource directory will be returned
+   to the resource consumer.  Some or all of these resource providers,
+   plus further resource providers learned by other means such as direct
+   communication between peers, will be contacted by the resource
+   consumer for accessing the resource.  The purpose of ALTO is giving
+   guidance on this peer selection, which should yield better-than-
+   random results.  The tracker response as well as the ALTO guidance
+   are most beneficial in the initial phase after the resource consumer
+   has decided to access a resource, as long as only few resource
+   providers are known.  Later, when the resource consumer has already
+   exchanged some data with other peers and measured the transmission
+   speed, the relative importance of ALTO may dwindle.
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 52]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+4.1.2.  Applicability of ALTO
+
+   A tracker-based P2P application can leverage ALTO in different ways.
+   In the following, the different alternatives and their pros and cons
+   are discussed.
+
+                            ,-------.         +-----------+
+          ,---.          ,-'         ========>|   Peer 1  |********
+       ,-'     `-.      /     ISP 1  V  \     |ALTO Client|       *
+      /           \    / +-------------+ \    +-----------+       *
+     /    ISP X    \   | + ALTO Server | |    +-----------+       *
+    /               \  \ +-------------+<====>|   Peer 2  |       *
+   ;   +---------+   :  \               /     |ALTO Client|****** *
+   |   | Global  |   |   `-.         ,-'      +-----------+     * *
+   |   | Tracker |   |      `-------'                           * *
+   |   +---------+   |      ,-------.         +-----------+     * *
+   :        *        ;   ,-'         ========>|   Peer 3  |     * *
+    \       *       /   /     ISP 2  V  \     |ALTO Client|**** * *
+     \      *      /   / +-------------+ \    +-----------+   * * *
+      \     *     /    | | ALTO Server | |    +-----------+   * * *
+       `-.  *  ,-'     \ +-------------+<====>|   Peer 4  |** * * *
+          `-*-'         \               /     |ALTO Client| * * * *
+            *            `-.         ,-'      +-----------+ * * * *
+            *               `-------'                       * * * *
+            *                                               * * * *
+            *******************************************************
+       Legend:
+       === ALTO protocol
+       *** Application protocol
+
+             Figure 21: Global Tracker and Local ALTO Servers
+
+   Figure 21 depicts a tracker-based P2P system with several peers.  The
+   peers (i.e., resource consumers) embed an ALTO client to improve the
+   resource provider selection.  The tracker (i.e., resource directory)
+   itself may be hosted and operated by another entity.  A tracker
+   external to the ISPs of the peers may be a typical use case.  For
+   instance, a tracker like Pirate Bay can serve BitTorrent peers
+   worldwide.  The figure only shows one tracker instance, but
+   deployments with several trackers could be possible, too.
+
+   The scenario depicted in Figure 21 lets the peers directly
+   communicate with their ISP's ALTO server (i.e., ALTO client embedded
+   in the peers), thus giving the peers the most control on which
+   information they query for, as they can integrate information
+   received from one tracker or several trackers and through direct
+   peer-to-peer knowledge exchange.  For instance, the latter approach
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 53]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   is called peer exchange (PEX) in BitTorrent.  In this deployment
+   scenarios, the peers have to discover a suitable ALTO server (e.g.,
+   offered by their ISP, as described in [RFC7286]).
+
+   There are also tracker-less P2P system architectures that do not rely
+   on centralized resource directories, e.g., unstructured P2P networks.
+   Regarding the use of ALTO, their deployment would be similar to
+   Figure 21, since the ALTO client would be embedded in the peers as
+   well.  This option is not further considered in this memo.
+
+                                 ,-------.
+          ,---.               ,-'         `-.   +-----------+
+       ,-'     `-.           /     ISP 1     \  |   Peer 1  |********
+      /           \         / +-------------+ \ |           |       *
+     /    ISP X    \   ++====>| ALTO Server |  )+-----------+       *
+    /               \  ||   \ +-------------+ / +-----------+       *
+   ; +-----------+   : ||    \               /  |   Peer 2  |       *
+   | |  Tracker  |<====++     `-.         ,-'   |           |****** *
+   | |ALTO Client|   |           `-------'      +-----------+     * *
+   | +-----------+<====++        ,-------.                        * *
+   :        *        ; ||     ,-'         `-.   +-----------+     * *
+    \       *       /  ||    /     ISP 2     \  |   Peer 3  |     * *
+     \      *      /   ||   / +-------------+ \ |           |**** * *
+      \     *     /    ++====>| ALTO Server |  )+-----------+   * * *
+       `-.  *  ,-'          \ +-------------+ / +-----------+   * * *
+          `-*-'              \               /  |   Peer 4  |** * * *
+            *                 `-.         ,-'   |           | * * * *
+            *                    `-------'      +-----------+ * * * *
+            *                                                 * * * *
+            *                                                 * * * *
+            *********************************************************
+       Legend:
+       === ALTO protocol
+       *** Application protocol
+
+      Figure 22: Global Tracker Accessing ALTO Server at Various ISPs
+
+   An alternative deployment scenario for a tracker-based system is
+   depicted in Figure 22.  Here, the tracker embeds the ALTO client.
+   When the tracker receives a request from a querying peer, it first
+   discovers the ALTO server responsible for the querying peer.  This
+   discovery can be done by using various ALTO server discovery
+   mechanisms [RFC7286] [XDOM-DISC].  The ALTO client subsequently sends
+   to the querying peer only those peers that are preferred by the ALTO
+   server responsible for the querying peer.  The peers do not query the
+   ALTO servers themselves.  This gives the peers a better initial
+   selection of candidates, but does not consider peers learned through
+   direct peer-to-peer knowledge exchange.
+
+
+
+Stiemerling, et al.           Informational                    [Page 54]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+                      ISP 1  ,-------.         +-----------+
+           ,---.          +-------------+******|   Peer 1  |
+        ,-'     `-.      /|   Tracker   |\     |           |
+       /           \    / +-------------+****  +-----------+
+      /    ISP X    \   |       ===       | *  +-----------+
+     /               \  \ +-------------+ / *  |   Peer 2  |
+    ;   +---------+   :  \| ALTO Server |/  ***|           |
+    |   | Global  |   |   +-------------+      +-----------+
+    |   | Tracker |   |      `-------'
+    |   +---------+   |                        +-----------+
+    :        *        ;      ,-------.         |   Peer 3  |
+     \       *       /    +-------------+  ****|           |
+      \      *      /    /|   Tracker   |***   +-----------+
+       \     *     /    / +-------------+ \    +-----------+
+        `-.  *  ,-'     |       ===       |    |   Peer 4  |**
+           `-*-'        \ +-------------+ /    |           | *
+             *           \| ALTO Server |/     +-----------+ *
+             *            +-------------+                    *
+             *        ISP 2  `-------'                       *
+             *************************************************
+        Legend:
+        === ALTO protocol
+        *** Application protocol
+
+      Figure 23: Local Trackers and Local ALTO Servers (P4P Approach)
+
+   There are some attempts to let ISPs deploy their own trackers, as
+   shown in Figure 23.  In this case, the client cannot get guidance
+   from the ALTO server other than by talking to the ISP's tracker,
+   which in turn communicates with the ALTO server using the ALTO
+   protocol.  It should be noted that the peers are still allowed to
+   contact other trackers operated by entities other than the peer's
+   ISP, but in this case they cannot benefit from ALTO guidance.
+
+4.2.  Deployment Recommendations
+
+4.2.1.  ALTO Services
+
+   The ALTO protocol specification [RFC7285] details how an ALTO client
+   can query an ALTO server for guiding information and receive the
+   corresponding replies.  In case of peer-to-peer networks, two
+   different ALTO services can be used: the cost map service is often
+   preferred as solution by peer-to-peer software implementors and
+   users, since it avoids disclosing peer IP addresses to a centralized
+   entity.  Alternatively, network operators may have a preference for
+   the ECS, since it does not require exposure of the network topology.
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 55]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   For actual use of ALTO in P2P applications, both software vendors and
+   network operators have to agree which ALTO services to use.  The ALTO
+   protocol is flexible and supports both services.  Note that for other
+   use cases of ALTO, in particular in more controlled environments,
+   both the cost map service and the ECS might be feasible; it is more
+   of an engineering trade-off whether to use a map-based or query-based
+   ALTO service.
+
+4.2.2.  Guidance Considerations
+
+   As explained in Section 4.1.2, for a tracker-based P2P application,
+   there are two fundamentally different possibilities where to place
+   the ALTO client:
+
+   1.  ALTO client in the resource consumer ("peer")
+
+   2.  ALTO client in the resource directory ("tracker")
+
+   Both approaches have advantages and drawbacks that have to be
+   considered.  If the ALTO client is in the resource consumer
+   (Figure 21), a potentially very large number of clients has to be
+   deployed.  Instead, when using an ALTO client in the resource
+   directory (Figures 22 and 23), ostensibly peers do not have to
+   directly query the ALTO server.  In this case, an ALTO server could
+   even not permit access to peers.
+
+   However, it seems to be beneficial for all participants to let the
+   peers directly query the ALTO server.  Considering the plethora of
+   different applications that could use ALTO, e.g., multiple-tracker-
+   based or non-tracker-based P2P systems or other applications
+   searching for relays, this renders the ALTO service more useful.  The
+   peers are also the single point having all operational knowledge to
+   decide whether to use the ALTO guidance and how to use the ALTO
+   guidance.  For a given peer, one can also expect that an ALTO server
+   of the corresponding ISP provides useful guidance and can be
+   discovered.
+
+   Yet, ALTO clients in the resource consumer also have drawbacks
+   compared to use in the resource directory.  In the following, both
+   scenarios are compared more in detail in order to explain the impact
+   on ALTO guidance and the need for third-party ALTO queries.
+
+   In the first scenario (see Figure 24), the peer (resource consumer)
+   queries the tracker (resource directory) for the desired resource
+   (F1).  The resource directory returns a list of potential resource
+   providers without considering ALTO (F2).  It is then the duty of the
+   resource consumer to invoke ALTO (F3/F4), in order to solicit
+   guidance regarding this list.
+
+
+
+Stiemerling, et al.           Informational                    [Page 56]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   Peer w. ALTO cli.            Tracker               ALTO Server
+   --------+--------       --------+--------       --------+--------
+           | F1 Tracker query      |                       |
+           |======================>|                       |
+           | F2 Tracker reply      |                       |
+           |<======================|                       |
+           | F3 ALTO protocol query                        |
+           |---------------------------------------------->|
+           | F4 ALTO protocol reply                        |
+           |<----------------------------------------------|
+           |                       |                       |
+
+   ====  Application protocol (i.e., tracker-based P2P app protocol)
+   ----  ALTO protocol
+
+                Figure 24: Basic Message Sequence Chart for
+                  Resource-Consumer-Initiated ALTO Query
+
+   In the second scenario (see Figure 25), the resource directory has an
+   embedded ALTO client, which we will refer to as Resource Directory
+   ALTO Client (RDAC) in this document.  After receiving a query for a
+   given resource (F1), the resource directory invokes the RDAC to
+   evaluate all resource providers it knows (F2/F3).  Then, it returns
+   a, possibly shortened, list containing the "best" resource providers
+   to the resource consumer (F4).
+
+         Peer               Tracker w. RDAC           ALTO Server
+   --------+--------       --------+--------       --------+--------
+           | F1 Tracker query      |                       |
+           |======================>|                       |
+           |                       | F2 ALTO cli. p. query |
+           |                       |---------------------->|
+           |                       | F3 ALTO cli. p. reply |
+           |                       |<----------------------|
+           | F4 Tracker reply      |                       |
+           |<======================|                       |
+           |                       |                       |
+
+   ====  Application protocol (i.e., tracker-based P2P app protocol)
+   ----  ALTO protocol
+
+    Figure 25: Basic Message Sequence Chart for Third-Party ALTO Query
+
+   Note: The message sequences depicted in Figures 24 and 25 may occur
+   both in the target-aware and the target-independent query mode (cf.
+   [RFC6708]).  In the target-independent query mode, no message
+   exchange with the ALTO server might be needed after the tracker
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 57]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   query, because the candidate resource providers could be evaluated
+   using a locally cached "map", which has been retrieved from the ALTO
+   server some time ago.
+
+   The first approach has the following problem: While the resource
+   directory might know thousands of peers taking part in a swarm, the
+   list returned to the resource consumer is usually shortened for
+   efficiency reasons.  Therefore, the "best" (in the sense of ALTO)
+   potential resource providers might not be contained in that list
+   anymore, even before ALTO can consider them.
+
+   Much better traffic optimization could be achieved if the tracker
+   would evaluate all known peers using ALTO.  This list would then
+   include a significantly higher fraction of "good" peers.  If the
+   tracker returned "good" peers only, there might be a risk that the
+   swarm might disconnect and split into several disjunct partitions.
+   However, finding the right mix of ALTO-biased and random peer
+   selection is out of the scope of this document.
+
+   Therefore, from an overall optimization perspective, the second
+   scenario with the ALTO client embedded in the resource directory is
+   advantageous, because it is ensured that the addresses of the "best"
+   resource providers are actually delivered to the resource consumer.
+   An architectural implication of this insight is that the ALTO server
+   discovery procedures must support third-party discovery.  That is, as
+   the tracker issues ALTO queries on behalf of the peer that contacted
+   the tracker, the tracker must be able to discover an ALTO server that
+   can give guidance suitable for that respective peer (see
+   [XDOM-DISC]).
+
+   In principle, a combined approach could also be possible.  For
+   instance, a tracker could use a coarse-grained "global" ALTO server
+   to find the peers in the general vicinity of the requesting peer,
+   while peers could use "local" ALTO servers for a more fine-grained
+   guidance.  Yet, there is no known deployment experience for such a
+   combined approach.
+
+5.  Using ALTO for CDNs
+
+5.1.  Overview
+
+5.1.1.  Usage Scenario
+
+   This section briefly introduces the usage of ALTO for CDNs, as
+   explained in [CDN-USE].  CDNs are used in the delivery of some
+   Internet services (e.g., delivery of websites, software updates, and
+   video delivery) from a location closer to the location of the user.
+   A CDN typically consists of a network of servers often attached to
+
+
+
+Stiemerling, et al.           Informational                    [Page 58]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   ISP networks.  The point of attachment is often as close to content
+   consumers and peering points as economically or operationally
+   feasible in order to decrease traffic load on the ISP backbone and to
+   provide better user experience measured by reduced latency and higher
+   throughput.
+
+   CDNs use several techniques to redirect a client to a server
+   (surrogate).  A request-routing function within a CDN is responsible
+   for receiving content requests from user agents, obtaining and
+   maintaining necessary information about a set of candidate
+   surrogates, and selecting and redirecting the user agent to the
+   appropriate surrogate.  One common way is relying on the DNS system,
+   but there are many other ways, see [RFC3568].
+
+   +--------------------+
+   | CDN Request Router |
+   |  with ALTO Client  |
+   +--------------------+
+             /\
+             || ALTO protocol
+             ||
+             \/
+         +---------+
+         |  ALTO   |
+         | Server  |
+         +---------+
+              :
+              : Provisioning protocol
+              :
+        ,-----------.
+     ,-'  Source of  `-.
+    (    topological    )
+     `-. information ,-'
+        `-----------'
+
+        Figure 26: Use of ALTO Information for CDN Request Routing
+
+   In order to derive the optimal benefit from a CDN, it is preferable
+   to deliver content from the servers (caches) that are "closest" to
+   the end user requesting the content.  The definition of "closest" may
+   be as simple as geographical or IP topology distance, but it may also
+   consider other combinations of metrics and CDN or ISP policies.  As
+   illustrated in Figure 26, ALTO could provide this information.
+
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 59]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   User Agent                  Request Router                 Surrogate
+        |                             |                           |
+        |     F1 Initial Request      |                           |
+        +---------------------------->|                           |
+        |                             +--+                        |
+        |                             |  | F2 Surrogate Selection |
+        |                             |<-+       (using ALTO)     |
+        |   F3 Redirection Response   |                           |
+        |<----------------------------+                           |
+        |                             |                           |
+        |     F4 Content Request      |                           |
+        +-------------------------------------------------------->|
+        |                             |                           |
+        |                             |          F5 Content       |
+        |<--------------------------------------------------------+
+        |                             |                           |
+
+               Figure 27: Example of CDN Surrogate Selection
+
+   Figure 27 illustrates the interaction between a user agent, a request
+   router, and a surrogate for the delivery of content in a single CDN.
+   As explained in [CDN-USE], the user agent makes an initial request to
+   the CDN (F1).  This may be an application-level request (e.g., HTTP)
+   or a DNS request.  In the second step (F2), the request router
+   selects an appropriate surrogate (or set of surrogates) based on the
+   user agent's (or its proxy's) IP address, the request router's
+   knowledge of the network topology (which can be obtained by ALTO) and
+   reachability cost between CDN caches and end users, and any
+   additional CDN policies.  Then, the request router responds to the
+   initial request with an appropriate response containing a redirection
+   to the selected cache (F3), for example, by returning an appropriate
+   DNS A/AAAA record or an HTTP 302 redirect, etc.  The user agent uses
+   this information to connect directly to the surrogate and request the
+   desired content (F4), which is then delivered (F5).
+
+5.1.2.  Applicability of ALTO
+
+   The most simple use case for ALTO in a CDN context is to improve the
+   selection of a CDN surrogate or origin.  In this case, the CDN makes
+   use of an ALTO server to choose a better CDN surrogate or origin than
+   would otherwise be the case.  Although it is possible to obtain raw
+   network map and cost information in other ways, for example,
+   passively listening to the ISP's routing protocols or use of active
+   probing, the use of an ALTO service to expose that information may
+   provide additional control to the ISP over how their network map/cost
+   is exposed.  Additionally, it may enable the ISP to maintain a
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 60]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   functional separation between their routing plane and network map
+   computation functions.  This may be attractive for a number of
+   reasons, for example:
+
+   o  The ALTO service could provide a filtered view of the network and/
+      or cost map that relates to CDN locations and their proximity to
+      end users, for example, to allow the ISP to control the level of
+      topology detail they are willing to share with the CDN.
+
+   o  The ALTO service could apply additional policies to the network
+      map and cost information to provide a CDN-specific view of the
+      network map/cost, for example, to allow the ISP to encourage the
+      CDN to use network links that would not ordinarily be preferred by
+      a Shortest Path First routing calculation.
+
+   o  The routing plane may be operated and controlled by a different
+      operational entity (even within a single ISP) than the CDN.
+      Therefore, the CDN may not be able to passively listen to routing
+      protocols, nor may it have access to other network topology data
+      (e.g., inventory databases).
+
+   When CDN servers are deployed outside of an ISP's network or in a
+   small number of central locations within an ISP's network, a
+   simplified view of the ISP's topology or an approximation of
+   proximity is typically sufficient to enable the CDN to serve end
+   users from the optimal server/location.  As CDN servers are deployed
+   deeper within ISP networks, it becomes necessary for the CDN to have
+   more detailed knowledge of the underlying network topology and costs
+   between network locations in order to enable the CDN to serve end
+   users from the optimal servers for the ISP.
+
+   The request router in a CDN will typically also take into account
+   criteria and constraints that are not related to network topology,
+   such as the current load of CDN surrogates, content owner policies,
+   end user subscriptions, etc.  This document only discusses use of
+   ALTO for network information.
+
+   A general issue for CDNs is that the CDN logic has to match the
+   client's IP address with the closest CDN surrogate, for approaches
+   that are both DNS or HTTP redirect based (see, for instance,
+   [ALTO-CDN]).  This matching is not trivial, for example, in DNS-based
+   approaches, where the IP address of the DNS original requester is
+   unknown (see [RFC7871] for a discussion of this and a solution
+   approach).
+
+   In addition to use by a single CDN, ALTO can also be used in
+   scenarios that interconnect several CDNs.  This use case is detailed
+   in [CDNI-FCI].
+
+
+
+Stiemerling, et al.           Informational                    [Page 61]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+5.2.  Deployment Recommendations
+
+5.2.1.  ALTO Services
+
+   In its simplest form, an ALTO server would provide an ISP with the
+   capability to offer a service to a CDN that provides network map and
+   cost information.  The CDN can use that data to enhance its surrogate
+   and/or origin selection.  If an ISP offers an ALTO Network and Cost
+   Map Service to expose a cost mapping/ranking between end user IP
+   subnets (within that ISP's network) and CDN surrogate IP subnets/
+   locations, periodic updates of the maps may be needed.  As introduced
+   in Section 3.3), it is common for broadband subscribers to obtain
+   their IP addresses dynamically, and in many deployments, the IP
+   subnets allocated to a particular network region can change
+   relatively frequently, even if the network topology itself is
+   reasonably static.
+
+   An alternative would be to use the ALTO ECS: when an end user
+   requests a given content, the CDN request router issues an ECS
+   request with the endpoint address (IPv4/IPv6) of the end user
+   (content requester) and the set of endpoint addresses of the
+   surrogate (content targets).  The ALTO server receives the request
+   and ranks the addresses based on their distance from the content
+   requester.  Once the request router obtained from the ALTO server the
+   ranked list of locations (for the specific user), it can incorporate
+   this information into its selection mechanisms in order to point the
+   user to the most appropriate surrogate.
+
+   Since CDNs operate in a controlled environment, the ALTO Network and
+   Cost Map Service and ECS have a similar level of security and
+   confidentiality of network-internal information.  However, the
+   Network and Cost Map Service and ECS differ in the way the ALTO
+   service is delivered and address a different set of requirements in
+   terms of topology information and network operations.
+
+   If a CDN already has means to model connectivity policies, the map-
+   based approaches could possibly be integrated into that.  If the ECS
+   service is preferred, a request router that uses ECS could cache the
+   results of ECS queries for later usage in order to address the
+   scalability limitations of ECS and to reduce the number of
+   transactions between the CDN and ALTO server.  The ALTO server may
+   indicate in the reply message how long the content of the message is
+   to be considered reliable and insert a lifetime value that will be
+   used by the CDN in order to cache (and then flush or refresh) the
+   entry.
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 62]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+5.2.2.  Guidance Considerations
+
+   The following discusses how a CDN could make use of ALTO services.
+
+   In one deployment scenario, ALTO could expose ISP end-user
+   reachability to a CDN.  The request router needs to have information
+   about which end-user IP subnets are reachable via which networks or
+   network locations.  The network map services offered by ALTO could be
+   used to expose this topology information while avoiding routing-plane
+   peering between the ISP and the CDN.  For example, if CDN surrogates
+   are deployed within the access or aggregation network, the ISP is
+   likely to want to utilize the surrogates deployed in the same access/
+   aggregation region in preference to surrogates deployed elsewhere, in
+   order to alleviate the cost and/or improve the user experience.
+
+   In addition, CDN surrogates could also use ALTO guidance, e.g., if
+   there is more than one upstream source of content or several origins.
+   In this case, ALTO could help a surrogate with the decision about
+   which upstream source to use.  This specific variant of using ALTO is
+   not further detailed in this document.
+
+   If content can be provided by several CDNs, there may be a need to
+   interconnect these CDNs.  In this case, ALTO can be used as an
+   interface [CDNI-FCI], in particular, for footprint and capabilities
+   advertisement.
+
+   Other, and more advanced, scenarios of deploying ALTO are also listed
+   in [CDN-USE] and [ALTO-CDN].
+
+   The granularity of ALTO information required depends on the specific
+   deployment of the CDN.  For example, an "over-the-top" CDN whose
+   surrogates are deployed only within the Internet backbone may only
+   require knowledge of which end-user IP subnets are reachable via
+   which ISP's networks, whereas a CDN deployed within a particular
+   ISP's network requires a finer granularity of knowledge.
+
+   An ALTO server ranks addresses based on topology information it
+   acquires from the network.  By default, according to [RFC7285],
+   distance in ALTO represents an abstract "routingcost" that can be
+   computed, for instance, from routing protocol information.  But an
+   ALTO server may also take into consideration other criteria or other
+   information sources for policy, state, and performance information
+   (e.g., geolocation), as explained in Section 3.2.2.
+
+   The different methods and algorithms through which the ALTO server
+   computes topology information and rankings is out of the scope of
+   this document.  If rankings are based on routing protocol
+   information, it is obvious that network events may impact the ranking
+
+
+
+Stiemerling, et al.           Informational                    [Page 63]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   computation.  Due to internal redundancy and resilience mechanisms
+   inside current networks, most of the network events happening in the
+   infrastructure will be handled internally in the network, and they
+   should have limited impact on a CDN.  However, catastrophic events
+   such as main trunks failures or backbone partitioning will have to be
+   taken into account by the ALTO server to redirect traffic away from
+   the impacted area.
+
+   An ALTO server implementation may want to keep state about ALTO
+   clients in order to inform and signal to these clients when a major
+   network event happened, e.g., by a notification mechanism.  In a CDN/
+   ALTO interworking architecture with few CDN components interacting
+   with the ALTO server, there are less scalability issues in
+   maintaining state about clients in the ALTO server, compared to ALTO
+   guidance to any Internet user.
+
+6.  Other Use Cases
+
+   This section briefly surveys and references other use cases that have
+   been tested or suggested for ALTO deployments.
+
+6.1.  Application Guidance in Virtual Private Networks (VPNs)
+
+   Virtual Private Network (VPN) technology is widely used in public and
+   private networks to create groups of users that are separated from
+   other users of the network and allows these users to communicate
+   among themselves as if they are on a private network.  Network
+   Service Providers (NSPs) offer different types of VPNs.  [RFC4026]
+   distinguishes between Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN)
+   using different sub-types.  In the following, the term "VPN" is used
+   to refer to provider supplied virtual private networking.
+
+   From the perspective of an application at an endpoint, a VPN may not
+   be very different from any other IP connectivity solution, but there
+   are a number of specific applications that could benefit from ALTO
+   topology exposure and guidance in VPNs.  As, in the general Internet,
+   one advantage is that applications do not have to perform excessive
+   measurements on their own.  For instance, potential use cases for
+   ALTO application guidance in VPN environments are:
+
+   o  Enterprise application optimization: Enterprise customers often
+      run distributed applications that exchange large amounts of data,
+      e.g., for synchronization of replicated data bases.  Network
+      topology information could be useful for placement of replicas as
+      well as for the scheduling of transfers.
+
+   o  Private cloud computing solution: An enterprise customer could run
+      its own data centers at several sites.  The cloud management
+
+
+
+Stiemerling, et al.           Informational                    [Page 64]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+      system could want to understand the network costs between
+      different sites for intelligent routing and placement decisions of
+      Virtual Machines (VMs) among the VPN sites.
+
+   o  Cloud-bursting: One or more VPN endpoints could be located in a
+      public cloud.  If an enterprise customer needs additional
+      resources, they could be provided by a public cloud, which is
+      accessed through the VPN.  Network topology awareness would help
+      to decide in which data center of the public cloud those resources
+      should be allocated.
+
+   These examples focus on enterprises, which are typical users of VPNs.
+   VPN customers typically have no insight into the network topology
+   that transports the VPN.  Similar to other ALTO use cases, better-
+   than-random application-level decisions would be enabled by an ALTO
+   server offered by the NSP, as illustrated in Figure 28.
+
+                       +---------------+
+                       |  Customer's   |
+                       |   management  |
+                       |  application  |.
+                       | (ALTO client) |  .
+                       +---------------+    .  VPN provisioning
+                              /\              . (out-of-scope)
+                              || ALTO           .
+                              \/                  .
+                    +---------------------+       +----------------+
+                    |     ALTO server     |       | VPN portal/OSS |
+                    |   provided by NSP   |       | (out-of-scope) |
+                    +---------------------+       +----------------+
+                               : VPN network
+                               : and cost maps
+                               :
+                     /---------:---------\ Network service provider
+                     |         :         |
+        +-------+   _______________________   +-------+
+        | App a | ()_____. .________. .____() | App d |
+        +-------+    |   | |        | |  |    +-------+
+                     \---| |--------| |--/
+                         | |        | |
+                         |^|        |^| Customer VPN
+                          V          V
+                      +-------+  +-------+
+                      | App b |  | App c |
+                      +-------+  +-------+
+
+                       Figure 28: Using ALTO in VPNs
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 65]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   A common characteristic of these use cases is that applications will
+   not necessarily run in the public Internet, and that the relationship
+   between the provider and customer of the VPN is rather well defined.
+   Since VPNs often run in a managed environment, an ALTO server may
+   have access to topology information (e.g., traffic engineering data)
+   that would not be available for the public Internet, and it may
+   expose it to the customer of the VPN only.
+
+   Also, a VPN will not necessarily be static.  The customer could
+   possibly modify the VPN and add new VPN sites by a Web portal,
+   network management systems, or other OSS solutions.  Prior to adding
+   a new VPN site, an application will not have connectivity to that
+   site, i.e., an ALTO server could offer access to information that an
+   application cannot measure on its own (e.g., expected delay to a new
+   VPN site).
+
+   The VPN use cases, requirements, and solutions are further detailed
+   in [VPN-SERVICE].
+
+6.2.  In-Network Caching
+
+   Deployment of intra-domain P2P caches has been proposed for
+   cooperation between the network operator and the P2P service
+   providers, e.g., to reduce the bandwidth consumption in access
+   networks [ALTO-P2PCACHE].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 66]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+            +--------------+                +------+
+            | ISP 1 network+----------------+Peer 1|
+            +-----+--------+                +------+
+            |
+   +--------+------------------------------------------------------+
+   |        |                                      ISP 2 network   |
+   |  +---------+                                                  |
+   |  |L1 Cache |                                                  |
+   |  +-----+---+                                                  |
+   |        +--------------------+----------------------+          |
+   |        |                    |                      |          |
+   | +------+------+      +------+-------+       +------+-------+  |
+   | | AN1         |      | AN2          |       | AN3          |  |
+   | | +---------+ |      | +----------+ |       |              |  |
+   | | |L2 Cache | |      | |L2 Cache  | |       |              |  |
+   | | +---------+ |      | +----------+ |       |              |  |
+   | +------+------+      +------+-------+       +------+-------+  |
+   |        |                                           |          |
+   |        +--------------------+                      |          |
+   |        |                    |                      |          |
+   | +------+------+      +------+-------+       +------+-------+  |
+   | | SUB-AN11    |      | SUB-AN12     |       | SUB-AN31     |  |
+   | | +---------+ |      |              |       |              |  |
+   | | |L3 Cache | |      |              |       |              |  |
+   | | +---------+ |      |              |       |              |  |
+   | +------+------+      +------+-------+       +------+-------+  |
+   |        |                    |                      |          |
+   +--------+--------------------+----------------------+----------+
+            |                    |                      |
+        +---+---+            +---+---+                  |
+        |       |            |       |                  |
+     +--+--+ +--+--+      +--+--+ +--+--+            +--+--+
+     |Peer2| |Peer3|      |Peer4| |Peer5|            |Peer6|
+     +-----+ +-----+      +-----+ +-----+            +-----+
+
+            Figure 29: General Architecture of Intra-ISP Caches
+
+   Figure 29 depicts the overall architecture of potential P2P cache
+   deployments inside an ISP 2 with various access network types.  As
+   shown in the figure, P2P caches may be deployed at various levels,
+   including the interworking gateway linking with other ISPs, internal
+   access network gateways linking with different types of accessing
+   networks (e.g., WLAN, cellular, and wired), and even within an
+   accessing network at the entries of individual WLAN subnetworks.
+   Moreover, depending on the network context and the operator's policy,
+   each cache can be a Forwarding Cache or a Bidirectional Cache
+   [ALTO-P2PCACHE].
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 67]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   In such a cache architecture, the locations of caches could be used
+   as dividers of different PIDs to guide intra-ISP network abstraction
+   and mark costs among them according to the location and type of
+   relevant caches.
+
+   Further details and deployment considerations can be found in
+   [ALTO-P2PCACHE].
+
+6.3.  Other Application-Based Network Operations
+
+   An ALTO server can be part of an overall framework for Application-
+   Based Network Operations (ABNO) [RFC7491] that brings together
+   different technologies.  Such an architecture may include additional
+   components such as a PCE for on-demand and application-specific
+   reservation of network connectivity, reliability, and resources (such
+   as bandwidth).  Some use cases how to leverage ALTO for joint network
+   and application-layer optimization are explained in [RFC7491].
+
+7.  Security Considerations
+
+   Security concerns were extensively discussed from the very beginning
+   of the development of the ALTO protocol, and they have been
+   considered in detail in the ALTO requirements document [RFC6708] as
+   well as in the ALTO protocol specification document [RFC7285].  The
+   two main security concerns are related to the unwanted disclosure of
+   information through ALTO and the negative impact of specially
+   crafted, wrong ("faked") guidance presented to an ALTO client.  In
+   addition to this, the usual concerns related to the operation of any
+   networked application apply.
+
+   This section focuses on the peer-to-peer use case, which is -- from a
+   security perspective -- probably the most difficult ALTO use case
+   that has been considered.  Special attention is given to the two main
+   security concerns.
+
+7.1.  ALTO as a Protocol Crossing Trust Boundaries
+
+   The optimization of peer-to-peer applications was the first use case
+   and the impetus for the development of the ALTO protocol, in
+   particular, file sharing applications such as BitTorrent [RFC5594].
+
+   As explained in Section 4.1.1, for the publisher of the ALTO
+   information (i.e., the ALTO server operator), it may not be apparent
+   who is in charge of the P2P application overlay.  Some P2P
+   applications do not have any central control entity and the whole
+   overlay consists only of the peers, which are under control of the
+   individual users.  Other P2P applications may have some control
+   entities such as super peers or trackers, but these may be located in
+
+
+
+Stiemerling, et al.           Informational                    [Page 68]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   foreign countries and under the control of unknown organizations.  As
+   outlined in Section 4.2.2, in some scenarios, it may be very
+   beneficial to forward ALTO information to such trackers, super peers,
+   etc., located in remote networks.  This situation is aggravated by
+   the vast number of different P2P applications that are evolving
+   quickly and often without any coordination with the network
+   operators.
+
+   In summary, it can be said that in many instances of the P2P use
+   case, the ALTO protocol bridges the border between the "managed" IP
+   network infrastructure under strict administrative control and one or
+   more "unmanaged" application overlays, i.e., overlays for which it is
+   hard to tell who is in charge of them.  This differs from more-
+   controlled environments (e.g., in the CDN use case), in which
+   bilateral agreements between the producer and consumer of guidance
+   are possible.
+
+7.2.  Information Leakage from the ALTO Server
+
+   An ALTO server will be provisioned with information about the ISP's
+   network and possibly also with information about neighboring ISPs.
+   This information (e.g., network topology, business relations, etc.)
+   is often considered to be confidential to the ISP and can include
+   very sensitive information.  ALTO does not require any particular
+   level of details of information disclosure; hence, the provider
+   should evaluate how much information is revealed and the associated
+   risks.
+
+   Furthermore, if the ALTO information is very fine grained, it may
+   also be considered sensitive with respect to user privacy.  For
+   example, consider a hypothetical endpoint property "provisioned
+   access link bandwidth" or "access technology (ADSL, VDSL, FTTH,
+   etc.)" and an ALTO service that publishes this property for
+   individual IP addresses.  This information could not only be used for
+   traffic optimization but, for example, also for targeted advertising
+   to residential users with exceptionally good (or bad) connectivity,
+   such as special banner ads.  For an advertisement system, it would be
+   more complex to obtain such information otherwise, e.g., by bandwidth
+   probing.
+
+   Different scenarios related to the unwanted disclosure of an ALTO
+   server's information have been itemized and categorized in RFC 6708,
+   Section 5.2.1., cases (1)-(3) [RFC6708].
+
+   In some use cases, it is not possible to use access control (see
+   Section 7.3) to limit the distribution of ALTO knowledge to a small
+   set of trusted clients.  In these scenarios, it seems tempting not to
+   use network maps and cost maps at all, and instead completely rely on
+
+
+
+Stiemerling, et al.           Informational                    [Page 69]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   ECS and endpoint ranking in the ALTO server.  While this practice may
+   indeed reduce the amount of information that is disclosed to an
+   individual ALTO client, some issues should be considered: first, when
+   using the map-based approach, it is trivial to analyze the maximum
+   amount of information that could be disclosed to a client -- the full
+   maps.  In contrast, when providing endpoint-cost service only, the
+   ALTO server operator could be prone to a false feeling of security,
+   while clients use repeated queries and/or collaboration to gather
+   more information than they are expected to get (see Section 5.2.1.,
+   case (3) in [RFC6708]).  Second, the ECS reveals more information
+   about the user or application behavior to the ALTO server, e.g.,
+   which other hosts are considered as peers for the exchange of a
+   significant amount of data (see Section 5.2.1., cases (4)-(6) in
+   [RFC6708]).
+
+   Consequently, users may be more reluctant to use the ALTO service at
+   all if it is based on the ECS instead of providing network and cost
+   maps.  Given that some popular P2P applications are sometimes used
+   for purposes such as distribution of files without the explicit
+   permission from the copyright owner, it may also be in the interest
+   of the ALTO server operator that an ALTO server cannot infer the
+   behavior of the application to be optimized.  One possible conclusion
+   could be to publish network and cost maps through ALTO that are so
+   coarse grained that they do not violate the network operator's or the
+   user's interests.
+
+   In other use cases, in more-controlled environments (e.g., in the CDN
+   use case) bilateral agreements, access control (see Section 7.3), and
+   encryption could be used to reduce the risk of information leakage.
+
+7.3.  ALTO Server Access
+
+   Depending on the use case of ALTO, it may be desired to apply access
+   restrictions to an ALTO server, i.e., by requiring client
+   authentication.  According to [RFC7285], ALTO requires that HTTP
+   Digest Authentication be supported, in order to achieve client
+   authentication and possibly to limit the number of parties with whom
+   ALTO information is directly shared.  TLS Client Authentication may
+   also be supported.
+
+   In general, well-known security management techniques and best
+   current practices [RFC4778] for operational ISP infrastructure also
+   apply to an ALTO service, including functions to protect the system
+   from unauthorized access, key management, reporting security-relevant
+   events, and authorizing user access and privileges.
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 70]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   For peer-to-peer applications, a potential deployment scenario is
+   that an ALTO server is solely accessible by peers from the ISP
+   network (as shown in Figure 21).  For instance, the source IP address
+   can be used to grant only access from that ISP network to the server.
+   This will "limit" the number of peers able to attack the server to
+   the user's of the ISP (however, including compromised computers that
+   are part of a botnet).
+
+   If the ALTO server has to be accessible by parties not located in the
+   ISP's network (see Figure 22), e.g., by a third-party tracker or by a
+   CDN system outside the ISP's network, the access restrictions have to
+   be looser.  In the extreme case, i.e., no access restrictions, each
+   and every host in the Internet can access the ALTO server.  This
+   might not be the intention of the ISP, as the server is not only
+   subject to more possible attacks, but also the server load could
+   increase, since possibly more ALTO clients have to be served.
+
+   There are also use cases where the access to the ALTO server has to
+   be much more strictly controlled, i.e., where an authentication and
+   authorization of the ALTO client to the server may be needed.  For
+   instance, in case of CDN optimization, the provider of an ALTO
+   service as well as potential users are possibly well-known.  Only CDN
+   entities may need ALTO access; access to the ALTO servers by
+   residential users may neither be necessary nor be desired.
+
+   Access control can also help to prevent Denial-of-Service (DoS)
+   attacks by arbitrary hosts from the Internet.  DoS can both affect an
+   ALTO server and an ALTO client.  A server can get overloaded if too
+   many requests hit the server, or if the query load of the server
+   surpasses the maximum computing capacity.  An ALTO client can get
+   overloaded if the responses from the sever are, either intentionally
+   or due to an implementation mistake, too large to be handled by that
+   particular client.
+
+7.4.  Faking ALTO Guidance
+
+   The ALTO services enables an ALTO service provider to influence the
+   behavior of network applications.  An attacker who is able to
+   generate false replies, or e.g. an attacker who can intercept the
+   ALTO server discovery procedure, can provide faked ALTO guidance.
+
+   Here is a list of examples of how the ALTO guidance could be faked
+   and what possible consequences may arise:
+
+   Sorting:  An attacker could change the sorting order of the ALTO
+      guidance (given that the order is of importance; otherwise, the
+      ranking mechanism is of interest), i.e., declaring peers located
+      outside the ISP as peers to be preferred.  This will not pose a
+
+
+
+Stiemerling, et al.           Informational                    [Page 71]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+      big risk to the network or peers, as it would mimic the "regular"
+      peer operation without traffic localization, apart from the
+      communication/processing overhead for ALTO.  However, it could
+      mean that ALTO is reaching the opposite goal of shuffling more
+      data across ISP boundaries, incurring more costs for the ISP.  In
+      another example, fake guidance could give unrealistically low
+      costs to devices in an ISP's mobile network, thus encouraging
+      other devices to contact them, thereby degrading the ISP's mobile
+      network and causing customer dissatisfaction.
+
+   Preference of a single peer:  A single IP address (thus a peer) could
+      be marked as to be preferred over all other peers.  This peer can
+      be located within the local ISP or also in other parts of the
+      Internet (e.g., a web server).  This could lead to the case that
+      quite a number of peers to trying to contact this IP address,
+      possibly causing a DoS attack.
+
+   The ALTO protocol protects the authenticity and integrity of ALTO
+   information while in transit by leveraging the authenticity and
+   integrity protection mechanisms in TLS (see Section 8.3.5 of
+   [RFC7285]).  It has not yet been investigated how wrong ALTO guidance
+   given by an authenticated ALTO server can impact the operation of the
+   network and the applications.
+
+8.  References
+
+8.1.  Normative References
+
+   [ALTO-REG]
+              IANA, "Application-Layer Traffic Optimization (ALTO)
+              Protocol",
+              <http://www.iana.org/assignments/alto-protocol>.
+
+   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
+              Optimization (ALTO) Problem Statement", RFC 5693,
+              DOI 10.17487/RFC5693, October 2009,
+              <http://www.rfc-editor.org/info/rfc5693>.
+
+   [RFC6708]  Kiesel, S., Ed., Previdi, S., Stiemerling, M., Woundy, R.,
+              and Y. Yang, "Application-Layer Traffic Optimization
+              (ALTO) Requirements", RFC 6708, DOI 10.17487/RFC6708,
+              September 2012, <http://www.rfc-editor.org/info/rfc6708>.
+
+   [RFC7285]  Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
+              Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
+              "Application-Layer Traffic Optimization (ALTO) Protocol",
+              RFC 7285, DOI 10.17487/RFC7285, September 2014,
+              <http://www.rfc-editor.org/info/rfc7285>.
+
+
+
+Stiemerling, et al.           Informational                    [Page 72]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   [RFC7286]  Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
+              H. Song, "Application-Layer Traffic Optimization (ALTO)
+              Server Discovery", RFC 7286, DOI 10.17487/RFC7286,
+              November 2014, <http://www.rfc-editor.org/info/rfc7286>.
+
+8.2.  Informative References
+
+   [ALTO-CDN]
+              Penno, R., Medved, J., Alimi, R., Yang, R., and S.
+              Previdi, "ALTO and Content Delivery Networks", Work in
+              Progress, draft-penno-alto-cdn-03, March 2011.
+
+   [ALTO-H12]
+              Kiesel, S. and M. Stiemerling, "ALTO H12", Work in
+              Progress, draft-kiesel-alto-h12-02, March 2010.
+
+   [ALTO-P2PCACHE]
+              Lingli, D., Chen, W., Yi, Q., and Y. Zhang,
+              "Considerations for ALTO with network-deployed P2P
+              caches", Work in Progress, draft-deng-alto-p2pcache-03,
+              February 2014.
+
+   [CDN-USE]  Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and
+              S. Previdi, "Use Cases for ALTO within CDNs", Work in
+              Progress, draft-jenkins-alto-cdn-use-cases-03, June 2012.
+
+   [CDNI-FCI]
+              Seedorf, J., Yang, Y., and J. Peterson, "CDNI Footprint
+              and Capabilities Advertisement using ALTO", Work in
+              Progress, draft-seedorf-cdni-request-routing-alto-08,
+              March 2015.
+
+   [CHINA-TRIAL]
+              Li, K. and G. Jian, "ALTO and DECADE service trial within
+              China Telecom", Work in Progress,
+              draft-lee-alto-chinatelecom-trial-04, March 2012.
+
+   [MAP-CALC]
+              Seidel, H., "ALTO map calculation from live network data",
+              Work in Progress, draft-seidel-alto-map-calculation-00,
+              October 2015.
+
+   [NETWORK-TOPO]
+              Clemm, A., Medved, J., Varga, R., Tkacik, T., Bahadur, N.,
+              Ananthakrishnan, H., and X. Liu, "A Data Model for Network
+              Topologies", Work in Progress,
+              draft-ietf-i2rs-yang-network-topo-06, September 2016.
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 73]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
+              Architecture for Describing Simple Network Management
+              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
+              DOI 10.17487/RFC3411, December 2002,
+              <http://www.rfc-editor.org/info/rfc3411>.
+
+   [RFC3568]  Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
+              Content Network (CN) Request-Routing Mechanisms",
+              RFC 3568, DOI 10.17487/RFC3568, July 2003,
+              <http://www.rfc-editor.org/info/rfc3568>.
+
+   [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
+              Private Network (VPN) Terminology", RFC 4026,
+              DOI 10.17487/RFC4026, March 2005,
+              <http://www.rfc-editor.org/info/rfc4026>.
+
+   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
+              Element (PCE)-Based Architecture", RFC 4655,
+              DOI 10.17487/RFC4655, August 2006,
+              <http://www.rfc-editor.org/info/rfc4655>.
+
+   [RFC4778]  Kaeo, M., "Operational Security Current Practices in
+              Internet Service Provider Environments", RFC 4778,
+              DOI 10.17487/RFC4778, January 2007,
+              <http://www.rfc-editor.org/info/rfc4778>.
+
+   [RFC5594]  Peterson, J. and A. Cooper, "Report from the IETF Workshop
+              on Peer-to-Peer (P2P) Infrastructure, May 28, 2008",
+              RFC 5594, DOI 10.17487/RFC5594, July 2009,
+              <http://www.rfc-editor.org/info/rfc5594>.
+
+   [RFC5632]  Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and
+              Y. Yang, "Comcast's ISP Experiences in a Proactive Network
+              Provider Participation for P2P (P4P) Technical Trial",
+              RFC 5632, DOI 10.17487/RFC5632, September 2009,
+              <http://www.rfc-editor.org/info/rfc5632>.
+
+   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
+              the Network Configuration Protocol (NETCONF)", RFC 6020,
+              DOI 10.17487/RFC6020, October 2010,
+              <http://www.rfc-editor.org/info/rfc6020>.
+
+   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+              and A. Bierman, Ed., "Network Configuration Protocol
+              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+              <http://www.rfc-editor.org/info/rfc6241>.
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 74]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+   [RFC6875]  Kamei, S., Momose, T., Inoue, T., and T. Nishitani, "The
+              P2P Network Experiment Council's Activities and
+              Experiments with Application-Layer Traffic Optimization
+              (ALTO) in Japan", RFC 6875, DOI 10.17487/RFC6875, February
+              2013, <http://www.rfc-editor.org/info/rfc6875>.
+
+   [RFC7491]  King, D. and A. Farrel, "A PCE-Based Architecture for
+              Application-Based Network Operations", RFC 7491,
+              DOI 10.17487/RFC7491, March 2015,
+              <http://www.rfc-editor.org/info/rfc7491>.
+
+   [RFC7752]  Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
+              S. Ray, "North-Bound Distribution of Link-State and
+              Traffic Engineering (TE) Information Using BGP", RFC 7752,
+              DOI 10.17487/RFC7752, March 2016,
+              <http://www.rfc-editor.org/info/rfc7752>.
+
+   [RFC7871]  Contavalli, C., van der Gaast, W., Lawrence, D., and W.
+              Kumari, "Client Subnet in DNS Queries", RFC 7871,
+              DOI 10.17487/RFC7871, May 2016,
+              <http://www.rfc-editor.org/info/rfc7871>.
+
+   [RFC7921]  Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
+              Nadeau, "An Architecture for the Interface to the Routing
+              System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
+              <http://www.rfc-editor.org/info/rfc7921>.
+
+   [RFC7922]  Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
+              the Routing System (I2RS) Traceability: Framework and
+              Information Model", RFC 7922, DOI 10.17487/RFC7922, June
+              2016, <http://www.rfc-editor.org/info/rfc7922>.
+
+   [UPDATE-SSE]
+              Roome, W. and Y. Yang, "ALTO Incremental Updates Using
+              Server-Sent Events (SSE)", Work in Progress,
+              draft-ietf-alto-incr-update-sse-03, September 2016.
+
+   [VPN-SERVICE]
+              Scharf, M., Gurbani, V., Soprovich, G., and V. Hilt, "The
+              Virtual Private Network (VPN) Service in ALTO: Use Cases,
+              Requirements and Extensions", Work in Progress,
+              draft-scharf-alto-vpn-service-02, February 2014.
+
+   [XDOM-DISC]
+              Kiesel, S. and M. Stiemerling, "Application Layer Traffic
+              Optimization (ALTO) Cross-Domain Server Discovery", Work
+              in Progress, draft-kiesel-alto-xdom-disc-02, July 2016.
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 75]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+Acknowledgments
+
+   This memo is the result of contributions made by several people:
+
+   o  Xianghue Sun, Lee Kai, and Richard Yang contributed text on ISP
+      deployment requirements and monitoring.
+
+   o  Rich Woundy contributed text to Section 3.3.
+
+   o  Lingli Deng, Wei Chen, Qiuchao Yi, and Yan Zhang contributed
+      Section 6.2.
+
+   Thomas-Rolf Banniza, Vinayak Hegde, Qin Wu, Wendy Roome, and Sabine
+   Randriamasy provided very useful comments and reviewed the document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 76]
+
+RFC 7971             ALTO Deployment Considerations         October 2016
+
+
+Authors' Addresses
+
+   Martin Stiemerling
+   Hochschule Darmstadt
+
+   Email: mls.ietf@gmail.com
+   URI:   http://ietf.stiemerling.org
+
+
+   Sebastian Kiesel
+   University of Stuttgart Information Center
+   Networks and Communication Systems Department
+   Allmandring 30
+   Stuttgart  70550
+   Germany
+
+   Email: ietf-alto@skiesel.de
+
+
+   Michael Scharf
+   Nokia
+   Lorenzstrasse 10
+   Stuttgart  70435
+   Germany
+
+   Email: michael.scharf@nokia.com
+
+
+   Hans Seidel
+   BENOCS GmbH
+   Winterfeldtstrasse 21
+   Berlin  10781
+   Germany
+
+   Email: hseidel@benocs.com
+
+
+   Stefano Previdi
+   Cisco Systems, Inc.
+   Via Del Serafico 200
+   Rome  00191
+   Italy
+
+   Email: sprevidi@cisco.com
+
+
+
+
+
+
+
+Stiemerling, et al.           Informational                    [Page 77]
+