summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7971.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7971.txt')
-rw-r--r--doc/rfc/rfc7971.txt4315
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]
+