RFC 7285
Application-Layer Traffic Optimization (ALTO) Protocol
Application-Layer Traffic Optimization (ALTO) Protocol 🦋
Request for Comments: 7285 🎀
- Category: Standards Track 👑
- ISSN: 2070-1721
- Date: September 2014 📅
- Obsoletes/Updates: the title block doesn't say this one obsoletes or updates any other RFC 💅
Authors (the editors are the ones marked Ed.): 💖
- R. Alimi, Ed. (Google) 🧚
- R. Penno, Ed. (Cisco Systems, Inc.) 🧚
- Y. Yang, Ed. (Yale University) 🧚
- S. Kiesel (University of Stuttgart) 🌸
- S. Previdi (Cisco Systems, Inc.) 🌸
- W. Roome (Alcatel-Lucent) 🌸
- S. Shalunov (Open Garden) 🌸
- R. Woundy (Comcast) 🌸
Abstract ✨
Okay so, bestie, listen 🫶. Apps on the Internet already get some topology info about ISP networks. Like, Looking Glass servers let you see Internet routing tables, and lots of network app clients can actually download that stuff, no cap 💅. But the thing that's been missing is the ISP's own view of its network topology. Basically, what does an ISP actually want when it comes to traffic optimization, and how does it share that with everyone? 👀 That's the whole gap.
The Application-Layer Traffic Optimization (ALTO) services in this document give apps network information, like the basic structure of network locations and how much the ISP prefers particular network paths. The goal is to change how network resources get used while keeping app performance the same or making it better 🔥. ALTO's basic info is built on abstract maps of a network. These maps are a simplified view, but they still have enough detail for apps to use them well. Extra services get stacked on top of those maps ✨.
This document describes a protocol that implements the ALTO services 🎀. ISPs would mainly be the ones providing ALTO, but other entities, like content service providers, could offer it too. Which apps can use ALTO? The ones that get to choose which end points to connect to. Peer-to-peer (P2P) apps and content delivery networks are the classic examples 🌈. Iconic behavior, honestly.
Status of This Memo 💜
This is an Internet Standards Track document 📜.
It's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, has been through public review, and got approved for publication by the Internet Engineering Steering Group (IESG) 🙌. For more on Internet Standards, check out Section 2 of RFC 5741 📚.
Want the current status, any errata, or a way to send feedback? Head over to http://www.rfc-editor.org/info/rfc7285 🦋.
Copyright Notice 🌸
Copyright (c) 2014 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), as they stand on the publication date of this document. Read these carefully, bestie, because they spell out your rights and restrictions for this document 🥹. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License ⚠️.
Part 1 of 18 is done, so part 2 is coming up next 🧚✨
Table of Contents 🎀
Okay bestie, here's the whole map of the doc so you can see where everything lives 🗺️✨
1. Introduction ....................................................6
1.1. Problem Statement ..........................................6
1.1.1. Requirements Language ...............................7
1.2. Design Overview ............................................7
2. Terminology .....................................................7
2.1. Endpoint ...................................................8
2.2. Endpoint Address ...........................................8
2.3. Network Location ...........................................8
2.4. ALTO Information ...........................................8
2.5. ALTO Information Base ......................................8
3. Architecture ....................................................8
3.1. ALTO Services and Protocol Scope ...........................9
3.2. ALTO Information Reuse and Redistribution .................11
4. ALTO Information Service Framework .............................11
4.1. ALTO Information Services .................................12
4.1.1. Map Service ........................................12
4.1.2. Map-Filtering Service ..............................12
4.1.3. Endpoint Property Service ..........................12
4.1.4. Endpoint Cost Service ..............................13
5. Network Map ....................................................13
5.1. Provider-Defined Identifier (PID) .........................13
5.2. Endpoint Addresses ........................................14
5.3. Example Network Map .......................................14
6. Cost Map .......................................................15
6.1. Cost Types ................................................16
6.1.1. Cost Metric ........................................16
6.1.2. Cost Mode ..........................................17
6.2. Cost Map Structure ........................................18
6.3. Network Map and Cost Map Dependency .......................18
6.4. Cost Map Update ...........................................19
7. Endpoint Properties ............................................19
7.1. Endpoint Property Type ....................................19
7.1.1. Endpoint Property Type: pid ........................19
8. Protocol Specification: General Processing .....................19
8.1. Overall Design ............................................19
8.2. Notation ..................................................20
8.3. Basic Operations ..........................................21
8.3.1. Client Discovering Information Resources ...........21
8.3.2. Client Requesting Information Resources ............22
8.3.3. Server Responding to Information Resource Request ..22
8.3.4. Client Handling Server Response ....................23
8.3.5. Authentication and Encryption ......................23
8.3.6. Information Refreshing .............................24
8.3.7. Parsing of Unknown Fields ..........................24
8.4. Server Response Encoding ..................................24
8.4.1. Meta Information ...................................24
8.4.2. Data Information ...................................25
8.5. Protocol Errors ...........................................25
8.5.1. Media Type .........................................25
8.5.2. Response Format and Error Codes ....................25
8.5.3. Overload Conditions and Server Unavailability ......28
9. Protocol Specification: Information Resource Directory .........28
9.1. Information Resource Attributes ...........................29
9.1.1. Resource ID ........................................29
9.1.2. Media Type .........................................29
9.1.3. Capabilities .......................................29
9.1.4. Accepts Input Parameters ...........................29
9.1.5. Dependent Resources ................................30
9.2. Information Resource Directory (IRD) ......................30
9.2.1. Media Type .........................................30
9.2.2. Encoding ...........................................30
9.2.3. Example ............................................32
9.2.4. Delegation Using IRD ...............................35
9.2.5. Considerations of Using IRD ........................37
10. Protocol Specification: Basic Data Types ......................38
10.1. PID Name .................................................38
10.2. Resource ID ..............................................38
10.3. Version Tag ..............................................38
10.4. Endpoints ................................................39
10.4.1. Typed Endpoint Addresses ..........................39
10.4.2. Address Type ......................................39
10.4.3. Endpoint Address ..................................40
10.4.4. Endpoint Prefixes .................................40
10.4.5. Endpoint Address Group ............................41
10.5. Cost Mode ................................................41
10.6. Cost Metric ..............................................42
10.7. Cost Type ................................................42
10.8. Endpoint Property ........................................42
10.8.1. Resource-Specific Endpoint Properties .............43
10.8.2. Global Endpoint Properties ........................43
11. Protocol Specification: Service Information Resources .........43
11.1. Meta Information .........................................43
11.2. Map Service ..............................................43
11.2.1. Network Map .......................................44
11.2.2. Mapping IP Addresses to PIDs for
'ipv4'/'ipv6' Network Maps ........................46
11.2.3. Cost Map ..........................................47
11.3. Map-Filtering Service ....................................50
11.3.1. Filtered Network Map ..............................50
11.3.2. Filtered Cost Map .................................53
11.4. Endpoint Property Service ................................57
11.4.1. Endpoint Property .................................58
11.5. Endpoint Cost Service ....................................61
11.5.1. Endpoint Cost .....................................61
12. Use Cases .....................................................64
12.1. ALTO Client Embedded in P2P Tracker ......................65
12.2. ALTO Client Embedded in P2P Client: Numerical Costs ......66
12.3. ALTO Client Embedded in P2P Client: Ranking ..............67
13. Discussions ...................................................68
13.1. Discovery ................................................68
13.2. Hosts with Multiple Endpoint Addresses ...................68
13.3. Network Address Translation Considerations ...............69
13.4. Endpoint and Path Properties .............................69
14. IANA Considerations ...........................................70
14.1. application/alto-* Media Types ...........................70
14.2. ALTO Cost Metric Registry ................................71
14.3. ALTO Endpoint Property Type Registry .....................73
14.4. ALTO Address Type Registry ...............................75
14.5. ALTO Error Code Registry .................................76
15. Security Considerations .......................................76
15.1. Authenticity and Integrity of ALTO Information ...........77
15.1.1. Risk Scenarios ....................................77
15.1.2. Protection Strategies .............................77
15.1.3. Limitations .......................................77
15.2. Potential Undesirable Guidance from Authenticated ALTO
Information ..............................................78
15.2.1. Risk Scenarios ....................................78
15.2.2. Protection Strategies .............................78
15.3. Confidentiality of ALTO Information ......................79
15.3.1. Risk Scenarios ....................................79
15.3.2. Protection Strategies .............................79
15.3.3. Limitations .......................................80
15.4. Privacy for ALTO Users ...................................80
15.4.1. Risk Scenarios ....................................80
15.4.2. Protection Strategies .............................80
15.5. Availability of ALTO Services ............................81
15.5.1. Risk Scenarios ....................................81
15.5.2. Protection Strategies .............................81
16. Manageability Considerations ..................................81
16.1. Operations ...............................................82
16.1.1. Installation and Initial Setup ....................82
16.1.2. Migration Path ....................................82
16.1.3. Dependencies on Other Protocols and
Functional Components .............................83
16.1.4. Impact and Observation on Network Operation .......83
16.2. Management ...............................................84
16.2.1. Management Interoperability .......................84
16.2.2. Management Information ............................84
16.2.3. Fault Management ..................................84
16.2.4. Configuration Management ..........................84
16.2.5. Performance Management ............................85
16.2.6. Security Management ...............................85
17. References ....................................................85
17.1. Normative References .....................................85
17.2. Informative References ...................................86
Appendix A. Acknowledgments .......................................89
Appendix B. Design History and Merged Proposals ...................901. Introduction ✨
1.1. Problem Statement 🌸
okay so this doc is all about the ALTO Protocol, which is the answer to the problem laid out in [RFC5693]. bestie, here's the tea: in today's networks, stuff like network topologies, link availability, routing policies, and path costs is hidden from the application layer, and a lot of apps have been happily benefiting from all that hiding of network complexity. 🙈 But new apps, like application-layer overlays, can actually level up by knowing about the infrastructure underneath them. These apps can be adaptive, so they get more network efficient (think less network resource consumption) and hit better application performance (like a faster download rate) just by using info the network hands them. it's giving main character energy 💅
At a high level, the ALTO Protocol in this doc is an information-publishing interface. It lets a network publish its info, like network locations, costs between them at configurable granularities, and endhost properties, to network apps. The info published by ALTO should benefit both the network and the apps (aka the consumers of the info). Either the network operator or a third party (like an information aggregator) can grab or derive related network info and publish it using ALTO. 🦋
To help you get the goal, this doc gives a short, non-normative overview of how ALTO helps both networks and apps:
- A network that provides ALTO information can get better utilization of its networking infrastructure. For example, by using ALTO to interact with apps, a network can give apps the info they need to better manage traffic on pricey or hard-to-provision links, like long-distance, transit, or backup links. During the interaction, the network can choose to protect its sensitive and confidential network state info by abstracting real metric values into non-real numerical scores or ordinal ranking. 🔐
- An application that uses ALTO information can benefit from better knowledge of the network to avoid network bottlenecks. For example, an overlay app can use info from the ALTO services to avoid picking peers connected via high-delay links (like some intercontinental links). Using ALTO to start each node off with promising ("better-than-random") peers, an adaptive peer-to-peer overlay may get faster, better convergence. 🚀
1.1.1. Requirements Language ✨
the big capital words in this doc are the official key words, and they're meant to be read exactly like that. 🎀 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Design Overview 💖
okay so the ALTO Protocol here meets the ALTO requirements from [RFC5693], and it unifies a bunch of protocols that were previously designed with similar goals. slay, right? 👑 Check out Appendix A for a list of people and Appendix B for a list of proposals that made major contributions to this effort.
the protocol is REST-ful (Representational State Transfer (REST)) in design [Fielding-Thesis], and it encodes its requests and responses in JSON [RFC7159]. Both of these were picked for their flexibility and extensibility, which is so important. ✨ Plus, these designs make it possible for ALTO to be deployed at scale by leveraging existing HTTP [RFC7230] implementations, infrastructures, and deployment experience. literally so smart. 🧠
ALTO splits info publication into multiple ALTO services, which is a very modular, very iconic move 🧚. Some examples are the Map service, the Map-Filtering Service, the Endpoint Property Service, and the Endpoint Cost Service. Each ALTO service provides its own set of functionalities and is realized by a set of information resources. Those resources get announced by information resource directories, which guide ALTO clients to them. 🗺️
2. Terminology 🦋
this doc uses the following terms defined in [RFC5693]: Application, Overlay Network, Peer, Resource, Resource Identifier, Resource Provider, Resource Consumer, Resource Directory, Transport Address, ALTO Server, ALTO Client, ALTO Query, ALTO Response, ALTO Transaction, Local Traffic, Peering Traffic, and Transit Traffic.
this doc extends the term "ALTO Service" from [RFC5693]. By adopting a modular design, it lets the ALTO Protocol offer multiple ALTO services, and that's a whole mood. 💅
this doc also uses these additional terms: Endpoint Address, Network Location, ALTO Information, and ALTO Information Base.
2.1. Endpoint 🌈
an endpoint is an application or host that can communicate on a network, meaning it can send and/or receive messages. 💌
an endpoint is typically either a resource provider or a resource consumer. 🫶
2.2. Endpoint Address 🎀
an endpoint address is the communication address of an endpoint. Common forms include IP addresses, Media Access Control (MAC) addresses, and overlay IDs. An endpoint address can be network-attachment based (like an IP address) or network-attachment agnostic (like a MAC address). 🧭
each endpoint address has an associated address type, which tells you both its syntax and its semantics. 🔍
2.3. Network Location 🍓
this doc uses network location as a generic term for a single endpoint or a group of endpoints. For instance, it can be a single IPv4 or IPv6 address, an IPv4 or IPv6 prefix, or a set of prefixes. 📍
2.4. ALTO Information 💜
this doc uses ALTO information as a generic term for the network information provided by an ALTO server. 🌸
2.5. ALTO Information Base 🧚
this doc uses the term ALTO information base to refer to the internal representation of ALTO information that an ALTO server keeps. Heads up, though: this doc does not define the structure of that internal representation. 🙈
3. Architecture 🏗️
this section defines the ALTO architecture and where the ALTO Protocol fits into the overall picture. ✨
3.1. ALTO Services and Protocol Scope 🌍
each network region in the global Internet can provide its own ALTO services, which convey network information from that region's perspective. A network region here can be an Autonomous System (AS), an ISP, a region smaller than an AS or ISP, or a set of ISPs. Which specific network region an ALTO service represents depends on the ALTO deployment scenario and the ALTO service discovery mechanism. 🗺️
the ALTO services in this doc define network endpoints (and aggregations of them) and generic costs between them, from the region's point of view. The network endpoints may include all endpoints in the global Internet. We say the network info provided by the ALTO services of a network region represents the "my-Internet view" of that region. 👀
the "my-Internet view" defined in this doc does not specify a network's internal topology, so it's said to provide a "single-node" abstract topology. Extensions to this doc may provide topology details in "my-Internet view". 🔮
Figure 1 gives you the big-picture vibe of ALTO's system architecture, so you can see the ALTO services and the role of the ALTO Protocol. In this architecture, an ALTO server prepares ALTO information, an ALTO client uses ALTO service discovery to find an appropriate ALTO server, and the ALTO client requests available ALTO information from that server using the ALTO Protocol. 🧩
the ALTO information from the ALTO server can be updated dynamically based on network conditions, or it can be seen as a policy that gets updated on a longer time scale. ⏳
+-------------------------------------------------------------------+
| Network Region |
| |
| +-----------+ |
| | Routing | |
| +--------------+ | Protocols | |
| | Provisioning | +-----------+ |
| | Policy | | |
| +--------------+\ | |
| \ | |
| \ | |
| +-----------+ \+---------+ +--------+ |
| |Dynamic | | ALTO | ALTO Protocol | ALTO | |
| |Network |.......| Server | ==================== | Client | |
| |Information| +---------+ +--------+ |
| +-----------+ / / |
| / ALTO SD Query/Response / |
| / / |
| +----------+ +----------------+ |
| | External | | ALTO Service | |
| | Interface| | Discovery (SD) | |
| +----------+ +----------------+ |
| | |
+-------------------------------------------------------------------+
|
+------------------+
| Third Parties |
| |
| Content Providers|
+------------------+
Figure 1: Basic ALTO ArchitectureFigure 1 shows that the ALTO information from an ALTO server may be influenced (at the service provider's discretion) by other systems. The ALTO server can aggregate info from multiple systems to give an abstract, unified view that's more useful to apps. 🧃 Other systems include (but aren't limited to) static network configuration databases, dynamic network information, routing protocols, provisioning policies, and interfaces to outside parties. Those components are in the figure for completeness, but they're outside the scope of this spec. And remember, while the ALTO Protocol may convey dynamic network information, it is not meant to replace near-real-time congestion control protocols. 🚫
it may also be possible for an ALTO server to exchange network information with other ALTO servers (either inside the same administrative domain or in another one, with the consent of both parties) to adjust the exported ALTO information. That kind of protocol is also outside the scope of this spec. 🤝
3.2. ALTO Information Reuse and Redistribution 🔁
okay so ALTO info can be useful for a ton of apps and users 🌍 but spreading it around has to be efficient, bestie. it can't turn into a bottleneck 😭
the ALTO Protocol is designed to plug into the existing HTTP caching setup for redistribution 🧠 which means if caching or redistribution is happening, the response an ALTO client gets back may come from a third party. no cap, that's a whole vibe 🦋
apps can also use their own mechanisms, like P2P Distributed Hash Tables (DHTs) or P2P file sharing, to cache and redistribute ALTO info 🌸 this document does not define any specific mechanism for that redistribution, so it's left open 💅
extra protocol features, like expiration times and digital signatures for returned ALTO info, are left for future investigation 🔮 we'll see what happens 👀
4. ALTO Information Service Framework ✨
okay now we're getting into the good stuff 🤩 the ALTO Protocol shares network info through ALTO information services (services for short), and each service covers a set of related functionalities 💖 an ALTO client can request each service on its own 🎀
all the services defined in ALTO together form the ALTO service framework 🧚 they all run on a shared transport protocol, messaging structure and encoding, and transaction model. the functionalities in different services can overlap, which is totally fine 🫶
the goals of the ALTO information services in this document are to convey three things: (1) network locations, which denote where endpoints sit in a network 📍, (2) provider-defined costs for paths between pairs of network locations 💰, and (3) network-related properties of endpoints 🌈
to get all that done, we have the Map Service, which gives clients the core ALTO info 🗺️, plus three more information services: the Map-Filtering Service, the Endpoint Property Service (EPS), and the Endpoint Cost Service (ECS) 🫧 more services can show up in companion documents later 🌸 Figure 2 gives you the big picture, and the details come in the sections that follow 📖
.-----------------------------------------.
| ALTO Information Services |
| .-----------. .----------. .----------. |
| | Map- | | Endpoint | | Endpoint | |
| | Filtering | | Property | | Cost | |
| | Service | | Service | | Service | |
| `-----------' `----------' `----------' |
| .-------------------------------------. |
| | Map Service | |
| | .-------------. .--------------. | |
| | | Network Map | | Cost Map | | |
| | `-------------' `--------------' | |
| `-------------------------------------' |
`-----------------------------------------'Figure 2: ALTO Information Service Framework
4.1. ALTO Information Services 💅
4.1.1. Map Service 🗺️
the Map Service gives ALTO clients batch info in the form of ALTO network maps (network maps for short) and ALTO cost maps (cost maps for short) 🍓 an ALTO network map (see Section 5) gives the full set of network location groupings defined by the ALTO server, plus the endpoints in each grouping ✨ an ALTO cost map (see Section 6) gives costs between those groupings 💜
you can think of these two maps as simple files with appropriate encoding from the ALTO server, and honestly that's a super clean way to picture it 🧁
4.1.2. Map-Filtering Service 🔍
resource-constrained ALTO clients can really benefit from having query results filtered at the ALTO server 🙏 otherwise a client would spend network bandwidth and CPU cycles collecting everything first, and only then filter it on its own side 😩 the Map-Filtering Service lets ALTO clients query an ALTO server for network maps and/or cost maps based on extra parameters 🎯
4.1.3. Endpoint Property Service 🪪
this service lets ALTO clients look up properties for individual endpoints 👀 one example property is an endpoint's network location (its grouping defined by the ALTO server) 📍 another is its connectivity type, like ADSL (Asymmetric Digital Subscriber Line), Cable, or FTTH (Fiber To The Home) 🏠
4.1.4. Endpoint Cost Service 💸
some ALTO clients can also benefit from asking for costs and rankings based on endpoints 📊 the Endpoint Cost Service lets an ALTO server return costs directly between endpoints, which is very iconic 👑
5. Network Map 🗺️
an ALTO network map defines a grouping of network endpoints 🫶 this document uses "ALTO network map" to refer to the syntax and semantics of how an ALTO server defines that grouping 📝 it does not get into how that data structure is represented inside an ALTO server 🙈
here's the thing: in real life, lots of endpoints are near each other in terms of network connectivity 🌸 so an ALTO server can treat a group of nearby endpoints as one single entity 🧩 that's how it shows these endpoints got aggregated because they're close together 💖 and this aggregation can make things more scalable without losing important info when sharing other network info, like when defining cost maps 🚀
5.1. Provider-Defined Identifier (PID) 🆔
the tricky part is that "close" depends on how granular the provider's ALTO info is 🔎 in one deployment, endpoints on the same subnet might count as close 🏡 but in another, endpoints connected to the same Point of Presence (POP) might count as close instead 📡
ALTO introduces provider-defined network location identifiers called Provider-defined Identifiers (PIDs) 🪄 they give an indirect, network-agnostic way to point at a group of network endpoints that can be treated similarly, based on network topology, type, or other properties 🧠 specifically, a PID is a string of type PIDName (see Section 10.1) plus its associated set of endpoint addresses 📦 as mentioned, there are lots of ways to group endpoints and assign PIDs 🧁 for example, a PID might be a subnet, a set of subnets, a metropolitan area, a POP, an autonomous system, or a set of autonomous systems 🌈 if you use the "single-node" abstraction, you can think of each PID as an abstract port (POP) that connects a set of endpoints 🔌
a key use case for PIDs is specifying network preferences (costs) between PIDs instead of between individual endpoints 💜 that keeps cost info compact and lets it get updated on a faster time scale than the network aggregations themselves ⚡ for example, an ISP might prefer that endpoints tied to the same POP in a P2P app talk locally instead of reaching endpoints in other POPs 🏃♀️ so the ISP groups the endpoints inside a POP into a single PID in a network map 🫧 the cost can then be encoded to show that network locations in the same PID are preferred, like cost(PID_i, PID_i) == c and cost(PID_i, PID_j) > c for i != j 🎀 Section 6 has more on using PIDs to represent costs in an ALTO cost map 📖
5.2. Endpoint Addresses 📬
the endpoints grouped into a PID are denoted by endpoint addresses 🫶 there are many types of addresses, like IP addresses, MAC addresses, or overlay IDs 🌐 this document specifies (in Section 10.4) how to write IPv4/IPv6 addresses or prefixes 💻 extension documents can define more address types, and Section 14.4 of this document provides an IANA registry for endpoint address types 📚
5.3. Example Network Map 🧪
this document uses the ALTO network map in Figure 3 for most of its examples 🥰
.------------------------------------------------------------.
| An ALTO Network Map |
| |
| .-----------------------------------. .----------------. |
| | NetLoc: PID-1 | | NetLoc: PID-3 | |
| | .------------------------------. | | | |
| | | 192.0.2.0/24 | | | .-----------. | |
| | | .--------------------------. | | | | 0.0.0.0/0 | | |
| | | | Endpoint: 192.0.2.34 | | | | `-----------` | |
| | | `--------------------------` | | | | |
| | `------------------------------` | | | |
| | .------------------------------. | | | |
| | | 198.51.100.0/25 | | | | |
| | | .--------------------------. | | | | |
| | | | Endpoint: 198.51.100.100 | | | | | |
| | | `--------------------------` | | | | |
| | `------------------------------` | | | |
| `-----------------------------------` | | |
| | | |
| .-----------------------------------. | | |
| | NetLoc: PID-2 | | | |
| | .------------------------------. | | | |
| | | 198.51.100.128/25 | | | | |
| | `------------------------------` | | | |
| `-----------------------------------` `----------------` |
`------------------------------------------------------------`Figure 3: Example Network Map
6. Cost Map 💰
an ALTO server shares its preferences between network locations in the form of path costs 💅 path costs are generic costs, and a network provider can compute them internally according to its own policy 🧠
for a given ALTO network map, an ALTO cost map defines path costs pairwise between the set of source and destination network locations defined by the PIDs in that network map 🗺️ each path cost is the end-to-end cost when one unit of traffic goes from the source to the destination 🚚
cost is directional (source to destination) 🧭 so an application using ALTO info can decide for itself which side is the resource consumer and which is the resource provider when it writes an ALTO query, and therefore how to use the path cost it gets back 🎯 for example, if cost is expected to be correlated with throughput, an app focused on bulk data retrieval might use the resource provider as the source and the resource consumer as the destination 📦
one perk of keeping ALTO info split into network maps and cost maps is that the two can be updated on different time scales 🕰️ for example, network maps might stay stable for longer, while cost maps get updated to reflect more dynamic network conditions 🌊
as used in this document, an ALTO cost map refers to the syntax and semantics of the info the ALTO server distributes 💖 this document does not discuss how that data structure is represented inside the ALTO server 🙈
6.1. Cost Types ✨
okay so path costs have two attributes and they're literally the whole vibe 💅
- Cost Metric: tells you what the costs represent 📏
- Cost Mode: tells you how to read the costs 🔍
When you combine a cost metric and a cost mode, you get an ALTO cost type 🎀 Some queries let the ALTO client ask for a specific cost type, and for any given ALTO server, the cost type plus the network map is the key. So an ALTO server MUST NOT define two ALTO cost maps with the same cost type \ network map pair. No duplicates, bestie 🙅♀️
6.1.1. Cost Metric
The cost metric is the "what" 💖 An ALTO server could define costs for things like air miles, hop-counts, or generic routing costs. In protocol messages, cost metrics are written as strings 🧚
6.1.1.1. Cost Metric: routingcost
An ALTO server MUST offer the routingcost cost metric 👑
This one is a generic measure of how expensive it is to route traffic from a source to a destination 🌸 Lower numbers mean a higher preference for sending traffic from that source to that destination. Simple, iconic 🫶
Heads up: an ISP is free to work out routing cost however it wants internally, like with air miles or hop-count, as long as it still follows the meaning above 🤓
6.1.2. Cost Mode
The cost mode is all about how to interpret the numbers 🦋 It says whether the returned costs are numerical values or ordinal rankings.
This matters SO much because some operations only make sense for some kinds of costs 😭 Imagine a server returns a bunch of IP addresses with costs that just show a ranking. Doing arithmetic on rankings is nonsense! So ALTO clients may need to handle those costs differently 💀
Cost modes are also written as strings in protocol messages 🍓
An ALTO server MUST support at least one of these modes: numerical or ordinal ✨ And an ALTO client has to be aware of what it can and can't do if its desired mode isn't supported. A client that wants numerical costs MAY adjust its behaviour if only ordinal is available. A client that wants ordinal costs MAY build its own ordinal costs from numerical values, if only numerical is available 🧠
6.1.2.1. Cost Mode: numerical
This mode is indicated by the string numerical 🔢 It means it's safe to do numerical operations on the returned costs, like normalization or computing ratios for weighted load-balancing. The values are floating-point numbers 💜
6.1.2.2. Cost Mode: ordinal
This mode is indicated by the string ordinal 🏅 The numbers in a cost map represent a ranking, relative to all the other values in that cost map, and are not actual costs. The values are non-negative integers, and a lower value means a higher preference.
Ordinal values don't have to be unique or contiguous 😳 So two entries in a cost map can have the exact same rank. This document doesn't say what an ALTO client should do in that case. It could break the tie randomly, use other app knowledge, or do something else entirely 🎲
6.2. Cost Map Structure ✨
A request for an ALTO cost map includes a list of source network locations and a list of destination network locations, either explicitly or implicitly. (Quick reminder: a network location can be an endpoint address or a PID 🎀)
Say a request has source locations [Src_1, Src_2, ..., Src_m] and destination locations [Dst_1, Dst_2, ..., Dst_n] 💅
The ALTO server returns the path cost for each of the m*n communicating pairs: Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., Src_m -> Dst_1, ..., Src_m -> Dst_n 🌈 If the server doesn't define the path cost for a particular pair, that cost may be omitted. This document calls this whole structure a cost map 🦋
If the cost mode is ordinal, each communicating pair's path cost is ranked relative to those m*n entries 🏆
6.3. Network Map and Cost Map Dependency ✨
Here's the tea 🫖 A cost map gives path costs between the PIDs defined in an ALTO network map. But an ALTO server can change a network map at any time, like adding or deleting PIDs or even redefining them. So to actually use a cost map, an ALTO client needs to know which version of the network map defined its PIDs 🕵️♀️ That's what version tags are for: they let the client match up cost map instances with the right network map versions.
A version tag is a tuple of (1) an ID for the resource, like an ALTO network map, and (2) a tag, which is an opaque string tied to that version of the resource 🎀 An ALTO network map from the server includes its version tag, and a cost map that refers to PIDs also includes the version tag of the network map it's based on 🫶
Two ALTO network maps are the same if they have the same version tag 👯♀️ And whenever the content of a network map changes, the tag MUST also change, no exceptions 🚨 For the tag, people might use the last-modified timestamp of the network map, or a hash of its contents, where the collision probability is treated as zero in practical deployments 🌟
6.4. Cost Map Update ✨
An ALTO server can update a cost map at any time 🔄 So the same cost map, fetched from the same server but with different requests, can come back inconsistent. Just something to keep in mind, babe 🙈
7. Endpoint Properties ✨
An endpoint property is a network-aware property of an endpoint 🧚♀️
7.1. Endpoint Property Type ✨
For each endpoint and each endpoint property type, there can be a value for that property 💖 The property type is written as a string in protocol messages, and the value depends on the specific property. For example, for whether an endpoint is metered, the value is just true or false 🍓 Check out Section 10.8 for more on specifying endpoint properties.
7.1.1. Endpoint Property Type: pid
An ALTO server MUST define the pid endpoint property type for each ALTO network map it provides 🌸 Each network map defines multiple PIDs. For an ipv4/ipv6 network map, the server takes an endpoint's IP address and uses the algorithm in Section 11.2.2 to look up that endpoint's PID. That PID is the endpoint's pid property for that network map. There's an example in Section 11.4.1.7 🔍
8. Protocol Specification: General Processing ✨
This section covers general client and server processing first 📋 The details for specific services come in the sections after it 👑
8.1. Overall Design ✨
The ALTO Protocol uses a REST-ful design 🦋 There are two main components:
- Information Resources: Every ALTO service is made up of a set of network information resources. Each one has a media type [RFC2046] 🎀 An ALTO client can build an HTTP request for a particular information resource (with any parameters it needs), and the ALTO server sends that resource back in an HTTP response 💌
- Information Resource Directory (IRD): An ALTO server uses an IRD to tell ALTO clients which information resources are available and the URI where each one can be accessed 🗺️ ALTO clients check the IRDs to find out what services an ALTO server provides ✨
8.2. Notation ✨
This document uses JSONString, JSONNumber, and JSONBool for the JSON string, number, and boolean types 🧁 The type JSONValue means any JSON value, as specified in Section 3 of [RFC7159] 💜
This document uses a bit of an adapted C-style struct notation to describe JSON objects 🧸 A JSON object is made of name/value pairs, and each pair is called a field. Sometimes it's also called an attribute, and its name can be called the key 🔑 An optional field goes inside [ ]. Field names are case sensitive in JSON. An array is written with two numbers in angle brackets, <m..n>, where m is the minimum number of values and n is the maximum. If n is *, there's no upper bound 🌈
For example, this defines a new type Type4 with three fields, "name1", "name2", and "name3". "name3" is optional, and "name2" is an array with at least one value 🎀
object { Type1 name1; Type2 name2<1..*>; [Type3 name3;]
} Type4;This document also defines dictionary maps (or just maps for short) from strings to JSON values 🗂️ For example, this defines Type3 as a map. Type1 has to be a string, and Type2 can be any type 💅
object-map { Type1 -> Type2; } Type3;This document uses subtyping to show that one type is derived from another 🦋 In this example, TypeDerived is derived from TypeBase. TypeDerived includes all the fields TypeBase has. If TypeBase doesn't have a field named "name1", TypeDerived gets a new field named "name1". If TypeBase already has a "name1" field but with a different type, TypeDerived's "name1" uses the type defined in TypeDerived (that's Type1 in this example) 🫶
object { Type1 name1; } TypeDerived : TypeBase;Heads up though: even with all this notation, this document doesn't provide a standard, machine-readable interface definition or schema. Extension documents may describe these where needed 🤓
8.3. Basic Operations ✨
The ALTO Protocol uses standard HTTP [RFC7230] 🌐 It's used to discover the available information resources on an ALTO server and to retrieve them. ALTO clients and ALTO servers exchange HTTP requests and responses carrying ALTO-specific content, encoded as this document specifies, and they MUST be compliant with [RFC7230] 💖
Instead of using the generic application/json media type for all ALTO request parameters (if any) and responses, ALTO clients and servers use multiple specific JSON-based media types 🎀 Examples are application/alto-networkmap+json and application/alto-costmap+json. Table 2 lists the media types defined in this document. This makes the protocol easy to extend while keeping the semantics clear and versioned 🌸 For example, a new version of a component, like ALTO network maps, can just get a new media type, such as application/alto-networkmap-v2+json 🧚♀️✨
8.3.1. Client Discovering Information Resources ✨
okay so first things first, an ALTO client needs to find out what the server has to offer 🔍 To do that, it requests its IRD(s), which are the information resource directories 💅
Using an ALTO service discovery protocol, the client gets a URI it can use to request an information resource directory (IRD). This document calls that the Root IRD of the ALTO client 👑 Every entry in an IRD points to a URI where an ALTO server accepts requests, and the server returns either an information resource or another IRD with more information resources in it 🧚 Starting from the Root IRD and following the links to IRDs recursively, the client can discover all the information resources it has access to. That whole set is called the information resource closure of the ALTO client 🌸 By checking out its closure, the client can tell whether the server supports the resource it wants, and if so, the URI where that resource lives 💖
See Section 9.2 for a detailed specification of IRDs 📖
8.3.2. Client Requesting Information Resources 🎀
Where possible, the ALTO Protocol uses the HTTP GET method to request resources, so GET is the main move 🦋 Some ALTO services are different though. Their information resources depend on one or more input parameters. The input parameters go in the HTTP request's entity body, and that means the ALTO client MUST use the HTTP POST method to send them 📮
When an ALTO client asks for an information resource that needs input parameters in an HTTP POST request, it MUST set the Content-Type HTTP header to the media type that matches the format of those parameters 💅
Now the important bit 🚨 An ALTO client MUST NOT assume that HTTP GET and POST are interchangeable. Especially for an information resource that uses GET, the client MUST NOT assume that the resource will accept a POST request as if it were a GET request. Not the same vibe, bestie 🙈
8.3.3. Server Responding to Information Resource Request 🌈
When the ALTO server gets a request for an information resource it can provide, it normally sends back the requested resource ✨ In other cases, to be more informative ([RFC7231]), the server either gives the client an information resource directory that shows how to reach the desired resource, or it returns an ALTO error object. See Section 8.5 for more on ALTO error handling 🫶
Caching is a fun one 🧁 An ALTO server can use caching HTTP intermediaries to answer both GET and POST requests, as long as it includes explicit freshness information (see Section 14 of [RFC7230]). Caching POST requests isn't widely implemented by HTTP intermediaries though, so there's a workaround. In response to a POST request, the ALTO server can return an HTTP 303 status code ("See Other"). That tells the client the resulting information resource is available through a GET request to an alternate URL. HTTP intermediaries that don't support caching POST requests can then cache the response to the GET request that the client sends to that alternate URL from the 303 response, as long as the response to that subsequent GET request contains explicit freshness information 🍓
The ALTO server MUST indicate the type of its response using a media type, which goes in the Content-Type HTTP header of the response 📦
8.3.4. Client Handling Server Response 🦋
8.3.4.1. Using Information Resources
This specification doesn't say what ALTO clients have to do after they successfully receive an information resource from an ALTO server 🤷♀️ ALTO clients are suggested to interpret the ALTO information they get and adapt their application behavior, but they're not required to do so. Totally their call 💜
8.3.4.2. Handling Server Response and IRD
After getting an information resource directory, the client can check it to see if any of the offered URIs have the resource it wants 🔎 However, an ALTO client MUST NOT assume that the media type the server returns for a request to a URI is the same as the media type advertised in the IRD or specified in its request. The client must still check the Content-Type header 👀 The expectation is that the returned media type will normally match the one that was advertised and requested, but in some cases it may legitimately not be so. Plot twist, but it's allowed 😭
It's also possible for an ALTO client to get an information resource directory from the server as a response to its request for a specific information resource 🌀 When that happens, the client may ignore the response or still parse it. If an ALTO client wants to make it clear that it will always check whether a response is an information resource directory, it can say so in the "Accept" header of an HTTP request by indicating that it can accept an information resource directory. See Section 9.2.1 for the media type 🎀
8.3.4.3. Handling Error Conditions
If an ALTO client doesn't successfully receive the information resource it wanted from a particular ALTO server (meaning the server response indicates an error, or there's no response at all), the client can either choose another server if one is available, or fall back to a default behavior. The example given is performing peer selection without ALTO information, when it's used in a peer-to-peer system 🫠
8.3.5. Authentication and Encryption 🔐
ALTO server implementations and ALTO client implementations both MUST support the "https" URI scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246]. For security considerations on this, see Section 15.1.2, and for manageability considerations on using HTTPS/TLS, see Section 16 🔒
For deployment scenarios where client authentication is desired, HTTP Digest Authentication MUST be supported. TLS Client Authentication is the preferred mechanism if it's available 🗝️
8.3.6. Information Refreshing ⏰
An ALTO client can figure out how often ALTO information is refreshed based on the information made available through HTTP 🔄
8.3.7. Parsing of Unknown Fields 🙈
This document only details the object fields that this specification uses. Extensions may add extra fields inside the JSON objects defined in this document. ALTO implementations MUST ignore unknown fields when they process ALTO messages. Ignore the extras and keep it moving 💅✨
8.4. Server Response Encoding 🧚
Okay, each type of ALTO server response has its own distinct syntax and therefore its own unique media type: an information resource directory, an individual information resource, or an error message. Even so, they're all designed to have a similar structure. Each one has a field named "meta" for meta definitions, and another field named "data" that holds the data, if needed 🎀
This document defines the base type of each ALTO server response as ResponseEntityBase:
object { ResponseMeta meta; } ResponseEntityBase;with field:
meta: meta information pertaining to the response.
8.4.1. Meta Information
Meta information is encoded as a map object, which keeps things flexible 🌈 ResponseMeta is defined as:
object-map { JSONString -> JSONValue } ResponseMeta;8.4.2. Data Information
The data component of the response encodes the response-specific data 📊 This document derives five types from ResponseEntityBase to add different kinds of data component:
- InfoResourceDirectory (Section 9.2.2)
- InfoResourceNetworkMap (Section 11.2.1.6)
- InfoResourceCostMap (Section 11.2.3.6)
- InfoResourceEndpointProperties (Section 11.4.1.6)
- InfoResourceEndpointCostMap (Section 11.5.1.6)
8.5. Protocol Errors 🚨
If an ALTO server runs into an error while processing a request, it SHOULD return additional ALTO-layer information, if it's available, as an ALTO error resource encoded in the HTTP response' entity body. If no ALTO-layer information is available, the ALTO server MAY leave the ALTO error resource out of the response 🫣
With or without that extra ALTO-layer error info, an ALTO server MUST set an appropriate HTTP status code. The HTTP status code and the ALTO error resource have different jobs, and that's important 🧠 An ALTO error resource gives detailed info about why a particular request for an ALTO information resource didn't work. The HTTP status code, on the other hand, tells HTTP processing elements (like intermediaries and clients) how the response should be treated 🍭
8.5.1. Media Type 💌
The media type for an ALTO error response is application/alto-error+json.
8.5.2. Response Format and Error Codes ✨
okay so every ALTO error response MUST include a code field inside its meta field 💌 and the value MUST be an ALTO error code, encoded as a string, from Table 1 🎀 the codes in Table 1 are only the ones this document needs, so companion or extension docs may define more status codes 🦋
+-----------------------+-------------------------------------------+
| ALTO Error Code | Description |
+-----------------------+-------------------------------------------+
| E_SYNTAX | Parsing error in request (including |
| | identifiers) |
| E_MISSING_FIELD | A required JSON field is missing |
| E_INVALID_FIELD_TYPE | The type of the value of a JSON field is |
| | invalid |
| E_INVALID_FIELD_VALUE | The value of a JSON field is invalid |
+-----------------------+-------------------------------------------+
Table 1: Defined ALTO Error Codesonce an ALTO server gets a request, it has to check both the syntactic and the semantic validity 🧐 the paragraphs below just show how those error codes get used during that checking, and an implementation is free to process messages in a different order 💅
first up, the server checks the syntax of the request body (aka can the JSON actually be parsed?) and flags a problem with E_SYNTAX 🙈 for E_SYNTAX, the ALTO server MAY give an optional syntax-error field in the meta field of the error response 💜 the whole point of syntax-error is to give developers debugging info, not end users 🫶 so it should be human-readable, free-form text that describes the problem. if it can, it should also include position info like the line number and the offset within that line ✨ if that's all it has, the value of syntax-error can be just the position 🌸 and if a syntax error shows up in production, the ALTO client could tell the end user there was a communication error with the ALTO server, and suggest they send the error info (including syntax-error) to the developers 😭
a request with no syntax errors can still be invalid, bestie 💀
the big one here is a request that's missing a required field, which the server reports with E_MISSING_FIELD 🍓 this document defines the required fields for the Filtered Network Map (Section 11.3.1.3), Filtered Cost Map (Section 11.3.2.3), Endpoint Properties (Section 11.4.1.3), and Endpoint Cost (Section 11.5.1.3) services 👑 for E_MISSING_FIELD, the server may include an optional field field in the meta field of the error response to point at the missing field 🧚 field should be a JSONString with the full path of the missing field 💖 example: say a Filtered Cost Map request (see Section 11.3.2.3) leaves out the cost-metric field. the error response could set field to cost-type/cost-metric 🌈
a request can have all the right fields and still use the wrong type for a value, like sending a JSONString where a JSONNumber is expected 😤 that's an E_INVALID_FIELD_TYPE error 🎀 the server may include an optional field field in the meta field of the response to say which field has the wrong type 🦋
and then there's a request with the right fields and right types whose value is just wrong 🙃 for example, a Filtered Cost Map request could use a bad value for CostMode in the cost-type field (Section 11.3.2.3) ✨ that gets E_INVALID_FIELD_VALUE 💅 for E_INVALID_FIELD_VALUE, the server may include an optional field field in the meta field of the response to say which field has the wrong value 🫶 it may also include an optional value field in the meta field of the response to show the wrong value that caused the error 🌸 if value is given, the field field MUST be given too 💜 the value field MUST have a JSONString value, and if the invalid value isn't a string, the ALTO server MUST convert it to a string 🔥 here's how to fill in the value key:
- if the invalid value is a string,
valueis that string; - if the invalid value is a number,
valuemust be the invalid number as a string; - if the invalid value is a subfield, the server must set the
fieldkey to the full path of the field name andvalueto the invalid subfield value, converting it to a string if needed. for example, if thecost-modesubfield of thecost-typefield is an invalid modefoo, the server should setvaluetofoo, andfieldtocost-mode/cost-type🧚 - if an element of a JSON array has an invalid value, the server sets
valueto the value of the invalid element, as a string, andfieldto the name of the array. an array element of the wrong type (e.g., a number in what is supposed to be an array of strings) counts as an invalid value error, not an invalid type error 🙈 so the server setsvalueto the string version of the incorrect element, andfieldto the name of the array 🍓
if a single request has more than one error (like a JSONString where a JSONNumber is expected AND a missing required field), the ALTO server MUST return exactly one of the errors it detected 🎀 which one it picks is implementation defined, because forcing a particular order would be needlessly restrictive for implementation techniques 👑
8.5.3. Overload Conditions and Server Unavailability 🌧️
if an ALTO server figures out it can't handle a request from an ALTO client because of heavy load, technical problems, or system maintenance, it SHOULD do one of the following 🫠
- return an HTTP 503 ("Service Unavailable") status code to the ALTO client. as [RFC7230] says, the Retry-After HTTP header may be used to tell the ALTO client when to retry the request ⏰
- return an HTTP 307 ("Temporary Redirect") status code pointing at an alternate ALTO server that might be able to handle the request. heads up that using Temporary Redirect may create infinite redirection loops 😬 [RFC7231] Section 6.4 says an HTTP client SHOULD detect infinite redirection loops, but it's way better if the ALTO servers are configured so they don't form redirection loops in the first place 💅
the ALTO server MAY also terminate the connection with the ALTO client 🔌
which policy an ALTO server uses to decide it can't service a request is outside the scope of this document 🤷♀️
9. Protocol Specification: Information Resource Directory 📚
okay so, as we already covered, an ALTO client starts by grabbing an information resource directory, which lists the attributes of each information resource the ALTO server offers 💖
9.1. Information Resource Attributes 🧁
in this doc, each information resource has up to five attributes attached to it: its assigned ID, its response format, its capabilities, its accepted input parameters, and any other resources it may depend on ✨ the information resource directory exists to publish these attributes 🫶
9.1.1. Resource ID 🆔
every information resource that an ALTO client can request MUST get a resource ID attribute that's unique across all information resources in the client's information resource closure 🔐 the resource ID SHOULD stay stable even when the data the resource provides changes 🌸 for example, even if the number of PIDs in an ALTO network map gets adjusted, its resource ID should remain the same 🦋 same deal if the entries in an ALTO cost map get updated: its resource ID should remain the same 💜 IDs SHOULD NOT be reused for different resources over time 😤
9.1.2. Media Type 🎀
ALTO uses media types [RFC2046] to clearly say what data format is used to encode the content sent between an ALTO server and an ALTO client in the HTTP entity body 💅
9.1.3. Capabilities 🌈
the Capabilities attribute of an information resource lists specific capabilities the server can provide ⭐ for example, if an ALTO server lets an ALTO client specify cost constraints when requesting a cost map information resource, then the server advertises the cost-constraints capability of that cost map information resource 🔥
9.1.4. Accepts Input Parameters 📥
an ALTO server may let an ALTO client supply input parameters when requesting certain information resources 🧚 the accepts attribute of that kind of information resource names a media type, which says how the client encodes the input parameters in the entity body of the HTTP POST request 🍓
9.1.5. Dependent Resources 🔗
the information in an information resource may use information from other resources (e.g., a cost map uses the PIDs defined in a network map) 🗺️ the uses attribute carries that info 💖
9.2. Information Resource Directory (IRD) 📖
an ALTO server uses the information resource directory to publish the available information resources and their attributes we just talked about ✨ since resource selection happens after the client has consumed the directory, the format is designed to be simple, with the goal that future ALTO Protocol versions stay backwards compatible 🫶 future extensions or versions of the ALTO Protocol SHOULD be done by extending existing media types or adding new ones, while keeping the same Information Resource Directory format 👑
an ALTO server MUST make one information resource directory available via the HTTP GET method at a URI that an ALTO client can discover 🔍 how the client discovers that URI is out of scope for this document. it could be done through manual configuration, or by getting the URI of an information resource directory back from the ALTO Discovery Protocol [ALTO-SERVER-DISC] 🌸 for recommendations on what that URI might look like, see [ALTO-SERVER-DISC] 🦋
9.2.1. Media Type 💜
the media type that marks an information resource directory is application/alto-directory+json 🎀
9.2.2. Encoding ✨
okay so an information resource directory response can include a cost-types field inside meta 🎀. Its value is an IRDMetaCostTypes object, where CostType is defined in Section 10.7 💅:
object-map {
JSONString -> CostType;
} IRDMetaCostTypes;The whole job of cost-types is giving names to a set of CostTypes so you can reuse them across one or more resources entries in the IRD without repeating yourself 🧚. Those names are local to the IRD they're defined in, so they only mean something inside that one document 🦋.
For a Root IRD, meta MUST include a field named default-alto-network-map, whose value is the resource ID of an ALTO network map 👑. When there are multiple network maps in an IRD (say, with different levels of granularity), default-alto-network-map is the guideline for simple clients that only use one network map 💜.
The data component of an information resource directory response is resources, a JSON object of type IRDResourceEntries 🌸:
object {
IRDResourceEntries resources;
} InfoResourceDirectory : ResponseEntityBase;
object-map {
ResourceID -> IRDResourceEntry;
} IRDResourceEntries;
object {
JSONString uri;
JSONString media-type;
[JSONString accepts;]
[Capabilities capabilities;]
[ResourceID uses<0..*>;]
} IRDResourceEntry;
object {
...
} Capabilities;An IRDResourceEntries object is a dictionary map keyed by ResourceIDs, where ResourceID is defined in Section 10.2. Each entry's value specifies:
uri: A URI at which the ALTO server provides one or more information resources, or an information resource directory indicating additional information resources. URIs can be relative to the URI of the IRD and MUST be resolved according to Section 5 of [RFC3986]. 🔗media-type: The media type of the information resource (see Section 9.1.2) available via GET or POST requests to the corresponding URI. A value ofapplication/alto-directory+jsonmeans the response for a request to the URI will be an information resource directory defining additional information resources in the information resource closure. 📂accepts: The media type of input parameters (see Section 9.1.4) accepted by POST requests to the corresponding URI. If this field is not present, it MUST be assumed to be empty. 🫙capabilities: A JSON object enumerating capabilities of an ALTO server in providing the information resource at the corresponding URI and the information resources discoverable via that URI. If this field is not present, it MUST be assumed to be an empty object. If a capability for one of the offered information resources is not explicitly listed here, an ALTO client may either issue an OPTIONS HTTP request to the corresponding URI to find out whether the capability is supported, or assume its default value documented in this specification or in an extension document describing the capability. 🧩uses: A list of resource IDs, defined in the same IRD, for the resources this resource directly depends on. An ALTO server SHOULD include in this list any resources that the ALTO client would need to retrieve in order to interpret the contents of this resource. For example, an ALTO cost map resource should include in this list the network map it depends on. ALTO clients may wish to check this list so they can pre-fetch necessary resources. 🪄
If an entry has an empty list for accepts, then the corresponding URI MUST support GET requests. If an entry has a non-empty accepts, then the corresponding URI MUST support POST requests. If an ALTO server wishes to support both GET and POST on a single URI, it MUST specify two entries in the information resource directory. 🙈
9.2.3. Example 🌈
Here's an example information resource directory that an ALTO server returns to an ALTO client. Pretend it's the client's Root IRD 🍓.
GET /directory HTTP/1.1
Host: alto.example.com
Accept: application/alto-directory+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 2333
Content-Type: application/alto-directory+json
{
"meta" : {
"cost-types": {
"num-routing": {
"cost-mode" : "numerical",
"cost-metric": "routingcost",
"description": "My default"
},
"num-hop": {
"cost-mode" : "numerical",
"cost-metric": "hopcount"
},
"ord-routing": {
"cost-mode" : "ordinal",
"cost-metric": "routingcost"
},
"ord-hop": {
"cost-mode" : "ordinal",
"cost-metric": "hopcount"
}
},
"default-alto-network-map" : "my-default-network-map"
},
"resources" : {
"my-default-network-map" : {
"uri" : "http://alto.example.com/networkmap",
"media-type" : "application/alto-networkmap+json"
},
"numerical-routing-cost-map" : {
"uri" : "http://alto.example.com/costmap/num/routingcost",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "num-routing" ]
},
"uses": [ "my-default-network-map" ]
},
"numerical-hopcount-cost-map" : {
"uri" : "http://alto.example.com/costmap/num/hopcount",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "num-hop" ]
},
"uses": [ "my-default-network-map" ]
},
"custom-maps-resources" : {
"uri" : "http://custom.alto.example.com/maps",
"media-type" : "application/alto-directory+json"
},
"endpoint-property" : {
"uri" : "http://alto.example.com/endpointprop/lookup",
"media-type" : "application/alto-endpointprop+json",
"accepts" : "application/alto-endpointpropparams+json",
"capabilities" : {
"prop-types" : [ "my-default-network-map.pid",
"priv:ietf-example-prop" ]
},
},
"endpoint-cost" : {
"uri" : "http://alto.example.com/endpointcost/lookup",
"media-type" : "application/alto-endpointcost+json",
"accepts" : "application/alto-endpointcostparams+json",
"capabilities" : {
"cost-constraints" : true,
"cost-type-names" : [ "num-routing", "num-hop",
"ord-routing", "ord-hop"]
}
}
}
}So the cost-types field in meta of this example IRD gives names to four cost types 🎀. For instance, num-routing is the name for a cost type whose cost mode is numerical and whose cost metric is routingcost 🧠. That name shows up in the second entry of resources, numerical-routing-cost-map, which is a cost map 🗺️. Its cost-type-names under capabilities says this resource supports the cost type named num-routing. The ALTO client looks up num-routing in cost-types of the IRD to get the actual cost type, and the last entry of resources uses all four names defined in cost-types 💖.
The other field in meta is default-alto-network-map, with the value my-default-network-map. That's the resource ID of an ALTO network map defined in resources 🫶.
The resources field defines six information resources ✨. Take the second entry, numerical-routing-cost-map: its resource ID gets a cost map, shown by the media type application/alto-costmap+json, and that cost map is based on the network map with resource ID my-default-network-map 🦋. The last entry, endpoint-cost, provides the Endpoint Cost Service, indicated by the media type application/alto-endpointcost+json 💅. An ALTO client should use the URI http://alto.example.com/endpointcost/lookup to access it 🌈.
The ALTO client should format its request body as the application/alto-endpointcostparams+json media type, as the accepts attribute of this resource says 📮. The cost-type-names field under capabilities includes four cost types defined in cost-types of meta in the IRD. So an ALTO client can confirm that the Endpoint Cost information resource supports both cost metrics, routingcost and hopcount, and each one is available in both numerical and ordinal cost modes 🙌. When requesting this information resource, an ALTO client can specify cost constraints, as signalled by the cost-constraints field under capabilities 🔥.
9.2.4. Delegation Using IRD ✨
Okay so IRDs are lowkey genius 🦋 because they let a bunch of ALTO servers running in different domains team up and each offer their own info resources. Say the ALTO server at alto.example.com wants to hand some resources off to a subdomain, "custom.alto.example.com" 🎀. The maps on that subdomain are filtered network maps, filtered cost maps, and some pre-generated maps for the "hopcount" and "routingcost" cost metrics in the "ordinal" cost mode 💅. The fourth entry in "resources" of the example IRD from before is the delegation. It has a media-type of application/alto-directory+json, and an ALTO client can find the info resources on "custom.alto.example.com" if its request to http://custom.alto.example.com/maps works out 🌸:
GET /maps HTTP/1.1
Host: custom.alto.example.com
Accept: application/alto-directory+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 1900
Content-Type: application/alto-directory+json
{
"meta" : {
"cost-types": {
"num-routing": {
"cost-mode" : "numerical",
"cost-metric": "routingcost",
"description": "My default"
},
"num-hop": {
"cost-mode" : "numerical",
"cost-metric": "hopcount"
},
"ord-routing": {
"cost-mode" : "ordinal",
"cost-metric": "routingcost"
},
"ord-hop": {
"cost-mode" : "ordinal",
"cost-metric": "hopcount"
}
}
},
"resources" : {
"filtered-network-map" : {
"uri" : "http://custom.alto.example.com/networkmap/filtered",
"media-type" : "application/alto-networkmap+json",
"accepts" : "application/alto-networkmapfilter+json",
"uses": [ "my-default-network-map" ]
},
"filtered-cost-map" : {
"uri" : "http://custom.alto.example.com/costmap/filtered",
"media-type" : "application/alto-costmap+json",
"accepts" : "application/alto-costmapfilter+json",
"capabilities" : {
"cost-constraints" : true,
"cost-type-names" : [ "num-routing", "num-hop",
"ord-routing", "ord-hop" ]
},
"uses": [ "my-default-network-map" ]
},
"ordinal-routing-cost-map" : {
"uri" : "http://custom.alto.example.com/ord/routingcost",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "ord-routing" ]
},
"uses": [ "my-default-network-map" ]
},
"ordinal-hopcount-cost-map" : {
"uri" : "http://custom.alto.example.com/ord/hopcount",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "ord-hop" ]
},
"uses": [ "my-default-network-map" ]
}
}
}Note that the subdomain doesn't define any network maps of its own 🙈. Instead it uses the network map with resource ID "my-default-network-map", which is defined in the Root IRD. Borrowing, but make it iconic 👑.
9.2.5. Considerations of Using IRD 🧚
9.2.5.1. ALTO client
This document doesn't put any requirements or constraints on ALTO clients for how they process an information resource directory to find the URI for a desired info resource. BUT some advice is given for implementers 💜.
It's possible that multiple entries in the directory match a desired info resource 🤔. For example, in the example from Section 9.2.3, a full cost map with the "numerical" cost mode and the "routingcost" cost metric could be pulled with a GET request to http://alto.example.com/costmap/num/routingcost, or with a POST request to http://custom.alto.example.com/costmap/filtered.
In general, ALTO clients should prefer GET requests where they make sense, since responses are more likely to be cacheable 💖. Still, an ALTO client may need to use POST, for example, to get ALTO costs or properties for a restricted set of PIDs or endpoints, or to update cached info it got earlier via GET requests 🫶.
9.2.5.2. ALTO server
This document says an ALTO server may or may not provide the info resources specified in the Map-Filtering Service 🌈. If those resources aren't provided, an ALTO client can tell by the absence of a network map or cost map with any media types listed under "accepts" 😭.
10. Protocol Specification: Basic Data Types 🎀
This section details the format of basic data types 💅.
10.1. PID Name
A PID Name is encoded as a JSON string. The string MUST be no more than 64 characters 🌸, and it MUST NOT contain characters other than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', U+002D), the colon (':', U+003A), the at sign ('@', code point U+0040), the low line ('_', U+005F), or the '.' separator (U+002E). The '.' separator is reserved for future use and MUST NOT be used unless specifically indicated in this document, or an extension document 🚫.
The type PIDName is used in this document to indicate a string of this format ✨.
10.2. Resource ID
A resource ID uniquely identifies a particular resource (e.g., an ALTO network map) within an ALTO server (see Section 9.2) 🦋.
A resource ID is encoded as a JSON string with the same format as that of the type PIDName 💜.
The type ResourceID is used in this document to indicate a string of this format 💖.
10.3. Version Tag
A version tag is defined as:
object {
ResourceID resource-id;
JSONString tag;
} VersionTag;As described in Section 6.3, the "resource-id" field provides the resource ID of a resource (e.g., a network map) defined in the information resource directory, and "tag" provides an identifier string 🧁.
Two version tags are equal if and only if both the "resource-id" fields are byte-for-byte equal and the "tag" fields are byte-for-byte equal 👯.
A string representing the "tag" field MUST be no more than 64 characters, and it MUST NOT contain any character below U+0021 or above U+007E 🙅. It is RECOMMENDED that the "tag" string have a low collision probability with other tags 🍓. One suggested mechanism is to compute it using a hash of the data contents of the resource 🔥.
10.4. Endpoints
This section defines formats used to encode addresses for endpoints 🌸. In a case where multiple textual representations encode the same endpoint address or prefix (within the guidelines outlined in this document), the ALTO Protocol does not require ALTO clients or ALTO servers to use a particular textual representation. It also doesn't require ALTO servers to reply using the same textual representation that the requesting ALTO client used 💅. ALTO clients must be cognizant of this 👀.
10.4.1. Typed Endpoint Addresses
When an endpoint address is used, an ALTO implementation must be able to determine its type 🔍. For this purpose, the ALTO Protocol allows endpoint addresses to also explicitly indicate their types. This document refers to such addresses as "Typed Endpoint Addresses" 🏷️.
Typed endpoint addresses are encoded as strings of the format AddressType:EndpointAddr, with the ':' character as a separator. The type TypedEndpointAddr is used to indicate a string of this format 💖.
10.4.2. Address Type
The AddressType component of TypedEndPointAddr is defined as a string consisting of only US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A) 🌈. The type AddressType is used in this document to indicate a string of this format.
This document defines two values for AddressType: "ipv4" to refer to IPv4 addresses and "ipv6" to refer to IPv6 addresses 🧚. All AddressType identifiers appearing in an HTTP request or response with an "application/alto-*" media type MUST be registered in the "ALTO Address Type Registry" (see Section 14.4) 📋.
10.4.3. Endpoint Address
The EndpointAddr component of TypedEndPointAddr is also encoded as a string. The exact characters and format depend on AddressType. This document defines EndpointAddr when AddressType is "ipv4" or "ipv6" 🎀.
10.4.3.1. IPv4
IPv4 Endpoint Addresses are encoded as specified by the IPv4address rule in Section 3.2.2 of [RFC3986] 💜.
10.4.3.2. IPv6
IPv6 endpoint addresses are encoded as specified in Section 4 of [RFC5952] ✨.
10.4.4. Endpoint Prefixes
For efficiency, it's useful to denote a set of endpoint addresses using a special notation (if one exists). This specification uses the prefix notations for both IPv4 and IPv6 for this purpose 🦋.
Endpoint prefixes are encoded as strings. The exact characters and format depend on the type of endpoint address.
The type EndpointPrefix is used in this document to indicate a string of this format 🌸.
10.4.4.1. IPv4
IPv4 endpoint prefixes are encoded as specified in Section 3.1 of [RFC4632] 💅.
10.4.4.2. IPv6
IPv6 endpoint prefixes are encoded as specified in Section 7 of [RFC5952] 🫶.
10.4.5. Endpoint Address Group
The ALTO Protocol includes messages that specify potentially large sets of endpoint addresses 📦. Endpoint address groups give a more efficient way to encode such sets, even when the set has endpoint addresses of different types 🍓.
An endpoint address group is defined as:
object-map {
AddressType -> EndpointPrefix<0..*>;
} EndpointAddrGroup;In particular, an endpoint address group is a JSON object representing a map, where each key is the string corresponding to an address type, and the corresponding value is an array listing prefixes of addresses of that type 🗺️.
Here's an example with both IPv4 and IPv6 endpoint addresses 💖:
{
"ipv4": [
"192.0.2.0/24",
"198.51.100.0/25"
],
"ipv6": [
"2001:db8:0:1::/64",
"2001:db8:0:2::/64"
]
}10.5. Cost Mode
A cost mode is encoded as a string. The string MUST have a value of either "numerical" or "ordinal" 🔢.
The type CostMode is used in this document to indicate a string of this format 🧁.
10.6. Cost Metric
A cost metric is encoded as a string. The string MUST be no more than 32 characters, and it MUST NOT contain characters other than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', U+002D), the colon (':', U+003A), the low line ('_', U+005F), or the '.' separator (U+002E). The '.' separator is reserved for future use and MUST NOT be used unless specifically indicated by a companion or extension document 🚧.
Identifiers prefixed with "priv:" are reserved for Private Use [RFC5226] without a need to register with IANA 🔐. All other identifiers that appear in an HTTP request or response with an "application/alto-*" media type and indicate cost metrics MUST be registered in the "ALTO Cost Metric Registry" Section 14.2 📋. For an identifier with the "priv:" prefix, an additional string (e.g., company identifier or random string) MUST follow (i.e., "priv:" only is not a valid identifier) to reduce potential collisions 💀.
The type CostMetric is used in this document to indicate a string of this format 💜.
10.7. Cost Type 💅
okay so the CostType is literally just a combo of CostMetric and CostMode 👯♀️ and you can put them together like this:
object {
CostMetric cost-metric;
CostMode cost-mode;
[JSONString description;]
} CostType;the description field is optional 🎀 but if you include it, it MUST be a string with a human-readable description of the cost-metric and cost-mode. a client MAY show that string to a developer during discovery 🔍 but honestly it's not meant to be read by the ALTO client itself, so don't build logic around it 🙅♀️
10.8. Endpoint Property 🌈
okay bestie, there are two kinds of endpoint properties in this doc: resource-specific ones and global ones 🦋 the type EndpointPropertyType is just a string that can be either kind ✨
10.8.1. Resource-Specific Endpoint Properties 🧚
the name of a resource-specific endpoint property MUST look like this: a resource ID, then a . (U+002E), then a name that follows the same rules as global endpoint property names (see Section 10.8.2) 💜
this doc only defines ONE resource-specific property, which is pid 🍓 for example: "my-default-networkmap.pid" 💖
10.8.2. Global Endpoint Properties 🌸
a global endpoint property is encoded as a string 🫶 the string MUST be no more than 32 characters, and it MUST NOT contain anything except US-ASCII alphanumerics (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen (-, U+002D), the colon (:, U+003A), or the low line (_, U+005F) 🔥
the . separator is NOT allowed, and that's on purpose 🙈 it keeps things unambiguous, so you can always tell whether a property is global or resource-specific 👑
identifiers starting with priv: are reserved for Private Use [RFC5226] and you don't have to register them with IANA ✨ every other identifier for endpoint properties that shows up in an HTTP request or response with an application/alto-* media type MUST be registered in the "ALTO Endpoint Property Type Registry" (Section 14.3) 🎀
for a priv: identifier, you MUST add an extra string after the prefix (like a company identifier or a random string) 🫧 so priv: by itself is not a valid endpoint property identifier, and this helps avoid collisions 💅
11. Protocol Specification: Service Information Resources 🦋
this section walks through each individual information resource that provides the services in this document 🎀
11.1. Meta Information 💜
for the meta field in the response to an individual information resource, this doc defines two generic fields 🌈 first, vtag, which gives the version tag of the current information resource (see Section 10.3) 🏷️ second, dependent-vtags, which is an array of version tags showing which resources this one depends on 🧩
11.2. Map Service 🗺️
the Map Service gives batch info to ALTO clients through two kinds of maps: ALTO network maps and ALTO cost maps 🫶
11.2.1. Network Map 🌸
an ALTO network map resource defines a set of PIDs, and for each PID it lists the network locations (endpoints) inside that PID ✨ an ALTO server MUST provide at least one network map 🔥
11.2.1.1. Media Type 🎀
the media type for ALTO network maps is application/alto-networkmap+json 💖
11.2.1.2. HTTP Method 🦋
an ALTO network map resource is requested with the HTTP GET method 🍓
11.2.1.3. Accept Input Parameters 🙃
None.
11.2.1.4. Capabilities 💅
None.
11.2.1.5. Uses 🧚
None.
11.2.1.6. Response 💌
the meta field of an ALTO network map response MUST include the vtag field, which gives the version tag of the retrieved network map 🏷️
the data part of an ALTO network map response is called network-map, and it's a JSON object of type NetworkMapData 📦
object {
NetworkMapData network-map;
} InfoResourceNetworkMap : ResponseEntityBase;
object-map {
PIDName -> EndpointAddrGroup;
} NetworkMapData;basically, a NetworkMapData object is a dictionary keyed by PIDs, and the value for each PID is the set of endpoint addresses for that PID 🗝️
the returned network map MUST include all PIDs known to the ALTO server 💯
11.2.1.7. Example 📝
GET /networkmap HTTP/1.1
Host: alto.example.com
Accept: application/alto-networkmap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 449
Content-Type: application/alto-networkmap+json
{
"meta" : {
"vtag": {
"resource-id": "my-default-network-map",
"tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
}
},
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/25"
]
},
"PID2" : {
"ipv4" : [
"198.51.100.128/25"
]
},
"PID3" : {
"ipv4" : [
"0.0.0.0/0"
],
"ipv6" : [
"::/0"
]
}
}
}when an ALTO client parses a network map, it MUST ignore any EndpointAddressGroup whose address type it doesn't recognize 🙈 if that leaves a PID with no address types the client knows, the client still MUST recognize that PID name as valid, even though the PID has no endpoints 🫧
also, the encoding of an ALTO network map response was picked for readability and compactness 📖 if runtime lookup efficiency is crucial, you can transform the returned network map into data structures with faster lookup 🚀 for example, you could store it as a trie-based data structure, which may allow efficient longest-prefix matching of IP addresses 🌳
11.2.2. Mapping IP Addresses to PIDs for 'ipv4'/'ipv6' Network Maps 🗺️✨
a key use of an ALTO network map is mapping endpoint addresses to PIDs 💘 for network maps containing the ipv4 and ipv6 address types, whenever an ALTO client or ALTO server needs to compute the mapping from IP addresses to PIDs, the longest-prefix matching algorithm (Longest Match in Section 5.2.4.3 of [RFC1812]) MUST be used 🎯
to make sure longest-prefix matching gives exactly one PID, an ALTO network map with the ipv4/ipv6 address types MUST meet the following two requirements 🫶
first, the map MUST define a PID for every possible address in the IP address space for all the address types in the map 🌍 this is called the completeness property of an ALTO network map 💫 a RECOMMENDED way to get there is to define a PID with the shortest enclosing prefix of the addresses in the map 📏 for a map with full IPv4 reachability, that means including the 0.0.0.0/0 prefix in a PID, and for full IPv6 reachability, it's the ::/0 prefix 🌐
second, the map MUST NOT define two or more PIDs that contain an identical IP prefix 🚫 that way, longest-prefix matching maps each IP address into exactly one PID 🎀 this is called the non-overlapping property 🧁 to map an IP address to its PID in a non-overlapping map, you look at the set S of all prefixes in the network map, apply the longest-prefix mapping algorithm to S to find the longest prefix containing the IP address, and then give the IP address the PID that contains that longest prefix 🗝️
here's an example of a complete and non-overlapping ALTO network map 💕
"network-map" : {
"PID0" : { "ipv6" : [ "::/0" ] },
"PID1" : { "ipv4" : [ "0.0.0.0/0" ] },
"PID2" : { "ipv4" : [ "192.0.2.0/24", "198.51.100.0/24" ] },
"PID3" : { "ipv4" : [ "192.0.2.0/25", "192.0.2.128/25" ] }
}so 192.0.2.1 should be mapped to PID3 🎯
but if the two adjacent prefixes in PID3 got combined into one prefix, and PID3 became:
"PID3" : { "ipv4" : [ "192.0.2.0/24" ] }then the new map is no longer non-overlapping, and 192.0.2.1 could no longer be mapped unambiguously to a PID with longest-prefix matching 😭 the vibe is: don't merge things carelessly 💀
extension documents may define techniques that let a single IP address map to multiple PIDs, when a need is identified 🧩
11.2.3. Cost Map 💸
an ALTO cost map resource lists the path cost for each source/destination PID pair that the ALTO server defines, for a given cost metric and cost mode 📊 this resource MUST be provided for at least the routingcost cost metric 🛣️
11.2.3.1. Media Type 🎀
the media type for ALTO cost maps is application/alto-costmap+json 💖
11.2.3.2. HTTP Method 🦋
an ALTO cost map resource is requested with the HTTP GET method 🍓
11.2.3.3. Accept Input Parameters 🙃
None.
11.2.3.4. Capabilities 🧠
the capabilities of an ALTO server URI that provides an unfiltered cost map are a JSON object of type CostMapCapabilities:
object {
JSONString cost-type-names<1..1>;
} CostMapCapabilities;with this field:
cost-type-names: the array MUST include a single CostType name defined by thecost-typesfield in themetafield of the IRD 🧾 that's because an unfiltered cost map (accept == "") is requested with an HTTP GET that takes no input parameters 🙅♀️ by contrast, for filtered cost maps (see Section 11.3.2), the array can have multiple elements ✨
11.2.3.5. Uses 🔗
this is the resource ID of the network map that the cost map will be defined on top of 🗺️ remember (Section 6) that a network map plus a cost type makes a key 🔑 in other words, an ALTO server MUST NOT define two cost maps with the same cost type / network map pair 💜
11.2.3.6. Response ✨
okay so the meta field of a cost map response MUST include dependent-vtags 💅 its value is a single-element array holding the version tag of the network map used, and that network map is whatever's named in "uses" of the IRD 🎀 the meta MUST also include cost-type too, whose value tells you the cost type (Section 10.7) of the cost map 🦋
the data part of a cost map response is called cost-map and it's a JSON object of type CostMapData 🌸
object {
CostMapData cost-map;
} InfoResourceCostMap : ResponseEntityBase;
object-map {
PIDName -> DstCosts;
} CostMapData;
object-map {
PIDName -> JSONValue;
} DstCosts;so basically a CostMapData is a dictionary where each key is a PIDName string naming the source PID ✨ and each value is a DstCosts, which is the costs from that source PID to a bunch of destination PIDs (Section 6.2) 💖 an implementation of this protocol SHOULD assume the cost is a JSONNumber and fail to parse if it isn't 🙈 the exception is if the implementation is using an extension to this document that says when and how costs of other data types get signaled, ngl that's the only plot twist 😭
the returned cost map MUST include the path cost for each (source PID, destination PID) pair where a path cost is defined 🔥 an ALTO server MAY leave out entries where path costs aren't defined (e.g., either the source or the destination PIDs have addresses outside of the network provider's administrative domain) 🫶
the encoding of ALTO cost maps is similar to ALTO network maps, and it was picked for readability and compactness 🧚 if lookup efficiency at runtime is crucial, the returned cost map can be turned into data structures that look things up faster 👑 for example, you could store a cost map as a matrix 🍓
11.2.3.7. Example ✨
GET /costmap/num/routingcost HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 435
Content-Type: application/alto-costmap+json
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
}
],
"cost-type" : {"cost-mode" : "numerical",
"cost-metric": "routingcost"
}
},
"cost-map" : {
"PID1": { "PID1": 1, "PID2": 5, "PID3": 10 },
"PID2": { "PID1": 5, "PID2": 1, "PID3": 15 },
"PID3": { "PID1": 20, "PID2": 15 }
}
}so yeah, array-based encoding for "map" was a contender, just like with the network map case 💅 but the current encoding won because it's clearer 🌈
11.3. Map-Filtering Service 🧚
the Map-Filtering Service lets ALTO clients say what they want filtered, so they get back a subset of a full map from the Map Service 🦋
11.3.1. Filtered Network Map 🌸
a filtered ALTO network map is an ALTO network map information resource (Section 11.2.1) where an ALTO client can supply a list of PIDs to include 💖 a filtered ALTO network map MAY be provided by an ALTO server 🫶
11.3.1.1. Media Type ✨
since a filtered ALTO network map is still an ALTO network map, it uses the media type defined for ALTO network maps at Section 11.2.1.1 🎀
11.3.1.2. HTTP Method 🔥
a filtered ALTO network map is requested with the HTTP POST method 💅
11.3.1.3. Accept Input Parameters 👑
an ALTO client gives filtering parameters by specifying the media type "application/alto-networkmapfilter+json" with an HTTP POST body that holds a JSON object of type ReqFilteredNetworkMap, where:
object {
PIDName pids<0..*>;
[AddressType address-types<0..*>;]
} ReqFilteredNetworkMap;with these fields:
pids: the list of PIDs to include in the returned filtered network map 🍓 if the list of PIDs is empty, the ALTO server MUST interpret the list as if it contained a list of all currently defined PIDs 🙈 the ALTO server MUST interpret entries that show up multiple times as if they only showed up once 💜
address-types: the list of address types to include in the returned filtered network map ✨ if the "address-types" field isn't specified, or the list of address types is empty, the ALTO server MUST interpret the list as if it contained a list of all address types the ALTO server knows about 🦋 the ALTO server MUST interpret entries that show up multiple times as if they only showed up once 🌈
11.3.1.4. Capabilities ✨
none 🌸
11.3.1.5. Uses ✨
the resource ID of the network map the filtering is based on 🧚
11.3.1.6. Response 💖
the format is the same as unfiltered network maps, so check Section 11.2.1.6 for the format 🫶
the ALTO server MUST only include PIDs in the response that were specified (implicitly or explicitly) in the request 🔥 if the input parameters have a PID name that the ALTO server doesn't currently define, the ALTO server MUST behave as if that PID never showed up in the input parameters 😭 same vibe for addresses: the ALTO server MUST only enumerate addresses within each PID that have types specified (implicitly or explicitly) in the request 💅 and if the input parameters have an address type the ALTO server doesn't currently know, the ALTO server MUST behave as if that address type never showed up 👑
the version tag in the "vtag" field of the response MUST correspond to the full (unfiltered) network map information resource that the filtered info came from 🎀 this is the key bit: it means there's one canonical version tag no matter what filtering an ALTO client asks for 🍓
11.3.1.7. Example ✨
POST /networkmap/filtered HTTP/1.1
Host: custom.alto.example.com
Content-Length: 33
Content-Type: application/alto-networkmapfilter+json
Accept: application/alto-networkmap+json,application/alto-error+json
{
"pids": [ "PID1", "PID2" ]
}
HTTP/1.1 200 OK
Content-Length: 342
Content-Type: application/alto-networkmap+json
{
"meta" : {
"vtag" : {
"resource-id": "my-default-network-map",
"tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"
}
},
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/24"
]
},
"PID2" : {
"ipv4": [
"198.51.100.128/24"
]
}
}
}11.3.2. Filtered Cost Map 🦋
a filtered ALTO cost map is a cost map information resource (Section 11.2.3) where an ALTO client can add extra parameters that limit the scope of the resulting cost map 💖 a filtered ALTO cost map MAY be provided by an ALTO server 🌸
11.3.2.1. Media Type 🧚
since a filtered ALTO cost map is still an ALTO cost map, it uses the media type defined for ALTO cost maps at Section 11.2.3.1 ✨
11.3.2.2. HTTP Method 💅
a filtered ALTO cost map is requested with the HTTP POST method 🔥
11.3.2.3. Accept Input Parameters 🎀
the input parameters for a filtered cost map go in the entity body of the POST request 👑 this document specifies them with a data format indicated by the media type "application/alto-costmapfilter+json", which is a JSON object of type ReqFilteredCostMap, where:
object {
CostType cost-type;
[JSONString constraints<0..*>;]
[PIDFilter pids;]
} ReqFilteredCostMap;
object {
PIDName srcs<0..*>;
PIDName dsts<0..*>;
} PIDFilter;with these fields:
cost-type: the CostType (Section 10.7) for the returned costs 🍓 the "cost-metric" and "cost-mode" fields MUST match one of the supported cost types listed in this resource's "capabilities" field (Section 11.3.2.4) 🙈 the ALTO client SHOULD omit the "description" field, and if it's there anyway, the ALTO server MUST ignore it 💜
constraints: a list of extra constraints on which elements of the cost map get returned ✨ this parameter MUST NOT be specified if this resource's "capabilities" field (Section 11.3.2.4) says constraint support isn't available 🦋 a constraint has two entities separated by whitespace: (1) an operator, "gt" for greater than, "lt" for less than, "ge" for greater than or equal to, "le" for less than or equal to, or "eq" for equal to, and (2) a target cost value 🌈 the cost value is a number that MUST be defined in the same units as the cost metric given by the "cost-metric" parameter 🌸 ALTO servers SHOULD use at least IEEE 754 double-precision floating point [IEEE.754.2008] to store the cost value, and SHOULD perform internal computations using double-precision floating-point arithmetic 🧚 if multiple "constraint" parameters are given, they relate to each other with a logical AND 💖
pids: a list of source PIDs and a list of destination PIDs whose path costs should be returned 🫶 if a list is empty, the ALTO server MUST interpret it as the full set of currently defined PIDs 🔥 the ALTO server MUST interpret entries that show up multiple times in a list as if they only showed up once 😭 if the "pids" field isn't present, the ALTO server MUST interpret both lists as containing the full set of currently defined PIDs 💅
11.3.2.4. Capabilities 👑
this URI supports all capabilities documented in Section 11.2.3.4 (with identical semantics), plus some extra ones 🎀 the capabilities are defined by a JSON object of type FilteredCostMapCapabilities:
object {
JSONString cost-type-names<1..*>;
JSONBool cost-constraints;
} FilteredCostMapCapabilities;with these fields:
cost-type-names: see Section 11.2.3.4, and note the array can have one to many cost types 🍓
cost-constraints: if true, the ALTO server allows cost constraints in requests to the matching URI 🙈 if it isn't present, this field MUST be interpreted as if it specified false 💜 ALTO clients should be aware that constraints may not have the intended effect for cost maps with the ordinal cost mode, since ordinal costs aren't restricted to being sequential integers 🌈
11.3.2.5. Uses ✨
the resource ID of the network map the cost map will be filtered based on 🦋
11.3.2.6. Response
okay so the format is literally the same as an unfiltered ALTO cost map 🧁, so just peek at Section 11.2.3.6 for the details ✨
the dependent-vtags field inside meta gives you an array with exactly one element: the version tag of the network map that got used for filtering 🦋 ALTO clients should check that this tag matches the version tag of the network map used to make the request (if that applies). if it doesn't match, the client may wish to grab an updated network map, figure out what changed, and consider asking for a new filtered cost map 💅
the returned cost map MUST contain only source/destination pairs that were indicated (implicitly or explicitly) in the input parameters 🎀 and if the input parameters have a PID name the ALTO server doesn't currently define, the server MUST act like that PID never showed up in the first place 🙈
if any constraints were specified, source/destination pairs whose path costs don't meet those constraints MUST NOT be included in the returned cost map 🚫 and if no constraints were specified, every path cost is treated as meeting them ✨
11.3.2.7. Example
POST /costmap/filtered HTTP/1.1
Host: custom.alto.example.com
Content-Type: application/alto-costmapfilter+json
Content-Length: 181
Accept: application/alto-costmap+json,application/alto-error+json
{
"cost-type" : {"cost-mode": "numerical",
"cost-metric": "routingcost"
},
"pids" : {
"srcs" : [ "PID1" ],
"dsts" : [ "PID1", "PID2", "PID3" ]
}
}HTTP/1.1 200 OK
Content-Length: 341
Content-Type: application/alto-costmap+json
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "75ed013b3cb58f896e839582504f622838ce670f"
}
],
"cost-type": {"cost-mode" : "numerical",
"cost-metric" : "routingcost"
}
},
"cost-map" : {
"PID1": { "PID1": 0, "PID2": 1, "PID3": 2 }
}
}11.4. Endpoint Property Service
the Endpoint Property Service is where the server spills the tea on endpoint properties for ALTO clients 💜
11.4.1. Endpoint Property
an endpoint property resource gives you info about properties for individual endpoints 🌸 on top of the required pid endpoint property (see Sections 7.1.1 and 11.4.1.4), the ALTO server MAY provide extra endpoint properties too ✨
11.4.1.1. Media Type
the media type of an endpoint property resource is application/alto-endpointprop+json 🧚
11.4.1.2. HTTP Method
you request the endpoint property resource with the HTTP POST method 📮
11.4.1.3. Accept Input Parameters
the input parameters for an endpoint property request go in the entity body of the POST request 🎀 this doc specifies them with the media type application/alto-endpointpropparams+json, which is a JSON object of type ReqEndpointProp:
object {
EndpointPropertyType properties<1..*>;
TypedEndpointAddr endpoints<1..*>;
} ReqEndpointProp;here are the fields:
properties: the list of endpoint properties to be returned for each endpoint 💖 every property you list MUST be in the list of supported properties that this resource'scapabilitiesfield shows (Section 11.4.1.4) 🫶 and the ALTO server MUST treat repeated entries as if they only showed up once 🔁endpoints: the list of endpoint addresses you want those properties for 🌈 same deal here, the ALTO server MUST treat repeated entries as if they only appeared once 💅
11.4.1.4. Capabilities
the capabilities of an ALTO server URI that provides endpoint properties are defined by a JSON object of type EndpointPropertyCapabilities:
object {
EndpointPropertyType prop-types<1..*>;
} EndpointPropertyCapabilities;the one field is:
prop-types: the endpoint properties (see Section 10.8) that the corresponding URI supports 👑
especially important: the information resource closure MUST provide the lookup of pid for every ALTO network map that's defined 🔥
11.4.1.5. Uses
None. 🫠
11.4.1.6. Response
the dependent-vtags field inside the response's meta field MUST be an array that includes the version tags of all ALTO network maps whose pid got queried 🦋
the data part of an endpoint properties response is named endpoint-properties, which is a JSON object of type EndpointPropertyMapData, and it looks like this:
object {
EndpointPropertyMapData endpoint-properties;
} InfoResourceEndpointProperties : ResponseEntityBase;
object-map {
TypedEndpointAddr -> EndpointProps;
} EndpointPropertyMapData;
object {
EndpointPropertyType -> JSONValue;
} EndpointProps;basically, an EndpointPropertyMapData object has one member for each endpoint from the input parameters (named by that endpoint encoded as a TypedEndpointAddr) 🍓 the requested properties for each endpoint go into a matching EndpointProps object, with one name/value pair per requested property, where the property names are strings of type EndpointPropertyType 🌸 an implementation of this protocol SHOULD assume the property value is a JSONString and fail to parse if it isn't, unless the implementation is using an extension to this document that says when and how other data types get signaled 🧠
the ALTO server returns the value of each requested property for each endpoint listed in the input parameters ✨
if the ALTO server doesn't define a requested property's value for a particular endpoint, it MUST leave that property out of the response for that endpoint only 🙈
11.4.1.7. Example
POST /endpointprop/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 181
Content-Type: application/alto-endpointpropparams+json
Accept: application/alto-endpointprop+json,application/alto-error+json
{
"properties" : [ "my-default-networkmap.pid",
"priv:ietf-example-prop" ],
"endpoints" : [ "ipv4:192.0.2.34",
"ipv4:203.0.113.129" ]
}HTTP/1.1 200 OK
Content-Length: 396
Content-Type: application/alto-endpointprop+json
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"
}
]
},
"endpoint-properties": {
"ipv4:192.0.2.34" : { "my-default-network-map.pid": "PID1",
"priv:ietf-example-prop": "1" },
"ipv4:203.0.113.129" : { "my-default-network-map.pid": "PID3" }
}
}11.5. Endpoint Cost Service
the Endpoint Cost Service tells you the costs between individual endpoints 💸
it's especially useful because it lets an ALTO server rank (order) lists of endpoint prefixes (and plain addresses, as a special case) 🏆
11.5.1. Endpoint Cost
an endpoint cost resource gives you info about costs between individual endpoints 🦋 an ALTO server MAY provide it ✨
how the server provides this resource is up to the implementation 🎀 the server can use fine-grained costs between individual endpoints, or coarse-grained costs based on the costs between the PIDs that match those endpoints 💅 see Section 15.3 for more details 📖
11.5.1.1. Media Type
the media type of the endpoint cost resource is application/alto-endpointcost+json 🧚
11.5.1.2. HTTP Method
the endpoint cost resource is requested with the HTTP POST method 📮
11.5.1.3. Accept Input Parameters
an ALTO client sends the endpoint cost parameters using the media type application/alto-endpointcostparams+json, as an HTTP POST entity body that's a JSON object of type ReqEndpointCostMap:
object {
CostType cost-type;
[JSONString constraints<0..*>;]
EndpointFilter endpoints;
} ReqEndpointCostMap;
object {
[TypedEndpointAddr srcs<0..*>;]
[TypedEndpointAddr dsts<0..*>;]
} EndpointFilter;the fields:
cost-type: the cost type (Section 10.7) to use for the returned costs 💖 thecost-metricandcost-modefields MUST match one of the supported cost types listed in this resource'scapabilitiesfields (Section 11.5.1.4) 🫶 the ALTO client SHOULD omit thedescriptionfield, and if it does show up, the ALTO server MUST ignore it 🙈constraints: defined the same way as theconstraintsinput parameter of a filtered cost map (see Section 11.3.2) 🎀endpoints: a list of source endpoints and destination endpoints whose path costs you want back 🌈 if the source or destination list is empty (or left out), the ALTO server MUST read it as if it held the endpoint address that matches the client IP address from the incoming connection (see Section 13.3 for discussion and considerations about this mode) 🧠 the source and destination lists MUST NOT both be empty ❌ and the ALTO server MUST treat repeated entries in a list as if they only appeared once 🔁
11.5.1.4. Capabilities
this doc defines EndpointCostCapabilities as the same thing as FilteredCostMapCapabilities 🫶 see Section 11.3.2.4 🍓
11.5.1.5. Uses
this one's a big deal 🚨 even though this resource lets an ALTO server reveal costs between individual endpoints, the server is NOT required to do it 🙅♀️ a simple ECS implementation can compute the cost between two endpoints as the cost between their matching PIDs, using one of the network and cost maps the server exposes 🗺️ ECS MUST NOT specify the use field to point at a network or cost map 💀 so the ECS cost is the cost from the source endpoint to the destination endpoint 👑 a future extension might let ECS say it "uses" a network map, but then that extension would need to define what that means 🔮
11.5.1.6. Response ✨
bestie, the meta field in an endpoint cost response MUST include the cost-type field, so everyone knows which cost type got used 💅
The data part of an endpoint cost response is called endpoint-cost-map, and it's a JSON object of type EndpointCostMapData 🎀
object {
EndpointCostMapData endpoint-cost-map;
} InfoResourceEndpointCostMap : ResponseEntityBase;
object-map {
TypedEndpointAddr -> EndpointDstCosts;
} EndpointCostMapData;
object-map {
TypedEndpointAddr -> JSONValue;
} EndpointDstCosts;So here's the vibe 🦋 An EndpointCostMapData object is a dictionary map where each key is a TypedEndpointAddr string for the source endpoint from the input parameters. For each source, an EndpointDstCosts dictionary map shows the cost to each destination endpoint from the input parameters. An implementation of this protocol SHOULD assume the cost value is a JSONNumber and fail to parse if it isn't, unless it's using an extension to this document that says when and how other data types get signaled 🤓 And if the ALTO server doesn't define a cost value from a source endpoint to a certain destination endpoint, that pair MAY be omitted from the response. Lowkey iconic, no notes 🌸
11.5.1.7. Example 🧚
Okay, here's a full example, so you can see how the request and response actually look 👀
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 248
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {"cost-mode" : "ordinal",
"cost-metric" : "routingcost"},
"endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv4:203.0.113.45"
]
}
}HTTP/1.1 200 OK
Content-Length: 274
Content-Type: application/alto-endpointcost+json
{
"meta" : {
"cost-type": {"cost-mode" : "ordinal",
"cost-metric" : "routingcost"
}
},
"endpoint-cost-map" : {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89" : 1,
"ipv4:198.51.100.34" : 2,
"ipv4:203.0.113.45" : 3
}
}
}12. Use Cases 🌈
Okay, these are the typical use cases, bestie 💜 They're mostly about peer-to-peer apps, but ALTO can also be used in other places, like Content Distribution Networks (CDNs) [ALTO-USE-CASES] 🍓
12.1. ALTO Client Embedded in P2P Tracker 🎀
Lots of deployed P2P systems use a tracker to manage swarms and pick peers, and a P2P tracker can already use all sorts of info to hit app-specific goals 🔥 By acting as an ALTO client, the tracker can use ALTO info as an extra source, so traffic is more network-efficient and the app just performs better ✨
Here's the thing: a lot of P2P trackers have to handle a huge number of clients 😭 A tracker can grab and store ALTO info (like network maps and cost maps) from the ISPs where those clients live, and it gets the same grouping of network locations that the ALTO servers already do 🧚
.---------. (1) Get Network Map .---------------.
| | <----------------------> | |
| ALTO | | P2P Tracker |
| Server | (2) Get Cost Map | (ALTO client) |
| | <----------------------> | |
`---------' `---------------'
^ |
(3) Get Peers | | (4) Selected Peer
| v List
.---------. .-----------.
| Peer 1 | <-------------- | P2P |
`---------' | Client |
. (5) Connect to `-----------'
. Selected Peers /
.---------. /
| Peer 50 | <------------------
`---------'Figure 4: ALTO Client Embedded in P2P Tracker
Figure 4 is an example where the P2P tracker is an ALTO client and uses ALTO info to pick peers for its P2P clients 👑 Here's how it plays out:
- The P2P tracker asks the ALTO server for a network map, so it can locally map P2P clients into PIDs.
- The P2P tracker asks the ALTO server for the cost map between all the PIDs from the step before.
- A P2P client joins the swarm and asks the P2P tracker for a peer list.
- The P2P tracker sends a peer list back to the P2P client. That list is computed from the network map and the cost map from the ALTO server, plus maybe other info sources. Also, it's possible a tracker only uses the network map to do hierarchical peer selection, by preferring peers in the same PID and ISP 🫶
- The P2P client connects to the selected peers 🦋
Note that the P2P tracker might give peer lists to P2P clients spread across multiple ISPs. In that case, the P2P tracker may talk to multiple ALTO servers 💅
12.2. ALTO Client Embedded in P2P Client: Numerical Costs 🌸
P2P clients can use ALTO info themselves when choosing from available peers 🙈 Not every P2P system uses a tracker for peer discovery and selection, and even when there is a tracker, the P2P clients might also rely on other sources, like peer exchange and DHTs, to find peers ✨
When a P2P client uses ALTO info, it usually only asks the ALTO server for its own ISP. That ISP's "my-Internet view" can include preferences to all the potential peers 💜
.---------. (1) Get Network Map .---------------.
| | <----------------------> | |
| ALTO | | P2P Client |
| Server | (2) Get Cost Map | (ALTO client) |
| | <----------------------> | | .---------.
`---------' `---------------' <- | P2P |
.---------. / | ^ ^ | Tracker |
| Peer 1 | <-------------- | | \ `---------'
`---------' | (3) Gather Peers
. (4) Select Peers | | \
. and Connect / .--------. .--------.
.---------. / | P2P | | DHT |
| Peer 50 | <---------------- | Client | `--------'
`---------' | (PEX) |
`--------'Figure 5: ALTO Client Embedded in P2P Client
Figure 5 is an example where a P2P client applies ALTO info locally to pick peers. The use case goes like this 🧚
- The P2P client asks the ALTO server for its own ISP for the network map covering all PIDs.
- The P2P client asks the ALTO server for the cost map with path costs between all PIDs. By default, the cost map gives numerical costs 🔥
- The P2P client finds peers from sources like peer exchange (PEX) from other P2P clients, distributed hash tables (DHT), and P2P trackers 👀
- The P2P client uses ALTO info as part of its algorithm for picking new peers, then connects to the chosen peers 🎀
12.3. ALTO Client Embedded in P2P Client: Ranking 👑
A P2P client can also hand off the selection and ranking to an ALTO server ✨ In this case, the ALTO client inside the P2P client collects a list of known peers in the swarm and asks the ALTO server to rank them. This document limits this use case to when the P2P client and the ALTO server are run by the same entity, so the P2P client uses the ranking from the ALTO server directly 🫶
Same as the numerical costs case, the P2P client usually only asks the ALTO server for its own ISP 💅
.---------. .---------------.
| | | |
| ALTO | (2) Get Endpoint Ranking | P2P Client |
| Server | <----------------------> | (ALTO client) |
| | | | .---------.
`---------' `---------------' <- | P2P |
.---------. / | ^ ^ | Tracker |
| Peer 1 | <-------------- | | \ `---------'
`---------' | (1) Gather Peers
. (3) Connect to | | \
. Selected Peers / .--------. .--------.
.---------. / | P2P | | DHT |
| Peer 50 | <---------------- | Client | `--------'
`---------' | (PEX) |
`--------'Figure 6: ALTO Client Embedded in P2P Client: Ranking
Figure 6 shows this scenario 🦋 The use case goes like this:
- The P2P client finds peers from sources like Peer Exchange (PEX) from other P2P clients, Distributed Hash Tables (DHT), and P2P trackers.
- The P2P client asks the ALTO server's ranking service (aka the ECS Service) and includes the discovered peers as the set of destination endpoints, with the "ordinal" cost mode. The response shows the ranking of the candidate peers 🌈
- The P2P client connects to the peers in the order the ranking gives 💖
13. Discussions 💅
13.1. Discovery 🔍
How an ALTO client finds a suitable ALTO server is out of scope for this document 🙈 This document assumes the ALTO client can discover an appropriate ALTO server. Once it does, the ALTO client may use the information resource directory (see Section 9.2) to find an information resource with the ALTO info it wants ✨
13.2. Hosts with Multiple Endpoint Addresses 🌸
In real deployments, one host can be reachable through several addresses (like a wireless IPv4 connection, a wireline IPv4 connection, and a wireline IPv6 connection) 🧚 Generally, the network path a packet takes to the host depends on which address gets used, and network providers may prefer one path over another. Another thing to think about is how to handle private address spaces (like ones behind carrier-grade NATs) 👀
To support this, the document allows multiple endpoint addresses and address types 💜 With that, the ALTO Protocol lets an ALTO service provider set preferences for paths from an endpoint address of one type to an endpoint address of a different type. Main character energy, honestly 👑🎀
13.3. Network Address Translation Considerations ✨
okay so NAT is literally everywhere rn 💀 we've got NAT v4<->v4, v4<->v6 [RFC6144], and maybe even v6<->v6 [RFC6296]. so a protocol should strive to be NAT friendly 🦋 which means it should minimize carrying IP addresses in the payload, OR it should have a mode where the source IP address already tells the server everything it needs. main character energy, fr fr 👑
this protocol has that second mode! 🎀 the ALTO server (the Endpoint Cost Service) works out the source network location from the source IP address in the ALTO client query packets. it's giving the same vibe as some P2P trackers (like BitTorrent trackers, see "Tracker HTTP/HTTPS Protocol" in [BitTorrent]) 🧚
now, there can be times when an ALTO client needs to figure out its own IP address, like when it's specifying a source endpoint address in the Endpoint Cost Service 🫶 and it's totally possible for a client to have several network interface addresses, where some or all of them might need NAT to reach the public Internet. ngl that's a lot of moving parts 😭
if a network interface needs a public IP address, the ALTO client SHOULD use the Session Traversal Utilities for NAT (STUN) [RFC5389] 🔥 and if it does, the host MUST use the Binding Request message and then grab the XOR-MAPPED-ADDRESS parameter from the response. but here's the catch 🙈 STUN needs a publicly accessible STUN server to cooperate, so the ALTO client also needs configuration info that tells it which STUN server to use, or a domain name it can use to discover one. and to get picked for this job, the STUN server has to provide the public reflexive transport address of the host ✨
one more thing, bestie 💅 ALTO clients should be cognizant that the network path between endpoints can depend on lots of factors, like the source address and the destination address being used for communication. an ALTO server gives info based on endpoint addresses (or network locations more generally), but how you figure out whether connectivity exists or whether NAT is involved between endpoints is out of scope for this document 🌸
13.4. Endpoint and Path Properties 🌈
an ALTO server could make a bunch of properties about endpoints available, way beyond their network location or grouping 💜 things like connection type or geographical location might be useful to applications, and this specification focuses on network location and grouping, BUT the protocol may be extended to handle other endpoint properties later on 🧚✨
14. IANA Considerations 📋
this part is all about the registries 🍓 this document defines registries for application/alto-* media types, ALTO cost metrics, ALTO endpoint property types, ALTO address types, and ALTO error codes. the initial values for those registries, plus how future assignments happen, are given below 👑
14.1. application/alto-* Media Types 💖
this document registers multiple media types, all listed in Table 2 🎀
+-------------+------------------------------+-------------------+
| Type | Subtype | Specification |
+-------------+------------------------------+-------------------+
| application | alto-directory+json | Section 9.2.1 |
| application | alto-networkmap+json | Section 11.2.1.1 |
| application | alto-networkmapfilter+json | Section 11.3.1.1 |
| application | alto-costmap+json | Section 11.2.3.1 |
| application | alto-costmapfilter+json | Section 11.3.2.1 |
| application | alto-endpointprop+json | Section 11.4.1.1 |
| application | alto-endpointpropparams+json | Section 11.4.1.1 |
| application | alto-endpointcost+json | Section 11.5.1.1 |
| application | alto-endpointcostparams+json | Section 11.5.1.1 |
| application | alto-error+json | Section 8.5.1 |
+-------------+------------------------------+-------------------+
Table 2: ALTO Protocol Media Typeshere's the registration template, so you know exactly what gets filed 🦋
Type name: application
Subtype name: This documents registers multiple subtypes, as listed in Table 2.
Required parameters: n/a
Optional parameters: n/a
Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type. See [RFC7159]. 🫶
Security considerations: Security considerations relating to the generation and consumption of ALTO Protocol messages are discussed in Section 15. 🔥 this part is SERIOUS, bestie, so go read Section 15 ✨
Interoperability considerations: This document specifies format of conforming messages and the interpretation thereof. 🧚
Published specification: This document is the specification for these media types; see Table 2 for the section documenting each media type. 💜
Applications that use this media type: ALTO servers and ALTO clients either stand alone or are embedded within other applications. 🌸
Additional information:
- Magic number(s): n/a
- File extension(s): This document uses the mime type to refer to protocol messages and thus does not require a file extension.
- Macintosh file type code(s): n/a
Person & email address to contact for further information: See Authors' Addresses section.
Intended usage: COMMON
Restrictions on usage: n/a
Author: See Authors' Addresses section.
Change controller: Internet Engineering Task Force (mailto:iesg@ietf.org). 👑
14.2. ALTO Cost Metric Registry 🌈
IANA has created and now maintains the "ALTO Cost Metric Registry", which is listed in Table 3 ✨
+-------------+---------------------+
| Identifier | Intended Semantics |
+-------------+---------------------+
| routingcost | See Section 6.1.1.1 |
| priv: | Private use |
+-------------+---------------------+
Table 3: ALTO Cost Metricsthis registry has two jobs 💅 first, it makes sure identifiers for ALTO cost metrics are unique. second, it points to the particular semantics of each allocated cost metric, so both ALTO servers and applications using ALTO clients apply them the same way 🦋
new ALTO cost metrics get assigned after IETF Review [RFC5226], so that proper documentation of the metric's semantics and security considerations exists 🔥 the RFCs documenting new metrics should be detailed enough to guide both ALTO service providers and applications using ALTO clients on how to interpret the registered values. updates and deletions of ALTO cost metrics follow the same procedure 🎀
registered ALTO cost metric identifiers MUST conform to the syntactical requirements in Section 10.6 🙈 identifiers get recorded and displayed as strings 💖
and as Section 10.6 says, identifiers prefixed with "priv:" are reserved for Private Use 🌸
requests to add a new value to the registry MUST include the following info:
- Identifier: The name of the desired ALTO cost metric. 🍓
- Intended Semantics: ALTO costs carry semantics that guide how ALTO clients use them. for example, if a value refers to a measurement, the measurement units must be documented. and for proper implementation of the ordinal cost mode (for instance, by a third-party service), it should be documented whether higher or lower values of the cost are more preferred. 🧚
- Security Considerations: ALTO costs expose information to ALTO clients, so proper usage of a particular cost metric may require certain information to be exposed by an ALTO service provider. network information is frequently regarded as proprietary or confidential, so ALTO service providers should be made aware of the security ramifications of using a cost metric. 😭 this is the part where we all need to be careful, periodt 💀
this specification requests registration of the identifier "routingcost" 👑 the semantics for this cost metric are documented in Section 6.1.1.1, and its security considerations are documented in Section 15.3 ✨🌈
14.3. ALTO Endpoint Property Type Registry 🗂️
okay so IANA made the ALTO Endpoint Property Type Registry and still looks after it 💅 It's the list of endpoint property types, and you can see the current entries in Table 4 ✨
+------------+--------------------+
| Identifier | Intended Semantics |
+------------+--------------------+
| pid | See Section 7.1.1 |
| priv: | Private use |
+------------+--------------------+
Table 4: ALTO Endpoint Property TypesManaging this one is basically the same vibe as the cost metric registry we just did 🦋 IANA runs it, and the rules are the ones in Section 10.8.2.
New endpoint property types get assigned after an IETF Review [RFC5226], so somebody has to actually document what the type means and what the security stakes are first 🔍 Updates and deletions go through the exact same process, no shortcuts bestie 🙅♀️
Registered identifiers MUST follow the syntax rules from Section 10.8.1, and they get recorded and displayed as strings 🧵 Anything starting with priv: is reserved for Private Use, as described in Section 10.8.1 🔒
If you want to add a new value, your request MUST include the following info:
- Identifier: The name of the endpoint property type you want.
- Intended Semantics: Endpoint properties come with meaning that helps ALTO clients decide how to use them 🧠 So your document should explain to both ALTO service providers and apps using ALTO clients how to read the values. For example, if a value is a measurement, the measurement units must be documented 📏
- Security Considerations: Endpoint properties expose information to ALTO clients 👀 ALTO service providers should be made aware of the security ramifications of exposing a given endpoint property 🚨
Honestly the request should really dig into how sensitive the info is and why ALTO operations need that sensitive info in the first place 🥺 It may recommend that ISPs give users ways to grant or deny consent to sharing it. Limiting it to a trust domain counts as a type of consent bounding 🫶
A request defining new endpoint properties should focus on attributes of endpoints that tie back to the whole point of ALTO, which is optimizing application-layer traffic ⚡ It should not be about general endpoint properties. Keeping things technical and network-layer also helps extension developers dodge the privacy concerns that come with publishing endpoint info 🙈 Some examples:
- An extension that indicates the capacity of a server would likely be appropriate, since clients can use server capacities to pick between multiple equivalent servers 💪 These properties are also unlikely to be seen as private info ✨
- An extension that indicates the geolocation of endpoints might be appropriate 🌍 At a certain level, like the country level, geolocation can help with picking content sources. More precise geolocation isn't relevant to content delivery, though, and it's typically considered private 🔐
- An extension indicating demographic attributes of the owner of an endpoint (e.g., age, sex, income) would not be appropriate 🚫 Those attributes aren't related to delivery optimization, and they're clearly private data 💀
This specification requests registration of the identifier pid 🎀 Its semantics are documented in Section 7.1.1, and its security considerations are documented in Section 15.4 💖
14.4. ALTO Address Type Registry 🏠
IANA made the ALTO Address Type Registry and maintains it now 🧭 You can find its entries in Table 5 👇
+------------+-----------------+-----------------+------------------+
| Identifier | Address | Prefix Encoding | Mapping to/from |
| | Encoding | | IPv4/v6 |
+------------+-----------------+-----------------+------------------+
| ipv4 | See Section | See Section | Direct mapping |
| | 10.4.3 | 10.4.4 | to IPv4 |
| ipv6 | See Section | See Section | Direct mapping |
| | 10.4.3 | 10.4.4 | to IPv6 |
+------------+-----------------+-----------------+------------------+
Table 5: ALTO Address TypesThis registry has two jobs 💫 First, it keeps identifiers for ALTO address types unique. Second, it lays out what allocated address type identifiers need to look like.
New ALTO address types are assigned after an IETF Review [RFC5226], so the new types and their security considerations get properly documented first 📚 RFCs defining new address types should explain how an address of that type gets encoded as an EndpointAddr 🔤 If possible, they should also give a compact way to encode a set of addresses as an EndpointPrefix, like the IPv4 and IPv6 prefixes do 📦 Updates and deletions of address types follow the same procedure 🔁
Registered ALTO address type identifiers MUST conform to the syntactical requirements in Section 10.4.2 📝 They get recorded and displayed as strings, too.
Adding a new value means your request MUST include the following info:
- Identifier: The name of the address type you want.
- Endpoint Address Encoding: How to encode an address of the registered type as an EndpointAddr (see Section 10.4.3) 🔢
- Endpoint Prefix Encoding: How to encode a set of addresses of the registered type as an EndpointPrefix (see Section 10.4.4) 🧩 If there's no compact encoding, the same encoding used for a single address may be used. In that case, it must be documented that sets of addresses of this type always have exactly one element ☝️
- Mapping to/from IPv4/IPv6 Addresses: If possible, a mechanism for mapping addresses of the registered type to and from IPv4 or IPv6 addresses should be specified 🗺️
- Security Considerations: In some scenarios, endpoint addresses carried in ALTO Protocol messages may reveal info about an ALTO client or an ALTO service provider 👁️ Applications and ALTO service providers using addresses of the registered type should be made aware of how (or if) the addressing scheme relates to private information and network proximity 🕵️♀️
This specification requests registration of the identifiers ipv4 and ipv6, as shown in Table 5 🌈
14.5. ALTO Error Code Registry 🚨
IANA made the ALTO Error Code Registry and maintains it 🛠️ The initial values are listed in Table 1, and the recommended usage of the error codes is in Section 8.5.2 📋
The error codes in Table 1 are already pretty complete, but future extensions may define new ones 🔮 The ALTO Error Code Registry keeps error codes unique whenever new ones get added 🫡
New ALTO error codes are assigned after an IETF Review [RFC5226], so their documentation and usage are sorted out first 📖
A request to add a new ALTO error code MUST include the following info:
- Error Code: A string starting with
E_to show it's an error ❌ - Intended Usage: ALTO error codes come with meaning that guides how ALTO servers and clients use them 🧭 If a new error code covers conditions that overlap with an existing one, the recommended usage of the new code should be specified 🤝
15. Security Considerations 🛡️
okay this part is SO important, bestie 😭 Some ALTO environments and use cases need security attacks on ALTO servers and clients to be considered 👀 To support those environments interoperably, the ALTO requirements document [RFC6708] outlines the minimum authentication and other security requirements that must be implemented 🔐 This document looks at the threats and protection strategies below 💜
15.1. Authenticity and Integrity of ALTO Information 🪪
15.1.1. Risk Scenarios 💀
An attacker might want to give ALTO clients false or modified ALTO information resources, or a false information resource directory, to get some nasty results 😈 For example, an attacker could provide false endpoint properties. Say a network supports an endpoint property called hasQuota, which reports whether an endpoint has a usage quota 📊 An attacker could send a fake reply to cause unexpected charges for the endpoint 💸 An attack may also aim to provide a false cost map 🗺️ For example, by faking a cost map that highly prefers a small address range or even a single address, the attacker could turn a distributed application into a Distributed-Denial-of-Service (DDoS) tool 🌋
Depending on the network scenario, an attacker can go after the authenticity and integrity of ALTO information resources using lots of techniques 🧰 That includes, but isn't limited to, sending forged DHCP replies in an Ethernet, DNS poisoning, and installing a transparent HTTP proxy that makes modifications 🕸️
15.1.2. Protection Strategies 🛡️✨
ALTO protects the authenticity and integrity of ALTO information, both the information directory and the individual information resources 🎁 It does this by leaning on the authenticity and integrity mechanisms in TLS (see Section 8.3.5) 🔏
ALTO service providers who request server certificates, and certification authorities who issue ALTO-specific certificates, SHOULD consider the recommendations and guidelines defined in [RFC6125] 📜
Software engineers building ALTO and service providers deploying it should get familiar with any updated standards documents, plus up-to-date Best Current Practices on configuring HTTP over TLS 📚 Stay current, babe 💅
15.1.3. Limitations ⚠️
The protection of HTTP over TLS for ALTO depends on the domain name in the URI for the information resources not being compromised. Whether that holds depends on the protection implemented by service discovery 🙏
A deployment scenario may need redistribution of ALTO information to improve scalability 📡 When authenticity and integrity of ALTO information are still required, ALTO clients that get ALTO information through redistribution must be able to validate the info they receive 🧐 This document doesn't provide support for that validation, but extension documents may provide it 🧩
15.2. Potential Undesirable Guidance from Authenticated ALTO Information 🫣
15.2.1. Risk Scenarios 👀
okay so ALTO gives an ALTO service provider a LOT of power over how network applications behave 😳. An ALTO service provider may be hostile to some applications, so it could try to use ALTO information resources to hit certain goals [RFC5693]:
...redirecting applications to corrupted mediators providing malicious content, or applying policies in computing cost maps based on criteria other than network efficiency.
see [ALTO-DEPLOYMENT] for more on faked ALTO guidance 🙈
a related scenario is that an ALTO server could accidentally give "bad" guidance 💀. for example, if lots of ALTO clients follow the cost map or the Endpoint Cost Service guidance without doing any extra sanity checks or adaptation, the more preferable hosts and/or links could get overloaded while the less preferable ones just sit there idle 😭. see AR-14 of [RFC6708] for related application considerations 🎀.
15.2.2. Protection Strategies 🛡️
okay so to protect applications from undesirable ALTO information resources, you have to know that there is no protocol mechanism to require conforming behaviors on how applications use ALTO information resources 😤. an application using ALTO may consider including a mechanism to detect misleading or undesirable results from using ALTO information resources ✨. for example, if throughput measurements do not show "better-than-random" results when using an ALTO cost map to select resource providers, the application may want to disable ALTO usage or switch to an external ALTO server provided by an "independent organization" (see AR-20 and AR-21 in [RFC6708]) 🦋. if the first ALTO server is provided by the access network service provider, and that provider tries to redirect access to the external ALTO server back to its own ALTO server or tries to tamper with the responses, the preceding authentication and integrity protection can detect such behavior 🔥.
15.3. Confidentiality of ALTO Information 🔒
15.3.1. Risk Scenarios 🫣
ngl, in lots of cases ALTO information resources are totally non-confidential 🌸. BUT there are deployment cases where ALTO information resources can be sensitive, and exposing them to unauthorized parties can pose real risks 😬. this document talks about the risks and protection strategies for those deployment scenarios 💜.
for example, an attacker may infer details about a network's topology, status, and operational policies through its ALTO network and cost maps 👀. as a result, a sophisticated attacker may be able to infer more fine-grained topology information than an ISP hosting an ALTO server intends to disclose 😱. the attacker can use that info to mount effective attacks, like focusing on high-cost links 💀.
revealing some endpoint properties may also reveal more than the provider meant to share 🙈. for example, when you add the line bitrate as one endpoint property, that info could potentially be linked to the income of the people living at the network location of an endpoint 💸.
in Section 5.2.1 of [RFC6708], three types of risks tied to the confidentiality of ALTO information resources are identified 📝:
- risk type (1) Excess disclosure of the ALTO service provider's data to an authorized ALTO client;
- risk type (2) Disclosure of the ALTO service provider's data (e.g., network topology information or endpoint addresses) to an unauthorized third party; and
- risk type (3) Excess retrieval of the ALTO service provider's data by collaborating ALTO clients.
[ALTO-DEPLOYMENT] also discusses information leakage from ALTO 🦋.
15.3.2. Protection Strategies 🛡️
to address risk types (1) and (3), the provider of an ALTO server must be cognizant that the network topology and provisioning information provided through ALTO may lead to attacks 🚨. ALTO does not require any particular level of detail in information disclosure, so the provider should evaluate how much information is revealed and what the associated risks are 🧐.
to address risk type (2), the ALTO Protocol needs confidentiality 🔐. since ALTO requires that HTTP over TLS must be supported, the confidentiality mechanism is provided by HTTP over TLS 💖.
for deployment scenarios where client authentication is desired to address risk type (2), ALTO requires that HTTP Digestion Authentication is supported 🫶. that gets you ALTO client authentication, which limits the number of parties the ALTO information is directly shared with 🎀. TLS client authentication may also be supported 🌈. depending on the use case and scenario, an ALTO server may apply other access control techniques to restrict access to its services 🚪. access control can also help prevent Denial-of-Service attacks by arbitrary hosts from the Internet 🙅♀️. see [ALTO-DEPLOYMENT] for a more detailed discussion on this issue 📚.
see Section 14.3 on guidelines for registering endpoint properties to protect endpoint privacy 🧚.
15.3.3. Limitations ⚠️
ALTO information providers should be cognizant that encryption only protects ALTO information until it is decrypted by the intended ALTO client. Digital Rights Management (DRM) techniques and legal agreements protecting ALTO information are outside of the scope of this document.
15.4. Privacy for ALTO Users 🕵️♀️
15.4.1. Risk Scenarios 😶
the ALTO Protocol has mechanisms where the ALTO client serving a user can send messages containing network location identifiers (IP addresses or fine-grained PIDs) to the ALTO server 📨. this is especially true for the Endpoint Property, the Endpoint Cost, and the fine-grained Filtered Map services 🍓. the ALTO server, or a third party who can intercept such messages, can store and process the info to analyze user behaviors and communication patterns 👁️. the analysis may correlate info collected from multiple clients to deduce additional application/content information, and that can lead to privacy risks 😬. for a more comprehensive classification of related risk scenarios, see cases 4, 5, and 6 in [RFC6708], Section 5.2 💜.
15.4.2. Protection Strategies 🫶
to protect user privacy, an ALTO client should be cognizant of potential ALTO server tracking through client queries, e.g., by using HTTP cookies 🍪. the ALTO Protocol as defined by this document does not rely on HTTP cookies, bestie 💅. ALTO clients MAY decide not to return cookies received from the server, which makes tracking more difficult 🙈. however, this might break protocol extensions that are beyond the scope of this document 💀.
an ALTO client may consider relying only on ALTO network maps for PIDs and cost maps amongst PIDs, so it doesn't pass IP addresses of other endpoints (e.g., peers) to the ALTO server 🌸. when specific IP addresses are needed (e.g., when using the Endpoint Cost Service), an ALTO client SHOULD minimize the amount of information sent in IP addresses 🧠. for example, the ALTO client may consider obfuscation techniques, such as specifying a broader address range (i.e., a shorter prefix length) or zeroing out or randomizing the last few bits of IP addresses 🦋. note that obfuscation may yield less accurate results 🥲.
15.5. Availability of ALTO Services 🌧️
15.5.1. Risk Scenarios 😈
an attacker may want to disable the ALTO services of a network, as a way to take down network guidance for large-scale applications 🔪. in particular, queries that can be generated with low effort but result in expensive workloads at the ALTO server could be exploited for Denial-of-Service attacks 🚨. for instance, a simple ALTO query with n source network locations and m destination network locations can be generated pretty easily, but it results in the computation of n*m path costs between pairs by the ALTO server (see Section 5.2) 🧮.
15.5.2. Protection Strategies 🛡️
the ALTO service provider should be cognizant of the workload at the ALTO server generated by certain ALTO queries, such as certain queries to the Map Service, the Map-Filtering Service, and the Endpoint Cost (Ranking) Service 👀. one way to limit Denial-of-Service attacks is to use access control on the ALTO server 🚪. the ALTO server can also indicate overload and reject repeated requests that can cause availability problems 🙅♀️. more advanced protection schemes, such as computational puzzles [SIP], may be considered in an extension document 🧩.
an ALTO service provider should also take advantage of the fact that the Map Service lets ALTO servers pre-generate maps that can be distributed to many ALTO clients 🍰.
16. Manageability Considerations 🛠️
this section covers operations and management considerations based on existing deployments and discussions during protocol development ✨. it also points out where extension documents are expected to provide the functionality discussed in [RFC5706] as more deployment experience becomes available 🌈.
16.1. Operations 🧑💻
16.1.1. Installation and Initial Setup 🧁
the ALTO Protocol is based on HTTP 💫. so configuring an ALTO server may require configuring the underlying HTTP server implementation to define appropriate security policies, caching policies, performance settings, etc. 🎀
also, an ALTO service provider will need to configure the ALTO information the ALTO server provides 📋. the granularity of the topological map and the cost maps is left to the specific policies of the ALTO service provider 🫧. however, a reasonable default may include two PIDs: one to hold the endpoints in the provider's network, and a second PID to represent full IPv4 and IPv6 reachability (see Section 11.2.2), with the cost between each source/destination PID set to 1 🌟. another operational issue the ALTO service provider needs to consider is that the filtering service can degenerate into a full map service when the filtering input is empty 🤯. even though this degeneration behavior provides continuity, the computational and network load of serving full maps to a large number of ALTO clients should be considered 🏋️♀️.
implementers employing an ALTO client should attempt to automatically discover an appropriate ALTO server 🔎. manual configuration of the ALTO server location may be used where automatic discovery is not appropriate 🛎️. methods for automatic discovery and manual configuration are discussed in [ALTO-SERVER-DISC] 📖.
specifications for underlying protocols (e.g., TCP, HTTP, TLS) should be consulted for their available settings and proposed default configurations 📜.
16.1.2. Migration Path 🛤️
this document does not detail a migration path for ALTO servers, since there is no previous standard protocol providing similar functionality 🙌.
there are existing applications that use network information discovered from other entities, such as whois, geo-location databases, or round-trip time measurements 🗺️. such applications should consider using ALTO as an additional source of information, because ALTO need not be the sole source of network information 💖.
16.1.3. Dependencies on Other Protocols and Functional Components 🔗
okay so ALTO just assumes that HTTP client and server implementations already exist, and that JSON encoder and decoder implementations exist too. it's giving "someone else already built the plumbing" 💅
an ALTO server also assumes it can gather sufficient information to populate Network and Cost maps 🗺️ "sufficient information" depends on what's being exposed, but it likely includes info gathered from protocols like IGP and EGP Routing Information Bases (see Figure 1). specific mechanisms have been proposed (e.g., [ALTO-SVR-APIS]) and are expected to be provided in extension documents. bestie, the extensions are coming 🧚
16.1.4. Impact and Observation on Network Operation 🦋
ALTO is a brand new opportunity for managing network traffic, because it gives clients additional information. the deployment of an ALTO server may shift network traffic patterns, and the potential impact on network operation can be large 😭 so an ALTO service provider should make sure that appropriate information is being exposed. privacy implications for ISPs are discussed in Section 15.3.
an ALTO service provider should also think about how to measure impacts on (or integration with) traffic engineering, on top of monitoring the correctness and responsiveness of ALTO servers. measuring impact can be genuinely hard, because ALTO-enabled applications may not send related info back to the provider. and here's the twist: measurements might show that ALTO clients aren't bound to ALTO server guidance, since ALTO is only one source of information 🙈
it can be tricky to measure the impact of ALTO guidance, but there are some possible techniques! in certain trusted deployment environments, it may be possible to collect information directly from ALTO clients. it may also be possible to vary or selectively disable ALTO guidance for a portion of ALTO clients, by time, geographical region, or some other criteria, so you can compare network traffic characteristics with and without ALTO 📊
both ALTO service providers and people using ALTO clients should be aware of the impact of incorrect or faked guidance (see [ALTO-DEPLOYMENT]). be aware, babes ⚠️
16.2. Management 🎀
16.2.1. Management Interoperability 🧩
a common management API would be desirable, because ALTO servers may typically be configured with dynamic data from various sources, and ALTO servers are intended to scale horizontally for fault-tolerance and reliability. a specific API or protocol is outside the scope of this document, but an extension document may provide one ✨
logging is an important functionality for ALTO servers and, depending on the deployment, ALTO clients too. logging should be done via syslog [RFC5424] 📝
16.2.2. Management Information 📚
a Management Information Model (see Section 3.2 of [RFC5706]) is not provided by this document, but should be included or referenced by any extension documenting an ALTO-related management API or protocol. ✨
16.2.3. Fault Management 🚨
an ALTO service provider should monitor whether any ALTO servers have failed. see Section 16.2.5 for related metrics that may indicate server failures 👀
16.2.4. Configuration Management ⚙️
standardized approaches and protocols to configuration management for ALTO are outside the scope of this document, but this document does outline high-level principles suggested for future standardization efforts 💖
an ALTO server requires at least the following logical inputs:
- Data sources from which ALTO information resources is derived. This can be either raw network information (e.g., from routing elements) or pre-processed ALTO-level information in the forms of network maps, cost maps, etc.
- Algorithms for computing the ALTO information returned to clients. These could return either information from a database or information customized for each client.
- Security policies mapping potential clients to the information that they have privilege to access.
multiple ALTO servers can be deployed for scalability. a centralized configuration database may be used to make sure they're providing the desired ALTO information with appropriate security controls. the ALTO information (e.g., network maps and cost maps) being served by each ALTO server, as well as security policies (HTTP authentication, TLS client and server authentication, TLS encryption parameters) intended to serve the same information should be monitored for consistency 🔍
16.2.5. Performance Management 📈
an exhaustive list of desirable performance information from ALTO servers and ALTO clients is outside the scope of this document. the following is a list of suggested ALTO-specific metrics to be monitored, based on the existing deployment and protocol development experience:
- 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).
16.2.6. Security Management 🔐
Section 15 documents ALTO-specific security considerations, so operators should configure security policies with those in mind. readers should refer to HTTP [RFC7230] and TLS [RFC5246] and related documents for the mechanisms available for configuring security policies. other appropriate security mechanisms (e.g., physical security, firewalls, etc.) should also be considered. this part is serious, friends 💀🔒
17. References 📚
17.1. Normative References
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014.17.2. Informative References
[ALTO-DEPLOYMENT]
Stiemerling, M., Ed., Kiesel, S., Ed., Previdi, S., and M.
Scharf, "ALTO Deployment Considerations", Work in Progress,
February 2014.
[ALTO-INFOEXPORT]
Shalunov, S., Penno, R., and R. Woundy, "ALTO Information
Export Service", Work in Progress, October 2008.
[ALTO-MULTI-PS]
Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi
Dimensional Peer Selection Problem", Work in Progress,
October 2008.
[ALTO-QUERYRESPONSE]
Das, S. and V. Narayanan, "A Client to Service Query
Response Protocol for ALTO", Work in Progress, March 2009.
[ALTO-SERVER-DISC]
Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
H. Song, "ALTO Server Discovery", Work in Progress,
September 2013.
[ALTO-SVR-APIS]
Medved, J., Ward, D., Peterson, J., Woundy, R., and D.
McDysan, "ALTO Network-Server and Server-Server APIs",
Work in Progress, March 2011.
[ALTO-USE-CASES]
Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and
S. Previdi, "Use Cases for ALTO within CDNs", Work in
Progress, June 2012.
[BitTorrent]
"Bittorrent Protocol Specification v1.0",
<http://wiki.theory.org/BitTorrentSpecification>.
[Fielding-Thesis]
Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", University of
California, Irvine, Dissertation 2000, 2000.
[IEEE.754.2008]
Institute of Electrical and Electronics Engineers,
"Standard for Binary Floating-Point Arithmetic", IEEE
Standard 754, August 2008.
[P4P-FRAMEWORK]
Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang,
"P4P: Provider Portal for P2P Applications", Work in
Progress, November 2008.
[P4P-SIGCOMM08]
Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A.
Silberschatz, "P4P: Provider Portal for (P2P)
Applications", SIGCOMM 2008, August 2008.
[P4P-SPEC] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang,
"P4P Protocol Specification", Work in Progress, March
2009.
[PROXIDOR] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D.
Saucez, "The PROXIDOR Service", Work in Progress, March
2009.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, October
2009.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", RFC
5706, November 2009.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, June 2011.
[RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
Y. Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", RFC 6708, September 2012.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[SIP] Jennings, C., "Computational Puzzles for SPAM Reduction in
SIP", Work in Progress, July 2007.Appendix A. Acknowledgments ✨
Okay bestie, huge thank yous 🫶 Jan Seedorf (NEC) did substantial work on the Security Considerations section 💖 Ben Niven-Jenkins (Velocix), Michael Scharf, and Sabine Randriamasy (Alcatel-Lucent) gave substantial feedback and suggestions on the protocol design 🧚
We also want to thank these people, whose input and involvement was indispensable in getting this merged proposal across the finish line 👑
- Obi Akonjang (DT Labs/TU Berlin)
- Saumitra M. Das (Qualcomm Inc.)
- Syon Ding (China Telecom)
- Doug Pasko (Verizon)
- Laird Popkin (Pando Networks)
- Satish Raghunath (Juniper Networks)
- Albert Tian (Ericsson/Redback)
- Yu-Shun Wang (Microsoft)
- David Zhang (PPLive)
- Yunfei Zhang (China Mobile)
We'd also like to thank the following additional people, who were involved in the projects that contributed to this merged document 🌈 Alex Gerber (ATT), Chris Griffiths (Comcast), Ramit Hora (Pando Networks), Arvind Krishnamurthy (University of Washington), Marty Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (ATT), Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), Damien Saucez (UCL), Thomas Scholl (ATT), Emilio Sepulveda (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song (Huawei), Oliver Spatscheck (ATT), See-Mong Tang (Microsoft), Jia Wang (ATT), Hao Wang (Yale University), Ye Wang (Yale University), and Haiyong Xie (Yale University) 🦋
Stanislav Shalunov would like to thank BitTorrent, where he worked while contributing to ALTO development 💜
Appendix B. Design History and Merged Proposals 🎀
The ALTO Protocol specified in this document is made up of contributions from:
- P4P [P4P-FRAMEWORK], [P4P-SIGCOMM08], [P4P-SPEC];
- ALTO Info-Export [ALTO-INFOEXPORT];
- Query/Response [ALTO-QUERYRESPONSE], [ALTO-MULTI-PS]; and
- Proxidor [PROXIDOR].
Authors' Addresses 💌
Richard Alimi (editor)
Richard Alimi (editor)
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
USA
EMail: ralimi@google.comReinaldo Penno (editor)
Reinaldo Penno (editor)
Cisco Systems, Inc.
170 West Tasman Dr
San Jose, CA 95134
USA
EMail: repenno@cisco.comY. Richard Yang (editor)
Y. Richard Yang (editor)
Yale University
51 Prospect St
New Haven, CT 06511
USA
EMail: yry@cs.yale.eduSebastian Kiesel
Sebastian Kiesel
University of Stuttgart Information Center
Networks and Communication Systems Department
Allmandring 30
Stuttgart 70550
Germany
EMail: ietf-alto@skiesel.deStefano Previdi
Stefano Previdi
Cisco Systems, Inc.
Via Del Serafico, 200
Rome 00142
Italy
EMail: sprevidi@cisco.comWendy Roome
Wendy Roome
Alcatel-Lucent
600 Mountain Ave.
Murray Hill, NJ 07974
USA
EMail: w.roome@alcatel-lucent.comStanislav Shalunov
Stanislav Shalunov
Open Garden
751 13th St
San Francisco, CA 94130
USA
EMail: shalunov@shlang.comRichard Woundy
Richard Woundy
Comcast Cable Communications
One Comcast Center
1701 John F. Kennedy Boulevard
Philadelphia, PA 19103
USA
EMail: Richard_Woundy@cable.comcast.com📦 where this page comes from
- ietf: rfc7285 2014-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms