A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol

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 3 December 2022.¶

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

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

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 [I-D.ietf-alto-path-vector]).¶

5. 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:¶

   +============+=============================+============+===========+
   | Identifier | Description                 | Intended   | Reference |
   |            |                             | Semantics  |           |
   +============+=============================+============+===========+
   | numerical  | Indicates that numerical    | Section    | RFCXXXX   |
   |            | operations can be performed | 6.1.2.1 of |           |
   |            | on the returned costs       | RFC7285    |           |
   +------------+-----------------------------+------------+-----------+
   | ordinal    | Indicates that the cost     | Section    | RFCXXXX   |
   |            | values in a cost map        | 6.1.2.2 of |           |
   |            | represent ranking           | RFC7285    |           |
   +------------+-----------------------------+------------+-----------+

The assignment policy for this registry 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]). This document requests IANA to add the following note to the new subregistry:¶

Note:

Identifiers prefixed with 'priv:' are reserved for Private Use (see [RFCXXXX], Section 5).¶

6. Security Considerations

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

7. 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, 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, and Paul Wouters for the IESG review.¶

Authors' Addresses