]> 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 Sichuan 610000 China kaigao@scu.edu.cn

Deutsche Telekom

Ida-Rhodes-Straße 2 Darmstadt 64295 Germany Roland.Schott@telekom.de

Huawei

101 Software Avenue, Yuhua District Nanjing Jiangsu 210012 China maqiufang1@huawei.com

Networks ALTO WG Automation, Service Provisioning, Control, Operation This document defines a YANG data model for Operations, Administration, and Maintenance (OAM) & Management of the Application-Layer Traffic Optimization (ALTO) Protocol. The operator of an ALTO server can use this data model to (1) set up the ALTO server, (2) configure server discovery, (3) create, update and remove ALTO information resources, (4) manage the access control of each ALTO information resource, and (5) collect statistical data from the ALTO server. The application provider can also use this data model to configure ALTO clients to communicate with known ALTO servers. 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 of an ALTO server can use this data model to:

• set up the ALTO server,
• configure server discovery,
• create, update and remove ALTO information resources,
• manage the access control of each ALTO information resource,
• collect statistical data of the ALTO server.

The application provider can also use this data model to configure ALTO clients to communicate with known ALTO servers. describes what is and is not in scope. and define more concrete requirements for the data model. 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: , , , , , , and . The detailed design of the data model is illustrated in and . Some examples of how to extend this data model for specific ALTO server implementations are shown in .

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.

Acronyms and Abbreviations This document uses the following acronyms:

ALTO:

Application-Layer Traffic Optimization

CPU:

Central Processing Unit

DNS:

Domain Name System

HTTP:

Hypertext Transfer Protocol

IRR:

Internet Routing Registry

OAM:

Operations, Administration, and Maintenance (Section 3 of )

O&M:

OAM and Management (Section 3 of )

OAuth:

Open Authorization

PID:

Provider-defined Identifier in ALTO

TCP:

Transmission Control Protocol

TLS:

Transport Layer Security

URI:

Uniform Resource Identifier

Tree Diagrams The meaning of the symbols in the tree diagrams is defined in .

Prefixes in Data Node Names The complete name of a data node or data model object includes a prefix, which indicates the YANG module in which the name is defined. In this document, the prefix is omitted when the YANG module is clear from the context; otherwise, the prefix is included. The prefixes indicating the corresponding YANG modules are shown in . Prefixes and corresponding YANG modules

Prefix	YANG module	Reference
yang	ietf-yang-types
inet	ietf-inet-types
ds	ietf-datastores
yp	ietf-yang-push
tcp	ietf-tcp-server
tls	ietf-tls-server
http	ietf-http-server
ncc	ietf-netconf-client
rcc	ietf-restconf-client

Placeholders in Reference Statements Note to the RFC Editor: This section is to be removed prior to publication. This document contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Please apply the following replacements:

• DDDD --> the assigned RFC number for
• FFFF --> the assigned RFC number for
• GGGG --> the assigned RFC number for
• HHHH --> the assigned RFC number for
• IIII --> the assigned RFC number for
• XXXX --> the assigned RFC number for this draft
• YYYY --> the assigned RFC number for

Design Scope and Requirements

Scope of Data Models for ALTO O&M The following items are in the scope of the data models specified in this document:

• Deploying an ALTO server/client.
• Operating and managing an ALTO server/client.
• Configuring functionality/capability configuration of ALTO services.
• Monitoring ALTO-related performance metrics.

This document does not normatively define any data model related to a 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 )

For convenience, examples of how related extensions can be defined are provided in the Appendices.

Basic Requirements Based on recommendations in and , the data models provided by this document satisfy 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 support configuration for security policy management.	Section 16.2.6 of
R5-1: The data model should support basic configuration to receive data from 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 metrics for server failures.	Section 16.2.3 of , Section 3.3 of
R7: The data model should provide performance monitoring for ALTO-specific metrics.	Section 16.2.5 of , Section 3.4 of

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

Overview of ALTO O&M Data Models for ALTO Servers shows a sample architecture for an ALTO server implementation. It indicates the major server components that an ALTO server usually needs to include and the YANG modules that these server components need to implement.

• This section does not intend to impose an internal structure of server implementations, but is provided to exemplify how the various data model components can be used, including having provisions for future augmentations.

The following server components need to implement the 'ietf-alto' module ():

Server manager:

Provides the functionality and configuration of the server-level management, including server listen stack setup, server discovery setup, logging system configuration, global metadata, and server-level security configuration.

Information resource manager:

Provides the operation and management for creating, updating, and removing ALTO information resources.

Data source listener:

An ALTO server may start multiple data source listeners. Each data source listener defines a communication endpoint that can fetch ALTO-related information from data sources. The information can be either raw network/computation information or pre-processed ALTO-level information.

The following components need to implement the 'ietf-alto-stats' module () to provide statistics information:

Performance monitor:

Collects ALTO-specific performance metrics at a running ALTO server.

Logging and fault manager:

Collects runtime logs and failure events that are generated by an ALTO server and the service of each ALTO information resource.

The following components are also important for an ALTO server, although they are not in the scope of the data models defined in this document:

Data broker:

An ALTO server may implement a data broker to store network/computation information collected from data sources or cache some preprocessed data. The service of the ALTO information resource can read them from the data broker to calculate ALTO responses and return to ALTO clients.

Algorithm plugin:

The service of each ALTO information resource needs to configure an algorithm to decide how to calculate the ALTO responses. The algorithm plugins implement those algorithms. User-specified YANG modules can be applied to different algorithm plugins by augmenting the ALTO modules ().

Generally, the ALTO server components illustrated above have the following interactions with each other:

• Both the server manager and information resource manager will report statistics data to the performance monitor and the logging and fault manager.
• The algorithm plugins will register callbacks to the corresponding ALTO information resources upon configuration; Once an ALTO information resource is requested, the registered callback algorithm will be invoked.
• A data source listener will fetch data from the configured data source using the corresponding data source API in either proactive mode (polling) or reactive mode (subscription/publication).
• A data source listener will send the preprocessed data to a data broker.
• An algorithm plugin may read data from an optional data broker to calculate the ALTO information resource.

A Sample ALTO Server Architecture and ALTO YANG Modules || Data Source || | "ietf-alto" | || || +----------------+ ++=============++ ]]>

Design of ALTO O&M Data Model

Overview of ALTO O&M Data Model The "ietf-alto" module is designed to fit all the requirements listed in . As shown in , the top-level container 'alto' in the "ietf-alto" module contains a single 'alto-server' and a list 'alto-client'. 'alto-client' defines a list of configurations for other applications to bootstrap an ALTO client. These data nodes can also be used by data sources and information resource creation algorithms that are configured by an ALTO server instance. The container 'alto-server' contains both configuration and operational data of an administrated ALTO server instance.

IETF ALTO Tree Structure

Data Model for ALTO Client Operation and Management As shown in , the 'alto-client' contains a list of client-side configurations. Each 'alto-client' entry contains the following data nodes:

'client-id':

A unique identifier that can be referenced by other applications.

'server-discovery-client':

A container that is used to configure how this ALTO client discovers an ALTO server.

IETF ALTO Client Subtree Structure

Data Model for Server-level Operation and Management The ALTO server instance contains a set of data nodes for server-level operation and management for ALTO that are shown in . This structure satisfies R1 - R4 in .

IETF ALTO Server Level Subtree Structure

Data Model for ALTO Server Setup To satisfy R1 in , the ALTO server instance contains the basic data nodes for the server setup that are detailed in the following subsections.

ALTO Server Listen Stack The container 'listen' contains all the data nodes for the whole server listen stack across HTTP, TLS, and TCP layers ().

IETF ALTO Server Groupings Structure

ALTO Server Discovery Setup In practice, for a large-scale network consisting of multiple administrative domains, the information about the network may be partitioned and distributed over multiple ALTO servers. That may require discovery and communication among different ALTO servers. The "ietf-alto" module provides the configuration for how an ALTO server can be discovered by another ALTO server or client on demand (). However, it does not contain any configuration for the communication among ALTO servers because the related solution has not become a standard. Future documents may extend it to fully support multi-domain scenarios.

IETF ALTO Server Discovery Grouping Structure

The 'server-discovery' node provides configuration for the discovery of ALTO servers using a variety of mechanisms. The initial version of the "ietf-alto" module only defines the 'reverse-dns' case that is used to configure DNS NAPTR records for ALTO server discovery as sugested by and . It configures a set of endpoints that can be served by this ALTO server. The node contains two leaf lists. The 'static' list contains a list of manually configured endpoints. The 'dynamic' list points to a list of data sources to retrieve the endpoints dynamically. As suggested by and , the IP prefixes of the endpoints configured by both 'static' and 'dynamic' lists will be translated into DNS NAPTR resource records for server discovery. The 'server-discovery-manner' choice can be augmented by the future modules to support other mechanisms.

Data Model for Logging Management To satisfy R2 in , the ALTO server instance contains the the logging data nodes shown in . The 'logging-system' data node provides configuration to select a logging system to capture log messages generated by an ALTO server. By default, 'syslog' is the only supported logging system. When selecting 'syslog', the related configuration is delegated to the configuration file of the syslog server.

IETF ALTO Logging System Grouping Structure

A specific server implementation can extend the 'logging-system' node to add other logging systems.

Data Model for ALTO-related Management To satisfy R3 in , the data model contains the following ALTO-related management information ():

• 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 is populated into the meta field of the default Information Resource Directory (IRD).

Data Model for Security Management To satisfy R4 in , the data model leverages HTTP and TLS to provide basic security management for an ALTO server. All the related configurations are covered by the server listen stack.

Data Model for ALTO Server Configuration Management

Data Source Configuration Management To satisfy R5-1 in , the ALTO server instance contains a list of 'data-source' entries to subscribe the data sources from which ALTO information resources are derived (Section 16.2.4 of ).

IETF ALTO Server Data Source Subtree Structure

As shown in , a 'data-source' list entry includes:

• 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 reactively waits for the data source to push updates. For the proactive update, the ALTO server proactively fetches the data source periodically. Two publish modes are available to support reactive updates:

• If the 'on-change' attribute is present, the data source is expected to push the update as soon as the data source changes.
• Otherwise, if the 'feed-interval' attribute is present, the data source is expected to push the updates periodically. The value of 'feed-interval' specifies the interval of pushing the data change updates in milliseconds. If 'feed-interval' is zero, the data source is expected to work in the 'on-change' mode.

To use the proactive update, the 'poll-interval' attribute MUST be present. The value of 'poll-interval' specifies the interval of fetching the data in milliseconds. If 'poll-interval' is zero, the data source listener will not automatically fetch the data source periodically. In this case, a algorithm plugin can still call the data source listener to fetch the data at runtime. The 'data-source/source-params' node can be augmented for different types of data sources. This data model only includes common configuration parameters for an ALTO server to correctly interact with a data source. The implementation-specific parameters of any certain data source can be augmented in another module. An example is included in .

ALTO Information Resources Configuration Management To satisfy R5-2 and R-3 in , the ALTO server instance contains a list of 'resource' entries (). Each 'resource' entry contains the data nodes 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 resources. Each 'resource' entry provides data nodes defining how to create or update an ALTO information resource. Adding a new 'resource' entry notifies the ALTO server to create a new ALTO information resource. Updating an existing 'resource' entry notifies the ALTO server to update the generation parameters (e.g., capabilities and the creation algorithm) of an existing ALTO information resource. Removing an existing 'resource' entry will remove the corresponding ALTO information resource.

IETF ALTO Resource Subtree Structure

A 'resource' list entry MUST include a unique 'resource-id' and a 'resource-type'. It may also include an 'accepted-role' node containing a list of 'role-name's that is used by role-based access control for this ALTO information resource. See for details of information resource access control. For some 'resource-type', the 'resource' entry may also include a 'dependency' node containing the 'resource-id' of the dependent ALTO information resources (Section 9.1.5 of ). For each type of ALTO information resource, the 'resource' entry may also need type-specific parameters. These type-specific parameters can be split into two categories:

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

