summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9274.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc9274.txt')
-rw-r--r--doc/rfc/rfc9274.txt324
1 files changed, 324 insertions, 0 deletions
diff --git a/doc/rfc/rfc9274.txt b/doc/rfc/rfc9274.txt
new file mode 100644
index 0000000..0aee2d8
--- /dev/null
+++ b/doc/rfc/rfc9274.txt
@@ -0,0 +1,324 @@
+
+
+
+
+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