ALTO (protocol)
Application Layer Transport Optimization (ALTO) is a protocol that allows internet clients to obtain information that compares the network properties of paths to other endpoints. Typically, this would be used to identify the lowest-cost location to access a copy of some sort of content.
The protocol requires "ALTO servers" to be deployed in the network with knowledge of network properties, often simply the routing cost to various endpoints. An "ALTO client," typically tied to a user agent attempting to obtain a resource, queries the ALTO server over HTTP to obtain the optimal location from which to retrieve the resource.
The Internet Engineering Task Force (IETF) documented the ALTO design in RFC7285 in 2014. Originally designed to support peer-to-peer file sharing, the concept is broadly applicable to many network problems. However, as of 2021 it has not achieved widespread deployment in the internet. However, there have been experiments in Internet Service Provider (ISP) networks and a deployment to support large data transfers for the Large Hadron Collider at CERN. [1]
Protocol Overview
ALTO servers typically operate inside an ISP and collect information about the topology of the ISP network. The means of collecting this information are out of scope for the ALTO design, but typically this would involve participating in the routing protocol's information exchange, accepting policy inputs from network management, and data from various network monitoring systems.
The ALTO server uses this information to provide services to the client.
The first step in retrieving ALTO information is to locate the ALTO server, which is specified in RFC7286. A client might have the service discovery domain name directly configured, but usually it will obtain the name via DHCP when joining a network. It then composes a DDDS query to that service discovery host for the "ALTO:https" or "ALTO:http" Application Service tag, which in turn returns the URL for any available ALTO Server Information Resource Directories (IRD).
A client would then retrieve the IRD from one of the ALTO servers, which lists the specifics of what services are available, supported parameters, and the locations of those services.
There are four service types in the base protocol:
The Map Service provides a file that lists all the endpoints or PIDs that the server tracks. A "network map" serves as a "table of contents" that the client can use to construct more specific queries. These endpoints are identified by IPv4 or IPv6 address and are grouped with other endpoints with similar properties into Provider-Defined Identifiers (PIDs) to reduce the size of future queries and responses. A "cost map" lists the routing cost for each pair of PIDs.
The Map-Filtering Service provides a subset of the network map or cost map based on client-provided parameters.
The Endpoint Property Service allows the client to query properties, such as the connectivity type or encapsulating PID, of a specific endpoint.
The Endpoint Cost Service gives clients the routing cost to specific endpoints, which might be expressed as the absolute cost metric or a ranking of the relative cost of each.
All ALTO client messages are REST HTTP requests that elicit HTTP responses from the ALTO server. The payloads of these requests of responses consist of JSON text that contain hierarchical key-value pairs.
Protocol syntax
Clients obtain the IRD via the HTTP GET message. The following example from RFC7285 depicts a request for the IRD. The requested target (/directory) came from the DDDS service discovery process described above. This IRD provides targets for the services available on this server, as well as acceptable parameters.
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"]
}
}
}
}
Clients obtain the Map Service via the HTTP GET message. The following example from RFC7285 depicts a request for a network map and a response that groups five endpoints into 3 PIDs:
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"
]
}
}
}
The other three services rely on additional information the client provides in the request payload. As HTTP GET does not have a request payload, clients access these services with the HTTP POST method. The following example from RFC7285 shows a request for the cost from one source to three potential destinations, and the response.
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
}
}
}
Extensions
Numerous additional standards have extended the protocol to extend its usability and feature set.
RFC8189 allows clients to request multiple cost types (for example, routing cost and hop count) in a single request.
RFC8686 provides a method of discovering ALTO servers outside of the local network.
RFC8895 allows the client to subscribe to stream of updates about a particular resource.
RFC8996 introduces the concept of a "cost calendar", where the server can express how the cost to reach an endpoints evolves over time.