Except for the 'ird' resource, all the other types of 'resource' entries have an augmented 'algorithm' node. The augmented 'algorithm' node can reference data sources subscribed by the 'data-source' entries (See ). An example of extending the 'algorithm' node for a specific type of 'resource' is included in . The developer does not have to 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 (Section 9.2.4 of ). Each 'resource' entry may also set thresholds of memory usage and active update streams (if "incr-update" feature is enabled). describes limits that, once exceeded, will trigger notifications to be generated: Notification Thresholds.

Notification Threshold	Description
notify-res-mem-limit	Used to notify high memory utilization of the resource configured to an ALTO server instance. When exceeded, an alto-resource-event will be generated.
notify-upd-stream-limit	Used to notify a high number of active update streams that are serviced by an update resource configured to an ALTO server instance. When exceeded, an alto-resource-event will be generated.

ALTO Information Resource Access Control Management To satisfy R-3 in and as per Section 15.5.2 of , the "ietf-alto" module also defines authentication and authorization related configuration to employ access control at the information resource level. The ALTO server returns the IRD to the ALTO client based on its authentication information. The information resource access control is supported using the structure shown in .

IETF ALTO Client Authentication Subtree Structure

The structure shown in can be used to configure the role-based access control:

• 'auth-client' declares a list of ALTO clients that can be authenticated by the internal or external authorization server. This basic model only includes authentication approach directly provided by the HTTP server, but the operators or future documents can augment the 'authentication' choice for different authentication mechanisms.
• 'role' defines a list of roles for access control. Each role contains a list of authenticated ALTO clients. Each client can be assigned to multiple roles. The 'role-name' can be referenced by the 'accepted-role' list of a 'resource'. If an authenticated ALTO client is included in any roles with access permission to a resource, the client is granted access to that resource.

Design of ALTO O&M Statistics Data Model The "ietf-alto-stats" module augments the "ietf-alto" module to include statistics at the ALTO server and information resource level ().

IETF ALTO Statistics Structure

Model for ALTO Server Failure Monitoring To satisfy R6 in , the "ietf-alto-stats" module contains statistics that indicate server failures (). More specifically, 'num-total-*' and 'num-total-last-*' provide server-level failure counters; 'num-res-*' and 'num-res-last-*' provide information resource-level failure counters.

Model for ALTO-specific Performance Monitoring To satisfy R7 in ,the "ietf-alto-stats" module also contains statistics for ALTO-specific performance metrics (). More specifically, this data model contains the following measurement information of "system and service performance" suggested by and :

• Requests and responses for each information resource
• CPU and memory utilization
• ALTO map updates
• Number of PIDs
• ALTO map sizes

Besides the above measurement information suggested by and , the "ietf-alto-stats" module also contains useful measurement information for other ALTO extensions:

• 'num-map-entry' and 'num-base-obj' provide measurement for number of generic ALTO entities (for and )
• 'num-upd-stream' and 'num-upd-msg-*' provide statistics for update streams and messages (for )

The "ietf-alto-stats" module only focuses on the performance metrics that can be directly measured at the ALTO server. The following metrics for "measurement of the impact" suggested by are not contained in this data model:

• Total amount and distribution of traffic
• Application performance

ALTO OAM YANG Modules

