ALTO (protocol)

Last updated
Application Layer Transport Optimization (ALTO)
International standard RFC   7285
Developed by IETF

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. [1]

Contents

The ALTO base protocol is specified in RFC 7285. [2] It requires "ALTO servers" to be deployed in the network with knowledge of network properties, often simply the routing cost to various endpoints. [3] 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.

History

Starting around 2005, the widespread use of peer-to-peer applications such as BitTorrent was a serious concern to many network operators, as the massive amounts of network traffic caused by these applications had a significant impact on traffic engineering and revenues. Some network operators tried to throttle this traffic. [4]

In May 2008, in an IETF Workshop on Peer-to-Peer Infrastructure, several areas of work were identified: [5]

  1. A standardized interface for the exchange of information between the underlying IP network and an overlay network, such as a peer-to-peer network. The basic idea is, that if the overlay network was aware of the topology and the cost for sending traffic through the underlying IP network, it could optimize decisions with respect to the overlay network's topology (e.g., peer selection) and routing of traffic through the overlay network. The result would be better performance or Quality of Experience in the application while reducing the utilization of the underlying network infrastructure. This work item led to the establishment of the IETF ALTO working group.
  2. Content caches in the network. This has been studied in the IETF DECADE working group. However, no new protocol has been developed and standardized. [6]
  3. A new congestion control mechanism in the transport layer for background traffic, which "yields" to standard TCP. This was worked on in the IETF LEDBAT working group and has been standardized in RFC 6817. [7]
  4. A new DiffServ code point to mark IP packets to have a lower priority than the default "best effort" category has been standardized in RFC 8622. [8]

The IETF ALTO working group was established in November 2008. [9] The first deliverables were the problem statement, [1] the requirements document, [3] the specification of the core ALTO protocol [2] and an ALTO server discovery mechanism. [10] Since then, various extensions have been specified (see below) or are still work in progress (see IETF ALTO Datatracker [11] ).

Originally designed to support peer-to-peer file sharing, the concept is broadly applicable to many network problems. [12] However, as of 2021 it has not achieved widespread deployment in the internet. Nevertheless, 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. [13]

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. If the ALTO client is located on the host that is also the endpoint of the data transmissions to be optimized, the ALTO server discovery procedure specified in RFC 7286 [10] may be used. In contrast, when the ALTO client is located on a different host (e.g., when a BitTorrent tracker with an embedded ALTO client wants to optimize peer selection on behalf of a peer that might be in a different network domain), the cross-domain server discovery procedure specified in RFC 8686 [14] should be used. 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.

Later specifications specify additional services:

The Update Stream Service, specified in RFC 8895, [15] leaves the connection open for the server to provide a stream of update messages as information changes. The same RFC also specifies the Stream Control Service, allowing the client to change its request for update messages.

All ALTO client messages are REST HTTP requests that elicit HTTP responses from the ALTO server. The payloads of these requests and 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 RFC 7285 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/directoryHTTP/1.1Host:alto.example.comAccept:application/alto-directory+json,application/alto-error+json
HTTP/1.1200OKContent-Length:2333Content-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 RFC 7285 depicts a request for a network map and a response that groups five endpoints into 3 PIDs:

GET/networkmapHTTP/1.1Host:alto.example.comAccept:application/alto-networkmap+json,application/alto-error+json
HTTP/1.1200OKContent-Length:449Content-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 RFC 7285 shows a request for the cost from one source to three potential destinations, and the response.

POST/endpointcost/lookupHTTP/1.1Host:alto.example.comContent-Length:248Content-Type:application/alto-endpointcostparams+jsonAccept: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.1200OKContent-Length:274Content-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}}}

Other extensions

Numerous additional standards have extended the protocol's usability and feature set.

Related Research Articles

The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on Internet Protocol (IP) networks for automatically assigning IP addresses and other communication parameters to devices connected to the network using a client–server architecture.

<span class="mw-page-title-main">HTTP</span> Application protocol for distributed, collaborative, hypermedia information systems

The Hypertext Transfer Protocol (HTTP) is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

<span class="mw-page-title-main">IPv6</span> Version 6 of the Internet Protocol

Internet Protocol version 6 (IPv6) is the most recent version of the Internet Protocol (IP), the communications protocol that provides an identification and location system for computers on networks and routes traffic across the Internet. IPv6 was developed by the Internet Engineering Task Force (IETF) to deal with the long-anticipated problem of IPv4 address exhaustion, and was intended to replace IPv4. In December 1998, IPv6 became a Draft Standard for the IETF, which subsequently ratified it as an Internet Standard on 14 July 2017.

