Internet-Draft ALTO Cost Mode March 2022
Boucadair & Wu Expires 22 September 2022 [Page]
Workgroup:
alto
Internet-Draft:
draft-ietf-alto-cost-mode-00
Updates:
7285 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
M. Boucadair
Orange
Q. Wu
Huawei

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 Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 22 September 2022.

1. Introduction

The cost mode attribute indicates how costs should be interpreted when communicated in the Application-Layer Traffic Optimization (ALTO) protocol [RFC7285]. The base ALTO specification 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., [I-D.ietf-alto-path-vector]). In order to allow for such use cases, this document creates a new ALTO registry to track new cost mode values (Section 4) and relaxes the constraints imposed by the base ALTO specification on allowed cost mode values (Section 3).

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 RFC7285

3.1. Update to Section 6.1.2 of RFC7285

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. 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.

3.2. Update to Section 10.5 of RFC7285

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 ('-', U+002D), the colon (':', U+003A), or the low line ('_', +005F). Cost modes reserved for Private Use are prefixed with "priv:" (Section 4). Otherwise, the cost mode MUST have a value that is listed in the registry created in Section 4 of RFCXXXX.

  • Note to the RFC Editor: Please replace RFCXXXX with the RFC number to be assigned to this document.

4. IANA Considerations

This document requests IANA to create a new subregistry entitled "ALTO Cost Modes" under the "Application-Layer Traffic Optimization (ALTO) Protocol" registry available at [ALTO].

The registry is initially populated with the following values:

+===========+=============================+=================+
| Cost Mode | Description                 | Specification   |
+===========+=============================+=================+
| numerical | Indicates that numerical    | Section 6.1.2.1 |
|           | operations can be performed |  of RFC7285     |
|           | on the returned costs       |                 |
+-----------+-----------------------------+-----------------+
| ordinal   | Indicates that the cost     | Section 6.1.2.2 |
|           | values in a cost map        |  of RFC7285     |
|           | represent ranking           |                 |
+-----------+-----------------------------+-----------------+

The assignment policy for this registry is "IETF Review" (Section 4.8 of [RFC8126]).

Cost modes prefixed with "priv:" are reserved for Private Use (Section 4.1 of [RFC8126]).

5. Security Considerations

This document does not introduce new concerns other than those already discussed in Section 15 of [RFC7285].

6. Acknowledgements

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, and Sabine Randriamasy for the review and comments.

Special thanks to Kai Gao for Shepherding the document.

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, , <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, , <https://www.rfc-editor.org/info/rfc7285>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

7.2. Informative References

[ALTO]
"Application-Layer Traffic Optimization (ALTO) Protocol", , <https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml>.
[I-D.ietf-alto-path-vector]
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, , <https://www.ietf.org/archive/id/draft-ietf-alto-path-vector-25.txt>.
[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, , <https://www.rfc-editor.org/info/rfc8126>.

Authors' Addresses

Mohamed Boucadair
Orange
35000 Rennes
France
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing
Jiangsu, 210012
China