The "ietf-alto" YANG Module WG List: "; description "This YANG module defines a set of configured and operational parameters of an administrated ALTO server instance. Copyright (c) 2023 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 2023-02-23 { description "Initial Version."; reference "RFC XXXX: YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol"; } // Features feature alto-client { description "Indicates that the implementation embeds an ALTO client instance."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol"; } feature alto-server { description "Indicates that the implementation embeds an ALTO server instance."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol"; } feature http-listen { description "The 'http-listen' feature is only used for test deployment. This feature shouldn't be used in the production deployment."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 8.3.5 "; } feature xdom-disc { description "Indicates support of cross-domain server discovery."; reference "RFC 8686: Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery"; } feature multi-cost { description "Indicates support of multi-cost extension."; reference "RFC 8189: Multi-Cost Application-Layer Traffic Optimization (ALTO)"; } feature incr-update { description "Indicates support of incremental update extension."; reference "RFC 8895: Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)"; } feature cost-calendar { description "Indicates support of cost calendar extension."; reference "RFC 8896: Application-Layer Traffic Optimization (ALTO) Cost Calendar"; } feature propmap { description "Indicates support of entity property map extension."; reference "RFC 9240: An ALTO Extension: Entity Property Maps"; } feature cdni { description "Indicates support of CDNi extension."; reference "RFC 9241: Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO"; } feature path-vector { description "Indicates support of path vector extension."; reference "RFC 9275: An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector"; } feature performance-metrics { description "Indicates support of performance metrics extension."; reference "RFC YYYY: ALTO Performance Cost Metrics"; } // Base identities identity resource-type { description "Base identity for type of information resource."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 8.1 "; } identity source-type { description "Base identity for type of data source. A data source indicates the origin from which the ALTO information resources are derived."; } identity cost-metric { description "The cost metric indicates what the cost represents."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 6.1.1"; } identity cost-mode { description "The cost mode indicates how costs should be interpreted. Specifically, the cost mode attribute indicates whether indicated costs should be interpreted as numerical values or ordinal rankings."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 6.1.2 RFC 9274: A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol"; } identity cost-source { description "The cost source indicates the high-level type of the data source."; reference "RFC YYYY: ALTO Performance Cost Metrics, Section 3.1"; } // Identities for ALTO information resources identity ird { base resource-type; description "Identity for information resource directory."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 9"; } identity network-map { base resource-type; description "Identity for network map."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 5"; } identity cost-map { base resource-type; description "Identity for cost map."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 6"; } identity endpoint-prop { base resource-type; description "Identity for endpoint property service."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 11.4.1"; } identity endpoint-cost { base resource-type; description "Identity for endpoint cost service."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 11.5.1"; } identity property-map { base resource-type; description "Identity for property map."; reference "RFC 9240: An ALTO Extension: Entity Property Maps"; } identity cdni { base resource-type; description "Identity for Content Delivery Network Interconnection (CDNI) advertisement service."; reference "RFC 9241: Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO"; } identity update { base resource-type; description "Identity for update stream service."; reference "RFC 8895: Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)"; } // Identities for cost mode identity numerical { base cost-mode; description "This mode indicates that it is safe to perform numerical operations"; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 6.1.2.1"; } identity ordinal { base cost-mode; description "This mode indicates that the cost values in a cost map represent ranking"; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 6.1.2.2"; } 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 is interpreted as a JSON array."; reference "RFC 9275: An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector, Section 6.5.2"; } // 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."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 6.1.1.1"; } 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."; reference "RFC 9275: An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector, Section 6.5.1"; } identity delay-ow { if-feature "performance-metrics"; base cost-metric; description "RFC YYYY: ALTO Performance Cost Metrics, Section 4.1"; } identity delay-rt { if-feature "performance-metrics"; base cost-metric; description "RFC YYYY: ALTO Performance Cost Metrics, Section 4.2"; } identity delay-variation { if-feature "performance-metrics"; base cost-metric; description "RFC YYYY: ALTO Performance Cost Metrics, Section 4.3"; } identity lossrate { if-feature "performance-metrics"; base cost-metric; description "RFC YYYY: ALTO Performance Cost Metrics, Section 4.4"; } identity hopcount { if-feature "performance-metrics"; base cost-metric; description "RFC YYYY: ALTO Performance Cost Metrics, Section 4.5"; } identity tput { if-feature "performance-metrics"; base cost-metric; description "RFC YYYY: ALTO Performance Cost Metrics, Section 5.1"; } identity bw-residual { if-feature "performance-metrics"; base cost-metric; description "RFC YYYY: ALTO Performance Cost Metrics, Section 5.2"; } identity bw-available { if-feature "performance-metrics"; base cost-metric; description "RFC YYYY: ALTO Performance Cost Metrics, Section 5.3"; } // Identities for cost sources identity nominal { if-feature "performance-metrics"; base cost-source; description "The 'nominal' category indicates that the metric value is statically configured by the underlying devices."; reference "RFC YYYY: ALTO Performance Cost Metrics, Section 3.1"; } identity sla { if-feature "performance-metrics"; base cost-source; description "The 'sla' category indicates that the metric value is derived from some commitment which this document refers to as service-level agreement (SLA)."; reference "RFC YYYY: ALTO Performance Cost Metrics, Section 3.1"; } identity estimation { if-feature "performance-metrics"; base cost-source; description "The 'estimation' category indicates that the metric value is computed through an estimation process."; reference "RFC YYYY: ALTO Performance Cost Metrics, Section 3.1"; } // Typedefs typedef resource-id { type string { length "1..64"; pattern '[0-9a-zA-Z\-:@_]*'; } description "Type for a resource ID that are used to reference an ALTO information resource."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 9.1.1"; } typedef cost-type-name { type string { length "1..max"; } description "Type for the name of a single CostType that can be referenced by other ALTO information resources."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 9.2.2"; } typedef meta-key { type string { length "1..max"; } description "Type for a custom meta key of an ALTO server."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 8.4.1"; } typedef endpoint-property { type union { type resource-specific-endpoint-property; type global-endpoint-property; } description "Type for an endpoint property."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 10.8"; } typedef resource-specific-endpoint-property { type string { length "1..97"; pattern '[0-9a-zA-Z\-:@_]*\.[0-9a-zA-Z\-:_]*'; } description "Type for a resource-specific endpoint property."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 10.8.1"; } typedef global-endpoint-property { type string { length "1..32"; pattern '[0-9a-zA-Z\-:_]*'; } description "Type for a global endpoint property."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 10.8.2"; } typedef source-id { type string { length "1..max"; } description "Type for a data source ID that are used to reference a data source."; } typedef role-name { type string { length "1..max"; } description "Type for a name of a role for role-based access control."; } // Typedefs for referencing purposes typedef cost-type-ref { type leafref { path "/alto:alto/alto:alto-server/alto:cost-type" + "/alto:cost-type-name"; } description "Type to reference a cost type name."; } typedef data-source-ref { type leafref { path "/alto:alto/alto:alto-server/alto:data-source" + "/alto:source-id"; } description "Type to reference a data source identifier."; } typedef http-user-id-ref { type leafref { path "/alto:alto/alto:alto-server/alto:listen" + "/alto:http/alto:http-server-parameters" + "/alto:client-authentication/alto:users" + "/alto:user/alto:user-id"; } description "Type to reference an HTTP client user id."; } typedef https-user-id-ref { type leafref { path "/alto:alto/alto:alto-server/alto:listen" + "/alto:https/alto:http-server-parameters" + "/alto:client-authentication/alto:users" + "/alto:user/alto:user-id"; } description "Type to reference an HTTPS client user id."; } typedef resource-ref { type leafref { path "/alto:alto/alto:alto-server/alto:resource" + "/alto:resource-id"; } description "Type to reference a resource identifier."; } typedef role-ref { type leafref { path "/alto:alto/alto:alto-server/alto:role" + "/alto:role-name"; } description "Type to reference a role."; } typedef client-ref { type leafref { path "/alto:alto/alto:alto-server/alto:auth-client" + "/alto:client-id"; } description "Type to reference an authenticated client."; } // Groupings grouping filter-costmap-cap { description "This grouping defines a data model for FilteredCostMapCapabilities."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 11.3.2.4"; leaf-list cost-type-name { type cost-type-ref; min-elements 1; description "Supported cost types."; } leaf cost-constraints { type boolean; default false; description "If set to true, then the ALTO server allows cost constraints to be included in requests to the corresponding URI."; } 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 and can return a multi-cost map with any combination of N or fewer cost types in the 'cost-type-names' list."; } leaf-list testable-cost-type-name { if-feature "multi-cost"; type cost-type-ref; 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"; description "Configuration for CalendarAttributes."; reference "RFC 8896: Application-Layer Traffic Optimization (ALTO) Cost Calendar, Section 4.1"; leaf-list cost-type-name { type cost-type-ref; 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; } units "seconds"; mandatory true; description "The duration of an ALTO Calendar time interval."; } 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."; } } } grouping algorithm { description "This grouping defines the base data model for information resource creation algorithm."; choice algorithm { mandatory true; description "Information resource creation algorithm to be augmented."; } reference "RFC XXXX: YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol, Section 5.4.2"; } grouping alto-server { description "A reuseable grouping for configuring an ALTO server without any consideration for how underlying transport sessions are established."; leaf base-uri { type inet:uri; description "The base URI for the ALTO server."; } } grouping alto-server-listen-stack { 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; } } } 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 alto-server-discovery { description "Grouping for the configuration of how to set up server discovery for clients or other ALTO servers to discovery the URI of this ALTO server."; choice method { description "Selects among available server discovery methods."; case reverse-dns { if-feature "xdom-disc"; description "Configures DNS NAPTR records for cross-domain ALTO server discovery using reverse DNS lookup."; reference "RFC 8686: Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery."; container rdns-naptr-records { description "Configuration parameters for DNS NAPTR records."; leaf-list static-prefix { type inet:ip-prefix; description "Specifies a list of static IP prefixes."; } leaf-list dynamic-prefix-source { type data-source-ref; description "Dynamic IP prefixes collected from data sources."; } } } } } grouping alto-server-discovery-client { description "Grouping for configuration of how a client can discover an ALTO server."; choice method { description "Selects among available server discovery methods."; case reverse-dns { if-feature "xdom-disc"; description "Uses reverse DNS lookup to discover an ALTO server."; reference "RFC 8686: Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery."; container rdns-params { description "Defines a set of parameters for reverse DNS lookups."; leaf-list dns-server { type inet:host; description "Provides a DNS server list for reverse DNS lookup."; } } } } } grouping alto-logging-system { description "Grouping for configuration of logging system used by the ALTO server."; choice logging-system { description "Selects among available logging systems."; case syslog { description "Specifies syslog as the logging system."; container syslog-params { description "Provides a set of syslog parameters."; leaf config-file { type inet:uri { pattern 'file:.*'; } description "Indicates the file location of the syslog configuration."; } } } } } // Top-level container container alto { presence "The ALTO service is enabled"; description "Indicates a set of parameters for both ALTO clients and servers. A single device can implement either alto-client or alto-server. No need to implement both."; list alto-client { if-feature alto-client; key "client-id"; description "The ALTO client configuration."; leaf client-id { type string; description "A unique identifier of a client that can be referenced by a data source or a resource creation algorithm to communicate with other ALTO servers."; } container server-discovery { description "Specifies a set of parameters for ALTO server discovery."; uses alto-server-discovery-client; } } container alto-server { if-feature alto-server; description "The ALTO server instance configuration."; container listen { description "Configure the ALTO server to listen for ALTO clients."; uses alto-server-listen-stack; } container server-discovery { description "Configures how the ALTO server to be discovered by others."; uses alto-server-discovery; } container logging-system { description "Configure logging system to capture log messages generated by the ALTO server."; uses alto-logging-system; } list cost-type { key "cost-type-name"; description "Mapping between name and referenced cost type."; leaf cost-type-name { type cost-type-name; description "The name to reference a 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."; } leaf description { type string; description "A human-readable description fo the 'cost-mode' and 'cost-metric'."; } container cost-context { if-feature "performance-metrics"; description "Context of how the metric is obtained."; leaf cost-source { type identityref { base cost-source; } mandatory true; description "The referenced cost source."; } container parameters { description "Additional computation parameters for the cost source."; choice parameters { description "Cases of parameters to be augmented."; } } } } list meta { key "meta-key"; description "Mapping of custom meta information"; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 8.4.1"; leaf meta-key { type meta-key; description "Custom meta key"; } leaf meta-value { type binary; mandatory true; description "Custom meta value encoded with the base64 encoding schema. The encoded value must be a valid JSON value."; } } list auth-client { key "client-id"; description "List of authenticated ALTO clients."; leaf client-id { type string; description "Identifier to reference an ALTO client."; } choice authentication { description "Choice of authentication methods to identify this ALTO client. If no authentication method is configured, the client must be ignored."; case http { description "The client is authenticated by the HTTP server."; container http-auth-client { if-feature "http-listen"; if-feature "http:client-auth-supported"; if-feature "http:local-users-supported"; description "Parameters of the authenticated HTTP client."; leaf user-id { type http-user-id-ref; mandatory true; description "Reference of the user-id for the authenticated HTTP client."; } } } case https { description "The client is authenticated by the HTTP server."; container https-auth-client { if-feature "http:client-auth-supported"; if-feature "http:local-users-supported"; description "Parameters of the authenticated HTTPS client."; leaf user-id { type https-user-id-ref; mandatory true; description "Reference of the user-id for the authenticated HTTPS client."; } } } } } list role { key "role-name"; description "List of roles for access control."; leaf role-name { type role-name; description "Name of a role for access control."; } leaf-list client { type client-ref; description "List of authenticated ALTO clients assigned to the role."; } } list data-source { key "source-id"; description "List of subscribed data sources."; leaf source-id { type source-id; description "Data source id that can be referenced by information resource creation algorithms."; } leaf source-type { type identityref { base source-type; } mandatory true; description "Identify the type of the data source."; } choice update-policy { mandatory true; description "Policy to get updates from data sources."; case reactive { description "Configuration for the data source listener to reactively subscribe data and wait for updates published by the data source."; choice publish-mode { description "Configuration for when the data source publish an update."; case on-change { description "The data source is requested to publish an update once the data has a change."; leaf on-change { type empty; mandatory true; description "Indicates an on-change subscription."; } } case periodic { description "The data source is requested to periodically publish an update."; leaf feed-interval { type uint32; units "seconds"; mandatory true; description "Specifies the duration of time that should occur between periodic push updates, in units of seconds. If it is set to zero, it is equivalent to the on-change mode."; } } } } case proactive { description "Configuration for the data source listener to proactively pull data from the data source."; leaf poll-interval { type uint32; units "seconds"; mandatory true; description "Polling interval in seconds for proactive mode. If it is set to zero, the data source listener will never pull data periodically. The data can still be pulled when an algorithm plugin of an information resource calls this data source listener. This can be useful for some on-demand settings."; } } } choice source-params { description "Data source specific configuration."; reference "RFC XXXX: YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol, Section 5.4.1"; } } list resource { key "resource-id"; description "ALTO information resources to be defined"; 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-role { type role-ref; description "Roles allowed to access this information resource."; } leaf-list dependency { type resource-ref; description "A list of dependent information resources."; } container alto-ird-params { when 'derived-from-or-self(../resource-type,' + '"alto:ird")'; description "IRD-specific configuration."; leaf delegation { type inet:uri; mandatory true; description "Upstream IRD to be delegated."; } } container alto-networkmap-params { when 'derived-from-or-self(../resource-type,' + '"alto:network-map")'; description "Filtered Network Map specific configuration."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Sections 11.2.1 and 11.3.1"; leaf is-default { type boolean; description "Sets whether this is the default network map."; } leaf filtered { type boolean; default false; description "Configures whether filtered network map is supported."; } uses algorithm; } container alto-costmap-params { when 'derived-from-or-self(../resource-type,' + '"alto:cost-map")'; description "Filtered Cost Map specific configuration."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Sections 11.2.2 and 11.3.2"; leaf filtered { type boolean; description "Configures whether filtered cost map is supported."; } uses filter-costmap-cap; uses algorithm; } container alto-endpointcost-params { when 'derived-from-or-self(../resource-type,' + '"alto:endpoint-cost")'; description "Endpoint Cost Service specific configuration."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 11.5"; uses filter-costmap-cap; uses algorithm; } container alto-endpointprop-params { when 'derived-from-or-self(../resource-type,' + '"alto:endpoint-prop")'; description "Endpoint Cost Service specific configuration."; reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 11.5"; leaf-list prop-type { type endpoint-property; min-elements 1; description "Supported endpoint properties."; } uses algorithm; } container alto-propmap-params { when 'derived-from-or-self(../resource-type,' + '"alto:property-map")'; if-feature "propmap"; description "(Filtered) Entity Property Map specific configuration."; reference "RFC 9240: An ALTO Extension: Entity Property Maps"; uses algorithm; } container alto-cdni-params { when 'derived-from-or-self(../resource-type,' + '"alto:cdni")'; if-feature "cdni"; description "CDNi specific configuration."; reference "RFC 9241: Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO"; uses algorithm; } container alto-update-params { when 'derived-from-or-self(../resource-type,' + '"alto:update")'; if-feature "incr-update"; description "Incremental Updates specific configuration."; reference "RFC 8895: Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)"; uses algorithm; } container resource-limits { description "Sets resource limits."; leaf notify-res-mem-limit { type uint64; units "bytes"; description "Notification of resource memory usage. Notification must be generated when the defined threshold is reached."; } leaf notify-upd-stream-limit { when 'derived-from-or-self(../../resource-type,' + '"alto:update")'; if-feature "incr-update"; type uint64; description "Notification of number of active update streams. Notification must be generated when the defined threshold is reached."; } } } } } // Notifications notification alto-resource-event { if-feature alto-server; description "Notifications must be generated when notify-res-mem-limit and/or notify-upd-stream-limit thresholds are reached."; leaf resource-id { type resource-ref; mandatory true; description "Resource identifier."; } leaf notify-res-mem-threshold { type uint64; units "bytes"; description "The notify-res-mem-limit threshold has been fired."; } leaf notify-upd-stream-threshold { if-feature "incr-update"; type uint64; description "The notify-upd-stream-limit threshold has been fired."; } } } ]]>

