]> Tongji University

4800 Cao'An Hwy Shanghai 201804 China jingxuan.n.zhang@gmail.com

Huawei Technologies

Divyashree Techno Park, Whitefield Bangalore Karnataka 560066 India dhruv.ietf@gmail.com

Sichuan University

No.24 South Section 1, Yihuan Road Chengdu 610000 China kaigao@scu.edu.cn

Deutsche Telekom

Heinrich-Hertz-Strasse 3-7 Darmstadt 64295 Germany Roland.Schott@telekom.de

Networks ALTO WG ALTO, Internet-Draft This document defines a YANG data model for Operations, Administration, and Maintenance (OAM) & Management of Application-Layer Traffic Optimization (ALTO) Protocol. The operator can use the data model to create and update ALTO information resources, manage the access control, configure server-to-server communication and server discovery, and collect statistical data. Discussion Venues Discussion of this document takes place on the ALTO Working Group mailing list (alto@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction This document defines a YANG data model for the Operations, Administration, and Maintenance (OAM) & Management of Application-Layer Traffic Optimization (ALTO) Protocol. The basic purpose of this YANG data model is discussed in Section 16 of . The operator can use the data model to create and update ALTO information resources, manage the access control, configure server-to-server communication and server discovery, and collect statistical data. The basic structure of this YANG data model is guided by Section 16 of and . Although the scope of the YANG data model in this document mainly focuses on the support of the base ALTO protocol and the existing ALTO standard extensions (including , and ), the design will also be extensible for future standard extensions (e.g., , , , and ).

Requirements Language 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. When the words appear in lower case, they are to be interpreted with their natural language meanings.

Terminology This document uses the following acronyms:

• OAM - Operations, Administration, and Maintainance
• O&M - OAM and Management

Tree Diagrams A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is defined in .

Prefixes in Data Node Names In this document, names of data nodes and other data model objects are often used without a prefix, as long as it is clear from the context in which YANG module each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in . Prefixes and corresponding YANG modules

Prefix	YANG module	Reference
yang	ietf-yang-types
inet	ietf-inet-types
key-chain	ietf-key-chain

Design Scope and Requirements

Scope of Data Model for ALTO O&M What is in the scope of this document?

• Data model for deploy an ALTO server/client.
• Data model for operate and manage a running ALTO server/client.
• Data model for functionality/capability configuration for ALTO services.
• Data model for monitoring ALTO-related performance metrics.

What is not in the scope of this document? This document does not define any data model related to specific implementation, including:

• Data structures for how to store/deliver ALTO information resources (e.g., database schema to store a network map).
• Data structures for how to store information collected from data sources. (e.g., database schema to store topology collected from an Interface to the Routing System (I2RS) client )

Basic Requirements Based on discussions and recommendations in and , the data model provided by this document satisfies basic requirements listed in . Basic Requirements of Data Model for ALTO O&M.

Requirement	Reference
R1: The data model should support configuration for ALTO server setup.	Section 16.1 of
R2: The data model should provide logging management.	Section 16.2.1 of
R3: The data model should provide ALTO-related management information.	Section 16.2.2 of
R4: The data model should provide metrics for server failures.	Section 16.2.3 of , Section 3.3 of
R5-1: The data model should support configuration for different data sources.	Section 16.2.4 of , Section 3.2 of
R5-2: The data model should support configuration for information resource generation algorithms.	Section 16.2.4 of
R5-3: The data model should support configuration for access control at information resource level.	Section 16.2.4 of
R6: The data model should provide performance monitoring for ALTO-specific metrics.	Section 16.2.5 of , Section 3.4 of
R7: The data model should support configuration for security policy management.	Section 16.2.6 of

Additional Requirements for Extensibility R8: As the ALTO protocol is extensible, the data model for ALTO O&M should allow for augmentation to support potential future extensions.

Overview of ALTO O&M Data Model for Reference ALTO Architecture shows a reference architecture for ALTO server implementation and YANG modules that server components implement. The server manager, information resource manager and data source listeners need to implement ietf-alto.yang (see ). The performance monitor and logging and fault manager need to implement ietf-alto-stats.yang (see ). The data broker and algorithm plugins are not in the scope of the data model defined in this document. But user specified YANG modules can be applied to different algorithm plugins by augmenting the data model defined in this document (see ).

A Reference ALTO Server Architecture and YANG Modules . Algorithm Plugin: . . Data Broker . read . example-ietf-alto-alg.yang . ............... .............................. ^ | write +----------------+ Southbound ++=============++ | Data Source | API || || | Listener: | <==========> || Data Source || | ietf-alto.yang | || || +----------------+ ++=============++ ]]>

Design of ALTO O&M Data Model

Overview of ALTO O&M Data Model The ietf-alto module defined in this document provide all the basic ALTO O&M data models fitting the requirements listed in . The container "alto-server" in the ietf-alto module contains all the configured and operational parameters of the adminstrated ALTO server instance. NOTE: So far, the ALTO YANG module only focuses on the ALTO server related configuration. The ALTO client related configuration will be added in a future version of the document.

Meta Information of ALTO Server The ALTO server instance contains the following basic configurations for the server setup. The "listen" contains all the configurations for the whole server listen stack across HTTP layer, TLS layer and TCP layer. TODO: A "base-uri" for ALTO clients to access may still be needed. The "cost-type" list is the registry for the cost types that can be used in the ALTO server. The "meta" list contains the customized meta data of the ALTO server. It will be populated into the meta field of the default Information Resource Directory (IRD). TODO: As suggested by and , the configuration related to ALTO server discovery should also be included here.

ALTO Information Resources Configuration Management The ALTO server instance contains a list of resource entries. Each resource entry contains the configurations of an ALTO information resource (See Section 8.1 of ). The operator of the ALTO server can use this model to create, update, and remove the ALTO information resource. Each resoruce entry provide configuration defining how to create or update an ALTO information resource. Adding a new resource entry will submit an ALTO information resource creation intent to the intent system to create a new ALTO information resource. Updating an existing resource entry will update the corresponding ALTO information resource creation intent. Removing an existing resource entry will remove the corresponding ALTO information resource creation intent and also the created ALTO information resource. The parameter of the intent interface defined by a resource entry MUST include a unique resource-id and a resource-type. It can also include an accepted-group node containing a list of user-groups that can access this ALTO information resource. As section 15.5.2 of suggests, the module also defines authentication related configuration to employ access control at information resource level. The ALTO server returns the IRD to the ALTO client based on its authentication information. For some resource-type, the parameter of the intent interface MUST also include the a dependency node containing the resource-id of the dependent ALTO information resources (See Section 9.1.5 of ). For each type of ALTO information resource, the creation intent MAY also need type-specific parameters. These type-specific parameters include two categories:

1. One categories of the type-specific parameters are common for the same type of ALTO information resource. They declare the Capabilities of the ALTO information resource (See Section 9.1.3 of ).
2. The other categories of the type-specific parameters are algorithm-specific. The developer of the ALTO server can implement their own creation altorithms and augment the algorithm node to declare algorithm-specific input parameters.

Except for the ird resource, all the other types of resource entries have augmented algorithm node. The augmented algorithm node can reference data sources subscribed by the data-source entries (See ). The developer cannot customize the creation algorithm of the ird resource. The default ird resource will be created automatically based on all the added resource entries. The delegated ird resource will be created as a static ALTO information resource (See Section 9.2.4 of ).

Data Sources The ALTO server instance contains a list of data-source entries to subscribe the data sources from which ALTO information resources are derived (See Section 16.2.4 of ). A data-source entry MUST include:

• a unique source-id for resource creation algorithms to reference,
• the source-type attribute to declare the type of the data source,
• the update-policy to specify how to get the data update from the data source,
• the source-params to specify where and how to query the data.

