ALTO Cost Modes: A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol
A new IANA registry for the ways ALTO can say how its cost values should be read.
Boucadair, M. and Q. Wu, "A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol", RFC 9274, DOI 10.17487/RFC9274, July 2022, <https://www.rfc-editor.org/info/rfc9274>.
@misc{rfc9274,
series = {Request for Comments},
number = 9274,
howpublished = {RFC 9274},
publisher = {RFC Editor},
doi = {10.17487/RFC9274},
url = {https://www.rfc-editor.org/info/rfc9274},
author = {M. Boucadair and Q. Wu},
title = {{A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol}},
pagetotal = 7,
year = 2022,
month = jul,
} RFC text
Contents
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 9274 Orange
Updates: 7285 Q. Wu
Category: Standards Track Huawei
ISSN: 2070-1721 July 2022
A Cost Mode Registry for the Application-Layer Traffic Optimization
(ALTO) Protocol
Abstract
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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9274.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
2. Terminology
3. Updates to RFC 7285
3.1. Updates to Section 6.1.2 of RFC 7285
3.2. Updates to Section 10.5 of RFC 7285
4. Backward Compatibility Considerations
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
1. Introduction
The cost mode attribute indicates how costs should be interpreted
when communicated as described in "Application-Layer Traffic
Optimization (ALTO) Protocol" [RFC7285], which includes a provision
for only two modes:
"numerical": Indicates that numerical operations can be performed
(e.g., normalization) on the returned costs (Section 6.1.2.1 of
[RFC7285]).
"ordinal": 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 [RFC7285]).
Additional cost modes are required for specific ALTO deployment cases
(e.g., [ALTO-PV]). In order to allow for such use cases, this
document relaxes the constraint imposed by the base ALTO
specification on allowed cost modes (Section 3) and creates a new
ALTO registry to track new cost modes (Section 5).
The mechanisms defined in [RFC7285] are used to advertise the support
of new cost modes for specific cost metrics. Refer to Section 4 for
more details.
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document makes use of the terms defined in [RFC7285].
3. Updates to RFC 7285
3.1. Updates to Section 6.1.2 of RFC 7285
This document updates Section 6.1.2 of [RFC7285] 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.
3.2. Updates to Section 10.5 of RFC 7285
This document updates Section 10.5 of [RFC7285] 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:" (Section 5). Otherwise,
the cost mode MUST have a value that is listed in the registry
created in Section 5 of [RFC9274].
4. Backward Compatibility Considerations
ALTO servers that support new cost modes for specific cost metrics
will use the mechanism specified in Section 9.2 of [RFC7285] 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 Section 9.2.3 of [RFC7285].
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 Section 8.5.2 of [RFC7285]. 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 Section 3.2 do not introduce any
interoperability issue given that currently implemented cost modes
adhere to these constrains (mainly, those in [RFC7285] and
[ALTO-PV]).
5. IANA Considerations
IANA has created the new "ALTO Cost Modes" subregistry within the
"Application-Layer Traffic Optimization (ALTO) Protocol" registry
available at [ALTO].
The assignment policy for this subregistry is "IETF Review"
(Section 4.8 of [RFC8126]).
Requests to register a new ALTO cost mode must include the following
information:
Identifier: The name of the ALTO cost mode. Refer to Section 3.2
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
(Section 4.1 of [RFC8126]). IANA has added the following note to the
new subregistry:
| Identifiers prefixed with "priv:" are reserved for Private Use
| (see RFC 9274, Section 5).
The subregistry is initially populated with the following values:
+============+=============================+============+===========+
| Identifier | Description | Intended | Reference |
| | | Semantics | |
+============+=============================+============+===========+
| numerical | Indicates that numerical | Section | RFC 9274 |
| | operations can be performed | 6.1.2.1 | |
| | on the returned costs | of | |
| | | [RFC7285] | |
+------------+-----------------------------+------------+-----------+
| ordinal | Indicates that the cost | Section | RFC 9274 |
| | values in a cost map | 6.1.2.2 | |
| | represent ranking | of | |
| | | [RFC7285] | |
+------------+-----------------------------+------------+-----------+
Table 1: ALTO Cost Modes
6. Security Considerations
This document does not introduce new concerns other than those
already discussed in Section 15 of [RFC7285].
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References
[ALTO] IANA, "Application-Layer Traffic Optimization (ALTO)
Protocol",
<https://www.iana.org/assignments/alto-protocol/>.
[ALTO-PV] Gao, K., Lee, Y., Randriamasy, S., Yang, Y. R., and J. J.
Zhang, "An ALTO Extension: Path Vector", Work in Progress,
Internet-Draft, draft-ietf-alto-path-vector-25, 20 March
2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
alto-path-vector-25>.
Acknowledgements
Many thanks to Benjamin Kaduk for spotting the issue during the
review of [ALTO-PV].
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.
Thanks to Martin Duke for the AD review.
Thanks to Roni Even for the gen-art review, Jaime Jimenez for the
artart review, and Stephen Farrell for the secdir review.
Thanks to Robert Wilton, Lars Eggert, Francesca Palombini, Roman
Danyliw, Paul Wouters, and Murray Kucherawy for the IESG review.
Authors' Addresses
Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
Qin Wu
Huawei
Yuhua District
101 Software Avenue
Nanjing
Jiangsu, 210012
China
Email: bill.wu@huawei.com
AI ELI5
On this page
§1Why Cost Modes Needed a Registry
In the Application-Layer Traffic Optimization (ALTO) protocol from RFC 7285, the cost mode attribute tells a client how to interpret the costs it receives. The base specification provides for only two modes.
The numerical mode says numerical operations, such as normalization, can be performed on the returned costs. The ordinal mode says the cost values in a cost map represent a ranking relative to all other values, not actual costs.
RFC 9274 points out that additional cost modes are required for specific ALTO deployment cases, such as the Path Vector extension, then relaxes the limit on allowed modes and creates a registry to track new ones.
Imagine a list that says 'how far' either in real miles or just as first, second, third. ALTO only knew those two ways, and this RFC lets people add more.
§3.1Opening the Door to New Modes
The first update changes Section 6.1.2 of RFC 7285. The old text described the attribute as indicating whether costs are numerical values or ordinal rankings. The new text says two modes are defined but additional ones can be defined in the future.
The RFC strongly recommends that any future document defining a new cost mode say whether it applies to all cost metrics or only a subset. This is meant to prevent nondeterministic behavior when a mode is paired with a metric where the combination does not make sense or cannot be interpreted unambiguously.
If a definition does not say, ALTO implementations MUST be prepared to accept that cost mode for any cost metric.
The rule book used to say there are only two kinds. Now it says more can be invented, and anyone inventing one should say where it can be used.
§3.2Encoding Rules for Cost Mode Names
The second update changes Section 10.5 of RFC 7285. Previously a cost mode string had to be either numerical or ordinal. Now the string MUST be no more than 32 characters long.
It MUST NOT contain characters other than US-ASCII letters and digits, the hyphen-minus, the colon and the low line (underscore). Cost modes reserved for Private Use are prefixed with priv:. Any other cost mode MUST be one listed in the new registry.
Names must be short and use only simple letters, digits and a few symbols, like a username with rules. Names starting with priv: are for your own private use.
§4Backward Compatibility
Servers that support new cost modes for particular cost metrics advertise this with the capability mechanism in Section 9.2 of RFC 7285. Clients, including legacy ones, use that information to set cost constraints in requests.
If a client asks for a cost mode a server does not support, the server answers with the error code E_INVALID_FIELD_VALUE. Legacy servers do the same for any cost type other than numerical or ordinal with the routingcost metric.
The new encoding limits introduce no interoperability issue, because the cost modes currently implemented already follow them.
If you ask for a kind of answer a server does not know, it politely says it cannot understand the request. Older servers already do that.
§5The ALTO Cost Modes Registry
IANA created the ALTO Cost Modes subregistry inside the ALTO Protocol registry. The assignment policy is IETF Review.
A registration request must give four things: an Identifier (the mode name), a Description, the Intended Semantics (a reference to where the meaning is defined) and a Reference to the registering document. Identifiers starting with priv: are reserved for Private Use, and IANA added a note saying so.
The registry starts with two entries, numerical and ordinal, both pointing at Sections 6.1.2.1 and 6.1.2.2 of RFC 7285 with RFC 9274 as the reference.
It is an official notebook of all allowed kinds. To add a new one, the proposal has to pass a review, and the first two are already written in.
- numericalnumerical — Numerical operations can be performed on the returned costs. Section 6.1.2.1 of RFC 7285.
- ordinalordinal — Cost values in a cost map represent a ranking, not actual costs. Section 6.1.2.2 of RFC 7285.
§6Security Considerations
The document says it does not introduce new concerns beyond those already discussed in Section 15 of RFC 7285. Nothing further is specified.
The change is administrative: it affects how modes are named and tracked, not how ALTO messages are protected.
This only adds a list and naming rules, so there are no new safety worries beyond the ones ALTO already had.