The "ietf-alto-stats" YANG Module WG List: "; description "This YANG module defines a set of statistics of an ALTO server instance. Copyright (c) 2023 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 2023-02-23 { description "Initial Version."; reference "RFC XXXX: YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol"; } // Groupings grouping server-level-stats { description "This grouping defines statistics for server-level monitoring."; leaf discontinuity-time { type yang:timestamp; description "The time on the most recent occasion at which the ALTO server suffered a discontinuity. This must be initialized when the ALTO server is configured or rebooted."; } leaf last-report-time { type yang:timestamp; description "The time on the most recent occasion at which the statistics were reported."; } leaf num-total-req { type yang:counter64; description "The total number of ALTO requests received by the ALTO server."; } leaf num-total-succ { type yang:counter64; description "The total number of successful responses sent by the ALTO server."; } leaf num-total-fail { type yang:counter64; description "The total number of failed responses sent by the ALTO server."; } leaf num-total-last-req { type yang:gauge64; description "The total number of ALTO requests received by the ALTO server within the last time window. The duration of the time window is configured by time-window-size parameter."; } leaf num-total-last-succ { type yang:gauge64; description "The total number of successful responses sent by the ALTO server within the last time window. The duration of the time window is configured by time-window-size parameter."; } leaf num-total-last-fail { type yang:gauge64; description "The total number of failed responses sent by the ALTO server within the last time window. The duration of the time window is configured by time-window-size parameter."; } } grouping network-map-stats { description "This grouping defines resource-specific statstics for the network map service only."; leaf num-map-pid { type yang:gauge64; description "Number of PIDs contained in the network map."; } reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 5"; } grouping prop-map-stats { description "This grouping defines resource-specific statstics for the endpoint property or property map service only."; leaf num-map-entry { type yang:gauge64; description "Number of ALTO entities contained in the property map."; } reference "RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol, Section 11.4.1 RFC 9240: An ALTO Extension: Entity Property Maps"; } grouping cdni-stats { description "This grouping defines resource-specific statstics for the CDNI advertisement service only."; leaf num-base-obj { type yang:gauge64; description "Number of base CDNi advertisement objects contained in the CDNI resource."; } reference "RFC 9241: Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO"; } grouping upd-stream-stats { description "This grouping defines resource-specific statstics for the update stream service only."; leaf num-upd-stream { type yang:gauge64; description "Number of active update streams connected to the update stream service."; } leaf num-upd-msg-total { type yang:gauge64; description "Total number of update messages sent to all the active update streams."; } leaf num-upd-msg-max { type yang:gauge64; description "The maximum value over the total number of update messages sent to each active update stream. Assume there are 3 active update streams A, B, and C with 4, 3, and 2 update messages sent to them respectively, the value of this metric is 4. After a while, if there is no new update message sent to any update stream, but the update stream A is closed, then the value of this metric is updated to 3."; } leaf num-upd-msg-min { type yang:gauge64; description "The minimum value over the total number of update messages sent to each active update stream. The procedure is similar to num-msg-max."; } leaf num-upd-msg-avg { type yang:gauge64; description "The average value over the total number of update messages sent to each active update stream. The procedure is similar to num-msg-max."; } leaf num-upd-msg-total-last { type yang:gauge64; description "Total number of update messages sent to all the active update streams within the last time window. The duration of the time window is configured by time-window-size parameter."; } leaf num-upd-msg-max-last { type yang:gauge64; description "The maximum value over the number of update messages sent to each active update stream within the last time window. The procedure is similar to num-msg-max, but only count the update messages within the last time window. The duration of the time window is configured by time-window-size parameter."; } leaf num-upd-msg-min-last { type yang:gauge64; description "The minimal value over the number of update messages sent to each active update stream within the last time window. The procedure is similar to num-msg-max, but only count the update messages within the last time window. The duration of the time window is configured by time-window-size parameter."; } leaf num-upd-msg-avg-last { type yang:gauge64; description "The average value over the number of update messages sent to each active update stream within the last time window. The procedure is similar to num-msg-max, but only count the update messages within the last time window. The duration of the time window is configured by time-window-size parameter."; } reference "RFC 8895: Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)"; } grouping resource-level-stats { description "This grouping defines statistics for resource-level monitoring."; leaf discontinuity-time { type yang:timestamp; description "The time on the most recent occasion at which the ALTO service providing the information resource suffered a discontinuity. This must be initialized when the ALTO information resource is configured or the ALTO server is rebooted."; } leaf last-report-time { type yang:timestamp; description "The time on the most recent occasion at which the statistics are reported."; } leaf num-res-upd { type yang:counter64; description "The number of version updates since the information resource was created."; } leaf res-mem-size { type uint64; units "bytes"; description "Memory size utilized by the information resource."; } leaf res-enc-size { type uint64; units "bytes"; description "Size of JSON encoded data of the information resource."; } leaf num-res-req { type yang:counter64; description "The total number of ALTO requests to this information resource."; } leaf num-res-succ { type yang:counter64; description "The total number of successful responses for requests to this information resource."; } leaf num-res-fail { type yang:counter64; description "The total number of failed responses for requests to this information resource."; } leaf num-res-last-req { type yang:gauge64; description "The number of ALTO requests to this information resource within the last time window. The duration of the time window is configured by time-window-size parameter."; } leaf num-res-last-succ { type yang:gauge64; description "The number of successful responses for requests to this information resource within the last time window. The duration of the time window is configured by time-window-size parameter."; } leaf num-res-last-fail { type yang:gauge64; description "The number of failed responses for requests to this information resource within the last time window. The duration of the time window is configured by time-window-size parameter."; } container network-map-stats { when 'derived-from-or-self(../../alto:resource-type,' + '"alto:network-map")'; description "Resource-specific statistics for network map service only."; uses network-map-stats; } container endpoint-prop-stats { when 'derived-from-or-self(../../alto:resource-type,' + '"alto:endpoint-prop")'; description "Resource-specific statistics for endpoint property service only."; uses prop-map-stats; } container property-map-stats { when 'derived-from-or-self(../../alto:resource-type,' + '"alto:property-map")'; description "Resource-specific statistics for entity property map service only."; uses prop-map-stats; } container cdni-stats { when 'derived-from-or-self(../../alto:resource-type,' + '"alto:cdni")'; description "Resource-specific statistics for CDNI advertisement service only."; uses cdni-stats; } container upd-stream-stats { when 'derived-from-or-self(../../alto:resource-type,' + '"alto:update")'; description "Resource-specific statistics for update stream service only."; uses upd-stream-stats; } } // Augment modules to add statistics augment "/alto:alto/alto:alto-server" { description "Augmenting statistics and configuration parameters for server-level monitoring."; container server-level-monitor-config { description "Configuration parameters for server-level monitoring."; leaf time-window-size { type uint32; units "seconds"; default "300"; description "Duration of the time window within that the statistics are reported."; } } container server-level-stats { config false; description "Top-level statistics for the whole ALTO server."; uses server-level-stats; } } augment "/alto:alto/alto:alto-server/alto:resource" { description "Augmenting statistics and configuration parameters for resource-level monitoring."; container resource-level-stats { config false; description "Common statistics for each information resource."; uses resource-level-stats; } } } ]]>