The update policy can be either reactive or proactive. For the reactive update, the ALTO server gets the update as soon as the data source changes. For the proactive update, the ALTO server has to proactively fetch the data source periodically. To use the reactive update, the reactive attribute MUST be set true. To use the proactive update, the poll-interval attribute MUST be greater than zero. The value of poll-interval specifies the interval of fetching the data in milliseconds. If reactive is false or poll-interval is zero, the ALTO server will not update the data source. The data-source/source-params node can be augmented for different types of data sources. This data model only includes import interfaces for a list of predefined data sources. More data sources can be supported by future documents and other third-party providers. Note: Current source configuration still has limitations. It should be revised to support more general southbound and data retrieval mechanisms.

Yang DataStore Data Source The yang-datastore-source-params is used to import the YANG data from a YANG model-driven data store. It supports two types of endpoints: local and remote.

• For a local endpoint, the YANG data is located the data from the same YANG model-driven data store supplying the current ALTO O&M data model. Therefore, the ALTO data source listener retrieves the data using the internal API provided by the data store.
• For a remote endpoint, the ALTO data source listener establishes an HTTP connection to the remote RESTCONF server, and retrieve the data using the RESTCONF API.

The source-path is used to specify the XPath of the data source node.

Prometheus Data Source The prometheus-source-params is used to import common performance metrics data which is provided by a Prometheus server. The source-uir is used to establish the connection with the Prometheus server. The query-data is used to speficify the potential query expression in PromQL.

Model for ALTO Server-to-server Communication In practice, multiple ALTO servers can be deployed for scalability. That may require communication among different ALTO servers. The YANG module defined in this document contains the configuration for the communication between two ALTO servers. TODO: this is still under the open discussion status.

Design of ALTO O&M Statistics Data Model

Model for ALTO Logging and Fault Management As section 16.2.1 and section 16.2.3 of suggest, the YANG data module defined in this document contains statistics for logging and failure detection. NOTE: The detailed YANG module will appear in the future version.

Model for ALTO-specific Performance Monitoring As section 16.2.5 of suggests, the YANG data module defined in this document also contains statistics for ALTO-specific performance metrics. More specifically, this data model contains the following measurement information suggested by :

• Measurement of impact
  • Total amount and distribution of traffic
  • Application performance
• System and service performance
  • Requests and responses for each information resource
  • CPU and memory utilization
  • ALTO map updates
  • Number of PIDs
  • ALTO map sizes

Besides the measurement information suggested by , this data model also contains useful measurement information for other ALTO extensions:

• Number of generic ALTO entities (for and )
• Statistics for update sessions and events (for )
• Statistics for calendar (for )

The module, "ietf-alto-stats", augments the ietf-alto module to include statistics at the ALTO server and information resource level.

Extension of ALTO O&M Data Model As ALTO protocol is extensible, new protocol extensions can be developed after this data model is published. To support future ALTO protocol extensions, the extension documents can augment the existing cases of the resource-params choice with new configuration parameters for existing ALTO information resource extensions, or augment the resource-params with new cases for new ALTO information resources. Developers and operators can also extend this ALTO O&M data model to align with their own implementations. Specifically, the following nodes of the data model can be augmented:

• The algorithm choice of the resource-params of each resource.
• The data-source choice.

The following example shows how the developer augments the algorithm choice of alto-networkmap-params with a creation algorithm for the network map resource. /alto:alto-server/data-source/source-id +--rw depth? uint32 ]]> This example defines a creation algorithm called l3-unicast-cluster-algorithm for the network map resource. It takes two algorithm-specific parameters:

l3-unicast-topo

This parameter refers to the source id of a data source node subscribed in the data-source list (See ). The corresponding data source is assumed to be an internel data source (See ) for an IETF layer 3 unicast topology defined in . The algorithm uses the topology data from this data source to compute the ALTO network map resource.

depth

This optional parameter sets the depth of the clustering algorithm. For example, if the depth sets to 1, the algorithm will generate PID for every l3-node in the topology.

The creation algorithm can be reactively called once the referenced data source updates. Therefore, the ALTO network map resource can be updated dynamically. The update of the reference data source depends on the used update-policy (See ).

