Showing content from https://www.rfc-editor.org/rfc/rfc9274.xml below:
Introduction The cost mode attribute indicates how costs should be interpreted when communicated as described in "Application-Layer Traffic Optimization (ALTO) Protocol" , which includes a provision for only two modes:
-
"numerical":
-
Indicates that numerical operations can be performed (e.g., normalization) on the returned costs ().
-
"ordinal":
-
Indicates that the cost values in a cost map represent ranking (relative to all other values in a cost map), not actual costs ().
Additional cost modes are required for specific ALTO deployment cases (e.g., ). In order to allow for such use cases, this document relaxes the constraint imposed by the base ALTO specification on allowed cost modes ( ) and creates a new ALTO registry to track new cost modes ( ). The mechanisms defined in are used to advertise the support of new cost modes for specific cost metrics. Refer to for more details. 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 when, and only when, they appear in all capitals, as shown here. This document makes use of the terms defined in . Updates to RFC 7285 Updates to Section 6.1.2 of RFC 7285 This document updates 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.
Updates to Section 10.5 of RFC 7285 This document updates 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:" (). Otherwise, the cost mode MUST have a value that is listed in the registry created in of [RFC9274].
Backward Compatibility Considerations ALTO servers that support new cost modes for specific cost metrics will use the mechanism specified in 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 . 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 . 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 do not introduce any interoperability issue given that currently implemented cost modes adhere to these constrains (mainly, those in and ). IANA Considerations IANA has created the new "ALTO Cost Modes" subregistry within the "Application-Layer Traffic Optimization (ALTO) Protocol" registry available at . The assignment policy for this subregistry is "IETF Review" ( ). Requests to register a new ALTO cost mode must include the following information:
-
Identifier:
-
The name of the ALTO cost mode. Refer to 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 ( ). IANA has added the following note to the new subregistry:
Identifiers prefixed with "priv:" are reserved for Private Use (see RFC 9274, ).
The subregistry is initially populated with the following values: ALTO Cost Modes Identifier Description Intended Semantics Reference numerical Indicates that numerical operations can be performed on the returned costs RFC 9274 ordinal Indicates that the cost values in a cost map represent ranking RFC 9274 Security Considerations This document does not introduce new concerns other than those already discussed in . References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Application-Layer Traffic Optimization (ALTO) Protocol Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it. The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps. This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Application-Layer Traffic Optimization (ALTO) Protocol IANA An ALTO Extension: Path Vector Sichuan University Samsung Nokia Bell Labs Yale University Tongji University This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO Cost Map and ALTO Property Map services so that an application can decide which endpoint(s) to connect based on not only numerical/ordinal cost values but also fine-grained abstract information of the paths. This is useful for applications whose performance is impacted by specified components of a network on the end-to-end paths, e.g., they may infer that several paths share common links and prevent traffic bottlenecks by avoiding such paths. This extension introduces a new abstraction called Abstract Network Element (ANE) to represent these components and encodes a network path as a vector of ANEs. Thus, it provides a more complete but still abstract graph representation of the underlying network(s) for informed traffic optimization among endpoints. Work in Progress Acknowledgements Many thanks to for spotting the issue during the review of . Thanks to , , , , and for the review and comments. Special thanks to for Shepherding the document. Thanks to for the AD review. Thanks to for the gen-art review, for the artart review, and for the secdir review. Thanks to , , , , , and for the IESG review. Authors' Addresses Orange Rennes 35000 France mohamed.boucadair@orange.com Huawei Yuhua District 101 Software Avenue Nanjing Jiangsu 210012 China bill.wu@huawei.com
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4