Security Considerations The "ietf-alto" and "ietf-alto-stats" YANG modules define data nodes that are designed to be accessed via YANG based management protocols, such as NETCONF and RESTCONF . Both of these protocols have mandatory-to-implement secure transport layers (e.g., SSH, TLS) with mutual authentication. The Network Access Control Model (NACM) provides the means to restrict access for particular users to a pre-configured subset of all available protocol operations and content. There are a number of data nodes defined in these two YANG modules that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes in "ietf-alto" YANG module and their sensitivity/vulnerability:

'/alto/alto-client/server-discovery':

This subtree specifies a set of parameters for an ALTO client to discover ALTO servers. Unauthorized access to it could cause intruders to modify the ALTO discovery parameters (e.g., 'dns-server') in order to expose an ALTO client to fake ALTO servers. Likewise, this data node can be manipulated to prevent an ALTO client from discovering a reachable ALTO server.

'/alto/alto-server/auth-client':

This list specifies all the authenticated ALTO clients on an ALTO server. Unauthorized write access to this list can allow intruders to modify the entries so as to add a client that have not been authenticated yet or delete a client that has already been authenticated. Likewise, this data node can be manipulated to prevent access of legitimate ALTO clients.

'/alto/alto-server/role':

This list specifies roles which authenticated ALTO clients were assigned to for access control. Unauthorized write access to this list allow intruders to modify the entries so as to permit access that should not be permitted, or deny access that should be permitted.