ALTO OAM YANG Module

The ietf-alto Module WG List: "; description "This YANG module defines all the configured and operational parameters of the administrated ALTO server instance. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision "2022-07-11" { description "Initial Version."; reference "RFC XXXX: A YANG Data Model for OAM and Management of ALTO Protocol."; } typedef resource-id { type string { length "1..64"; pattern "[0-9a-zA-Z\\-:@_]*"; } description "Format of Resource ID"; reference "Section 9.1.1 of RFC 7285."; } // Base identities identity resource-type { description "Base identity for type of information resource."; } identity source-type { description "Base identity for type of data source."; } identity cost-mode { description "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."; reference "Section 6.1.2 of RFC 7285."; } identity cost-metric { description "The cost metric attribute indicates what the cost represents."; reference "Section 6.1.1 of RFC 7285."; } // Identities for ALTO information resources identity network-map { base resource-type; description "Identity for network map."; } identity cost-map { base resource-type; description "Identity for cost map."; } identity property-map { base resource-type; description "Identity for property map."; } // Identities for predefined data sources identity yang-datastore { base source-type; description "Identity for data source of YANG-based datastore."; } identity prometheus { base source-type; description "Identity for data source of prometheus system."; } // Identities for cost mode identity numerical { base cost-mode; description "This mode indicates that it is safe to perform numerical operations"; } identity ordinal { base cost-mode; description "This mode indicates that the cost values in a cost map represent ranking"; } identity array { if-feature "path-vector"; base cost-mode; description "This mode indicates that every cost value in the response body of a (Filtered) Cost Map or an Endpoint Cost Service MUST be interpreted as a JSON array."; } // Identities for cost metrics identity routingcost { base cost-metric; description "This metric conveys a generic measure for the cost of routing traffic from a source to a destination."; } identity ane-path { if-feature "path-vector"; base cost-metric; description "This metric indicates that the value of such a cost type conveys an array of Abstract Network Element (ANE) names, where each ANE name uniquely represents an ANE traversed by traffic from a source to a destination."; } identity delay-ow { if-feature "performance-metrics"; base cost-metric; description "Section 4.1 of RFC XXXX"; } identity delay-rt { if-feature "performance-metrics"; base cost-metric; description "Section 4.2 of RFC XXXX"; } identity delay-variation { if-feature "performance-metrics"; base cost-metric; description "Section 4.3 of RFC XXXX"; } identity lossrate { if-feature "performance-metrics"; base cost-metric; description "Section 4.4 of RFC XXXX"; } identity hopcount { if-feature "performance-metrics"; base cost-metric; description "Section 4.5 of RFC XXXX"; } identity tput { if-feature "performance-metrics"; base cost-metric; description "Section 5.1 of RFC XXXX"; } identity bw-residual { if-feature "performance-metrics"; base cost-metric; description "Section 5.2 of RFC XXXX"; } identity bw-available { if-feature "performance-metrics"; base cost-metric; description "Section 5.3 of RFC XXXX"; } // Features feature http-listen { description "The 'http-listen' feature is only used for test depolyment. According to Sec 8.3.5 of RFC 7285, it shouldn't be used in the production depolyment."; } feature multi-cost { description "Support multi-cost extension."; reference "RFC 8189: Multi-Cost Application-Layer Traffic Optimization (ALTO)"; } feature incr-update { description "Support incremental update extension."; reference "RFC 8895: Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)"; } feature cost-calendar { description "Support cost calendar extension."; reference "RFC 8896: Application-Layer Traffic Optimization (ALTO) Cost Calendar"; } feature propmap { description "Support entity property map extension."; reference "RFC 9240: An ALTO Extension: Entity Property Maps"; } feature cdni { description "Support CDNi extension."; reference "RFC 9241: Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO"; } feature path-vector { description "Support path vector extension."; reference "RFC XXXX: An ALTO Extension: Path Vector"; } feature performance-metrics { description "Support performance metrics extension."; reference "RFC XXXX: ALTO Performance Cost Metrics"; } // Groupings grouping filt-costmap-cap { description "This grouping defines data model for FilteredCostMapCapabilities."; reference "Sec 11.3.2.4 of RFC 7285."; leaf-list cost-type-names { type string; min-elements 1; description "Supported cost types"; } leaf cost-constraints { type boolean; description "If true, then the ALTO server allows cost constraints to be included in requests to the corresponding URI. If not present, this field MUST be interpreted as if it specified false."; } leaf max-cost-types { if-feature "multi-cost"; type uint32; default 0; description "If present with value N greater than 0, this resource understands the multi-cost extensions in this document and can return a multi-cost map with any combination of N or fewer cost types in the 'cost-type-names' list. If omitted, the default value is 0."; } leaf-list testable-cost-type-names { if-feature "multi-cost"; type string; description "If present, the resource allows constraint tests, but only on the cost type names in this array."; } container calendar-attributes { if-feature "cost-calendar"; leaf-list cost-type-names { type string; min-elements 1; description "An array of one or more elements indicating the cost type names in the IRD entry to which the values of 'time-interval-size' and 'number-of-intervals' apply."; } leaf time-interval-size { type decimal64 { fraction-digits 4; } mandatory true; description "The duration of an ALTO Calendar time interval in a unit of seconds."; } leaf number-of-intervals { type uint32 { range "1..max"; } mandatory true; description "A strictly positive integer (greater or equal to 1) that indicates the number of values of the Cost Calendar array."; } description "Configuration for CalendarAttributes."; reference "Section 4.1 of RFC 8896."; } } grouping algorithm { choice algorithm { mandatory true; description "Information resource creation algorithm to be augmented."; } description "This grouping defines base data model for information resource creation algorithm."; } grouping alto-server-grouping { description "A reuseable grouping for configuring an ALTO server without any consideration for how underlying transport sessions are established."; // TODO: ALTO specific server-level configuration } grouping alto-server-listen-stack-grouping { description "A reuseable grouping for configuring an ALTO server 'listen' protocol stack for a single connection."; choice transport { mandatory true; description "Selects between available transports."; case http { if-feature "http-listen"; container http { description "Configures ALTO server stack assuming that TLS-termination is handled externally."; container tcp-server-parameters { description "A wrapper around the TCP server parameters to avoid name collisions."; uses tcp:tcp-server-grouping { refine "local-port" { default "80"; description "The RESTCONF server will listen on the IANA- assigned well-known port value for 'http' (80) if no value is specified."; } } } container http-server-parameters { description "A wrapper around the HTTP server parameters to avoid name collisions."; uses http:http-server-grouping; } container alto-server-parameters { description "A wrapper around the ALTO server parameters to avoid name collisiions."; uses alto-server-grouping; } } } case https { container https { description "Configures ALTO server stack assuming that TLS-termination is handled internally."; container tcp-server-parameters { description "A wrapper around the TCP server parameters to avoid name collisions."; uses tcp:tcp-server-grouping { refine "local-port" { default "443"; description "The ALTO server will listen on the IANA- assigned well-known port value for 'https' (443) if no value is specified."; } } container tls-server-parameters { description "A wrapper around the TLS server parameters to avoid name collisions."; uses tls:tls-server-grouping; } container http-server-parameters { description "A wrapper around the HTTP server parameters to avoid name collisions."; uses http:http-server-grouping; } container alto-server-parameters { description "A wrapper around the ALTO server parameters to avoid name collisions."; uses alto-server-grouping; } } } } } } // Top-level container container alto-server { description "The ALTO server instance."; container listen { description "Configure the ALTO server to listen for ALTO clients."; uses alto-server-listen-stack-grouping; } list cost-type { key "cost-type-name"; leaf cost-type-name { type string; description "The name to reference cost type"; } leaf cost-mode { type identityref { base cost-mode; } mandatory true; description "The referenced cost mode"; } leaf cost-metric { type identityref { base cost-metric; } mandatory true; description "The referenced cost metric"; } description "Mapping between name and referenced cost type"; } list meta { key "meta-key"; leaf meta-key { type string; description "Custom meta key"; } leaf meta-value { type string; mandatory true; description "Custom meta value"; } description "Mapping of custom meta information"; reference "Section 8.4.1 of RFC 7285."; } list resource { key "resource-id"; leaf resource-id { type resource-id; description "resource-id to be defined."; } leaf resource-type { type identityref { base resource-type; } mandatory true; description "identityref to be defined."; } leaf description { type string; description "The optional description for this information resource."; } leaf-list accepted-group { type string; description "Access list for authenticated clients."; } leaf-list dependency { type resource-id; description "A list of dependent information resources."; } container auth { description "The authentication options"; choice auth-type-selection { description "Options for expressing authentication setting."; case auth-key-chain { leaf key-chain { type key-chain:key-chain-ref; description "key-chain name."; } } case auth-key { } case auth-tls { } } } choice resource-params { description "Resource-specific configuration."; case ird { container alto-ird-params { leaf delegation { type inet:uri; mandatory true; description "Upstream IRD to be delegated"; } description "IRD-specific configuration"; } } case networkmap { container alto-networkmap-params { description "(Filtered) Network Map specific configuration"; reference "Section 11.2.1 and Section 11.3.1 of RFC 7285."; leaf is-default { type boolean; description "Set whether this is the default network map"; } leaf filtered { type boolean; default false; description "Configure whether filtered network map is supported."; } uses algorithm; } } case costmap { container alto-costmap-params { description "(Filtered) Cost Map specific configuration"; reference "Section 11.2.2 and Section 11.3.2 of RFC 7285."; leaf filtered { type boolean; description "Configure whether filtered cost map is supported."; } uses filt-costmap-cap; uses algorithm; } } case endpointcost { container alto-endpointcost-params { description "Endpoint Cost Service specific configuration"; reference "Section 11.5 of RFC 7285"; uses filt-costmap-cap; uses algorithm; } } case endpointprop { container alto-endpointprop-params { description "Endpoint Cost Service specific configuration"; reference "Section 11.5 of RFC 7285"; leaf-list prop-types { type string; min-elements 1; description "Supported endpoint properties."; } uses algorithm; } } case propmap { if-feature "propmap"; container alto-propmap-params { uses algorithm; description "(Filtered) Entity Property Map specific configuration"; } } case cdni { if-feature "cdni"; container alto-cdni-params { uses algorithm; description "CDNi specific configuration"; } } case update { if-feature "incr-update"; container alto-update-params { uses algorithm; description "Incremental Updates specific configuration"; } } } description "ALTO information resources to be defined"; } list data-source { key "source-id"; leaf source-id { type string; description "Data source id that can be referenced by information resource creation algorithms."; } leaf source-type { type identityref { base source-type; } mandatory true; description "Source-type to be defined"; } choice update-policy { mandatory true; case reactive { leaf reactive { type boolean; mandatory true; description "Reactive mode"; } } case proactive { leaf poll-interval { type uint32; mandatory true; description "Polling interval in seconds for proactive mode"; } } description "Policy to get updates from data sources"; } choice source-params { case yang-datastore { container yang-datastore-source-params { leaf source-path { type yang:xpath1.0; mandatory true; description "XPath to subscribed YANG datastore node"; } description "YANG datastore specific configuration"; choice restconf-endpoint { case local { // Use local API to access YANG datastore } case remote { container restconf-endpoint-params { uses rcc:restconf-client-listen-stack-grouping; } } } } } case prometheus { container prometheus-source-params { leaf source-uri { type inet:uri; mandatory true; description "URI to prometheus agent"; } leaf query-data { type string; description "Query expression"; } description "Prometheus specific configuration"; } } description "Data source specific configuration"; } description "List of subscribed data sources."; } } } ]]>

