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: [email protected]


  Qin Wu
  Huawei
  Yuhua District
  101 Software Avenue
  Nanjing
  Jiangsu, 210012
  China
  Email: [email protected]

You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.