rfc9274.original   rfc9274.txt 
alto M. Boucadair Internet Engineering Task Force (IETF) M. Boucadair
Internet-Draft Orange Request for Comments: 9274 Orange
Updates: 7285 (if approved) Q. Wu Updates: 7285 Q. Wu
Intended status: Standards Track Huawei Category: Standards Track Huawei
Expires: 4 December 2022 2 June 2022 ISSN: 2070-1721 July 2022
A Cost Mode Registry for the Application-Layer Traffic Optimization A Cost Mode Registry for the Application-Layer Traffic Optimization
(ALTO) Protocol (ALTO) Protocol
draft-ietf-alto-cost-mode-05
Abstract Abstract
This document creates a new IANA registry for tracking cost modes This document creates a new IANA registry for tracking cost modes
supported by the Application-Layer Traffic Optimization (ALTO) supported by the Application-Layer Traffic Optimization (ALTO)
Protocol. Also, this document relaxes a constraint that was imposed Protocol. Also, this document relaxes a constraint that was imposed
by the ALTO specification on allowed cost mode values. by the ALTO specification on allowed cost mode values.
This document updates RFC 7285. This document updates RFC 7285.
Editorial Note (To be removed by RFC Editor)
Please update RFC XXXX statements within the document with the RFC
number to be assigned to this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 4 December 2022. 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 Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Updates to RFC7285 . . . . . . . . . . . . . . . . . . . . . 3 3. Updates to RFC 7285
3.1. Updates to Section 6.1.2 of RFC7285 . . . . . . . . . . . 3 3.1. Updates to Section 6.1.2 of RFC 7285
3.2. Updates to Section 10.5 of RFC7285 . . . . . . . . . . . 4 3.2. Updates to Section 10.5 of RFC 7285
4. Backward Compatibility Considerations . . . . . . . . . . . . 5 4. Backward Compatibility Considerations
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses
1. Introduction 1. Introduction
The cost mode attribute indicates how costs should be interpreted The cost mode attribute indicates how costs should be interpreted
when communicated in the Application-Layer Traffic Optimization when communicated as described in "Application-Layer Traffic
(ALTO) Protocol [RFC7285]. The base ALTO specification includes a Optimization (ALTO) Protocol" [RFC7285], which includes a provision
provision for only two modes: for only two modes:
"numerical": Indicates that numerical operations can be performed "numerical": Indicates that numerical operations can be performed
(e.g., normalization) on the returned costs (Section 6.1.2.1 of (e.g., normalization) on the returned costs (Section 6.1.2.1 of
[RFC7285]). [RFC7285]).
"ordinal": Indicates that the cost values in a cost map represent "ordinal": Indicates that the cost values in a cost map represent
ranking (relative to all other values in a cost map), not actual ranking (relative to all other values in a cost map), not actual
costs (Section 6.1.2.2 of [RFC7285]). costs (Section 6.1.2.2 of [RFC7285]).
Additional cost modes are required for specific ALTO deployment cases Additional cost modes are required for specific ALTO deployment cases
(e.g., [I-D.ietf-alto-path-vector]). In order to allow for such use (e.g., [ALTO-PV]). In order to allow for such use cases, this
cases, this document relaxes the constraint imposed by the base ALTO document relaxes the constraint imposed by the base ALTO
specification on allowed cost modes (Section 3) and creates a new specification on allowed cost modes (Section 3) and creates a new
ALTO registry to track new cost modes (Section 5). ALTO registry to track new cost modes (Section 5).
The mechanisms defined in [RFC7285] are used to advertise the support The mechanisms defined in [RFC7285] are used to advertise the support
of new cost modes for specific cost metrics. Refer to Section 4 for of new cost modes for specific cost metrics. Refer to Section 4 for
more details. more details.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119][RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document makes use of the terms defined in [RFC7285]. This document makes use of the terms defined in [RFC7285].
3. Updates to RFC7285 3. Updates to RFC 7285
3.1. Updates to Section 6.1.2 of RFC7285 3.1. Updates to Section 6.1.2 of RFC 7285
This document updates Section 6.1.2 of [RFC7285] as follows: This document updates Section 6.1.2 of [RFC7285] as follows:
OLD: OLD:
The cost mode attribute indicates how costs should be interpreted. The cost mode attribute indicates how costs should be interpreted.
Specifically, the cost mode attribute indicates whether returned Specifically, the cost mode attribute indicates whether returned
costs should be interpreted as numerical values or ordinal costs should be interpreted as numerical values or ordinal
rankings. rankings.
skipping to change at page 4, line 10 skipping to change at line 139
It is important to communicate such information to ALTO clients, It is important to communicate such information to ALTO clients,
as certain operations may not be valid on certain costs returned as certain operations may not be valid on certain costs returned
by an ALTO server. For example, it is possible for an ALTO server 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 to return a set of IP addresses with costs indicating a ranking of
the IP addresses. Arithmetic operations that would make sense for the IP addresses. Arithmetic operations that would make sense for
numerical values, do not make sense for ordinal rankings. ALTO numerical values, do not make sense for ordinal rankings. ALTO
clients may handle such costs differently. clients may handle such costs differently.
Cost modes are indicated in protocol messages as strings. Cost modes are indicated in protocol messages as strings.
Future documents that define a new cost mode are strongly For any future documents that defines a new cost mode, indicating
recommended to indicate whether that new cost mode applies to all whether that new cost mode applies to all or a subset of cost
or a subset of cost metrics. This recommendation is meant to metrics is strongly recommended. This recommendation is meant to
prevent non-deterministic behaviors that may result in presenting prevent nondeterministic behaviors that may result in presenting a
a cost mode with a specific metric, while such an association does cost mode with a specific metric, while such an association does
not make sense or can't be unambiguously interpreted by ALTO not make sense or can't be unambiguously interpreted by ALTO
implementations. implementations.
If the definition of a cost mode does not indicate whether that If the definition of a cost mode does not indicate whether that
cost mode applies to a subset of cost metrics, ALTO cost mode applies to a subset of cost metrics, ALTO
implementations MUST be prepared to accept that cost mode for any implementations MUST be prepared to accept that cost mode for any
cost metric. cost metric.
3.2. Updates to Section 10.5 of RFC7285 3.2. Updates to Section 10.5 of RFC 7285
This document updates Section 10.5 of [RFC7285] as follows: This document updates Section 10.5 of [RFC7285] as follows:
OLD: OLD:
A cost mode is encoded as a string. The string MUST have a value A cost mode is encoded as a string. The string MUST have a value
of either "numerical" or "ordinal". of either "numerical" or "ordinal".
NEW: NEW:
A cost mode is encoded as a string. The string MUST be no more 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 than 32 characters, and it MUST NOT contain characters other than
US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A,
and U+0061-U+007A), the hyphen-minus ('-', U+002D), the colon and U+0061-U+007A), the hyphen-minus ('-', U+002D), the colon
(':', U+003A), or the low line ('_', U+005F). Cost modes reserved (':', U+003A), or the low line ('_', U+005F). Cost modes reserved
for Private Use are prefixed with "priv:" (Section 5). Otherwise, for Private Use are prefixed with "priv:" (Section 5). Otherwise,
the cost mode MUST have a value that is listed in the registry the cost mode MUST have a value that is listed in the registry
created in Section 5 of RFCXXXX. created in Section 5 of [RFC9274].
4. Backward Compatibility Considerations 4. Backward Compatibility Considerations
ALTO servers that support new cost modes for specific cost metrics ALTO servers that support new cost modes for specific cost metrics
will use the mechanism specified in Section 9.2 of [RFC7285] to will use the mechanism specified in Section 9.2 of [RFC7285] to
advertise their capabilities. ALTO clients (including legacy) will advertise their capabilities. ALTO clients (including legacy) will
use that information to specify cost constraints in their requests 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 (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]. behavior is depicted in Section 9.2.3 of [RFC7285].
If an ALTO client includes a cost mode that is not supported by an 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 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 E_INVALID_FIELD_VALUE as per Section 8.5.2 of [RFC7285]. In
practice, legacy ALTO servers will reply with the error code practice, legacy ALTO servers will reply with the error code
E_INVALID_FIELD_VALUE to requests that include a cost type other than E_INVALID_FIELD_VALUE to requests that include a cost type other than
"numerical" or "ordinal" for the "routingcost" cost metric. "numerical" or "ordinal" for the "routingcost" cost metric.
The encoding constraints in Section 3.2 do not introduce any The encoding constraints in Section 3.2 do not introduce any
interoperability issue given that currently implemented cost modes interoperability issue given that currently implemented cost modes
adhere to these constrains (mainly, those in [RFC7285] and adhere to these constrains (mainly, those in [RFC7285] and
[I-D.ietf-alto-path-vector]). [ALTO-PV]).
5. IANA Considerations 5. IANA Considerations
This document requests IANA to create a new subregistry entitled IANA has created the new "ALTO Cost Modes" subregistry within the
"ALTO Cost Modes" under the "Application-Layer Traffic Optimization "Application-Layer Traffic Optimization (ALTO) Protocol" registry
(ALTO) Protocol" registry available at [ALTO]. available at [ALTO].
The assignment policy for this subregistry is "IETF Review" The assignment policy for this subregistry is "IETF Review"
(Section 4.8 of [RFC8126]). (Section 4.8 of [RFC8126]).
Requests to register a new ALTO cost mode must include the following Requests to register a new ALTO cost mode must include the following
information: information:
Identifier: The name of the ALTO cost mode. Refer to Section 3.2 Identifier: The name of the ALTO cost mode. Refer to Section 3.2
for more details on allowed encoding. for more details on allowed encoding.
Description: A short description of the requested ALTO cost mode. Description: A short description of the requested ALTO cost mode.
Intended Semantics: A reference to where the semantic of the Intended Semantics: A reference to where the semantic of the
requested cost mode is defined. requested cost mode is defined.
Reference: A reference to the document that registers the requested Reference: A reference to the document that registers the requested
cost mode. cost mode.
Cost modes prefixed with "priv:" are reserved for Private Use Cost modes prefixed with "priv:" are reserved for Private Use
(Section 4.1 of [RFC8126]). This document requests IANA to add the (Section 4.1 of [RFC8126]). IANA has added the following note to the
following note to the new subregistry: new subregistry:
Note: Identifiers prefixed with 'priv:' are reserved for Private Use | Identifiers prefixed with "priv:" are reserved for Private Use
(see [RFCXXXX], Section 5). | (RFC 9274, Section 5).
The subregistry is initially populated with the following values: The subregistry is initially populated with the following values:
+============+=============================+============+===========+ +============+=============================+============+===========+
| Identifier | Description | Intended | Reference | | Identifier | Description | Intended | Reference |
| | | Semantics | | | | | Semantics | |
+============+=============================+============+===========+ +============+=============================+============+===========+
| numerical | Indicates that numerical | Section | RFCXXXX | | numerical | Indicates that numerical | Section | RFC 9274 |
| | operations can be performed | 6.1.2.1 of | | | | operations can be performed | 6.1.2.1 | |
| | on the returned costs | RFC7285 | | | | on the returned costs | of | |
| | | [RFC7285] | |
+------------+-----------------------------+------------+-----------+ +------------+-----------------------------+------------+-----------+
| ordinal | Indicates that the cost | Section | RFCXXXX | | ordinal | Indicates that the cost | Section | RFC 9274 |
| | values in a cost map | 6.1.2.2 of | | | | values in a cost map | 6.1.2.2 | |
| | represent ranking | RFC7285 | | | | represent ranking | of | |
| | | [RFC7285] | |
+------------+-----------------------------+------------+-----------+ +------------+-----------------------------+------------+-----------+
Table 1: ALTO Cost Modes
6. Security Considerations 6. Security Considerations
This document does not introduce new concerns other than those This document does not introduce new concerns other than those
already discussed in Section 15 of [RFC7285]. already discussed in Section 15 of [RFC7285].
7. Acknowledgements 7. References
Many thanks to Benjamin Kaduk for spotting the issue during the
review of [I-D.ietf-alto-path-vector].
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.
8. References
8.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy, Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol", "Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014, RFC 7285, DOI 10.17487/RFC7285, September 2014,
skipping to change at page 7, line 25 skipping to change at line 271
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 7.2. Informative References
[ALTO] "Application-Layer Traffic Optimization (ALTO) Protocol", [ALTO] IANA, "Application-Layer Traffic Optimization (ALTO)
2 March 2022, <https://www.iana.org/assignments/alto- Protocol",
protocol/alto-protocol.xhtml>. <https://www.iana.org/assignments/alto-protocol/>.
[I-D.ietf-alto-path-vector] [ALTO-PV] Gao, K., Lee, Y., Randriamasy, S., Yang, Y. R., and J. J.
Gao, K., Lee, Y., Randriamasy, S., Yang, Y. R., and J. J.
Zhang, "An ALTO Extension: Path Vector", Work in Progress, Zhang, "An ALTO Extension: Path Vector", Work in Progress,
Internet-Draft, draft-ietf-alto-path-vector-25, 20 March Internet-Draft, draft-ietf-alto-path-vector-25, 20 March
2022, <https://www.ietf.org/archive/id/draft-ietf-alto- 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
path-vector-25.txt>. 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 Authors' Addresses
Mohamed Boucadair Mohamed Boucadair
Orange Orange
35000 Rennes 35000 Rennes
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Qin Wu Qin Wu
Huawei Huawei
101 Software Avenue, Yuhua District Yuhua District
101 Software Avenue
Nanjing Nanjing
Jiangsu, 210012 Jiangsu, 210012
China China
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
 End of changes. 30 change blocks. 
102 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/