Multiprotocol Label Switching (MPLS) is a routing technique in telecommunications networks that directs data from one node to the next based on labels rather than network addresses. Whereas network addresses identify endpoints the labels identify established paths between endpoints. MPLS can encapsulate packets of various network protocols, hence the multiprotocol component of the name. MPLS supports a range of access technologies, including T1/E1, ATM, Frame Relay, and DSL.

The Session Initiation Protocol (SIP) is a signaling protocol used for initiating, maintaining, and terminating communication sessions that include voice, video and messaging applications. SIP is used in Internet telephony, in private IP telephone systems, as well as mobile phone calling over LTE (VoLTE).

The Transmission Control Protocol (TCP) is one of the main protocols of the Internet protocol suite. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Therefore, the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network. Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP, which is part of the Transport Layer of the TCP/IP suite. SSL/TLS often runs on top of TCP.

In computer networking, the User Datagram Protocol (UDP) is one of the core communication protocols of the Internet protocol suite used to send messages to other hosts on an Internet Protocol (IP) network. Within an IP network, UDP does not require prior communication to set up communication channels or data paths.

A multicast address is a logical identifier for a group of hosts in a computer network that are available to process datagrams or frames intended to be multicast for a designated network service. Multicast addressing can be used in the link layer, such as Ethernet multicast, and at the internet layer for Internet Protocol Version 4 (IPv4) or Version 6 (IPv6) multicast.

In computing, Internet Protocol Security (IPsec) is a secure network protocol suite that authenticates and encrypts packets of data to provide secure encrypted communication between two computers over an Internet Protocol network. It is used in virtual private networks (VPNs).

<span class="mw-page-title-main">Network address translation</span> Protocol facilitating connection of one IP address space to another

Network address translation (NAT) is a method of mapping an IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device. The technique was originally used to bypass the need to assign a new address to every host when a network was moved, or when the upstream Internet service provider was replaced, but could not route the network's address space. It has become a popular and essential tool in conserving global address space in the face of IPv4 address exhaustion. One Internet-routable IP address of a NAT gateway can be used for an entire private network.

Zero-configuration networking (zeroconf) is a set of technologies that automatically creates a usable computer network based on the Internet Protocol Suite (TCP/IP) when computers or network peripherals are interconnected. It does not require manual operator intervention or special configuration servers. Without zeroconf, a network administrator must set up network services, such as Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS), or configure each computer's network settings manually.

<span class="mw-page-title-main">Anycast</span> Network addressing and routing methodology

Anycast is a network addressing and routing methodology in which a single destination IP address is shared by devices in multiple locations. Routers direct packets addressed to this destination to the location nearest the sender, using their normal decision-making algorithms, typically the lowest number of BGP network hops. Anycast routing is widely used by content delivery networks such as web and DNS hosts, to bring their content closer to end users.

In computer networking, localhost is a hostname that refers to the current computer used to access it. It is used to access the network services that are running on the host via the loopback network interface. Using the loopback interface bypasses any local network interface hardware.

A middlebox is a computer networking device that transforms, inspects, filters, and manipulates traffic for purposes other than packet forwarding. Examples of middleboxes include firewalls, network address translators (NATs), load balancers, and deep packet inspection (DPI) boxes.

The Dynamic Host Configuration Protocol version 6 (DHCPv6) is a network protocol for configuring Internet Protocol version 6 (IPv6) hosts with IP addresses, IP prefixes, default route, local segment MTU, and other configuration data required to operate in an IPv6 network. It is not just the IPv6 equivalent of the Dynamic Host Configuration Protocol for IPv4.

In computer networking, a port or port number is a number assigned to uniquely identify a connection endpoint and to direct data to a specific service. At the software level, within an operating system, a port is a logical construct that identifies a specific process or a type of network service. A port at the software level is identified for each transport protocol and address combination by the port number assigned to it. The most common transport protocols that use port numbers are the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP); those port numbers are 16-bit unsigned numbers.

An IPv6 transition mechanism is a technology that facilitates the transitioning of the Internet from the Internet Protocol version 4 (IPv4) infrastructure in use since 1983 to the successor addressing and routing system of Internet Protocol Version 6 (IPv6). As IPv4 and IPv6 networks are not directly interoperable, transition technologies are designed to permit hosts on either network type to communicate with any other host.

Yet Another Next Generation is a data modeling language for the definition of data sent over network management protocols such as the NETCONF and RESTCONF. The YANG data modeling language is maintained by the NETMOD working group in the Internet Engineering Task Force (IETF) and initially was published as RFC 6020 in October 2010, with an update in August 2016. The data modeling language can be used to model both configuration data as well as state data of network elements. Furthermore, YANG can be used to define the format of event notifications emitted by network elements and it allows data modelers to define the signature of remote procedure calls that can be invoked on network elements via the NETCONF protocol. The language, being protocol independent, can then be converted into any encoding format, e.g. XML or JSON, that the network configuration protocol supports.

Port Control Protocol (PCP) is a computer networking protocol that allows hosts on IPv4 or IPv6 networks to control how the incoming IPv4 or IPv6 packets are translated and forwarded by an upstream router that performs network address translation (NAT) or packet filtering. By allowing hosts to create explicit port forwarding rules, handling of the network traffic can be easily configured to make hosts placed behind NATs or firewalls reachable from the rest of the Internet, which is a requirement for many applications.

References

  1. 1 2 Seedorf, Jan; Burger, Eric (October 2009). Application-Layer Traffic Optimization (ALTO) Problem Statement. IETF. doi: 10.17487/RFC5693 . RFC 5693.
  2. 1 2 Alimi, Richard; Penno, Reinaldo; Yang, Richard; Kiesel, Sebastian; Prevedi, Stefano; Roome, Wendy; Shalunov, Stanislav; Woundy, Richard (September 2014). Application-Layer Traffic Optimization (ALTO) Protocol. IETF. doi: 10.17487/RFC7285 . RFC 7285.
  3. 1 2 Kiesel, Sebastian; Prevedi, Stefano; Stiemerling, Martin; Woundy, Richard; Yang, Richard (September 2012). Application-Layer Traffic Optimization (ALTO) Requirements. IETF. doi: 10.17487/RFC6708 . RFC 6708.
  4. ↑ Kravets, David (September 19, 2008). "Comcast Discloses Throttling Practices - BitTorrent Targeted". wired.com. Retrieved July 9, 2021.
  5. ↑ Peterson, Jon; Cooper, Alissa (July 2009). Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008. IETF. doi: 10.17487/RFC5594 . RFC 5594.
  6. ↑ "Decoupled Application Data Enroute (decade)". ietf.org. IETF . Retrieved October 10, 2021.
  7. ↑ Shalunov, Stanislav; Hazel, Greg; Iyengar, Janardhan; Kuehlewind, Mirja (December 2012). Low Extra Delay Background Transport (LEDBAT). IETF. doi: 10.17487/RFC6817 . RFC 6817.
  8. ↑ Bless, Roland (June 2019). A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services. IETF. doi: 10.17487/RFC8622 . RFC 8622.
  9. ↑ "WG Action: Application-Layer Traffic Optimization (alto)". IESG Secretary. November 12, 2008. Retrieved October 10, 2021.
  10. 1 2 Kiesel, Sebastian; Stiemerling, Martin; Schwan, Nico; Scharf, Michael; Song, Haibin (November 2014). Application-Layer Traffic Optimization (ALTO) Server Discovery. IETF. doi: 10.17487/RFC7286 . RFC 7286.
  11. 1 2 "IETF Datatracker: Application-Layer Traffic Optimization (ALTO)". ietf.org. IETF . Retrieved October 10, 2021.
  12. ↑ Stiemerling, Martin; Kiesel, Sebastian; Scharf, Michael; Seidel, Hans; Prevedi, Stefano (October 2016). Application-Layer Traffic Optimization (ALTO) Deployment Considerations. IETF. doi: 10.17487/RFC7971 . RFC 7971.
  13. ↑ Gurbani, Vijay K.; Seedorf, Jan (June 2020). "Evolution of the IETF Application Layer Traffic Optimization (ALTO) Protocol". IEEE Communications Standards Magazine. 4 (2): 9. doi: 10.1109/MCOMSTD.2020.9139037 .
  14. ↑ Kiesel, Sebastian; Stiemerling, Martin (February 2020). Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery. IETF. doi: 10.17487/RFC8686 . RFC 8686.
  15. ↑ Roome, Wendy; Yang, Richard (November 2020). Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE). IETF. doi: 10.17487/RFC8895 . RFC 8895.
  16. ↑ Randriamasy, Sabine; Roome, Wendy; Schwan, Nico (October 2017). Multi-Cost Application-Layer Traffic Optimization (ALTO). IETF. doi: 10.17487/RFC8189 . RFC 8189.
  17. ↑ Randriamasy, Sabine; Yang, Richard; Wu, Qin; Deng, Lingli; Schwan, Nico (November 2020). Application-Layer Traffic Optimization (ALTO) Cost Calendar. IETF. doi: 10.17487/RFC8896 . RFC 8896.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.