HTTP/2 200 date: Sat, 11 Oct 2025 02:56:58 GMT content-type: application/rfc+xml; charset=utf-8 content-length: 4368 cf-ray: 98cb1656dce0e084-BLR last-modified: Tue, 26 Jul 2022 20:12:18 GMT etag: "3ace-5e4baead5d966-gzip" accept-ranges: bytes vary: Accept-Encoding content-encoding: gzip strict-transport-security: max-age=31536000; includeSubDomains x-frame-options: SAMEORIGIN x-xss-protection: 1; mode=block x-content-type-options: nosniff cf-cache-status: DYNAMIC set-cookie: __cf_bm=ovFUgkwTKWEX1F45ED8M6vmJsTLxB9HHx5xzYIniKFc-1760151418-1.0.1.1-jOOgMCKsDo.LJa_p_WEubV98aIyiDCGqLpLOcx0QvMtHS1DMZlqxEiumqcrQJo_cyhbRd.p.8O56t3beKMbQY_KtPqDUvXu7hbyWLlDyNEQ; path=/; expires=Sat, 11-Oct-25 03:26:58 GMT; domain=.rfc-editor.org; HttpOnly; Secure; SameSite=None server: cloudflare alt-svc: h3=":443"; ma=86400 ]> Orange

Rennes 35000 France mohamed.boucadair@orange.com

Huawei

Yuhua District 101 Software Avenue Nanjing Jiangsu 210012 China bill.wu@huawei.com

tsv alto Optimization service performance cost metric routing computation networks service-network interaction network programming This document creates a new IANA registry for tracking cost modes supported by the Application-Layer Traffic Optimization (ALTO) Protocol. Also, this document relaxes a constraint that was imposed by the ALTO specification on allowed cost mode values. This document updates RFC 7285.

Introduction The cost mode attribute indicates how costs should be interpreted when communicated as described in "Application-Layer Traffic Optimization (ALTO) Protocol" , which includes a provision for only two modes:

"numerical":

Indicates that numerical operations can be performed (e.g., normalization) on the returned costs ().

"ordinal":

Indicates that the cost values in a cost map represent ranking (relative to all other values in a cost map), not actual costs ().

Additional cost modes are required for specific ALTO deployment cases (e.g., ). In order to allow for such use cases, this document relaxes the constraint imposed by the base ALTO specification on allowed cost modes () and creates a new ALTO registry to track new cost modes (). The mechanisms defined in are used to advertise the support of new cost modes for specific cost metrics. Refer to for more details.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document makes use of the terms defined in .

Updates to RFC 7285

Updates to Section 6.1.2 of RFC 7285 This document updates as follows: OLD:

• The cost mode attribute indicates how costs should be interpreted. Specifically, the cost mode attribute indicates whether returned costs should be interpreted as numerical values or ordinal rankings.
• It is important to communicate such information to ALTO clients, as certain operations may not be valid on certain costs returned by an ALTO server. For example, it is possible for an ALTO server to return a set of IP addresses with costs indicating a ranking of the IP addresses. Arithmetic operations that would make sense for numerical values, do not make sense for ordinal rankings. ALTO clients may handle such costs differently.
• Cost modes are indicated in protocol messages as strings.

NEW:

• The cost mode attribute indicates how costs should be interpreted. Two cost modes (numerical values and ordinal rankings) are defined, but additional cost modes can be defined in the future.
• It is important to communicate such information to ALTO clients, as certain operations may not be valid on certain costs returned by an ALTO server. For example, it is possible for an ALTO server to return a set of IP addresses with costs indicating a ranking of the IP addresses. Arithmetic operations that would make sense for numerical values, do not make sense for ordinal rankings. ALTO clients may handle such costs differently.
• Cost modes are indicated in protocol messages as strings.
• For any future documents that defines a new cost mode, indicating whether that new cost mode applies to all or a subset of cost metrics is strongly recommended. This recommendation is meant to prevent nondeterministic behaviors that may result in presenting a cost mode with a specific metric, while such an association does not make sense or can't be unambiguously interpreted by ALTO implementations.
• If the definition of a cost mode does not indicate whether that cost mode applies to a subset of cost metrics, ALTO implementations MUST be prepared to accept that cost mode for any cost metric.

Updates to Section 10.5 of RFC 7285 This document updates as follows: OLD:

• A cost mode is encoded as a string. The string MUST have a value of either "numerical" or "ordinal".

NEW:

• A cost mode 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-minus ('-', U+002D), the colon (':', U+003A), or the low line ('_', U+005F). Cost modes reserved for Private Use are prefixed with "priv:" (). Otherwise, the cost mode MUST have a value that is listed in the registry created in of [RFC9274].

Backward Compatibility Considerations ALTO servers that support new cost modes for specific cost metrics will use the mechanism specified in to advertise their capabilities. ALTO clients (including legacy) will use that information to specify cost constraints in their requests (e.g., indicate a cost metric and a cost mode). An example of such a behavior is depicted in . If an ALTO client includes a cost mode that is not supported by an ALTO server, the server indicates such an error with the error code E_INVALID_FIELD_VALUE as per . In practice, legacy ALTO servers will reply with the error code E_INVALID_FIELD_VALUE to requests that include a cost type other than "numerical" or "ordinal" for the "routingcost" cost metric. The encoding constraints in do not introduce any interoperability issue given that currently implemented cost modes adhere to these constrains (mainly, those in and ).

IANA Considerations IANA has created the new "ALTO Cost Modes" subregistry within the "Application-Layer Traffic Optimization (ALTO) Protocol" registry available at . The assignment policy for this subregistry is "IETF Review" (). Requests to register a new ALTO cost mode must include the following information:

Identifier:

The name of the ALTO cost mode. Refer to for more details on allowed encoding.

Description:

A short description of the requested ALTO cost mode.

Intended Semantics:

A reference to where the semantic of the requested cost mode is defined.

Reference:

A reference to the document that registers the requested cost mode.

Cost modes prefixed with "priv:" are reserved for Private Use (). IANA has added the following note to the new subregistry:

Identifiers prefixed with "priv:" are reserved for Private Use (see RFC 9274, ).

The subregistry is initially populated with the following values: ALTO Cost Modes

Identifier	Description	Intended Semantics	Reference
numerical	Indicates that numerical operations can be performed on the returned costs		RFC 9274
ordinal	Indicates that the cost values in a cost map represent ranking		RFC 9274

Security Considerations This document does not introduce new concerns other than those already discussed in .

References Normative References Informative References IANA

Acknowledgements Many thanks to for spotting the issue during the review of . Thanks to , , , , and for the review and comments. Special thanks to for Shepherding the document. Thanks to for the AD review. Thanks to for the gen-art review, for the artart review, and for the secdir review. Thanks to , , , , , and for the IESG review.