'/alto/alto-server/data-source/feed-interval':

This leaf specifies a period for an ALTO server to wait for updates published by a data source. A malicious ALTO client could attempt to set a very low (or large) value to this node. Setting a very low value could attack the data source. Setting a very large value would lead to maintaining stale data in the ALTO server.

'/alto/alto-server/data-source/poll-interval':

This leaf specifies a period for an ALTO server to proactively poll updates from a data source. A malicious client could attempt to set a very low (or large) value to this node. Setting a very low value could attack the data source. Setting a very large value would lead to maintaining stale data in the ALTO server.

Some of the readable data nodes in "ietf-alto" YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:

'/alto/alto-server/logging-system':

This subtree provides configuration to select a logging system to capture log messages generated by an ALTO server. Unauthorized read access of this node can allow intruders to access logging information, which could be used to craft an attack the server.

The "ietf-alto" supports an HTTP listen mode to cover cases where the ALTO server stack does not handle the TLS termination itself, but is handled by a separate component. Special care should be considered when such mode is enabled. Note that the default listen mode is 'https'. Also, please be aware that these modules include choice nodes that can be augmented by other extended modules. The augmented data nodes may be considered sensitive or vulnerable in some network environments. For instance, an augmented case of the 'source-params' choice in 'data-source' may include authentication information about how to access a data source including private network information. The 'yang-datastore' case in is such an example. The 'restconf' and 'netconf' nodes in it may reveal the access to a private YANG datastore. Thus, those extended modules may have the NACM extension "default-deny-all" set. These modules use groupings defined in other RFCs that define data nodes that do set the NACM "default-deny-all" and "default-deny-write" extensions.

