RFC 7971
Application-Layer Traffic Optimization (ALTO) Deployment Considerations
Pages: 77
Informational
Informational
Part 4 of 4 – Pages 58 to 77
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
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.
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
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].
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.
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
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
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
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].
+--------------+ +------+ | 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].
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
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
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.
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
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>.
[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.
[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>.
[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.
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.
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