rfc-9274

A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol

M. Boucadair, Q. Wu
date2022-07 streamIETF areaops wgalto statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc9274 doi10.17487/RFC9274
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.

updates

Extracted elements (12)

design-rationale §3.1

New cost mode definitions should indicate whether the mode applies to all or a subset of cost metrics. This recommendation prevents nondeterministic behavior when a cost mode is paired with a metric for which the association is ambiguous or meaningless.

design-rationale §1

RFC 7285 originally allowed only 'numerical' and 'ordinal' cost modes. RFC 9274 relaxes this constraint to allow additional cost modes (e.g., for path vector use cases), with a registry to track them and prevent proliferation of incompatible values.

registry

interoperability-note §4

Legacy ALTO servers will reply with error code E_INVALID_FIELD_VALUE for requests including a cost type other than 'numerical' or 'ordinal' for the 'routingcost' metric. ALTO clients must use capability advertisement (RFC 7285 Section 9.2) to discover supported cost modes before using new ones.

interoperability-note §4

The encoding constraints introduced in Section 3.2 do not introduce interoperability issues because currently implemented cost modes ('numerical', 'ordinal', and those in ALTO-PV) already adhere to these constraints.

normative-requirement §3.2 MUST

A cost mode string MUST be no more than 32 characters and MUST NOT contain characters other than US-ASCII alphanumeric characters, hyphen-minus ('-'), colon (':'), or low line ('_').

normative-requirement §3.2 MUST

Cost modes not reserved for Private Use MUST have a value listed in the ALTO Cost Modes registry created in Section 5 of RFC 9274.

registry

normative-requirement §3.1 MUST

If the definition of a cost mode does not indicate whether it applies to a subset of cost metrics, ALTO implementations MUST be prepared to accept that cost mode for any cost metric.

protocol-element §1

The 'numerical' cost mode indicates that numerical operations (e.g., normalization) can be performed on returned costs. Defined in Section 6.1.2.1 of RFC 7285.

protocol-element §1

The 'ordinal' cost mode indicates that cost values in a cost map represent ranking relative to all other values, not actual costs. Defined in Section 6.1.2.2 of RFC 7285.

registry §5

IANA created a new 'ALTO Cost Modes' subregistry within the 'Application-Layer Traffic Optimization (ALTO) Protocol' registry. Assignment policy is IETF Review. Initial entries are 'numerical' and 'ordinal'. Identifiers prefixed with 'priv:' are reserved for Private Use.

registry

security-consideration §6

RFC 9274 does not introduce new security concerns beyond those already discussed in Section 15 of RFC 7285.

security

wire-format §3.2

Cost modes are encoded as strings of at most 32 characters using US-ASCII alphanumeric characters, hyphen-minus, colon, or low line. Private Use cost modes are prefixed with 'priv:'.