A Cost Mode Registry for the
Application-Layer Traffic Optimization (ALTO) ProtocolOrangeRennes35000Francemohamed.boucadair@orange.comHuawei101 Software Avenue, Yuhua DistrictNanjingJiangsu210012Chinabill.wu@huawei.comaltoThis 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.The cost mode attribute indicates how costs should be interpreted
when communicated in the Application-Layer Traffic Optimization (ALTO)
protocol . The base ALTO specification
includes a provision for only two modes: Indicates that numerical
operations can be performed (e.g., normalization) on the returned
costs (Section 6.1.2.1 of ).Indicates that the cost values in
a cost map represent ranking (relative to all other values in a cost
map), not actual costs (Section 6.1.2.2 of ).Additional cost modes are required for specific ALTO deployment cases
(e.g., ). In order to
allow for such use cases, this document creates a new ALTO registry to
track new cost mode values () and relaxes the
constraints imposed by the base ALTO specification on allowed cost mode
values ().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 .This document updates Section 6.1.2 of as follows:The cost mode attribute indicates how costs should be interpreted.
This document defines two cost modes (numerical values or ordinal
rankings), 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.Future documents that define a new cost mode SHOULD indicate
whether that new cost mode applies to all or a subset of cost
metrics.This document updates Section 10.5 of as follows: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 ('_', +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 RFCXXXX.Note to the RFC Editor: Please replace RFCXXXX with the RFC
number to be assigned to this document.This document requests IANA to create a new subregistry entitled
"ALTO Cost Modes" under the "Application-Layer Traffic Optimization
(ALTO) Protocol" registry available at .The registry is initially populated with the following values:The assignment policy for this registry is "IETF Review" (Section 4.8
of ).Cost modes prefixed with "priv:" are reserved for Private Use
(Section 4.1 of ).This document does not introduce new concerns other than those
already discussed in Section 15 of .Many thanks to Benjamin Kaduk for spotting the issue during the
review of .Thanks to Adrian Farrel, Dhruv Dhody, Luis Miguel Contreras Murillo,
Sabine Randriamasy, and Qiao Xiang for the review and comments.Special thanks to Kai Gao for Shepherding the document.Application-Layer Traffic Optimization (ALTO)
Protocol