RFC 7971
Application-Layer Traffic Optimization (ALTO) Deployment Considerations
RFC 7971: Application-Layer Traffic Optimization (ALTO) Deployment Considerations 🎀
Okay bestie, this is RFC 7971, and it's giving informational energy 💅 Here's the tea:
- Number: RFC 7971
- Category: Informational, so it's published for information and is not an Internet Standards Track spec 🌸
- ISSN: 2070-1721
- Date: October 2016 📅
- Authors: M. Stiemerling (Hochschule Darmstadt), S. Kiesel (University of Stuttgart), M. Scharf (Nokia), H. Seidel (BENOCS), and S. Previdi (Cisco) 👑
- Obsoletes and updates: The header doesn't list any, so it doesn't replace or change an earlier RFC 🦋
Status of This Memo ✨
Okay so this document is not an Internet Standards Track specification. It's published purely for information 💖
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 if you want the full picture 🧐
Info about the current status of this document, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc7971 🌈
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, because 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 they're provided without warranty as described in the Simplified BSD License. Read the fine print, bestie 🙈
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
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 ................................................77Abstract 🌸
Okay so a lot of internet apps grab stuff like pieces of information or server processes that exist in several identical copies on different hosts 🧚 Peer-to-peer file sharing is the classic example, and it's literally everywhere. ALTO's whole thing is giving apps guidance when they need to pick one or more hosts out of a bunch of candidates that can all deliver the thing they want 💖
This memo digs into the deployment side of ALTO. It covers different use cases, like peer-to-peer file sharing and Content Delivery Networks (CDNs), with corresponding examples. It also has recommendations for network admins and app designers who are planning to deploy ALTO, like how to generate ALTO map information ✨
1. Introduction 🦋
Okay, same vibe as the abstract but with more detail 💅 Lots of internet apps access resources like pieces of information or server processes that live in several equivalent replicas on different hosts. That includes peer-to-peer (P2P) file sharing apps and Content Delivery Networks (CDNs), but it's not limited to them 🌈 ALTO exists to give apps guidance when they have to select one or several hosts from a set of candidates that can provide the resource they want 💜
The basic ideas and problem space of ALTO are described in [RFC5693], and the set of requirements is discussed in [RFC6708]. The ALTO protocol itself is specified in [RFC7285], and an ALTO server discovery procedure is defined in [RFC7286] 🔥
This document talks about the use cases and operational issues you can expect when ALTO gets deployed. That includes where the ALTO server lives, how much load it takes on, and who starts the queries 🧚 It gives guidance on which ALTO services to use, and it sums up known challenges and deployment experiences, including potential processes for generating ALTO network and cost maps. It's a complement to the management considerations in the protocol specification [RFC7285], which don't depend on any specific use of ALTO 🎀
2. General Considerations ✨
2.1. ALTO Entities 🫧
2.1.1. Baseline Scenario ✨
okay bestie, so the ALTO protocol [RFC7285] is a client/server protocol 💖 A bunch of ALTO clients talk to one ALTO server, like in Figure 1 below. First we look at the baseline setup for ALTO entities on its own, no specific use case attached, and then the rest of this doc gets into the real examples 🦋
+----------+
| ALTO |
| Server |
+----------+
^
_.-----|------.
,-'' | `--.
,' | `.
( Network | )
`. | ,'
`--. | _.-'
`------|-----''
v
+----------+ +----------+ +----------+
| ALTO | | ALTO |...| ALTO |
| Client | | Client | | Client |
+----------+ +----------+ +----------+Figure 1: Baseline Deployment Scenario of the ALTO Protocol
This doc uses the terminology from [RFC5693] 🌸 Specifically, these terms are defined by [RFC5693]:
- 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.
- ALTO Server: A logical entity that provides interfaces to satisfy the queries about a particular ALTO service.
- 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.
- 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.
- 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.
Now the ALTO client vs. resource consumer difference, which is a big one 👑 The resource consumer is a specific instance of software ("process") running on a specific host. It's either a client instance of a client/server application or a peer of a peer-to-peer application. It's the given (constant) endpoint of the data transmissions to be optimized using ALTO. The optimization happens 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. It also has to implement an HTTP client and a JSON encoder/decoder, or include other software libraries that provide these building blocks 🧚 In the simplest case, the ALTO client library can be linked (or otherwise incorporated) into the resource consumer, so it can retrieve information from an ALTO server and satisfy the resource consumer's need for guidance. Other configurations are possible too, as discussed in Section 2.1.2 and other sections of this document.
Okay, so both an ALTO server and an ALTO client are logical entities 💅 A particular ALTO service may be offered by more than one ALTO server. So the functionality of an ALTO server can 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 doc uses "Resource Directory" as defined in [RFC5693]. Don't mix this up with the "Information Resource Directory (IRD)" that's defined as part of the ALTO protocol [RFC7285]. The IRD is a list of available information resources offered by a specific ALTO service, plus the URIs where each one can be accessed 🎀
2.1.2. Placement of ALTO Entities 🦋
The ALTO server and ALTO clients can be situated at various places in a network topology 🌈 A big differentiator is whether the ALTO client sits on the host that's the endpoint of the data transmissions being optimized with ALTO (see Figure 2), or on a resource directory, which helps peers or clients find other peers or servers, respectively, but doesn't directly take part in the data transmission (see Figure 3).
+--------------+
| App |
+-----------+ |
===>|ALTO Client| |****
=== +-----------+--+ *
=== * *
=== * *
+-------+ +-------+<=== +--------------+ *
| | | | | App | *
| |.....| |<======== +-----------+ | *
| | | | ========>|ALTO Client| | *
+-------+ +-------+<=== +-----------+--+ *
Source of ALTO == * *
topological Server == * *
information == +--------------+ *
== | App | *
== +-----------+ |****
==>|ALTO Client| |
+-----------+--+
Application
Legend:
=== ALTO protocol
*** Application protocol
... Provisioning protocolFigure 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 is a peer-to-peer file sharing application that doesn't use a tracker, like edonkey. ALTO clients at peers could also be used in a similar way even when there is a tracker, as further discussed in Section 4.1.2 ✨
+-----+
**| App |****
** +-----+ *
** * *
** * *
+-------+ +-------+ +--------------+ * *
| | | | | | +-----+ *
| |.....| | +-----------+ |*****| App | *
| | | |<===>|ALTO Client| | +-----+ *
+-------+ +-------+ +-----------+--+ * *
Source of ALTO Resource ** * *
topological Server directory ** * *
information ** +-----+ *
**| App |****
+-----+
Application
Legend:
=== ALTO protocol
*** Application protocol
... Provisioning protocolFigure 3: Overview of Protocol Interaction between ALTO Elements with a Resource Directory
In Figure 3 we get a use case with a resource directory, e.g., a tracker in a peer-to-peer file-sharing application like BitTorrent 🍓 Both deployment scenarios can differ in how many ALTO clients 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 detailed further 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 ✨
okay so ALTO is a general-purpose protocol 🎀, which means it's built for a whole range of apps, not just one. Different use cases can make the applications, resource directories, etc. do different jobs. The use cases in this doc are not meant to be comprehensive, bestie, so don't treat the list as the full menu 🦋. It also means the ALTO entities can be located in different places. The ALTO clients and the ALTO server might sit in the same Internet Service Provider (ISP) domain, or the clients and the server might be managed/owned/located in totally different domains 🌸.
An ALTO deployment involves four kinds of entities 💅:
- Source of topological information
- ALTO server
- ALTO client
- Resource consumer
Each of these entities corresponds to a certain role, and that role comes with its own requirements and constraints on how the entities interact 🧚.
A key design objective of the ALTO service is that each of these four roles can be separated 👑. That means they can be realized by different organizations or by disjoint system components. ALTO is inherently designed for multi-domain environments, and most importantly, it's built to enable deployments where the ALTO server and the ALTO client are not in the same administrative domain. Iconic behavior 😭.
As explained in [RFC5693], this means at least three different kinds of entities can operate an ALTO server 🫶:
- 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.
- 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 🌈.
- 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 🍓.
Regarding the interaction between the ALTO server and client, ALTO deployments can be differentiated according to the following aspects 💜:
- 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 🔥.
- 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 👀.
- 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 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 discuss the deployment implications of each one 📚. 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]). This part is non-negotiable, babe 🚨.
2.2.2. Information Exposure
There are basically two different approaches to how an ALTO server can provide network information and guidance 🌸:
- 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 through the Network and Cost Map Service 🗺️.
- The ALTO server provides a query interface that returns costs or rankings for explicitly specified endpoints. This means 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 the 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 🎀.
2.2.3. More-Advanced Deployments ✨
okay so from an ALTO client's point of view, there are a few different ways to use ALTO 💅
- Single-service instance with single-metric guidance: the client only asks for guidance about one metric (like
routingcost) from one ALTO service 🎯. That service might be an ALTO server run by the network service provider of the access network the client is in. You can find these server instances through ALTO server discovery [RFC7286] [XDOM-DISC]. ALTO is an HTTP-based, REST-ful (Representational State Transfer) protocol, so the operator can use the same well-known techniques people use for huge websites, like load balancers 🙌, to handle a big pile of ALTO queries. ALTO also supports different URIs for different ALTO features, so the service can be spread out across several servers 🧚. - Single service instance with multiple metric guidance: a client can ask one ALTO service for different kinds of info, like cost maps with different metrics 🗺️. ALTO is extensible and allows this. BUT ALTO doesn't define how a client is supposed to handle different forms of guidance. It's up to the client to interpret what it gets 🤷♀️.
- Multiple service instances: a client can also access several ALTO servers that give guidance, maybe from different operators or organizations. Each one might only offer partial guidance, like for a certain network partition, so comparing guidance between services can get tricky 😬. Different organizations may use different methods to work out their maps, and they may even have contradicting or competing guidance goals 🥊. How to discover multiple ALTO servers and how to deal with conflicting guidance is an open issue 🚧.
There are also different options for how guidance offered by an ALTO service gets synchronized:
- Authoritative servers: an ALTO server instance can provide guidance for all destinations, for all kinds of ALTO clients 👑.
- Cascaded servers: an ALTO server can itself include an ALTO client and query other ALTO servers, for example for certain destinations. This results in a cascaded deployment of ALTO servers, which gets explained further down 🍓.
- Inter-server synchronization: different ALTO servers may communicate by other means. This doc doesn't go deeper into that one 🙈.
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 some deployments may have different settings 🤓. Figure 4 shows one of those settings: a university network connected to two upstream providers 🏫.
NREN is a National Research and Education Network, which provides cheap high-speed connectivity to specific destinations, like 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 and the ISP both operate their own ALTO server. The ALTO clients on the peers in the university network will contact the ALTO server located at the university 🫶.
+-----------+
| ISP |
| ALTO |<==========================++
| Server | ||
+-----------+ ||
,-------. ,------. ||
,-' `-. ,-' `-. ||
/ Commercial \ / \ ||
( Upstream ) ( NREN ) ||
\ ISP / \ / ||
`-. ,-' `-. ,-' ||
`---+---' `+------' ||
| | ||
| | ||
|,-------------. | \/
,-+ `-+ +-----------+
,' University `. |University |
( Network ) | ALTO |
`. / | Server |
`-. +--' +-----------+
`+------------'| /\ /\
| | || ||
+--------+-+ +-+--------+ || ||
| Peer1 | | PeerN |<====++ ||
+----------+ +----------+ ||
/\ ||
|| ||
++======================================++
Legend:
=== ALTO protocol
Figure 4: Example of a Cascaded ALTO ServerIn 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 isn't routed via the NREN gets handled by the commercial upstream ISP and is generally less preferred, because of the associated costs 💀. Still, there may be big differences between the various destinations reached via the ISP 👀. So 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 of cascaded ALTO servers 🎀.
3. Deployment Considerations by ISPs 🌈
3.1. Objectives for the Guidance to Applications
3.1.1. General Objectives for Traffic Optimization
The Internet is made up of many networks 🌐. These networks are owned and managed by different network operators, like commercial ISPs, enterprise IT departments, universities, and other organizations. Network operators provide connectivity, for example through access networks like cable networks, xDSL networks, 3G/4G mobile networks, and so on 📶. Network operators need to manage, control, and audit the traffic 🧐. So it's 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 about which endpoints (like IP addresses or IP prefixes) are to be preferred according to the operator of the ALTO server 🎯. The ALTO protocol gives the ALTO server operator a way to express its preference, whatever that preference is ✨.
ALTO lets network operators support application-level traffic engineering by influencing application resource provider selection 🦋. This traffic engineering can have different objectives:
- Inter-network traffic localization: ALTO can help reduce inter-domain traffic 🔁. The networks of different network operators are interconnected through peering points. From a business point of view, inter-network settlement is needed for exchanging traffic between these networks 💰. These peering agreements can be costly. To cut those costs, a simple objective is to decrease the traffic exchanged across the peering points, and keep the traffic inside the operator's own network or Autonomous System (AS) as much as possible 🏠.
- Intra-network traffic localization: big network operators may split their network 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 kept within certain areas, like access networks, that reduces the use of the backbone, which helps save resources and costs 🤑.
- Network offloading: compared to fixed networks, mobile networks have some special characteristics, including lower link bandwidth, high cost, limited radio frequency resources, and limited terminal battery 🔋. In mobile networks, wireless links should be used efficiently 📡. For example, with a P2P service, hosts will likely prefer retrieving data from hosts in fixed networks, and avoid retrieving data from mobile hosts 💅.
- Application tuning: ALTO is also a tool for optimizing the performance of applications that depend on the network and make resource provider selection decisions among network endpoints. An example is the network-aware selection of CDN caches 🧁.
Next, these objectives get explained in more detail with examples 🌸.
3.1.2. Inter-Network Traffic Localization
ALTO guidance can be used to keep traffic local within a network, for instance 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 hosts located in another operator's network 🙅♀️. Here, a network operator always expresses its preference for hosts in its own network, while hosts located outside its own network are to be avoided, meaning applications are not meant to consider them 🚫. Figure 5 shows this scenario, where hosts prefer hosts in the same network. For example, Host 1 and Host 2 are in ISP1, and Host 3 and Host 4 are in ISP2 🦄.
,-------. +-----------+
,---. ,-' `-. | 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 LocalizationExamples of corresponding ALTO maps can be found in Section 3.5 🗂️. Depending on the application's characteristics, it may not be possible, or even desirable, to localize all traffic completely 🤔.
3.1.3. Intra-Network Traffic Localization 🏠
okay so the last bit was about ALTO guidance between networks, but the same trick works inside one network too 💅 ALTO can tell hosts which internal hosts to pick first inside a single network (like one AS). This kind of app-level traffic engineering can lower the capacity the ISP's core network needs 🧠✨
Figure 6 shows the situation. Host 1 and Host 2 live in access net 1 of ISP 1 and connect through a low-capacity link to the core of that same ISP 1. If they swap data with remote hosts, they'd probably clog that bottleneck link 😭
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 LocalizationIn that situation, the operator can nudge hosts to try local hosts in the same network islands first 🌸 That way the bottleneck link gets less hammered, or at least less affected, just like Figure 6 shows 🦋
The goal is to dodge bottlenecks with smarter endpoint selection at the app level 🎯 BUT, it must be understood that ALTO is not a general-purpose fix for congestion at the bottleneck 🚫 no cap, that's a different job!
3.1.4. Network Offloading 📦
Another scenario is offloading traffic from networks 🚀 This is especially useful in mobile networks. A network operator may want to guide hosts in its mobile network to use hosts outside that mobile network 📱 One reason? The wireless network or the mobile hosts might not have been designed for direct peer-to-peer communication between mobile hosts, so it makes sense for peers to grab content from remote peers in other parts of the Internet 🌐
,-------. +-----------+
,---. ,-' `-. | 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-localizationFigure 7 shows the result of this guidance, where Host 2 prefers a connection with Host 3 instead of Host 1, as shown in Figure 5 🎀
Heads up, this might have some limits and won't work in every case 🙈 For instance, it may require the ALTO server to tell mobile and non-mobile hosts apart based on their IP address. That can depend on mobility solutions and may not be possible or accurate 😬 In general, ALTO is not meant to be a fine-grained traffic engineering tool for individual hosts. It typically works on aggregates instead (e.g., if it is known that certain IP prefixes are often assigned to mobile users) 💜
3.1.5. Application Tuning 🎛️
ALTO can also give guidance to tune the application-level topology of networked apps, e.g., by exposing network performance information 📊 Apps can often run their own measurements to figure out network performance, like active delay measurements or bandwidth probing, but those measurements add overhead and complexity 😩 Asking an ALTO server can be a simpler option. Plus, an ALTO server may also expose network information that apps cannot easily measure or reverse-engineer 🔍✨
3.2. Provisioning of ALTO Topology Data 🗺️
3.2.1. High-Level Process and Requirements 📋
Okay, so making ALTO topology information usually takes several steps 🛠️ The first step is gathering information, which the next section covers. The sections after that explain how the gathered data gets processed and which methods can be used to generate the info ALTO exposes, like network and cost maps 🧩
Providing ALTO guidance can be a total win-win for network providers and users of the ALTO information 🥰 Apps may get better performance, while the network provider gets tools to optimize traffic engineering and cut its costs 💰 That said, exposing topology data can bring security concerns 😬 Those limitations are discussed in Section 7.2 🔒
ISPs may have important privacy requirements when deploying ALTO, and those have to be taken into account when processing ALTO topology data 🕵️♀️ In particular, an ISP may not want to expose sensitive operational details of its network. The topology abstraction of ALTO lets an ISP expose the network topology at only the granularity it wants, as set by its security policies 🫶
With the ECS, the ALTO client does not have to implement any specific algorithm or mechanism to retrieve, maintain, and process network topology information (of any kind) 🙌 The complexity of the network topology (computation, maintenance, and distribution) stays in the ALTO server, and the ECS is delivered on demand. This lets the ALTO server enhance and modify how the topology information sources are used and combined, which makes enforcing the ISP's privacy policies much simpler 👑
The ALTO Network and Cost Map Service exposes an abstract view of the ISP network topology 🦋 So care is needed when constructing those maps to take privacy policies into account, as further discussed in Section 3.2.3 💅 ALTO also supports other features, like endpoint properties, which could be used to expose topology guidance too 🌈 The privacy considerations for ALTO maps also apply to those ALTO extensions 🔐
3.2.2. Data Collection from Data Sources ✨
Okay bestie, step one of making ALTO info is literally gathering the info from the network 🧚. An ALTO server can collect topology info from a bunch of different sources, and then it gives applications using an ALTO client a cohesive, abstract view of the network topology 💖. Those sources can include routing protocols, network policies, state and performance info, geolocation, etc. An ALTO server needs at least some topology and/or routing info, aka info about existing endpoints and how they're interconnected. With that, it's in principle possible to compute paths between all known endpoints 👑. From that basic data, the ALTO server builds its own ALTO-specific network topology, which shows the network the way applications (resource consumers) at endpoints should understand and use it, through ALTO services like the Network and Cost Map Service or ECS 🫶. And the basic dataset can be extended with tons of other info that's obtainable from the network ✨.
The ALTO protocol doesn't assume any specific network technology or topology, so it's giving flexibility 🦋. 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 info 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 differ a lot depending on the use case, the network architecture, and the trust relationship between the ALTO server and the ALTO client, etc. Besides the security requirements, which consist of not delivering any confidential or critical info about the infrastructure, there are efficiency requirements about which aspects of the network are visible and required by the given use case and/or application 🔥.
The ALTO server operator has to make sure the ALTO topology doesn't reveal any details that would endanger the network's 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 😭.
+--------+ +--------+
| 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 ALTOAs the figure shows, the topology data used by an ALTO server can come from different data sources 🦋:
- Relevant information sources are IGPs or BGP. An ALTO server could get network routing info 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. So it's possible to obtain info about all routers and their neighbors from one single router in the network 🧠. In contrast, distance-vector protocols are less suitable, since routing info is only shared among neighbors. To get the whole topology with distance-vector routing protocols, it's necessary to retrieve routing info from every router in the network 😩.
- [RFC7752] describes a mechanism by which link-state and Traffic Engineering (TE) info 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 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 💅.
- 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 info. With the rise of Software-Defined Networking (SDN) and the decoupling of network data and control plane, topology info could also be fetched from an SDN controller. If I2RS is used, [RFC7922] provides traceability for these interactions. This scenario is not discussed further in the rest of this document 🌈.
- Another potential source of topology info could be a Path Computation Element (PCE) [RFC4655]. Topology and traffic-related info can be retrieved from the Traffic Engineering Database (TED) and Label Switched Path Database (LSP-DB). This scenario is not discussed further in the rest of this document ⭐.
- 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 they 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 info 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) info can be leveraged, including traffic utilization obtained from IP Flow Information Export (IPFIX), event notifications (e.g., via syslog), and liveness detection (e.g., bidirectional forwarding detection, BFD). NMS or OSS systems also may have functions to correlate and orchestrate info 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 info could be modeled in a YANG data model [NETWORK-TOPO] 🍓.
The data sources mentioned so far are only a subset of the 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's challenging to gather detailed info about the whole Internet, since the network consists of multiple domains and in many cases it's not possible to collect info across network borders. So potential info 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 a 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's 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's 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 info that is available in a network's service provider network layer and compute the group of prefixes. An example is 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 in order 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 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 ✨
okay so an ALTO server spills its preferences about network locations in the form of abstract costs 💅 these costs are generic, and the operator of the ALTO server can compute them internally however it wants, based on its own policy 🫶 for any given ALTO network map, an ALTO cost map defines directional costs for every pair of source and destination network locations (the ones defined by the PIDs) 🗺️
the ALTO protocol lets you use different cost types 🎀 an ALTO cost type is a cost metric plus a cost mode. the metric says what the costs represent, and the mode says how to read them: are they numerical values, or just an ordinal ranking? 🔢 the protocol also lets you define extra constraints that decide which elements of a cost map shall be returned 💖
the basic set is the "routingcost" cost metric from [RFC7285] 👑 every implementation has to support it, and it's a generic measure for the cost of routing traffic from a source to a destination. a lower value means a higher preference for traffic to be sent from that source to that destination. how the metric gets calculated? totally up to the ALTO server 🤷♀️
it's also possible to calculate "routingcost" from actual routing protocol information 🧠 typically, IGPs give you details about endpoints and links inside a given network, while BGP is used to give you details about links to endpoints in other networks. and networks have a whole multitude of other attributes about their state, condition, and operation, like link utilization, bandwidth and delay, and the ingress/egress points of data flows to and from endpoints outside the network, all the way down to where the nodes and endpoints are. it's giving complex 😭
to make room for extended info, there's a protocol extension procedure for adding new ALTO cost types 🌈 the list below is an overview of further rating criteria that have been proposed or that are in use by ALTO-related prototype implementations. it is not intended as normative text 🙅♀️ its only purpose is to document and discuss rating criteria that have been proposed so far. whether these criteria are useful, and whether ISPs would actually make the corresponding information available, can also depend on the use case of ALTO. if you want the criteria with normative specs that have successfully passed the IETF review process, check IANA's "ALTO Cost Metric Registry", available from [ALTO-REG] 📚
Distance-related rating criteria: 📏
- Relative topological distance: the term relative means that a larger numerical value means greater distance, but it's 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. on top of the AS path, a relative cost value could also be calculated using other routing protocol parameters, such as BGP local preference or Multi-Exit Discriminator (MED) attributes.
- Absolute topological distance, expressed in the number of traversed autonomous systems.
- 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).
- Absolute physical distance, based on knowledge of the approximate geolocation (e.g., continent, country) of an IP address.
Performance-related rating criteria: 🚀
- The minimum achievable throughput between the resource consumer and the candidate resource provider, which is considered useful by the application (only in ALTO queries).
- 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.
- 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).
- 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: 💸
- 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 of a metric for which the cost function does not have to be disclosed.
- 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 that 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 rating criteria above 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 permission to send data at the indicated rate without using congestion control mechanisms. no shortcuts, bestie 🚫
the discrepancies are due to various reasons, including (but not limited to) these facts:
- The ALTO service is not an admission control system.
- The ALTO service may not know the instantaneous congestion status of the network.
- The ALTO service may not know all link bandwidths, i.e., where the bottleneck really is, and there may be shared bottlenecks.
- The ALTO service may not have all information about the actual routing.
- The ALTO service may not know whether the candidate endpoint itself is overloaded.
- The ALTO service may not know whether the candidate endpoint throttles the bandwidth it devotes to the considered application.
- 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. it must also use appropriate congestion control mechanisms in order to avoid a congestion collapse 🌊 still, the rating criteria can be a useful shortcut for quickly excluding candidate resource providers from that probing, if it's known in advance that connectivity is in any case worse than the minimum useful value for the respective application ⚡
rating criteria that should not be defined for and used by the ALTO service include: 🚫💅
- Performance metrics that are closely related to the instantaneous congestion status. defining alternate approaches for congestion control is explicitly out of the scope of ALTO. instead, other appropriate means, such as TCP-based transport, have to be used to avoid congestion. in other words, ALTO is a service that provides network and policy information, with update intervals that are possibly several orders of magnitude slower than the points at which congestion-control loops (e.g., in TCP) can react to changes in network congestion state. this clear separation of responsibilities avoids traffic oscillations and can help with network stability and cost optimization 🧘♀️
- 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 🕵️♀️
3.3. ALTO Focus and Scope 🎯
the purpose of this section is to make sure 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 🦋
okay so ALTO is a protocol between clients that live inside applications and servers that share network information and guidance, like basic network location structure and which network paths are preferred 💅 The goal is to change how apps use network resources at the application level while keeping app performance the same or making it better ✨ That design focus gives ALTO a few signature traits:
- Endpoint focus: the ALTO client (the one asking for the info) and the resources it's looking at (like files on endpoints) are usually not part of the network itself 🎀 The ALTO server shows an abstract network topology that only includes what an app overlay needs for better-than-random resource provider selection among its endpoints. The ALTO protocol spec [RFC7285] is not built to expose network internals like routing tables or configuration data that don't matter for app-level provider selection at endpoints 🙈
- Abstraction: services like the Network and Cost Map Service or the ECS only give an abstract view of the network 🌈 The ALTO server operator is in full control of the granularity (like deciding the policies for how subnets get grouped into PIDs) and how detailed the abstract view is (like choosing which cost types to support) 👑
- Multiple administrative domains: ALTO is made for setups where the ALTO server and client can sit in different organizations or trust domains 🧚 It assumes a loose coupling between server and client. ALTO also doesn't assume the client knows anything a priori about the server or its supported features, and an ALTO server can be discovered automatically 🔍
- Read-only: ALTO is a query/response protocol for getting guidance info 🍓 Neither network/cost map queries nor ECS queries are designed to change any state in the network 🫶
If ALTO is gonna be deployed for use cases beyond these assumptions, the protocol design might bring some limitations 😭
For example, in an Application-Based Network Operations (ABNO) environment, the application could send an explicit service request to the network [RFC7491]. In that case, the application would need detailed knowledge about the internal network topology and the actual state 🤯 A network configuration would also need a matching security solution for authentication and authorization 🔐 Real talk: ALTO is not designed to control, operate, or manage a network 🙅♀️
Those kinds of deployments could be handled by network management solutions, like ones based on SNMP [RFC3411] or NETCONF [RFC6241] and YANG [RFC6020], which are usually designed to manipulate configuration state 🛠️ [RFC7491] has a more detailed discussion of the interfaces between components like the 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 ALTO Map Service [RFC7285] is built on the idea of network maps 💖 A network map splits the network into PIDs, and each PID groups one or more endpoints (like subnetworks) into a single aggregate. The "costs" between the different PIDs are stored in a cost map 📊 Map-based approaches like the ALTO Network and Cost Map Service keep the signaling load on the server low, since maps only have to be retrieved when they change ✨
One big assumption for map-based approaches is that the info in the maps stays static for a long time 🧊 That's totally fine as long as the network operator doesn't change any parameters (like routing within the network and toward upstream peers) and IP address assignment stays stable, so the mapping to the partitions stays the same 😌 But there are a few situations where this assumption breaks down 💀
- ISPs reallocate IP subnets from time to time.
- ISPs reallocate IP subnets on short notice.
- IP prefix blocks may be assigned to a router that serves a variety of access networks.
- Network costs between IP prefixes may change depending on the ISP's routing and traffic engineering.
Here's how these play out 👇
Case 1: ISPs may reallocate IP subnets inside their infrastructure from time to time 🔄 They do this partly to use IPv4 addresses efficiently (they're a scarce resource) and partly to keep route tables in their network routers efficient 🧠 How often these "renumbering events" happen depends on how fast subscribers grow and how much address space the ISP has available. So a subscriber's household device could keep an IP address for as little as a few minutes, for months at a time, or even longer ⏳
People have suggested that ISPs offering ALTO services could split their subscribers' devices into different IP subnets (or certain IP address ranges) based on the purchased service tier and on where they sit in the network topology 🤔 The problem is that this sub-allocation tends to make IP address allocation less efficient, especially for IPv4 😬 A growing ISP that needs to keep IP address utilization really high might be reluctant to risk its future acquisition of IP address space 🙃 Still, this isn't an issue for map-based approaches as long as the changes happen on the order of days ✅
Case 2: ISPs can use techniques that let them reallocate IP prefixes on very short notice, like within minutes ⚡ A prefix that no longer has any IP address assigned to a host can be moved over to areas where there's a lot of demand for IP addresses right now 🔥
Case 3: In residential access networks (like DSL or cable), IP prefixes get assigned to broadband gateways 🏠 These are the first IP hop in the access network between the Customer Premises Equipment (CPE) and the Internet. The access network between the CPE and the broadband gateway (called the aggregation network) can have varying characteristics (and so varying associated costs), but it still uses the same IP prefix 🤷♀️ For example, one IP address IP1 from a given CIDR prefix might be assigned to a VDSL access line (like 2 Mbit/s uplink), while another IP address IP2 from that same CIDR prefix goes to a slow ADSL line (like 128 kbit/s uplink) 🐢 These addresses may be handed out first come, first served, which means a single IP address from the same CIDR prefix can change its associated costs really fast 😳 That might not be a problem for the upstream provider (so for cross-ISP traffic), but depending on how much capacity the aggregation network has, it could turn into one 🚧
Case 4: Routing and traffic engineering inside an ISP network, plus peering with other autonomous systems, can change dynamically and affect the info an ALTO server exposes 🌊 So cost maps and possibly network maps can change too 🔁
One way 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 ALTO protocol [RFC7285] also includes the ECS mechanism 💫 With it, ALTO clients can ask the ALTO server for guidance on specific IP addresses, so they don't have to process maps at all. That can help with some of the problems from the last section 🙌
BUT (and this is a big but) frequent requests, especially ones with long lists of IP addresses, can overload the ALTO server 😵 The server has to rank every single IP address it receives, and that puts load on the server. It gets worse when lots of ALTO clients are asking for guidance at the same time 📈 ECS results are also harder to cache than ALTO maps 🙁 So the ALTO client might have to wait for the server's response before starting a communication, which adds an extra delay ⏰
Caching IP addresses at the ALTO client, or using the H12 approach [ALTO-H12] together with caching, can lower the query load on the ALTO server 🫧
When an ALTO server gets an ECS request, it might not have the most appropriate topology info to rank things accurately 🤓 [RFC7285] generally assumes that a server can always offer some guidance. In that case, the ALTO server could go with one of these strategies:
- Reply with available information (best effort).
- Query another ALTO server that's presumed to have better topology information and return that response (cascaded servers).
- Redirect the request to another ALTO server that's presumed to have better topology information (redirection).
The protocol mechanisms and decision processes for figuring out whether redirection is necessary and which mode to use are out of scope for this document 🚫 That's because protocol extensions could be required for them 🛠️
3.4. Monitoring ALTO 📡
3.4.1. Impact and Observation on Network Operation 👀
ALTO is a brand-new way to manage network traffic by giving clients extra info 🌟 Deploying an ALTO server can shift traffic patterns, and the potential impact on network operation can be huge 😱 An ISP providing ALTO may want to assess how much ALTO is actually helping as part of its management and operations (cf. [RFC7285]) 📋 For instance, the ISP might want to know whether the ALTO maps are working well, so it can decide if tweaking the ALTO configuration would be useful 🎯 That kind of insight can come from a monitoring infrastructure 🔎 An ISP offering ALTO could look at the impact on (or integration with) traffic engineering, and at deploying a monitoring service to watch what ALTO operations actually do 💅 Measuring the impact can be tricky, because ALTO-enabled applications may not send related info back to the ALTO service provider 🫠
To build an effective monitoring infrastructure, the ALTO service provider needs to decide how to monitor ALTO's performance, then identify and deploy data sources to collect the data needed to compute the performance metrics 📈 In certain trusted deployment environments, it may be possible to collect info directly from ALTO clients 🤝 It may also be possible to vary or selectively disable ALTO guidance for a portion of ALTO clients, based on time, geographical region, or some other criteria, so you can compare network traffic characteristics with and without ALTO 🧪 Third parties can monitor an ALTO service too 🕵️♀️ In that case, getting insight into ALTO data may require a trust relationship between the monitoring system operator and the network service provider offering the ALTO service 🫶
The required monitoring depends on the network infrastructure and how ALTO is used, and an exhaustive description is outside the scope of this document 🌸
3.4.2. Measurement of the Impact 💖
okay so ALTO is basically an interface between the network and applications, bestie 🫶 which means monitoring it is gonna need both network metrics AND application metrics. this doc doesn't list every single metric that could be relevant, and it doesn't formally specify any metrics either. just so we're clear 🎀
the impact of ALTO can be sorted into a few different buckets 🦋
- Total amount and distribution of traffic: ALTO lets ISPs influence and localize the traffic of apps that use the ALTO service ✨ so an ISP might wanna check whether the traffic patterns actually shifted. like, if the goal is to reduce inter-domain P2P traffic, it makes sense to look at the total inter-domain traffic of the ISP 👑. one thing you can do is study how adding ALTO reduces that total inter-domain traffic (inbound and/our outbound). if the ISP wants to localize traffic inside its own network, then the network-internal traffic distribution is the thing to watch 🌸. localization can be quantified in different ways, e.g., by the load on core routers and backbone links, or by more advanced stuff like the average number of hops that traffic traverses inside a domain 💅
- Application performance: the whole goal of ALTO is to improve application performance 🔥 and ALTO can be used by really different kinds of apps with really different communication characteristics and requirements 🌈. for instance, if ALTO guidance achieves traffic localization, you'd expect apps to get a higher throughput and/or smaller delays when retrieving data 🧚. if app-specific performance stuff (like video or audio quality) can be monitored, those user-experience metrics could also help show the benefit of an ALTO deployment 💜. and if it's available, selected statistics from the TCP/IP stack in hosts could be leveraged too ⭐
of potential interest is also the share of applications or customers that actually use an offered ALTO service, aka the adoption of the service 🍓
monitoring stats can be aggregated, averaged, and normalized in different ways 💀 this doc does not mandate specific ways to calculate metrics, so no one's boss-ing you around on the math 🙈
3.4.3. System and Service Performance ✨
okay so a bunch of interesting parameters can be measured at the ALTO server 🖥️ and [RFC7285] suggests some ALTO-specific metrics to be monitored 💖:
- Requests and responses for each service listed in an Information Directory (total counts and size in bytes) 🎀
- CPU and memory utilization 🔥
- ALTO map updates 🦋
- Number of PIDs 🌸
- ALTO map sizes (in-memory size, encoded size, number of entries) 👑
this data characterizes the workload, the system performance, AND the map data 💅 obviously, it's gonna depend on the implementation and the actual deployment of the ALTO service 🫶 also, logging is recommended in [RFC7285] too, so keep those logs coming 📝
3.4.4. Monitoring Infrastructures 🧚
so understanding the impact of ALTO can require interaction between different systems operating at different layers 💜. some info we talked about in the previous sections is only visible to an ISP, while application-level performance can hardly be measured inside the network 😭. it's possible that not all the info of potential interest can be measured directly, either because there's no corresponding monitoring infrastructure or measurement method, or because it's 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 through active measurements, but because of the overhead, the active ones should be used with care ⚠️. and here's the big thing: in all monitoring activities, an ALTO service provider has to keep in mind that ALTO clients are NOT bound to ALTO server guidance 💀, since ALTO is only one source of information, so any measurement result may be biased 🌈
⚠️ heads up bestie: clients aren't forced to follow what the ALTO server says, so measurements can come out biased. keep that in mind when you're reading the numbers 💅
potential sources for monitoring the use of ALTO include 🍓:
- Network monitoring and performance management systems: lots of ISPs deploy systems to monitor network traffic 🖥️, which may have insight into traffic volumes, network topology, and bandwidth info 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 🫶
- Applications/clients: relevant data could be obtained by instrumenting applications 👑
- ALTO server: if available, log files or other statistics data could be analyzed 📊
- Other application entities: in several use cases, there are other application entities that could provide data too 🧚. for instance, there may be centralized log servers that collect data 💜
in many ALTO use cases, some data sources sit inside an ISP network while other data gets gathered at the application level 🌸. correlating the data could require a collaboration agreement between the ISP and an application owner, including agreements on data interchange formats, methods of delivery, etc. 🤝 but honestly, that collab may not be possible in every ALTO use case 😬, because the monitoring data can be sensitive AND 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 🦋
okay so the ALTO protocol does not mandate how to determine costs between endpoints and/or how to determine map data 💅. in complex usage scenarios, that can be a non-trivial problem 😵. to show the basic principle, this section and the following ones explain how ALTO maps could be structured for different deployment scenarios 🧚
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 consists of all other network destinations 👑. the cost map can be defined like this: the cost of a link between clients inside the inner ISP's network is lower than the cost between clients of the outer ISP's network and clients of the inner ISP's network 🔥. as a result, a host with an ALTO client inside this ISP's network will prefer retrieving data from hosts connected to the same ISP 💖
an example is in Figure 9 🎀. ISP A is assumed to be a small ISP with only one access network 🌸. as operator of the ALTO service, ISP A can define its network as one optimization area, named PID1, and define the other networks as the other optimization area, named PID2 🦋. C1 is the cost inside ISP A's network 💜. C2 is the cost from PID2 to PID1, and C3 is the cost from PID1 to PID2 🌈. in the following, C2=C3 is assumed for simplicity 🫶. to keep traffic local inside ISP A, it makes sense to define C1<C2 💅
-----------
//// \\\\
// \\
// \\ /-----------\
| +---------+ | //// \\\\
| | 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 matching ALTO network and cost maps is in Figures 10 and 11 🍓, assuming ISP A's network has the IPv4 address ranges 192.0.2.0/24 and 198.51.100.0/25, plus the IPv6 address range 2001:db8:100::/48 🌸. in this example, the cost values C1 and C2 can be set to any numbers as long as C1<C2 🧚
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 🫶
3.5.2. ISP with Several Fixed-Access Networks ✨
Okay so this one is a P2P app traffic optimization use case for a bigger ISP 🌐. Its fixed network has several access networks plus a core network. The ISP has three goals: (1) using the backbone network efficiently, (2) balancing traffic across its access networks based on traffic conditions and management policies, and (3) cutting settlement costs with other ISPs 💸.
A big ISP running an ALTO service may want to optimize traffic based on the topology of its access networks 🗺️. For example, each access network can be its own optimization area, so traffic stays local inside that area whenever it can 🏡. You do this by mapping each area to a PID. Then the costs between those access networks get set according to what this ISP is trying to achieve. Figure 12 shows one example setup.
In this example, ISP A has one backbone network and three access networks, AN A, AN B, and AN C. A P2P application is running ✌️. For sensible application-level optimization, the first requirement is to decrease the P2P traffic on the backbone network inside ISP A's AS. The second requirement is to decrease the P2P traffic going to other ISPs, meaning other ASes. The second requirement gets priority over the first one 👑. We also assume 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, and here's how the ALTO setting and configuration could look.
In ISP A's network, the ALTO server operator can make each access network its own optimization area and assign one PID to each, such as PID 1, PID 2, and PID 3. Because ISP A has different peerings with different outside ISPs, ISP B can be its own additional optimization area with PID 4. Every other network can be grouped into one more optimization area with PID 5 🧚.
Now the costs. The setup uses costs (C1, C2, C3, C4, C5, C6, C7, C8), as shown in Figure 12. C1 is the link cost inside AN A (PID 1), and C2 and C3 are defined in the same way. C4 is the link cost from PID 1 to PID 2, and C5 is the matching cost from PID 3, which is assumed to be a similar value. C6 is the cost between PID 1 and PID 3. For simplicity, this scenario assumes symmetrical costs between the AN this example. C7 is the link cost from ISP B to ISP A. C8 is the link cost from other networks to ISP A.
Following the discussion of the first and second requirements, the cost relationships are 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 Structures3.5.3. ISP with Fixed and Mobile Network 📱
An ISP with both a mobile network and a fixed network may want to optimize its mobile traffic by keeping traffic in the fixed network as much as possible 🙌. Why? Wireless bandwidth is a scarce resource, and traffic is pricey on the mobile side 💀. So the main goal here could be cutting down how much radio resource the mobile network uses. An ALTO service can be deployed to cover these needs.
Figure 13 shows an example. ISP A runs one mobile network, which connects to a backbone network. It also runs two fixed-access networks, AN A and AN B, which connect to that same backbone. In this layout, the mobile network can be one optimization area with PID 1. AN A and AN B can each be optimization areas too, with PID 2 and PID 3 assigned to them respectively. The cost values are then set as shown in Figure 13.
To cut down on wireless link usage, the cost relationships can be defined like this 🌸:
From view of mobile network: C4 < C1 and C4 = C8. This means clients in the mobile network that need data from other clients will prefer clients in AN A or B over clients in the mobile network. This policy can reduce wireless link usage and power consumption in terminals 🔋.
From view of AN A: C2 < C6, C5 = maximum cost. This means clients in other optimization areas will avoid getting data from the mobile network 🙈.
From view of AN B: Analogous 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 NetworkThese examples show that for ALTO in particular, the relationships between different costs really matter 🔥. The server operator has several degrees of freedom in deciding how to set the absolute values 👑.
3.6. Comprehensive Example for Map Calculation 🧮
In addition to the previous abstract examples, this section walks through 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 ✨
okay so bestie, picture this 🗺️💖 Figure 14 is our little playground for walking through the whole example. There are nine routers (R1 to R9) 🧚, and two of them are the border routers (R1 + R8) that hang out with neighboring networks (AS 2 to AS 4) 🎀. AS 4 is not directly plugged into our local network, so it goes through AS 3 as a transit network. Iconic routing behavior, honestly 😭
The links between routers are point-to-point connections, and they also make up the core network with the 2001:db8:1:0::/56 prefix. That prefix is big enough to cover addresses for every router interconnection, so no one's getting left out 🫶 On top of the core, the local network has five client networks parked on five different routers (R2, R5, R6, R7 and R9). Each client network has a /56 prefix, written as 2001:db8:1:x00:: with x = [1..5], as its network address 🌸
+-------------------+ +-----+ +-----+ +-------------------+
|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 NetworkThe example network uses two different routing protocols: one for IGP and another for EGP routing 🔥 The IGP is a link-state protocol such as IS-IS. The link weights are annotated in the graph and also listed in Figure 15. All links are bidirectional, and their weights are symmetric, so no weird asymmetry drama here 💅 To grab the topology and routing info from the network, the topology data source MUST be connected directly to one of the routers (R1...R9). It also MUST be enabled to talk to the router and vice versa 🦋
Now the BGP part 🌈 BGP is used to route between autonomous systems in this scenario. External BGP runs on the two border routers R1 and R8. Internal BGP is used to propagate external as well as internal prefixes inside the network boundaries, and it runs on every router with an attached client network (R2, R5, R6, R7 and R9) 💜
Since there's no route reflector, it is necessary to fetch routes from each BGP router separately. Lowkey a lot of extra fetching, but that's just how it goes 🙈
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 WeightsFor monitoring purposes, you can enable, e.g., SNMP or NETCONF on the routers in the network. This way an ALTO server may obtain several additional pieces of information about the state of the network ✨ For example, utilization, latency, and bandwidth info could be retrieved periodically from the network components, so the server keeps an up-to-date view of what's actually happening 👑
In the following, it is assumed that these attributes are collected from the network:
IS-IS: topology, link weightsBGP: prefixes, AS numbers, AS distances, or other BGP metricsSNMP: latency, utilization, bandwidth
3.6.2. Potential Input Data Processing and Storage 🧠
Okay so with this many data sources floating around, it may be necessary to aggregate the info and define a suitable data model that can hold everything efficiently and stay easy to access 💅 One potential model is an annotated directed graph that represents the topology. The attributes get annotated at the matching positions in the graph. Here's how such a topology graph could describe the example topology 🦋
In the topology graph, a node represents a router, while the edges stand for the links that connect the routers. Both routers and links have a set of attributes that store info gathered from the network 🫶
Each router could be associated with a basic set of info, such as:
ID: Unique ID within the network to identify the router.Neighbor IDs: List of directly connected routers.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.
On top of the basic set, many more attributes may be assigned to router nodes 🌈 This mainly depends on the data sources being used. Examples are geographic location, host name and/or interface types, just to name a few.
The example network in Figure 14 is basically an internal network graph, where routers R1 to R9 are 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 R2Router R8 has two attached IPv6 endpoints, as explained in Figure 17 🍓 The first one belongs to a directly neighbored AS with AS number 3, and the AS distance from our network to AS3 is 1. The second endpoint belongs to an AS (AS4) that is not a direct neighbor but is directly connected to AS3. To reach endpoints in AS4, you have to cross AS3, which bumps the AS distance up by one 😭
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 R8A potential set of attributes for a link is described in the following list:
Source ID: ID of the source router of the link.Destination ID: ID of the destination router of the link.Weight: The cost to cross the link, e.g., defined by the used IGP.
Additional attributes that provide technical details and state info can be assigned to links too 💜 Whether these exist depends on the data sources being used. Such attributes can be things like maximum bandwidth, utilization, or latency on the link, as well as the link type 🦋
In the example, the link attributes are the same 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 link attributes explained in Figure 18 ✨
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 AttributesIt has to be emphasized that values for utilization and latency can be very volatile 😭💅 They can swing around a lot, so keep that in mind, bestie 🫶
3.6.3. Calculation of Network Map from the Input Data ✨
okay so the goal of ALTO map calculation is to take the graph view of a network and turn it into a coarser, more abstract matrix view 🧚. step one is generating the network map. only after that exists can you compute the cost map, because the cost map relies on it 💅
to make an ALTO network map you need a grouping function 🎀. a grouping function reads info from the network graph and groups endpoints into PIDs. there are lots of ways to group, and algorithms can use any info the graph gives them. the functions can also leave certain endpoints out, either to simplify the map or to hide network details that aren't meant to be published in the ALTO network map 🙈
for IP endpoints (an IP address or prefix, IPv4 or IPv6), [RFC7285] requires a longest-prefix matching algorithm to map IPs to PIDs 🌸. that leads to two constraints: every IP has to get mapped to a PID, and the same prefix or address can't be mapped to more than one PID. to meet the first one, every calculated map needs a default PID that contains the prefixes 0.0.0.0/0 for IPv4 and ::/0 for IPv6. both cover their entire address space, so if no other PID matches an IP endpoint, the default PID catches it 🫶. the second constraint is up to the grouping function that assigns endpoints to PIDs. if there's a collision, the grouping function has to decide which PID the endpoint goes to 👑. other endpoint types can have their own constraints too, depending on the matching algorithm being used.
a simple example of grouping is naming PIDs after host names 💖. for instance, each router's host name becomes the name of a PID, and the endpoints attached to that router are the PID's member endpoints. backbone prefixes should not show up in the map, so they get filtered out 🧚. the table in Figure 19 shows the resulting ALTO network map, using the network in Figure 14 as the 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 Mapsince routers R3 and R4 have no endpoints assigned, they don't show up in the network map at all 🙈. and like we mentioned earlier, the "default" PID was added to cover every endpoint that isn't part of the example network 💅
3.6.4. Calculation of Cost Map ✨
once the network map is successfully built, the usual next step is to work out the costs between the generated PIDs, which form the cost map 🌈. cost functions do that math. a cost function can give unidirectional values, which means you have to compute costs from every PID to every PID 😭. in general, a cost function can use all the info available in the network graph. if a PID has more than one IP address or prefix, the cost function can first work out a set of cost values for each source/destination IP pair 🧚. in that case you need a tiebreaker function to decide the final cost value, because [RFC7285] only allows one cost value between two PIDs 🎀. a tiebreaker can be something simple like the minimum, maximum, or average value.
no matter what metric the cost function uses, the path from source to destination is usually the path with the minimum weight 💖. when the link weight is an additive metric, the path weight is the sum of the link weights of every link you cross. the path can be found with the Bellman-Ford or Dijkstra algorithms 🦋. Dijkstra builds the shortest path step by step, based on cumulated link lengths. in our example, the link lengths are the link weights shown in Figure 15 🌸. so the cost function basically pulls out the optimal path for whatever metric you picked, like the IGP link weight. it's also possible for more than one path to share the same minimum weight, which means it isn't totally clear which path the network will actually choose 💀. that's why you need a tiebreaker similar to the one used for PIDs with multiple endpoints.
an important note: [RFC7285] does not require cost maps to include costs for every PID pair 👑. so if no path cost can be calculated for a certain pair, that field gets left out of the cost map. administrators might also not want to provide cost values for some PID pairs, for various reasons 🙈. those pairs can be defined before the cost calculation even runs.
based on the network map example from the previous section, we can calculate the cost maps 💅. Figure 20 uses the minimum number of hops needed to get from endpoints in the source PID to endpoints in the destination PID as the selected metric. our chosen tiebreaker picks the minimum hop count whenever the cost function returns more than one value 🫶
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 Maphere's a fun detail 🧠: 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. because of the minimum hop count tiebreaker, 3 hops is the value picked for the path R1->R4->R9 ✨. also, since the "default" PID is kind of a virtual PID with no endpoints from the example network, no cost values get calculated for other PIDs going from or towards it 💜
3.7. Deployment Experiences 🌷
there are multiple interoperable implementations of the ALTO protocol 🦋. some experiences implementing and using ALTO in large-scale networks have been documented in [MAP-CALC], and here's the summary 🫶
- Data collection: pulling topology info usually means implementing several protocols other than ALTO for data collection 😭. ALTO deployments ran into protocol behaviors that were different from what you'd expect from the spec of that protocol. this came from older versions of the protocol specification, a lax interpretation on the remote side, or just plain incompatibility with the corresponding standard 🙈. problems like this in collecting data can make an ALTO deployment more complicated, even when they have nothing to do with the ALTO protocol itself 💀
- Data processing: processing network info can be super complex and really resource demanding 🔥. gathering info from an autonomous system connected to the Internet may mean a server has to store and process hundreds of thousands of prefixes, several hundreds of megabytes of IPFIX/Netflow info per minute, and info from hundreds of routers plus attributes of thousands of links 😭. you need a lot of disk, RAM, and CPU cycles, plus efficient algorithms, to process it all 🧚. operators of an ALTO server have to be aware that significant compute resources are needed not only for the ALTO server, but also for the data collection 💅
- Network map calculation: large IP-based networks have hundreds of thousands of prefixes that have to be mapped to PIDs during network map calculation 🌈. as a result, network maps get really big, up to tens of megabytes 🙈. but depending on the network design and the grouping function you pick, the calculated network maps can contain redundancy that can be removed 🎀. there are at least two ways to shrink them by removing redundancy ✨. first, adjacent IP prefixes can be merged. when a PID has two adjacent prefix entries, it can merge them into one larger prefix. both prefixes have to be in the same PID 👑. the larger prefix might be assigned to another PID, and that can't be ruled out. this has to be checked, and it's up to the grouping function whether to merge the prefixes and remove the larger prefix from the other PID 🫶. a simple example: if a PID comprises the prefixes
2001:db8:0:0::/64and2001:db8:0:1::/64, it can merge them into2001:db8:0:0::/63💖. second, a prefix and its next-longest-prefix match may be in the same PID. in that case the smaller prefix can simply be removed, since it's redundant for obvious reasons 🦋. a simple example: a PID comprises the prefixes2001:db8:0:0::/62and2001:db8:0:1::/64, and the /62 is the next-longest prefix match of the /64, so the /64 prefix can simply be removed 🌸. but if another PID contains the2001:db8:0:0::/63prefix, the entry2001:db8:0:1::/64can't be removed, because the next-longest prefix isn't in the same PID anymore 💀. operators of an ALTO server therefore have to analyze whether their address assignment schemes allow this kind of tuning 🧠 - Cost map calculation: one known implementation challenge with cost map calculation is the huge amount of CPU cycles that may be needed to compute costs in large networks 🔥. this is especially problematic if costs are calculated between the endpoints of every source-destination PID pair 😭. very often, several to many endpoints of a PID are attached to the same node, so the same path cost gets calculated over and over 🙈. that's clearly inefficient 💅. one remedy could be more sophisticated algorithms, such as looking up the routers that each PID's endpoints are connected to in the network graph, and calculating the cost map based on the costs between those routers 🧚. when deploying and configuring ALTO servers, administrators should consider the impact of huge cost maps and possibly make sure the map sizes don't get too large 🫶
in addition, further deployment experiences have been documented 🌈. one real example is described in greater detail in reference [CHINA-TRIAL] 🎀
experiments have also been run with ALTO-like deployments in ISP networks ✨. for instance, NTT tested its HINT server implementation with dummy nodes to learn 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 ✨
Okay so, P2P apps were originally the main reason ALTO got built 💖. The setup is that one party, usually the operator of a "managed" IP network domain, shares information about the network through ALTO 🌐. The application overlay queries that info and adjusts its behavior to improve performance or Quality of Experience in the app, while also reducing the load on the underlying network infrastructure. That's the win-win situation 🎀, and it's the incentive for both sides to provide or consume the ALTO information, respectively.
P2P systems can be built with or without a centralized resource directory ("tracker") 🧚. This section is only about how P2P apps interact 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 ways ALTO can be deployed in these 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 gets returned to the resource consumer 📏. Some or all of those providers, plus other providers the consumer learns about in other ways (like direct communication between peers), will then be contacted by the resource consumer to access the resource. ALTO's job here is to guide this peer selection so it yields better-than-random results 🎯. The tracker response and the ALTO guidance are most useful in the early phase, after the resource consumer has decided to access a resource and only a few resource providers are known. Later on, once the consumer has already exchanged some data with other peers and measured the transmission speed, ALTO's relative importance may dwindle 🥀.
4.1.2. Applicability of ALTO 🦋
A tracker-based P2P app can use ALTO in a few different ways, so let's go through the alternatives and their pros and cons 💅.
,-------. +-----------+
,---. ,-' ========>| 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 protocolFigure 21: Global Tracker and Local ALTO Servers
Figure 21 shows a tracker-based P2P system with several peers 🌈. The peers (i.e., resource consumers) embed an ALTO client to improve their resource provider selection ✨. The tracker (i.e., resource directory) can be hosted and operated by another entity, too. A tracker that's external to the peers' ISPs is 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 in Figure 21 lets the peers talk directly to their ISP's ALTO server (i.e., the ALTO client is embedded in the peers) 🫶. This gives the peers the most control over what information they query for, since they can integrate information received from one tracker or several trackers, and from direct peer-to-peer knowledge exchange. For example, that last approach is called peer exchange (PEX) in BitTorrent 🔥. In this deployment scenario, the peers have to discover a suitable ALTO server (e.g., one offered by their ISP, as described in [RFC7286]) 🔍.
There are also tracker-less P2P system architectures that don't rely on centralized resource directories, like unstructured P2P networks 🌸. For ALTO, their deployment would be similar to Figure 21, since the ALTO client would be embedded in the peers as well. This option isn't 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 protocolFigure 22: Global Tracker Accessing ALTO Server at Various ISPs
Now for another deployment option for a tracker-based system, shown in Figure 22 🎀. This time the tracker embeds the ALTO client. When the tracker gets a request from a querying peer, it first discovers the ALTO server responsible for that peer 🕵️♀️. It can do this using various ALTO server discovery mechanisms [RFC7286] [XDOM-DISC]. The ALTO client then sends the querying peer only those peers that the responsible ALTO server prefers. The peers never query the ALTO servers themselves 🙅♀️. This gives the peers a better initial pick of candidates, but it doesn't take into account peers learned through direct peer-to-peer knowledge exchange.
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 protocolFigure 23: Local Trackers and Local ALTO Servers (P4P Approach)
Some folks are trying to let ISPs deploy their own trackers, as shown in Figure 23 🏠. In that case, the client can't get guidance from the ALTO server except by talking to the ISP's tracker, which then talks to the ALTO server using the ALTO protocol 🤓. Peers are still allowed to contact other trackers run by entities other than the peer's ISP, but then they can't benefit from ALTO guidance 😭.
4.2. Deployment Recommendations 💜
4.2.1. ALTO Services 🌷
The ALTO protocol specification [RFC7285] explains how an ALTO client can query an ALTO server for guiding information and receive the replies 📬. For P2P networks, there are two different ALTO services to choose from. The cost map service is often the go-to for P2P software implementors and users, because it avoids disclosing peer IP addresses to a centralized entity 🔒. Network operators, on the other hand, may prefer the ECS, since it doesn't require exposing the network topology 🗺️.
For actually using ALTO in P2P apps, software vendors and network operators both have to agree on which ALTO services to use 🤝. The ALTO protocol is flexible and supports both services. Also, for other ALTO use cases, especially in more controlled environments, both the cost map service and the ECS might be feasible. It's more of an engineering trade-off whether to go with a map-based or query-based ALTO service 🧠💅.
4.2.2. Guidance Considerations ✨
okay so, remember Section 4.1.2? For a tracker-based P2P app there are two totally different spots where the ALTO client can live 👀
- ALTO client in the resource consumer ("peer")
- ALTO client in the resource directory ("tracker")
Both options have pros and cons, bestie 💅 If the ALTO client lives in the resource consumer (Figure 21), you need a potentially huge number of clients deployed, which is a lot 😭 But with an ALTO client in the resource directory (Figures 22 and 23), peers don't have to query the ALTO server directly. Like, an ALTO server could even refuse to let peers in at all 💀
However, it's giving "everyone wins if peers can query the ALTO server directly" 🫶 With the plethora of apps that could use ALTO (multiple-tracker or non-tracker P2P systems, or other apps looking for relays), this makes the ALTO service way more useful 🦋 Peers are also the only ones holding all the operational knowledge to decide whether to use the ALTO guidance and how to use it 🧠 And for any given peer, you can expect that the ALTO server of the matching ISP gives useful guidance and can be discovered 🌸
Yet, the consumer-side client has drawbacks compared to the resource directory version. So let's compare both scenarios more closely, to see the impact on ALTO guidance and why third-party ALTO queries are needed 🔍
In the first scenario (Figure 24), the peer (resource consumer) asks the tracker (resource directory) for the resource it wants (F1). The resource directory returns a list of potential resource providers without considering ALTO at all (F2). So it's the resource consumer's job to invoke ALTO (F3/F4) to get guidance about that list 😩
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 QueryIn the second scenario (Figure 25), the resource directory has an embedded ALTO client, which we call the Resource Directory ALTO Client (RDAC) in this document ✨ After getting a query for a given resource (F1), the resource directory invokes the RDAC to evaluate all the resource providers it knows (F2/F3). Then it returns a list of the "best" resource providers to the resource consumer (F4), which might be shortened 🎀
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 QueryNote: the message sequences in Figures 24 and 25 may occur in both the target-aware and the target-independent query mode (cf. [RFC6708]). In the target-independent mode, there might not be any message exchange with the ALTO server after the tracker query, because the candidate resource providers could be evaluated using a locally cached "map" that was retrieved from the ALTO server some time ago 🗺️
The first approach has a problem, bestie 😬 The resource directory might know thousands of peers taking part in a swarm, but the list returned to the resource consumer is usually shortened for efficiency reasons. So the "best" (in the sense of ALTO) potential resource providers might not be in that list anymore, even before ALTO gets a chance to consider them 💀
Much better traffic optimization could happen if the tracker evaluated all known peers using ALTO 🔥 That list would include a significantly higher fraction of "good" peers. But if the tracker returned "good" peers only, there might be a risk that the swarm disconnects and splits into several disjoint partitions 🙈 Finding the right mix of ALTO-biased and random peer selection is out of scope for this document, though 🤷♀️
So from an overall optimization perspective, the second scenario (ALTO client embedded in the resource directory) is the winner 👑 It's ensured that the addresses of the "best" resource providers are actually delivered to the resource consumer. The architectural implication is that ALTO server discovery procedures must support third-party discovery. Since the tracker issues ALTO queries on behalf of the peer that contacted it, 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 work. For instance, a tracker could use a coarse-grained "global" ALTO server to find peers in the general vicinity of the requesting peer, while peers use "local" ALTO servers for more fine-grained guidance 🌈 Yet there is no known deployment experience for such a combined approach yet 🤔
5. Using ALTO for CDNs 🌸
5.1. Overview 💖
5.1.1. Usage Scenario ✨
okay, this section briefly introduces ALTO for CDNs, as explained in [CDN-USE] 🧁 CDNs are used to deliver some internet services (like websites, software updates, and video delivery) from a location closer to the user. A CDN typically consists of a network of servers, often attached to ISP networks. The point of attachment is usually as close to content consumers and peering points as is economically or operationally feasible 🛰️ That cuts traffic load on the ISP backbone and gives a better user experience through reduced latency and higher throughput. Iconic behavior 💅
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 the necessary info about a set of candidate surrogates, and selecting and redirecting the user agent to the right surrogate. One common way is relying on the DNS system, but there are many other ways too, 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 RoutingTo get the most out of a CDN, it's preferable to deliver content from the servers (caches) that are "closest" to the end user requesting it 🍓 "Closest" might be as simple as geographical or IP topology distance, but it can also consider other combinations of metrics and CDN or ISP policies. As Figure 26 shows, 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 SelectionFigure 27 shows the interaction between a user agent, a request router, and a surrogate for content delivery in a single CDN 💫 As explained in [CDN-USE], the user agent makes an initial request to the CDN (F1). This could 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 router's knowledge of the network topology (which can be obtained by ALTO), the 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 💅
okay so the simplest way ALTO helps a CDN is by making surrogate or origin selection smarter 🧚 the CDN asks an ALTO server, and it picks a better CDN surrogate or origin than it otherwise would have 💖 yes, you can get raw network map and cost info other ways, like passively listening to the ISP's routing protocols or doing active probing 🙈 but an ALTO service lets the ISP keep more control over how their network map/cost gets exposed 🎀 it also helps the ISP keep a functional separation between their routing plane and their network map computation functions ✨ this is lowkey attractive for a bunch of reasons, like:
- 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. 🌸
- 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. 🦋
- 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 🍓 but as CDN servers get deployed deeper within ISP networks, the CDN needs more detailed knowledge of the underlying network topology and costs between network locations, so it can 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 aren't 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, so that's the only thing we're talking about here ✨
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) 😭 the whole "who even is asking" problem, honestly iconic
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 obtains the ranked list of locations (for the specific user) from the ALTO server, 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) 🎀
okay so Virtual Private Network (VPN) tech is EVERYWHERE 🦋 in public and private networks. It creates groups of users who are separated from everyone else on the network, and lets them talk to each other like they're on their own private network 💜 Network Service Providers (NSPs) offer different types of VPNs, and [RFC4026] splits Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) into different sub-types. In this section, "VPN" just means provider supplied virtual private networking, so we're all on the same page 💅
From an application's point of view at an endpoint, a VPN may not feel super different from any other IP connectivity 🥱 but there are a bunch of apps that could totally benefit from ALTO topology exposure and guidance in VPNs 🔥 Same as on the general Internet, one big perk is that apps don't have to do a ton of their own measurements. Potential use cases for ALTO application guidance in VPN environments are:
- Enterprise application optimization: Enterprise customers often run distributed apps that swap huge amounts of data, e.g., for synchronizing replicated data bases. Network topology info could be useful for placing replicas and for scheduling transfers 📦
- 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 smart routing and placement decisions of Virtual Machines (VMs) among the VPN sites 🧚
- Cloud-bursting: One or more VPN endpoints could be located in a public cloud. If an enterprise customer needs extra resources, they could be provided by a public cloud, which is accessed through the VPN. Network topology awareness would help decide which data center of the public cloud those resources should be allocated from 🌈
These examples focus on enterprises, which are the typical VPN users 💼 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 shown 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 vibe across these use cases is that the apps won't necessarily be running on the public Internet, and the relationship between the VPN provider and customer is pretty well defined 🤝 Since VPNs often run in a managed environment, an ALTO server may have access to topology info (e.g., traffic engineering data) that wouldn't be available on the public Internet, and it may expose that info to the VPN customer only 🔐
Also, a VPN isn't necessarily static 🙈 The customer could modify the VPN and add new VPN sites through a Web portal, network management systems, or other OSS solutions. Before adding a new VPN site, an application won't have connectivity to that site, so an ALTO server could offer access to info that an application can't 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 🍓
Deploying intra-domain P2P caches has been proposed for cooperation between the network operator and the P2P service providers, e.g., to reduce 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 shows the overall architecture of potential P2P cache deployments inside an ISP 2 with various access network types 🗺️ As the figure shows, P2P caches may be deployed at various levels: the interworking gateway linking with other ISPs, internal access network gateways linking with different types of access networks (e.g., WLAN, cellular, and wired), and even within an access 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 a cache architecture like this, the locations of caches could be used as dividers between different PIDs, to guide intra-ISP network abstraction and mark costs among them based on the location and type of the 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 for leveraging ALTO for joint network and application-layer optimization are explained in [RFC7491] 🚀
7. Security Considerations 🔒
Security concerns were discussed extensively from the very beginning of ALTO protocol development, and they were 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 the unwanted disclosure of information through ALTO and the negative impact of specially crafted, wrong ("faked") guidance presented to an ALTO client. On top of that, the usual concerns related to running any networked application apply too 🚨
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 developing 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 have no central control entity, and the whole overlay consists only of peers, which are under the control of 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 made worse by the vast number of different P2P applications that are evolving quickly and often without any coordination with network operators 😵💫
In summary, 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 🥹 This differs from more-controlled environments (e.g., 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 🕵️
Okay bestie, an ALTO server gets loaded up with info about the ISP's network and maybe even neighboring ISPs 👀. Stuff like network topology and business relations is usually super confidential to the ISP, and it can be really sensitive. ALTO doesn't require any particular level of detail about what gets disclosed, so the provider should evaluate how much info is revealed and what risks come with it 💅.
Also, if the ALTO info is very fine grained, it can count as sensitive for user privacy too 🙈. Picture an endpoint property like "provisioned access link bandwidth" or "access technology (ADSL, VDSL, FTTH, etc.)" that gets published for individual IP addresses. That could be used for traffic optimization, but it could also be used for targeted advertising, like special banner ads for residential users with exceptionally good (or bad) connectivity 🍓. For an advertisement system, getting that info another way, like through bandwidth probing, would be way more complex 😤.
Different scenarios related to 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, you can't use access control (see Section 7.3) to limit who gets ALTO knowledge to a small set of trusted clients 🚫. In those scenarios, it can seem tempting to skip network maps and cost maps entirely and just rely on ECS and endpoint ranking in the ALTO server 🤔. Here's the tea, though. While that can reduce how much info gets disclosed to any one ALTO client, a few things need thinking about. First, with the map-based approach, it's trivial to analyze the maximum amount of info that could be disclosed to a client, which is the full maps 🗺️. With 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 info than they're expected to get (see Section 5.2.1., case (3) in [RFC6708]). Second, the ECS reveals more info about the user or application behavior to the ALTO server, like which other hosts are considered peers for exchanging a significant amount of data (see Section 5.2.1., cases (4)-(6) in [RFC6708]) 👀.
So users may be more reluctant to use the ALTO service at all if it's based on ECS instead of providing network and cost maps 😬. Some popular P2P applications are sometimes used for things like distributing files without explicit permission from the copyright owner, so it may also be in the interest of the ALTO server operator that an ALTO server cannot infer the behavior of the application being optimized 🙅♀️. One possible conclusion is to publish network and cost maps through ALTO that are so coarse grained that they don't 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, like 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. That includes 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 access only 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, that still includes 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. That might not be the ISP's intention, because the server is not only subject to more possible attacks, but the server load could also increase, since possibly more ALTO clients have to be served 😱.
There are also use cases where access to the ALTO server has to be much more strictly controlled, i.e., where authentication and authorization of the ALTO client to the server may be needed 🛡️. For instance, in the 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, and access to the ALTO servers by residential users may neither be necessary nor desired 🙅♀️.
Access control can also help prevent Denial-of-Service (DoS) attacks by arbitrary hosts from the Internet 🚨. DoS can affect both an ALTO server and an ALTO client. A server can get overloaded if too many requests hit it, or if the query load surpasses the maximum computing capacity of the server 🔥. An ALTO client can get overloaded if the responses from the sever are too large to be handled by that particular client, either intentionally or due to an implementation mistake 😵.
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's a list of examples of how 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 won't pose a big risk to the network or peers, since 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 quite a number of peers 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
okay bestie, here's the non-normative reading list 📚💖 these are the docs ALTO's story is built on, so every single one stays exactly as written, no edits 🫶
[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 doc was a group project 🫶 here's who helped make it happen:
- Xianghue Sun, Lee Kai, and Richard Yang contributed text on ISP deployment requirements and monitoring. 💅
- Rich Woundy contributed text to Section 3.3. 🦋
- 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. 💜 absolute legends, all of them 👑
Authors' Addresses 🧚
and here are the people who wrote it, with their contact info 💖
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📦 where this page comes from
- ietf: rfc7971 2016-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms