Application-Layer Traffic Optimization (ALTO) Protocol

Network maps and cost maps are separated so they can be updated at different timescales: PID groupings are stable over longer periods while cost maps may change frequently to reflect dynamic conditions. This separation also allows cost information to be compactly represented without re-transmitting endpoint-to-PID mappings.

json

PIDs provide a network-agnostic, indirect abstraction layer so that ALTO information remains stable and compact even as fine-grained topology changes. This abstraction also allows an ISP to protect sensitive internal topology by exposing only policy-level groupings rather than raw routing state.

ip

The ALTO Protocol uses a RESTful design with JSON encoding specifically to leverage existing HTTP infrastructure, caching intermediaries, and deployment experience at scale. Using specific 'application/alto-*+json' media types (rather than generic application/json) allows easy versioning and extensibility of individual components.

http, json

When mapping an endpoint IP address to a PID for 'ipv4' or 'ipv6' network maps, the ALTO server uses a longest-prefix-match algorithm over the IP prefixes associated with each PID. A catch-all PID entry (e.g., 0.0.0.0/0 or ::/0) may be used to cover endpoints not otherwise listed.

ip

ALTO implementations MUST ignore unknown fields when processing ALTO messages. This forward-compatibility requirement allows extensions to add JSON fields without breaking existing clients or servers.

http, json

ALTO server and client implementations MUST support the 'https' URI scheme and TLS. Where client authentication is desired, HTTP Digest Authentication MUST be supported; TLS Client Authentication is preferred when available.

security, http

An ALTO error response MUST include a 'code' field in the 'meta' object with one of the defined ALTO error code strings. The ALTO server MUST also set an appropriate HTTP status code independent of whether ALTO-layer error info is included.

http, json

An ALTO server MUST define the 'pid' endpoint property type for each ALTO network map it provides, using the longest-prefix-match algorithm specified in Section 11.2.2 to determine the PID for a given endpoint IP address.

ip

An ALTO server MUST make one information resource directory available via HTTP GET at a discoverable URI. For a Root IRD, the 'meta' field MUST include 'default-alto-network-map' specifying the resource ID of a default network map.

http, json

An ALTO server MUST NOT define two ALTO cost maps with the same cost type and network map pair; the (cost-type, network-map) combination is a unique key per ALTO server.

json

An ALTO server MUST offer the 'routingcost' cost metric, conveying a generic measure for the cost of routing traffic from source to destination where a lower value indicates higher preference. The internal computation method (e.g., air miles or hop-count) is left to the provider.

http, json

An ALTO server MUST support at least one cost mode: 'numerical' or 'ordinal'. A client desiring numerical costs MAY adjust its behavior if only ordinal is available, and may construct ordinal rankings from numerical values if only numerical is available.

http, json

The ALTO server MUST indicate the type of its response using the Content-Type HTTP header. ALTO clients and servers MUST be compliant with HTTP as specified in RFC 7230.

http

When requesting an ALTO information resource that requires input parameters, the ALTO client MUST use the HTTP POST method and MUST set the Content-Type header to the appropriate media type. An ALTO client MUST NOT assume GET and POST are interchangeable.

http

Whenever the content of an ALTO network map changes, its version tag MUST also be changed. The tag may be set to a last-modified timestamp or a hash of the map's contents.

http, json

ALTO clients reveal the IP addresses of endpoints they query (e.g., candidate peers in a P2P application) to the ALTO server, enabling the server to track client associations and activity patterns. Clients should use trusted ALTO servers and consider the privacy implications of the endpoint addresses included in queries.

privacy, security

A Cost Type is the combination of a cost metric (e.g., 'routingcost', 'hopcount') and a cost mode ('numerical' or 'ordinal'). Cost types are named in the IRD's 'meta.cost-types' field for reuse across resource entries.

json

A Provider-Defined Identifier (PID) is an opaque string identifying an aggregation of network endpoints (e.g., a subnet, POP, or AS). PIDs are defined in an ALTO network map and serve as the primary abstraction for compactly expressing path costs between groups of endpoints.