IANA Considerations This document registers the following URIs in the "IETF XML Registry" : This document registers the following two YANG modules in the "YANG Module Names" registry :

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. This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. [STANDARDS-TRACK] 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] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [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. This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. 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. 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. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. 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. This document specifies an extension to the base Application-Layer Traffic Optimization (ALTO) Protocol that generalizes the concept of "endpoint properties", which have been tied to IP addresses so far, 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 RFC 7285, 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 for specific endpoints to entire entity property maps. These extensions introduce additional features that allow 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. <p>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.</p> 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 to which endpoint(s) to connect based not only on numerical/ordinal cost values but also on fine-grained abstract information regarding the paths. This is useful for applications whose performance is impacted by specific 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 the "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. 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. Watsen Networks Hochschule Esslingen - University of Applied Sciences This document defines three YANG 1.1 modules to support the configuration of TCP clients and TCP servers. The modules include basic parameters of a TCP connection relevant for client or server applications, as well as client configuration required for traversing proxies. The modules can be used either standalone or in conjunction with configuration of other stack protocol layers. Watsen Networks This document defines three YANG 1.1 modules: the first defines features and groupings common to both TLS clients and TLS servers, the second defines a grouping for a generic TLS client, and the third defines a grouping for a generic TLS server. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * FFFF --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2023-04-17 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding Informative Reference in the Appendix. The following Appendix section is to be removed prior to publication: * Appendix B. Change Log Watsen Networks This document defines two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers). Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2023-04-17 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding Informative Reference in the Appendix. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log Watsen Networks This document defines two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for draft-ietf-netconf-http- client-server * HHHH --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2023-04-17 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding Informative Reference in the Appendix. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log Watsen Networks This document defines two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for draft-ietf-netconf-http- client-server * HHHH --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * IIII --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2023-04-17 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding Informative Reference in the Appendix. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log 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. This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. At first glance, the acronym "OAM" seems to be well-known and well-understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again. This document provides a definition of the acronym "OAM" (Operations, Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. This memo documents an Internet Best Current Practice. 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.

Examples of Extending the ALTO O&M Data Model Developers and operators can also extend the ALTO O&M data model to align with their own implementations. Specifically, the following nodes of the data model can be augmented:

• The server-discovery-manner choice of the server-discovery.
• The authentication choice of each auth-client.
• The data-source choice.
• The algorithm choice of the resource-params of each resource.

An Example Module for Extended Server Discovery Manners The base data model defined by ietf-alto.yang only includes a reverse DNS based server discovery manner. The following example module demonstrates how additional server discovery manners can be augmented into the base data model. The case internet-routing-registry allows the ALTO server to update the server URI to the attribute of the corresponding aut-num class in IRR. The case peeringdb allows the ALTO server to update the server URI to the org object of the organization record in PeeringDB.

An Example Module for Extended Client Authentication Approaches The base data model "ietf-alto" only includes the client authentication approaches directly provided by the HTTP server. However, an implementation may authenticate clients in different ways. For example, an implementation may delegate the authentication to a third-party OAuth 2.0 server. The following example module demonstrates how additional client authentication approaches can enrich the base data model. In this example, the oauth2 case includes the URI to a third-party OAuth 2.0 based authorization server that the ALTO server can redirect to for the client authentication.

Example Module for Extended Data Sources The base data model defined by ietf-alto.yang does not include any choice cases for specific data sources. The following example module demonstrates how a implementation-specific data source can be augmented into the base data model. The yang-datastore case is used to import the YANG data from a YANG model-driven datastore. It includes:

• datastore to indicate which datastore is fetched.
• target-paths to specify the list of nodes or subtrees in the datastore.
• protocol to indicate which protocol is used to access the datastore. Either restconf or netconf can be used.

An Example Module for Information Resource Creation Algorithm The base data model "ietf-alto" does not include any choices cases for information resource creation algorithms. But developers may augment the "ietf-alto" module with definitions for 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. 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 contains information referring to the target path name of an operational yang-datastore data source node (See ) subscribed in the data-source list (See ). The referenced target path in the corresponding yang-datastore data source is assumed 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. 'source-datastore' refers to the 'source-id' of the operational yang-datastore data source node, and 'topo-name' refers to the 'name' of the target path in the source datastore.

'depth':

This optional parameter sets the depth of the clustering algorithm. For example, if the depth is set 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 ).

Example Usage This section presents a complete example showing how the base data model and all the vendor extended models above are used to set up an ALTO server and configure corresponding components (e.g., data source listener, information resource, access control).

Acknowledgements The authors thank Qin Wu for the help with drafting the initial version of the YANG modules. Big thanks also to ALTO WG chairs (Mohamed Boucadair and Qin Wu) and Adrian Farrel, Dong Guo, Jordi Ros Giralt, Luis M. Contreras, Mahdi Soleimani, Qiao Xiang, Shenshen Chen, and Y. Richard Yang for their thorough reviews, shepherding, and valuable feedback. Thanks to Dan Romascanu for the opsdir review, Andy Bierman for the yangdoctors review, and Spencer Dawkins for the tsvart review. Thanks to Martin Duke for the careful AD review.