The ietf-alto-stats Module WG List: "; description "This YANG module defines all the configured and operational parameters of the administrated ALTO server instance. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; revision "2022-07-11" { description "Initial Version."; reference "RFC XXXX: A YANG Data Model for Operations, Administration, and Maintenance of ALTO Protocol."; } augment "/alto:alto-server" { description "Top-level statistics for the whole ALTO server."; leaf num-total-req { type yang:counter32; config false; description "The total number of ALTO requests received by this ALTO server."; } leaf num-total-succ { type yang:counter32; config false; description "The total number of successful responses sent by this ALTO server."; } leaf num-total-fail { type yang:counter32; config false; description "The total number of failed responses sent by this ALTO server."; } leaf num-total-last-req { type yang:counter32; config false; description "The total number of ALTO requests received within the last 5 minutes."; } leaf num-total-last-succ { type yang:counter32; config false; description "The total number of successful responses sent by this ALTO server within the last 5 minutes."; } leaf num-total-last-fail { type yang:counter32; config false; description "The total number of failed responses sent by this ALTO server within the last 5 minutes."; } } augment "/alto:alto-server/alto:resource" { description "Common statistics for each information resource."; leaf num-res-upd { type yang:counter32; config false; description "The number of version updates since the information resource was created."; } leaf res-mem-size { type yang:counter32; config false; description "Memory size (Bytes) utilized by the information resource."; } leaf res-enc-size { type yang:counter32; config false; description "Size (Bytes) of JSON encoded data of the information resource."; } leaf num-res-req { type yang:counter32; config false; description "The number of ALTO requests to this information resource."; } leaf num-res-succ { type yang:counter32; config false; description "The number of successful responses for requests to this information resource."; } leaf num-res-fail { type yang:counter32; config false; description "The total number of failed responses for requests to this information resource."; } } augment "/alto:alto-server/alto:resource/alto:resource-params" + "/alto:networkmap/alto:alto-networkmap-params" { description "Augmented statistics for network maps only."; leaf num-map-pid { type yang:counter32; config false; description "Number of PIDs contained by the network map."; } } augment "/alto:alto-server/alto:resource/alto:resource-params" + "/alto:propmap/alto:alto-propmap-params" { description "Augmented statistics for property maps only."; leaf num-map-entry { type yang:counter32; config false; description "Number of ALTO entities contained by the property map."; } } augment "/alto:alto-server/alto:resource/alto:resource-params" + "/alto:cdni/alto:alto-cdni-params" { description "Augmented statistics for CDNi resources only."; leaf num-base-obj { type yang:counter32; config false; description "Number of base CDNi advertisement objects contained by the CDNi resource."; } } augment "/alto:alto-server/alto:resource/alto:resource-params" + "/alto:update/alto:alto-update-params" { description "Augmented statistics for incremental updates only."; leaf num-upd-sess { type yang:counter32; config false; description "Number of sessions connected to the incremental update service."; } leaf num-event-total { type yang:counter32; config false; description "Total number of update events sent to all the connected clients."; } leaf num-event-max { type yang:counter32; config false; description "The maximum number of update events sent to the connected clients."; } leaf num-event-min { type yang:counter32; config false; description "The minimum number of update events sent to the connected clients."; } leaf num-event-avg { type yang:counter32; config false; description "The average number of update events sent to the connected clients."; } } } ]]>

