| Internet-Draft | ALTO OAM YANG | January 2022 |
| Zhang, et al. | Expires 17 July 2022 | [Page] |
This document defines a YANG data model for the operations and management of Application-Layer Traffic Optimization (ALTO) Protocol. The operator can use the data model to create and update ALTO information resources, manage the access control, configure server-to-server communication and server discovery, and collect statistical data.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the ALTO Working Group mailing list (alto@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/alto/.¶
Source for this draft and an issue tracker can be found at https://github.com/openalto/draft-alto-oam-yang.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 July 2022.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document defines a YANG data model for the operations and management of Application-Layer Traffic Optimization (ALTO) Protocol. The basic propose of this YANG data model is discussed in Section 16 of [RFC7285]. The operator can use the data model to create and update ALTO information resources, manage the access control, configure server-to-server communication and server discovery, and collect statistical data.¶
The basic structure of this YANG data model is guided by Section 16 of [RFC7285] and [RFC7971]. Although the scope of the YANG data model in this document mainly focuses on the support of the base ALTO protocol [RFC7285] and the existing ALTO standard extensions (including [RFC8189], [RFC8895] and [RFC8896]), the design will also be extensible for future standard extensions (e.g., [I-D.ietf-alto-path-vector], [I-D.ietf-alto-unified-props-new], [RFC8896], and [I-D.ietf-alto-performance-metrics]).¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. When the words appear in lower case, they are to be interpreted with their natural language meanings.¶
A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is defined in [RFC8340].¶
In this document, names of data nodes and other data model objects are often used without a prefix, as long as it is clear from the context in which YANG module each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1.¶
| Prefix | YANG module | Reference |
|---|---|---|
| yang | ietf-yang-types | [RFC6991] |
| inet | ietf-inet-types | [RFC6991] |
Based on discussions and recommendations in [RFC7285] and [RFC7971], the data model provided by this document satisfies basic requirements listed in Table 2¶
| Requirement | Reference |
|---|---|
| Support configuration for ALTO server setup | Section 16.1 of [RFC7285] |
| Define management information model | Section 16.2.2 of [RFC7285] |
| Support configuration for data sources | Section 16.2.4 of [RFC7285] |
| Support configuration for information resource generation algorithms | Section 16.2.4 of [RFC7285] |
| Support configuration for access control at information resource level | Section 16.2.4 of [RFC7285] |
| Support performance monitoring for ALTO-specific metrics | Section 16.2.5 of [RFC7285] |
| Support configuration for security policy management | Section 16.2.6 of [RFC7285] |
What is in the scope of this document?¶
What is not in the scope of this document?¶
This document does not define any data model related to specific implementation, including:¶
To satisfy all the basic requirements and consider the potential requirements for future extensions, this document focuses on the design objectives for the YANG data model as follows:¶
The data model should provide configurable data model for administrators to create, update and remove ALTO information resources.¶
NOTE: The data model supporting configuration for the ALTO client and the communication between the administrated ALTO server and other ALTO servers will be considered in a future version of the document.¶
The ALTO YANG module defined in this document has all the common building blocks for ALTO OAM.¶
NOTE: So far, the ALTO YANG module only focuses on the ALTO server related configuration. The ALTO client related configuration will be added in a future version of the document.¶
The container "alto-server" in the ALTO yang module contains all the configured and operational parameters of the adminstrated ALTO server instance.¶
module: ietf-alto
+--rw alto-server
+--rw hostname inet:host
+--rw cost-type* [cost-type-name]
| +--rw cost-type-name string
| +--rw cost-mode cost-mode
| +--rw cost-metric cost-metric
|--rw meta* [meta-key]
| +--rw meta-key string
| +--rw meta-value string
+--rw resource* [resource-id]
| +--rw resource-id resource-id
| +--rw resource-type identityref
| +--rw description? string
| +--rw accepted-group* [user-group]
| +--rw dependency* resource-id
| +--rw auth
| | +--rw (auth-type-selection)
| | +--:(auth-key-chain)
| | +--:(auth-key)
| | +--:(auth-tls)
| | ...
| +--rw (resource-params)
| +--:(ird)
| | +--rw alto-ird-params
| | +--rw delegation inet:uri
| +--:(networkmap)
| | +--rw alto-networkmap-params
| | +--rw is-default? boolean
| | +--rw filtered? boolean
| | +--rw (algorithm)
| +--:(costmap)
| | +--rw alto-costmap-params
| | +--rw filtered? boolean
| | +--rw cost-type-names* string
| | +--rw cost-constraints? boolean
| | +--rw max-cost-types? uint32 {multi-cost}?
| | +--rw testable-cost-type-names*
| | string {multi-cost}?
| | +--rw calendar? boolean {cost-calendar}?
| | +--rw (algorithm)
| +--:(endpointcost)
| | +--rw alto-endpointcost-params
| | +--rw cost-type* [cost-mode,cost-metric]
| | | +--rw cost-mode cost-mode
| | | +--rw cost-metric cost-metric
| | +--rw cost-constraints? boolean
| | +--rw max-cost-types? uint32 {multi-cost}?
| | +--rw testable-cost-type-names*
| | string {multi-cost}?
| | +--rw calendar? boolean {cost-calendar}?
| | +--rw (algorithm)
| +--:(endpointprop)
| | +--rw alto-endpointprop-params
| | +--rw (algorithm)
| +--:(propmap) {propmap}?
| | +--rw alto-propmap-params
| | +--rw (algorithm)
| +--:(cdni) {cdni}?
| | +--rw alto-cdni-params
| | +--rw (algorithm)
| +--:(update) {incr-update}?
| +--rw alto-update-params
| +--rw (algorithm)
+--rw data-source* [source-id]
+--rw source-id string
+--rw source-type identityref
+--rw (update-policy)
| +--:(reactive)
| | +--rw reactive boolean
| +--:(proactive)
| +--rw poll-interval uint32
+--rw (source-params)
+--:(yang-datastore)
| +--rw yang-datastore-source-params
| +--rw source-path yang:xpath1.0
+--:(prometheus)
+--rw prometheus-source-params
+--rw source-uri inet:uri
+--rw query-data? string
¶
The ALTO server instance contains the following basic configurations for the server setup.¶
The hostname is the name that is used to access the ALTO server. It will be also used in the URI of each information resource provided by the ALTO server.¶
The cost type list is the registry for the cost types that can be used in the ALTO server.¶
The meta list contains the customized meta data of the ALTO server. It will be
populated into the meta field of the default Information Resource Directory
(IRD).¶
module: ietf-alto
+--rw alto-server
+--rw hostname inet:host
+--rw cost-type* [cost-type-name]
| +--rw cost-type-name string
| +--rw cost-mode cost-mode
| +--rw cost-metric cost-metric
|--rw meta* [meta-key]
| +--rw meta-key string
| +--rw meta-value string
...
¶
The ALTO server instance contains a list of resource entries. Each resource
entry contains the configurations of an ALTO information resource (See Section
8.1 of [RFC7285]). The operator of the ALTO server can use this model to
create, update, and remove the ALTO information resource.¶
Each resoruce entry is considered as an intent to create or update an ALTO
information resource. Adding a new resource entry will submit an ALTO
information resource creation intent to the intent system to create a new ALTO
information resource. Updating an existing resource entry will update the
corresponding ALTO information resource creation intent. Removing an existing
resource entry will remove the corresponding ALTO information resource
creation intent and also the created ALTO information resource.¶
The parameter of the intent interface defined by a resource entry MUST include
a unique resource-id and a resource-type.¶
It can also include an accepted-group node containing a list of user-groups
that can access this ALTO information resource.¶
As section 15.5.2 of [RFC7285] suggests, the module also defines authentication related configuration to employ access control at information resource level. The ALTO server returns the IRD to the ALTO client based on its authentication information.¶
For some resource-type, the parameter of the intent interface MUST also
include the a dependency node containing the resource-id of the dependent
ALTO information resources (See Section 9.1.5 of [RFC7285]).¶
For each type of ALTO information resource, the creation intent MAY also need type-specific parameters. These type-specific parameters include two categories:¶
algorithm node to declare algorithm-specific input
parameters.¶
Except for the ird resource, all the other types of resource entries have
augmented algorithm node. The augmented algorithm node can reference data
sources subscribed by the data-source entries (See Section 5.4).¶
The developer cannot customize the creation algorithm of the ird resource. The
default ird resource will be created automatically based on all the added
resource entries. The delegated ird resource will be created as a static
ALTO information resource (See Section 9.2.4 of [RFC7285]).¶
module: ietf-alto
+--rw alto-server
...
+--rw resource* [resource-id]
| +--rw resource-id resource-id
| +--rw resource-type identityref
| +--rw description? string
| +--rw accepted-group* [user-group]
| +--rw dependency* resource-id
| +--rw auth
| | +--rw (auth-type-selection)
| | +--:(auth-key-chain)
| | +--:(auth-key)
| | +--:(auth-tls)
| | ...
| +--rw (resource-params)
| +--:(ird)
| | +--rw alto-ird-params
| | +--rw delegation inet:uri
| +--:(networkmap)
| | +--rw alto-networkmap-params
| | +--rw is-default? boolean
| | +--rw filtered? boolean
| | +--rw (algorithm)
| +--:(costmap)
| | +--rw alto-costmap-params
| | +--rw filtered? boolean
| | +--rw cost-type-names* string
| | +--rw cost-constraints? boolean
| | +--rw max-cost-types? uint32 {multi-cost}?
| | +--rw testable-cost-type-names*
| | string {multi-cost}?
| | +--rw calendar? boolean {cost-calendar}?
| | +--rw (algorithm)
| +--:(endpointcost)
| | +--rw alto-endpointcost-params
| | +--rw cost-type* [cost-mode,cost-metric]
| | | +--rw cost-mode cost-mode
| | | +--rw cost-metric cost-metric
| | +--rw cost-constraints? boolean
| | +--rw max-cost-types? uint32 {multi-cost}?
| | +--rw testable-cost-type-names*
| | string {multi-cost}?
| | +--rw calendar? boolean {cost-calendar}?
| | +--rw (algorithm)
| +--:(endpointprop)
| | +--rw alto-endpointprop-params
| | +--rw (algorithm)
| +--:(propmap) {propmap}?
| | +--rw alto-propmap-params
| | +--rw (algorithm)
| +--:(cdni) {cdni}?
| | +--rw alto-cdni-params
| | +--rw (algorithm)
| +--:(update) {incr-update}?
| +--rw alto-update-params
| +--rw (algorithm)
...
¶
The following example shows how the developer can augment a creation algorithm for the network map resource.¶
augment /alto:alto-server/alto:resource/alto:resource-params
/alto:networkmap/alto:alto-networkmap-params
/alto:algorithm:
+--rw l3-unicast-cluster-algorithm
+--rw l3-unicast-topo
| -> /alto:alto-server/data-source/source-id
+--rw depth? uint32
¶
This example defines a creation algorithm called l3-unicast-cluster-algorithm
for the network map resource. It takes two algorithm-specific parameters:¶
This parameter refers to the source id of a data source node subscribed in the
data-source list (See Section 5.4). The corresponding data source is
assumed to be an internel data source (See Section 5.4.1) for an
IETF layer 3 unicast topology defined in [RFC8346]. The algorithm uses the
topology data from this data source to compute the ALTO network map resource.¶
This optional parameter sets the depth of the clustering algorithm. For example, if the depth sets to 1, the algorithm will generate PID for every l3-node in the topology.¶
The creation algorithm can be reactively called once the referenced data source
updates. Therefore, the ALTO network map resource can be updated dynamically.
The update of the reference data source depends on the used update-policy (See
Section 5.4).¶
The ALTO server instance contains a list of data-source entries to subscribe
the data sources from which ALTO information resources are derived (See Section
16.2.4 of [RFC7285]).¶
A data-source entry MUST include:¶
source-id for resource creation algorithms to reference,¶
source-type attribute to declare the type of the data source,¶
update-policy to specify how to get the data update from the data
source,¶
source-params to specify where and how to query the data.¶
The update policy can be either reactive or proactive. For the reactive update, the ALTO server gets the update as soon as the data source changes. For the proactive update, the ALTO server has to proactively fetch the data source periodically.¶
To use the reactive update, the reactive attribute MUST be set true. To use
the proactive update, the poll-interval attribute MUST be greater than zero.
The value of poll-interval specifies the interval of fetching the data in
milliseconds. If reactive is false or poll-interval is zero, the ALTO server
will not update the data source.¶
The data-source/source-params node can be augmented for different types of
data sources. This data model only includes import interfaces for a list of
predefined data sources. More data sources can be supported by future documents
and other third-party providers.¶
module: ietf-alto
+--rw alto-server
...
+--rw data-source* [source-id]
+--rw source-id string
+--rw source-type identityref
+--rw (update-policy)
| +--:(reactive)
| | +--rw reactive boolean
| +--:(proactive)
| +--rw poll-interval uint32
+--rw (source-params)
+--:(yang-datastore)
| +--rw yang-datastore-source-params
| +--rw source-path yang:xpath1.0
+--:(prometheus)
+--rw prometheus-source-params
+--rw source-uri inet:uri
+--rw query-data? string
¶
Note: Current source configuration still has limitations. It should be revised to support more general southbound and data retrieval mechanisms.¶
The yang-datastore-source-params is used to import the YANG data which
is located in the same YANG model-driven data store supplying the current ALTO
OAM data model. The source-path is used to specify the XPath of the data
source node.¶
The prometheus-source-params is used to import common performance metrics
data which is provided by a Prometheus server. The source-uir is used to
establish the connection with the Prometheus server. The query-data is used
to speficify the potential query expression in PromQL.¶
As section 16.2.5 of [RFC7285] suggests, the YANG data module defined in this document also contains statistics for ALTO-specific performance metrics.¶
More specifically, this data model contains the following measurement information suggested by [RFC7971]:¶
Besides the measurement information suggested by [RFC7971], this data model also contains useful measurement information for other ALTO extensions:¶
The module, "ietf-alto-stats", augments the ietf-alto module to include statistics at the ALTO server and information resource level.¶
module: ietf-alto-stats
augment /alto:alto-server/alto:resource:
+--ro num-res-upd? yang:counter32
+--ro res-mem-size? yang:counter32
+--ro res-enc-size? yang:counter32
augment /alto:alto-server/alto:resource/alto:resource-params
/alto:networkmap/alto:alto-networkmap-params:
+--ro num-map-pid? yang:counter32
augment /alto:alto-server/alto:resource/alto:resource-params
/alto:propmap/alto:alto-propmap-params:
+--ro num-map-entry? yang:counter32
augment /alto:alto-server/alto:resource/alto:resource-params
/alto:cdni/alto:alto-cdni-params:
+--ro num-base-obj? yang:counter32
augment /alto:alto-server/alto:resource/alto:resource-params
/alto:update/alto:alto-update-params:
+--ro num-upd-sess yang:counter32
+--ro num-event-total yang:counter32
+--ro num-event-max? yang:counter32
+--ro num-event-min? yang:counter32
+--ro num-event-avg? yang:counter32
¶
TODO: The complete tree diagram and YANG modules will be updated soon.¶