ip, json

A version tag is a tuple of (resource ID, opaque string tag) that allows an ALTO client to correlate a cost map with the exact version of the network map on which it is based. Both network maps and cost maps carry version tags in their 'meta' field.

json

ALTO error responses carry four defined error codes in the 'meta.code' field: E_SYNTAX (request parse failure), E_MISSING_FIELD (required field absent), E_INVALID_FIELD_TYPE (wrong JSON type for a field), and E_INVALID_FIELD_VALUE (semantically invalid value). Optional 'field' and 'value' fields provide debugging detail.

http, json

The Information Resource Directory (IRD) maps ResourceIDs to IRDResourceEntry objects, each containing a URI, media-type, optional 'accepts' (POST input media type), optional 'capabilities', and optional 'uses' (list of dependent resource IDs). ALTO clients traverse IRDs recursively to discover all available resources.

http, json

This document creates the ALTO Address Type Registry for endpoint address type name strings (e.g., 'ipv4', 'ipv6'). New address types require IETF Review, allowing extension documents to define additional address families.

registry, ip

This document creates the ALTO Cost Metric Registry for cost metric name strings. New entries require IETF Review. The registry is seeded with 'routingcost' (generic routing preference, lower is preferred) and 'hopcount' (number of IP hops).

registry

This document creates the ALTO Endpoint Property Type Registry for endpoint property type name strings. New entries require IETF Review. The registry is seeded with 'pid' (the PID of an endpoint relative to a specific network map resource).

registry

This document creates the ALTO Error Code Registry for ALTO error code strings used in the 'meta.code' field of error responses. New codes require IETF Review. Seeded with E_SYNTAX, E_MISSING_FIELD, E_INVALID_FIELD_TYPE, and E_INVALID_FIELD_VALUE.

registry

This document registers multiple 'application/alto-*+json' media types with IANA: alto-directory+json, alto-networkmap+json, alto-networkmapfilter+json, alto-costmap+json, alto-costmapfilter+json, alto-endpointprop+json, alto-endpointpropparams+json, alto-endpointcost+json, alto-endpointcostparams+json, and alto-error+json.

registry, http, json

ALTO information authenticity and integrity may be compromised by an on-path attacker modifying responses. The primary protection is HTTPS/TLS; however, cached or redistributed ALTO information is not protected by the original TLS session, and future mechanisms such as digital signatures for cached content are identified as needed work.

security

ALTO information may reveal sensitive network topology or business relationships (e.g., peering structures, internal cost policies). ALTO servers should use HTTPS and consider access control to limit exposure to authorized clients only.

security

An authenticated but malicious or misconfigured ALTO server could provide guidance that directs traffic in ways harmful to the client (e.g., overloading specific peers, steering traffic to monitored paths). Clients should only trust ALTO servers that are operated by or vetted by a trusted party.

security

A PID Name is a JSON string constrained to a specific syntax (Section 10.1). A ResourceID similarly is a constrained JSONString (Section 10.2). Both are used as keys in object-maps and must not be reused across different resources over time.

json

All ALTO server responses share the base JSON type ResponseEntityBase, which contains a 'meta' field of type ResponseMeta (an object-map of JSONString to JSONValue). Service-specific types derive from this base and add a typed data field (e.g., 'network-map', 'cost-map', 'endpoint-cost').

http, json

An IRDResourceEntry is a JSON object with fields: 'uri' (string, resolved per RFC 3986), 'media-type' (string), optional 'accepts' (string), optional 'capabilities' (JSON object), and optional 'uses' (array of ResourceID strings). A URI MUST support GET if 'accepts' is absent, and MUST support POST if 'accepts' is non-empty.

http, json

Typed endpoint addresses are encoded as strings of the form 'type:value' (e.g., 'ipv4:192.0.2.1', 'ipv6:2001:db8::1'). Endpoint prefixes use CIDR notation (e.g., 'ipv4:192.0.2.0/24'). An EndpointAddrGroup is a JSON object mapping address-type strings to arrays of typed endpoint address strings.

ip, json