Security Considerations TBD.

IANA Considerations This document registers two URIs in the "IETF XML Registry" . Following the format in RFC 3688, the following registrations are requested. This document registers two YANG modules in the "YANG Module Names" registry . [RFC Editor: Please replace RFCthis with the published RFC number for this document.]

References Normative References 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. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. 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. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers. This document specifies a procedure for resource-consumer-initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer. 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. This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. The Application-Layer Traffic Optimization (ALTO) protocol, specified in RFC 7285, defines several services that return various metrics describing the costs between network endpoints. This document defines a new service that allows an ALTO Client to retrieve several cost metrics in a single request for an ALTO filtered cost map and endpoint cost map. In addition, it extends the constraints to further filter those maps by allowing an ALTO Client to specify a logical combination of tests on several cost metrics. This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers that can provide suitable guidance. In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be necessary to discover an ALTO server outside of the ALTO client's own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery. Technically, the procedure specified in this document takes one IP address or prefix and a U-NAPTR Service Parameter (typically, "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the "in-addr.arpa." or "ip6.arpa." trees) and returns one or more URIs of information resources related to that IP address or prefix. The Application-Layer Traffic Optimization (ALTO) protocol (RFC 7285) provides network-related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available. This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO cost information service so that applications decide not only 'where' to connect but also 'when'. This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. This extension introduces the ALTO Cost Calendar with which an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval. The time intervals, as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses. Informative References This document describes the IETF architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. It describes the high-level architecture, the building blocks of this high-level architecture, and their interfaces, with particular focus on those to be standardized as part of the Interface to the Routing System (I2RS). Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. This memo discusses deployment-related issues of ALTO. It addresses different use cases of ALTO such as peer-to-peer file sharing and Content Delivery Networks (CDNs) and presents corresponding examples. The document also includes recommendations for network administrators and application designers planning to deploy ALTO, such as recommendations on how to generate ALTO map information. This document defines a YANG data model for Layer 3 network topologies. 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. Nokia Bell Labs Nokia Bell Labs Yale University Tongji University Sichuan University This document specifies an extension to the base Application-Layer Traffic Optimization (ALTO) protocol that generalizes the concept of "endpoint properties", which were so far tied to IP addresses, to entities defined by a wide set of objects. Further, these properties are presented as maps, similar to the network and cost maps in the base ALTO protocol. While supporting the endpoints and related endpoint property service defined in RFC7285, the ALTO protocol is extended in two major directions. First, from endpoints restricted to IP addresses to entities covering a wider and extensible set of objects; second, from properties on specific endpoints to entire entity property maps. These extensions introduce additional features allowing entities and property values to be specific to a given information resource. This is made possible by a generic and flexible design of entity and property types. Huawei Yale University Samsung Huawei Nokia Bell Labs Telefonica The cost metric is a basic concept in Application-Layer Traffic Optimization (ALTO), and different applications may use different types of cost metrics. Since the ALTO base protocol (RFC 7285) defines only a single cost metric (namely, the generic "routingcost" metric), if an application wants to issue a cost map or an endpoint cost request in order to identify a resource provider that offers better performance metrics (e.g., lower delay or loss rate), the base protocol does not define the cost metric to be used. This document addresses this issue by extending the specification to provide a variety of network performance metrics, including network delay, delay variation (a.k.a, jitter), packet loss rate, hop count, and bandwidth. There are multiple sources (e.g., estimation based on measurements or service-level agreement) to derive a performance metric. This document introduces an additional "cost-context" field to the ALTO "cost-type" field to convey the source of a performance metric. HFT Stuttgart - Univ. of Applied Sciences Yale University Ericsson NeuStar Tongji University The Content Delivery Networks Interconnection (CDNI) framework in RFC 6707 defines a set of protocols to interconnect CDNs to achieve multiple goals, including extending the reach of a given CDN. A CDNI Request Routing Footprint & Capabilities Advertisement interface (FCI) is needed to achieve the goals of a CDNI. RFC 8008 defines the FCI semantics and provides guidelines on the FCI protocol, but the exact protocol is not specified. This document defines a new Application-Layer Traffic Optimization (ALTO) service, called "CDNI Advertisement Service", that provides an implementation of the FCI, following the guidelines defined in RFC 8008.

Example Module for Information Resource Creation Algorithm The base data model defined by ietf-alto.yang does not include any choice cases for information resource creation algorithms. But developers may augment the ietf-alto.yang data model with definitions for any custom creation algorithms for different information resources. The following example module demonstrates the parameters of a network map creation algorithm that translates an IETF layer 3 unicast topology into a network map.

Acknowledgements The authors thank Qiufang Ma and Qin Wu for their help with drafting the initial version of the YANG modules. Thanks also to Adrian Farrel, Qiao Xiang, Qin Wu, and Qiufang Ma for their reviews and valuable feedback.