YANG Data Model for Traffic Engineering (TE) TopologiesVolta Networksxufeng.liu.ietf@gmail.comFuturewei Technologies, Inc.i_bryskin@yahoo.comJuniper Networksvbeeram@juniper.netJuniper Networkstsaad@juniper.netCienahshah@ciena.comTelefonicaoscar.gonzalezdedios@telefonica.comTEAS Working GroupTE topologyTE topology YANG modelAbstract TE topologyNative TE topologyCustomized TE topologyUnderlay TE topologyOverlay TE topology
This document defines a YANG data model for representing, retrieving,
and manipulating Traffic Engineering (TE) Topologies. The model
serves as a base model that other technology-specific TE topology
models can augment.Introduction
The Traffic Engineering Database (TED) is an essential component of
Traffic Engineered (TE) systems that are based on MPLS-TE
and GMPLS . The TED is a collection of all TE information
about all TE nodes and TE links in the network. The TE topology is a
schematic arrangement of TE nodes and TE links present in a given
TED. There could be one or more TE topologies present in a given
TE system. A TE topology is the topology on which
path computational algorithms are run to compute TE paths.
This document defines a YANG data model for representing, retrieving,
and manipulating TE topologies. This model contains technology-agnostic TE topology building blocks that can be augmented and used
by other technology-specific TE topology models.TerminologyThe 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.
We assume that the reader is familiar with the general body of work
captured in currently available RFCs related to Traffic Engineering. serves as
a good starting point for those who may be less familiar with RFCs related to Traffic Engineering.
Some of the key terms used in this document are as follows:
TED:
The Traffic Engineering Database (TED) is a collection of all
TE information about all TE nodes and TE links in a given network.
TE topology:
The TE topology is a schematic arrangement of TE
nodes and TE links in a given TED. It forms the basis for a graph suitable
for TE path computations.
Native TE topology:
A Native TE topology is a topology that is
native to a given provider network. A Native TE topology could be discovered
via various routing protocols and/or subscribe/publish techniques. This is
the topology on which path computational algorithms are run to compute TE
paths.
Customized TE topology:
A Customized TE topology is a custom
topology that is produced by a provider for a given client. This topology
typically makes abstractions on the provider's Native TE topology and is
provided to the client. The client receives the Customized TE topology and
merges it into the client's Native TE topology. The client's path
computational algorithms aren't typically run on the Customized TE
topology; they are run on the client's Native TE topology after the
merge.
Tree Structure A simplified
graphical representation of the data model is presented in
of this document. The tree format defined in is used for the YANG data model tree
representation. Prefixes in Data Node NamesIn
this document, names of data nodes and other data model objects are
prefixed using the standard prefix associated with the corresponding
YANG imported modules, as shown in .
Prefixes and Corresponding YANG Modules
Prefix
YANG Module
Reference
yang
ietf-yang-types
inet
ietf-inet-types
nw
ietf-network
nt
ietf-network-topology
te-types
ietf-te-types
Characterizing TE Topologies
The data model defined by this document takes the following
characteristics of TE topologies into account:
The TE topology is an abstract control-plane representation of the
data-plane topology. Hence, attributes specific to the data plane
must make their way into the corresponding TE topology modeling.
The TE topology is comprised of dynamic autodiscovered data as well
as fairly static data associated with data-plane nodes and links.
The dynamic data, such as unreserved bandwidth available on data-plane
links, may change frequently. The static data, such as layer network
identification, switching and adaptation capabilities and limitations,
fate-sharing, and administrative colors, rarely changes.
It is possible for a single TE topology to
encompass TE information at multiple switching layers.
TE topologies are protocol independent. Information about
topological elements may be learned via link-state protocols, but
the topology can exist without being dependent on any particular
protocol.
The TE topology may not be congruent with the routing topology in a
given TE system. The routing topology is constructed based on
routing adjacencies. There isn't always a one-to-one association
between a TE link and a routing adjacency. For example, the
presence of a TE link between a pair of nodes doesn't necessarily
imply the existence of a routing adjacency between these nodes. To
learn more, see and
.
Each TE topological element has at least one information source
associated with it. In some scenarios, there could be more than
one information source associated with any given topological
element.
TE topologies can be hierarchical. Each node and link of a given
TE topology can be associated with a respective underlay topology.
This means that each node and link of a given TE topology can be
associated with an independent stack of supporting TE topologies.
TE topologies can be customized. TE topologies of a given network
presented by the network provider to its client could be
customized on a per-client-request basis. This customization could
be performed by the provider, by the client, or by provider&wj;/client
negotiation. The relationship between a customized topology and the
provider's native topology could be captured as hierarchical
(overlay/underlay), but otherwise the two topologies are decoupled
from each other. A customized topology is presented to the client,
while the provider's native topology is known in its entirety to the
provider itself.
Modeling Abstractions and TransformationsTE Topology
A TE topology is a Traffic Engineering representation of one or more
layers of network topologies. A TE topology is comprised of TE nodes
(TE graph vertices) interconnected via TE links (TE graph edges). A
TE topology is mapped to a TE graph.TE Node
A TE node is an element of a TE topology, presented as a vertex on a TE
graph. A TE node represents one or several nodes, or a fraction of a
node, which can be a switch or router that is physical or virtual. A TE
node belongs to and is fully defined in exactly one TE topology. A TE
node is assigned a unique ID within the TE topology scope. TE node
attributes include information related to the data&nbhy;plane aspects of
the associated node(s) (e.g., connectivity matrix), as well as
configuration data (such as the TE node name). A given TE node can be
reached on the TE graph over one of the TE links terminated by the TE
node.
Multi-layer TE nodes providing switching functions at multiple
network layers are an example where a physical node can be decomposed
into multiple logical TE nodes, which are fractions of the physical
node. Some of these (logical) TE nodes may reside in the client-layer
TE topology, while the remaining TE nodes belong to the server-layer
TE topology.
In , Node-1, Node-2, and Node-3 are
TE nodes.TE Link
A TE link is an element of a TE topology, presented as an edge on a TE
graph. The arrows on an edge indicate one or both directions of the
TE link. When there are a pair of parallel links of opposite
directions, an edge without arrows is also used. A TE link represents
one or several (physical) links or a fraction of a link. A TE link
belongs to and is fully defined in exactly one TE topology. A TE link
is assigned a unique ID within the TE topology scope. TE link
attributes include parameters related to the data-plane aspects of
the associated link(s) (unreserved bandwidth, resource maps / resource
pools, etc.), as well as the configuration data (remote
node IDs / link IDs, Shared Risk Link Groups (SRLGs),
administrative colors, etc.). A TE link is
connected to a TE node, terminating the TE link via exactly one TE Link
Termination Point (LTP).
In , Link-12 and Link-23 are TE links.Transitional TE Link for Multi-layer Topologies
Networks are typically composed of multiple network layers where one
or multiple signals in the client-layer network can be multiplexed
and encapsulated into a server-layer signal . The
server-layer signal can be carried in the server-layer network across
multiple nodes until the server-layer signal is terminated and the
client-layer signals reappear in the node that terminates the
server-layer signal. Examples of multi-layer networks include (1) IP over MPLS over
Ethernet and (2) low-order Optical Data Unit-k (ODUk) signals multiplexed
into a high-order ODUl (l>k) carried over an Optical Channel (OCh)
signal in an Optical Transport Network (OTN) as defined in and
.
TE links as defined in can be used to represent links
within a network layer. In the case of a multi-layer network, TE nodes
and TE links only allow the representation of each network layer as a
separate TE topology. Each of these single-layer TE topologies would
be isolated from their client and their server-layer TE topology, if
present. The highest network layer and the lowest network layer in the hierarchy
only have a single adjacent layer below or above, respectively.
Multiplexing client-layer signals and encapsulating them into a
server-layer signal require a function that is provided inside a
node (typically realized in hardware). This function is also called
"layer transition".
One of the key requirements for path computation is to be able to
calculate a path between two endpoints across a multi-layer network
based on the TE topology representing this multi-layer network. This
means that an additional TE construct is needed that represents
potential layer transitions in the multi-layer TE topology that
connects the TE topologies representing each separate network layer.
The so-called transitional TE link is such a construct, and it
represents the layer transition function residing inside a node that
is decomposed into multiple logical nodes that are represented as TE
nodes (also see for the definition of a transitional link for the OTN). Hence, a transitional TE link connects a
client-layer node with a server-layer node. A TE link as defined in
has LTPs of exactly the same kind on each link end, whereas the
transitional TE link has client-layer LTPs on the client side of the
transitional link and, in most cases, a single server-layer LTP on the
server side. It should be noted that transitional links are a helper
construct in the multi-layer TE topology and they only exist as long
as they are not in use, as they represent potential connectivity.
When the server-layer trail has been established between the
server-layer LTP of two transitional links in the server-layer network, the
resulting client-layer link in the data plane will be represented as
a normal TE link in the client-layer topology. The transitional TE
links will reappear when the server-layer trail has been torn down.TE Link Termination Point (LTP)
A TE Link Termination Point (LTP) is a conceptual point of connection
of a TE node to one of the TE links, terminated by the TE node.
Cardinality between an LTP and the associated TE link is 1:0..1.
In , Node-2 has six LTPs: LTP-1 through LTP-6.TE Tunnel Termination Point (TTP)
A TE Tunnel Termination Point (TTP) is an element of a TE topology
representing one or several potential transport service
termination points (i.e., service client adaptation points, such as
a WDM/OCh transponder). ("WDM" stands for "Wavelength Division Multiplexing".) A TTP is associated with (hosted by) exactly one
TE node. A TTP is assigned a unique ID within the TE node scope.
Depending on the TE node's internal constraints, a given TTP hosted
by the TE node could be accessed via one, several, or all TE links
terminated by the TE node.
In , Node-1 has two TTPs: TTP-1 and TTP-2.TE Node Connectivity Matrix
A TE node connectivity matrix is a TE node's attribute describing the
TE node's switching limitations in the form of valid switching
combinations of the TE node's LTPs (see below). From the point of
view of a potential TE path arriving at the TE node at a given
inbound LTP, the node's connectivity matrix describes valid
(permissible) outbound LTPs from which the TE path can leave the TE node.In , the connectivity matrix on Node-2 is as follows:{<LTP-6, LTP-1>, <LTP-5, LTP-2>, <LTP-5, LTP-4>, <LTP-4, LTP-1>,
<LTP-3, LTP-2>}TTP Local Link Connectivity List (LLCL)
A TTP Local Link Connectivity List (LLCL) is a list of TE links
terminated by the TE node hosting a TTP, to which the TTP could be connected. From the point of view of
the potential TE path of a connection, an LLCL provides a list of valid TE links the TE
path needs to start/stop on for the connection to be successfully
terminated on a TTP.In , the LLCL on Node-1 is as follows:{<TTP-1, LTP-5>, <TTP-1, LTP-2>, <TTP-2, LTP-3>, <TTP-2, LTP-4>}TE Path
A TE path is an ordered list of TE links and/or TE nodes on the TE
topology graph; this path interconnects a pair of TTPs to be used by a potential connection. For example, TE paths could be a product of
successful path computation performed for a given transport service.In , the TE path for TE-Tunnel-1 is as follows:{Node-1:TTP-1, Link-12, Node-2, Link-23, Node-3:TTP-1}TE Inter-layer LockA TE inter-layer lock is a modeling concept describing adaptation
relationships between the client layer and the server layer
and hence is important for multi-layer
Traffic Engineering. It is an association of M client-layer LTPs and N
server-layer TTPs, within which data arriving at any of the
client-layer LTPs could be adopted onto any of the server-layer
TTPs. A TE inter-layer lock is identified by an inter-layer lock ID, which is unique
across all TE topologies provided by the same provider. The
client-layer LTPs and the server-layer TTPs associated within a given TE
inter-layer lock are annotated with the same inter-layer lock ID
attribute.
In , a TE inter-layer lock with an ID of IL-1
associates six client-layer LTPs (C-LTP-1 through C-LTP-6) with two
server-layer TTPs (S-TTP-1 and S-TTP-2). They all have the same attribute
-- TE inter-layer lock ID IL-1, which is the only thing that indicates the
association. A given LTP may have zero, one, or more inter-layer lock IDs.
In the latter case, this means that the data arriving at the LTP may be
adopted onto any of the TTPs associated with all specified inter-layer
locks. For example, C-LTP-1 could have two inter-layer lock IDs -- IL-1 and
IL-2. This would mean that C-LTP-1 for adaptation purposes could use not
just the TTPs associated with inter-layer lock IL-1 (i.e., S-TTP-1 and
S-TTP-2 in the figure) but any of the TTPs associated with inter-layer lock
IL-2 as well. Likewise, a given TTP may have one or more inter-layer lock
IDs, meaning that it can offer the adaptation service to any of the
client-layer LTPs with an inter-layer lock ID matching one of its
own. Additionally, each TTP has an unreserved adaptation bandwidth
attribute, which announces its remaining adaptation resources that are
sharable between all potential client-layer LTPs.
LTPs and TTPs associated within the same TE inter-layer lock may be
hosted by the same (hybrid, multi-layer) TE node or multiple TE nodes
located in the same or separate TE topologies. The latter case is
especially important, since TE topologies of different layer networks
could be modeled by separate augmentations of the basic (common to
all layers) TE topology model.Underlay TE Topology
An underlay TE topology is a TE topology that serves as a base for
the construction of overlay TE topologies.Overlay TE Topology
An overlay TE topology is a TE topology that is constructed based on one or more
underlay TE topologies. Each TE node of the overlay TE topology
represents an arbitrary segment of an underlay TE topology; each TE
link of the overlay TE topology represents an arbitrary TE path in
one of the underlay TE topologies. The overlay TE topology and the
supporting underlay TE topologies may represent distinct layer
networks (e.g., OTN/ODUk and WDM/OCh, respectively) or the same layer
network.Abstract TE Topology
An abstract TE topology is a topology that contains abstract topological
elements (nodes, links, TTPs). An abstract TE
topology is an overlay TE topology created by a topology provider and
customized for a topology provider's client based on one or more of
the provider's Native TE topologies (underlay TE topologies), the
provider's policies, and the client's preferences. For example, a
first-level topology provider (such as a domain controller) can create
an abstract TE topology for its client (e.g., a multi-domain service
coordinator) based on one or more of the provider's Native TE
topologies, local policies/profiles, and the client's TE topology
configuration requests. shows an example of an abstract TE topology.Model ApplicabilityNative TE Topologies
The model discussed in this document can be used to represent and
retrieve Native TE topologies on a given TE system.
Consider the network topology depicted in . R1 .. R9
are nodes representing routers. An implementation MAY choose to construct a
Native TE topology using all nodes and links present in the given TED as
depicted in . The data model defined in this document
can be used to represent and retrieve this TE topology.
Consider the case where the topology is split in a way that some nodes
participate in OSPF-TE while others participate in ISIS-TE (). An implementation MAY choose to construct separate TE
topologies based on the information source. The Native TE topologies
constructed using only nodes and links that were learned via a specific
information source are depicted in . The data model
defined in this document can be used to represent and retrieve these TE
topologies.Similarly, the data model can be used to represent and retrieve a TE
topology that is constructed using only nodes and links that belong
to a particular technology layer. The data model is flexible enough
to represent and retrieve many such Native TE topologies.Customized TE Topologies
A Customized TE topology is a topology that was modified by the
provider to honor a particular client's requirements or preferences.
The model discussed in this document can be used to represent, retrieve,
and manipulate Customized TE topologies. The model allows the
provider to present the network in abstract TE terms on a per&nbhy;client
basis. These customized topologies contain sufficient information for
the client to compute and select paths according to its policies.
Consider the network topology depicted in . This is a
typical packet optical transport deployment scenario where the WDM-layer
network domain serves as a server network domain providing transport
connectivity to the packet-layer network domain (client network
domain). Nodes R1, R2, R3, and R4 are IP routers that are connected to an
optical WDM transport network. A, B, C, D, E, and F are WDM nodes that
constitute the server network domain.
The goal here is to augment the client's TE topology with a Customized TE
topology provided by the WDM network. Given the availability of the paths
A-E, B-F, and B-E (), a Customized TE topology as
depicted in is provided to the client. This Customized TE
topology is merged with the client's Native TE topology, and the resulting
topology is depicted in .
The data model defined in this document can be used to
represent, retrieve, and manipulate the Customized TE topology depicted in
.
A Customized TE topology is not necessarily an abstract TE topology.
The provider may produce, for example, an abstract TE topology of a
certain type (a single-abstract-node-with-connectivity-matrix
topology, a border-nodes-connected-via-mesh-of-abstract-links
topology, etc.) and expose it to all or some clients in the expectation that
the clients will use it without customization.
On the other hand, a client may request a customized version of the
provider's Native TE topology (e.g., by requesting the removal of TE links
that belong to certain layers, are too slow, are not protected, and/or
have a certain affinity). Note that the resulting TE topology will
not be abstract (because it will not contain abstract elements) but will be
customized (modified upon the client's instructions).
The client ID field in the TE topology identifier ()
indicates which client the TE topology is customized for. Although an
authorized client MAY receive a TE topology with the client ID field
matching some other client, the client can customize only TE
topologies with the client ID field either set to 0 or matching the ID of
the client in question. If the client starts the reconfiguration of a
topology, its client ID will be automatically set in the topology ID
field for all future configurations and updates with regard to the topology in
question.
The provider, by setting its own ID in the client ID field of the topology
ID, MAY tell the client that a given TE topology
cannot be renegotiated.
Even though this data model allows the access of TE topology information
across clients, implementations MAY restrict access for particular
clients to particular data fields. The Network Configuration Access Control Model (NACM) provides such a mechanism.Merging TE Topologies Provided by Multiple Providers
A client may receive TE topologies provided by multiple providers,
each of which manages a separate domain of a multi-domain network. In
order to make use of said topologies, the client is expected to merge
the provided TE topologies into one or more of its own Native TE
topologies, each of which homogeneously represents the multi-domain
network. This makes it possible for the client to select end-to-end
TE paths for its services traversing multiple domains.
In particular, the process of merging TE topologies includes:
Identifying neighboring domains and locking their topologies
horizontally by connecting their inter-domain open-ended TE links.
Renaming TE node IDs, link IDs, and SRLG IDs to IDs allocated from a
separate namespace; this is necessary because all TE topologies
are considered to be, generally speaking, independent, and clashes among
TE node IDs, link IDs, or SRLG IDs are possible.
Locking, vertically, TE topologies associated with different layer
networks, according to provided topology inter-layer locks; this is done
to facilitate inter-layer path computations across multiple TE
topologies provided by the same topology provider.
illustrates the process whereby the
client merges the TE topologies furnished by its providers.In , each of
the two providers caters to the client (abstract or Native) TE
topology, describing the network domain under the respective
provider's control. The client, by consulting such attributes of the
inter-domain TE links as inter-domain plug IDs or remote TE
node IDs / link IDs (as defined by the TE topology model), is able to
determine that:
the two domains are adjacent and are interconnected via three
inter-domain TE links, and
each domain is connected to a separate customer site, connecting
the domain on the left in the figure to customer devices C11 and C12, and
the domain on the right to customer devices C21, C22, and C23.
Therefore, the client interconnects the open-ended TE links, as
shown on the upper part of the figure.
As mentioned previously, one way to interconnect the open-ended inter-domain TE links
of neighboring domains is to mandate that the providers specify a remote
node ID / link ID attribute in the provided inter-domain TE
links. However, this may prove not to be flexible. For example, the providers may not
know the respective remote node IDs / link IDs. More importantly, this option
does not allow the client to mix and match multiple topologies (more than
one topology) catered by the same providers (see below). Another option
(which is more flexible) for resolving the open-ended inter-domain TE links is to
annotate them with the inter-domain plug ID attribute. The inter-domain plug
ID is a network-wide unique number that identifies on the network a
connection that supports a given inter-domain TE link. Instead of specifying
a remote node ID / link ID, an inter-domain TE link may provide a non-zero
inter-domain plug ID. It is expected that two neighboring domain TE
topologies (provided by separate providers) will each have at least one
open-ended inter-domain TE link with an inter-domain plug ID matching
an ID provided by its neighbor. For example, the inter-domain TE link
originating from node S15 of the Domain 1 TE topology () and the inter-domain TE link coming from node S23 of the
Domain 2 TE topology may specify a matching inter-domain plug ID
(e.g., 175344). This allows the client to identify adjacent nodes in the
separate neighboring TE topologies and resolve the inter-domain TE links
connecting them, regardless of their respective node IDs / link IDs (which, as
mentioned previously, could be allocated from independent namespaces). Inter-domain
plug IDs may be assigned and managed by a central network authority.
Alternatively, inter-domain plug IDs could be dynamically autodiscovered
(e.g., via the Link Management Protocol (LMP)).
Furthermore, the client renames the TE nodes, links, and SRLGs offered
in the abstract TE topologies by assigning to them IDs allocated from
a separate namespace managed by the client. Such renaming is
necessary, because the two abstract TE topologies may have their own
namespaces, generally speaking, independent one from another; hence,
ID overlaps/clashes are possible. For example, both TE topologies
have TE nodes named S7, which, after renaming, appear in the merged
TE topology as S17 and S27, respectively.
Once the merging process is complete, the client can use the merged
TE topology for path computations across both domains -- for example,
to compute a TE path connecting C11 to C23.Dealing with Multiple Abstract TE Topologies Provided by the Same Provider
Based on local configuration, templates, and/or policies pushed by the
client, a given provider may expose more than one abstract TE
topology to the client. For example, one abstract TE topology could
be optimized based on a lowest-cost criterion, while another one
could be based on best possible delay metrics, while yet another one
could be based on maximum bandwidth availability for the client
services. Furthermore, the client may request all or some providers
to expose additional abstract TE topologies, possibly of a different
type and/or optimized differently, as compared to already-provided TE
topologies. In any case, the client should be prepared for a provider
to offer to the client more than one abstract TE topology.
It should be up to the client (based on the client's local configuration
and/or policies conveyed to the client by the client's clients) to decide
how to mix and match multiple abstract TE topologies provided by each or
some of the providers, as well as how to merge them into the client's
Native TE topologies. The client also decides how many such merged TE
topologies it needs to produce and maintain. For example, in addition to
the merged TE topology depicted in the upper part of , the client may merge the abstract TE topologies received
from the two providers, as shown in , into the client's additional
Native TE topologies, as shown in .
Note that allowing the client to mix and match multiple TE
topologies assumes that inter-domain plug IDs (rather than a remote
node ID / link ID) are used as the option for identifying neighboring domains and
inter-domain TE link resolution.
It is important to note that each of the three Native (merged) TE
topologies could be used by the client for computing TE paths for any
of the multi-domain services. The choice of which topology to use
for a given service depends on the service parameters/requirements,
the topology's style and optimization criteria, and the level of
detail.Modeling ConsiderationsNetwork Topology Building Blocks
The network topology building blocks are discussed in . The
TE topology model defined in this document augments and uses the
"ietf-network-topology" module defined in .Technology-Agnostic TE Topology Model
The TE topology model defined in this document is meant to be
network technology agnostic. Other technology-specific TE topology
models can augment and use the building blocks provided by this model,
as illustrated in .Model Structure
The high-level model structure defined by this document is as shown
below:Topology Identifiers
The TE topology is uniquely identified by a key that has three
constituents -- "topology-id", "provider-id", and "client-id". The
combination of "provider-id" and "topology-id" uniquely identifies a
Native TE topology on a given provider. "client-id" is used only
when Customized TE topologies come into play; a "client-id" value of "0" is
used for Native TE topologies.Generic TE Link Attributes
The model covers the definitions for generic TE link attributes --
bandwidth, administrative groups, SRLGs, switching capabilities, TE metric
extensions, etc.Generic TE Node Attributes
The model covers the definitions for generic TE node attributes.The definition of a generic connectivity matrix is shown below:The definition of a TTP Local Link Connectivity List is shown below:
The attributes directly under container "connectivity-matrices" are the
default attributes for all connectivity matrix entries when the per&nbhy;entry
corresponding attribute is not specified. When a per-entry attribute is
specified, it overrides the corresponding attribute directly under the
container "connectivity-matrices". The same rule applies to the attributes
directly under container "local&nbhy;link&nbhy;connectivities".
Each TTP MAY be supported by one or more
supporting TTPs. If the TE node hosting the TTP in question refers to
a supporting TE node, then the supporting TTPs are hosted by the
supporting TE node. If the TE node refers to an underlay TE topology,
the supporting TTPs are hosted by one or more specified TE nodes of
the underlay TE topology.TED Information Sources
The model allows each TE topological element to have multiple TE
information sources (OSPF-TE, ISIS-TE, Border Gateway Protocol - Link State
(BGP-LS), user-configured,
system-processed, other). Each information source is associated with
a credibility preference to indicate precedence. In scenarios where a
Customized TE topology is merged into a client's Native TE topology,
the merged topological elements would point to the corresponding
Customized TE topology as its information source.Overlay/Underlay Relationship
The model captures the overlay and underlay relationship for TE
nodes/links. For example, in networks where multiple TE topologies
are built hierarchically, this model allows the user to start from a
specific topological element in the topmost topology and traverse
all the way down to the supporting topological elements in the
bottommost topology.
This relationship is captured via the "underlay-topology" field for
the node and via the "underlay" field for the link. The use of these
fields is optional, and this functionality is tagged as a "feature"
("te-topology-hierarchy").Templates
The data model provides users with the ability to define
templates and apply them to link and node configurations. The use of
the "template" configuration is optional, and this functionality is tagged
as a "feature" ("template"). ../../../../te/templates/node-template/name
| {template}?
augment /nw:networks/nw:network/nt:link:
+--rw te!
+--rw te-link-template*
| -> ../../../../te/templates/link-template/name
| {template}?
augment /nw:networks:
+--rw te!
+--rw templates
+--rw node-template* [name] {template}?
| +--rw name
| | te-types:te-template-name
| +--rw priority? uint16
| +--rw reference-change-policy? enumeration
| +--rw te-node-attributes
..........
+--rw link-template* [name] {template}?
+--rw name
| te-types:te-template-name
+--rw priority? uint16
+--rw reference-change-policy? enumeration
+--rw te-link-attributes
..........]]>
Multiple templates can be specified for a configuration element. When
two or more templates specify values for the same configuration
field, the value from the template with the highest priority is used.
The range of the priority is from 0 to 65535, with a lower number
indicating a higher priority. The "reference-change-policy" parameter specifies
the action that needs to be taken when the template changes on a
configuration element that has a reference to this template. The
choices of action include taking no action, rejecting the change to
the template, and applying the change to the corresponding
configuration.Scheduling Parameters
The model allows time-scheduling parameters to be specified for each
topological element or for the topology as a whole. These parameters
allow the provider to present different topological views to the
client at different time slots. The use of time-scheduling parameters is
optional.
The YANG data model for configuration scheduling is defined in , which allows specifying
configuration schedules without altering this data model.Notifications
Notifications are a key component of any topology data model. and
define a subscription mechanism and a push
mechanism for YANG datastores. These mechanisms currently allow the user
to:
Subscribe to notifications on a per-client basis.
Specify subtree filters or XML Path Language (XPath) filters so that only
contents of interest will be sent.
Specify either periodic or on-demand notifications.
Guidance for Writing Technology-Specific TE Topology Augmentations
The TE topology model defined in this document is technology agnostic,
as it defines concepts, abstractions, and attributes that are common
across multiple network technologies. It is envisioned that this base
model will be widely used when defining technology-specific TE
topology models for various layer networks.
, , and
are some examples of
technology-specific TE topology models. Writers of such models are encouraged to
augment the basic TE topology model's containers, such as those for TE
topologies, TE nodes, TE links, Link Termination Points (LTPs), Tunnel
Termination Points (TTPs), bandwidth, and labels, with the layer-specific
attributes instead of defining new containers.
Consider the following technology-specific example-topology model:
The technology-specific TE bandwidth for this example topology can be
specified using the following augment statements:
The technology-specific TE label for this example topology can be
specified using the following augment statements:
The example YANG module that implements the above example topology is
provided in .TE Topology YANG Module
This module references , , , , , , , , , , , , , , , , , , , , , , , , and .
WG List:
Editor: Xufeng Liu
Editor: Igor Bryskin
Editor: Vishnu Pavan Beeram
Editor: Tarek Saad
Editor: Himanshu Shah
Editor: Oscar Gonzalez de Dios
";
description
"This YANG module defines a TE topology model for representing,
retrieving, and manipulating technology-agnostic TE topologies.
Copyright (c) 2020 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 Simplified 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 8795; see the
RFC itself for full legal notices.";
revision 2020-08-06 {
description
"Initial revision.";
reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
/*
* Features
*/
feature nsrlg {
description
"This feature indicates that the system supports NSRLGs
(Non-Shared Risk Link Groups).";
}
feature te-topology-hierarchy {
description
"This feature indicates that the system allows an underlay
and/or overlay TE topology hierarchy.";
}
feature template {
description
"This feature indicates that the system supports
template configuration.";
}
/*
* Typedefs
*/
typedef geographic-coordinate-degree {
type decimal64 {
fraction-digits 8;
}
description
"Decimal degree (DD) used to express latitude and longitude
geographic coordinates.";
}
// geographic-coordinate-degree
typedef te-info-source {
type enumeration {
enum unknown {
description
"The source is unknown.";
}
enum locally-configured {
description
"Configured entity.";
}
enum ospfv2 {
description
"OSPFv2.";
}
enum ospfv3 {
description
"OSPFv3.";
}
enum isis {
description
"IS-IS.";
}
enum bgp-ls {
description
"BGP-LS.";
reference
"RFC 7752: North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP";
}
enum system-processed {
description
"System-processed entity.";
}
enum other {
description
"Other source.";
}
}
description
"Describes the type of source that has provided the
related information, and the source's credibility.";
}
// te-info-source
/*
* Groupings
*/
grouping connectivity-matrix-entry-path-attributes {
description
"Attributes of a connectivity matrix entry.";
leaf is-allowed {
type boolean;
description
"'true' - switching is allowed;
'false' - switching is disallowed.";
}
container underlay {
if-feature "te-topology-hierarchy";
description
"Attributes of the TE link underlay.";
reference
"RFC 4206: Label Switched Paths (LSP) Hierarchy with
Generalized Multi-Protocol Label Switching (GMPLS)
Traffic Engineering (TE)";
uses te-link-underlay-attributes;
}
uses te-types:generic-path-constraints;
uses te-types:generic-path-optimization;
uses te-types:generic-path-properties;
}
// connectivity-matrix-entry-path-attributes
grouping geolocation-container {
description
"Contains a GPS location.";
container geolocation {
config false;
description
"Contains a GPS location.";
leaf altitude {
type int64;
units "millimeters";
description
"Distance above sea level.";
}
leaf latitude {
type geographic-coordinate-degree {
range "-90..90";
}
description
"Relative position north or south on the Earth's surface.";
}
leaf longitude {
type geographic-coordinate-degree {
range "-180..180";
}
description
"Angular distance east or west on the Earth's surface.";
}
}
// geolocation
}
// geolocation-container
grouping information-source-state-attributes {
description
"The attributes identifying the source that has provided the
related information, and the source's credibility.";
leaf credibility-preference {
type uint16;
description
"The preference value for calculating the Traffic
Engineering database credibility value used for
tie-break selection between different information-source
values. A higher value is preferable.";
}
leaf logical-network-element {
type string;
description
"When applicable, this is the name of a logical network
element from which the information is learned.";
}
leaf network-instance {
type string;
description
"When applicable, this is the name of a network instance
from which the information is learned.";
}
}
// information-source-state-attributes
grouping information-source-per-link-attributes {
description
"Per-node container of the attributes identifying the source
that has provided the related information, and the source's
credibility.";
leaf information-source {
type te-info-source;
config false;
description
"Indicates the type of information source.";
}
leaf information-source-instance {
type string;
config false;
description
"The name indicating the instance of the information
source.";
}
container information-source-state {
config false;
description
"Contains state attributes related to the information
source.";
uses information-source-state-attributes;
container topology {
description
"When the information is processed by the system,
the attributes in this container indicate which topology
is used to generate the result information.";
uses nt:link-ref;
}
}
}
// information-source-per-link-attributes
grouping information-source-per-node-attributes {
description
"Per-node container of the attributes identifying the source
that has provided the related information, and the source's
credibility.";
leaf information-source {
type te-info-source;
config false;
description
"Indicates the type of information source.";
}
leaf information-source-instance {
type string;
config false;
description
"The name indicating the instance of the information
source.";
}
container information-source-state {
config false;
description
"Contains state attributes related to the information
source.";
uses information-source-state-attributes;
container topology {
description
"When the information is processed by the system,
the attributes in this container indicate which topology
is used to generate the result information.";
uses nw:node-ref;
}
}
}
// information-source-per-node-attributes
grouping interface-switching-capability-list {
description
"List of Interface Switching Capability Descriptors (ISCDs).";
list interface-switching-capability {
key "switching-capability encoding";
description
"List of ISCDs for this link.";
reference
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description
RFC 4203: OSPF Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS)";
leaf switching-capability {
type identityref {
base te-types:switching-capabilities;
}
description
"Switching capability for this interface.";
}
leaf encoding {
type identityref {
base te-types:lsp-encoding-types;
}
description
"Encoding supported by this interface.";
}
uses te-link-iscd-attributes;
}
// interface-switching-capability
}
// interface-switching-capability-list
grouping statistics-per-link {
description
"Statistics attributes per TE link.";
leaf discontinuity-time {
type yang:date-and-time;
description
"The time of the most recent occasion at which any one or
more of this interface's counters suffered a
discontinuity. If no such discontinuities have occurred
since the last re-initialization of the local management
subsystem, then this node contains the time the local
management subsystem re-initialized itself.";
}
/* Administrative attributes */
leaf disables {
type yang:counter32;
description
"Number of times that a link was disabled.";
}
leaf enables {
type yang:counter32;
description
"Number of times that a link was enabled.";
}
leaf maintenance-clears {
type yang:counter32;
description
"Number of times that a link was taken out of maintenance.";
}
leaf maintenance-sets {
type yang:counter32;
description
"Number of times that a link was put in maintenance.";
}
leaf modifies {
type yang:counter32;
description
"Number of times that a link was modified.";
}
/* Operational attributes */
leaf downs {
type yang:counter32;
description
"Number of times that a link was set to an operational state
of 'down'.";
}
leaf ups {
type yang:counter32;
description
"Number of times that a link was set to an operational state
of 'up'.";
}
/* Recovery attributes */
leaf fault-clears {
type yang:counter32;
description
"Number of times that a link experienced a fault-clear
event.";
}
leaf fault-detects {
type yang:counter32;
description
"Number of times that a link experienced fault detection.";
}
leaf protection-switches {
type yang:counter32;
description
"Number of times that a link experienced protection
switchover.";
}
leaf protection-reverts {
type yang:counter32;
description
"Number of times that a link experienced protection
reversion.";
}
leaf restoration-failures {
type yang:counter32;
description
"Number of times that a link experienced restoration
failure.";
}
leaf restoration-starts {
type yang:counter32;
description
"Number of times that a link experienced restoration
start.";
}
leaf restoration-successes {
type yang:counter32;
description
"Number of times that a link experienced restoration
success.";
}
leaf restoration-reversion-failures {
type yang:counter32;
description
"Number of times that a link experienced restoration
reversion failure.";
}
leaf restoration-reversion-starts {
type yang:counter32;
description
"Number of times that a link experienced restoration
reversion start.";
}
leaf restoration-reversion-successes {
type yang:counter32;
description
"Number of times that a link experienced restoration
reversion success.";
}
}
// statistics-per-link
grouping statistics-per-node {
description
"Statistics attributes per TE node.";
leaf discontinuity-time {
type yang:date-and-time;
description
"The time of the most recent occasion at which any one or
more of this interface's counters suffered a
discontinuity. If no such discontinuities have occurred
since the last re-initialization of the local management
subsystem, then this node contains the time the local
management subsystem re-initialized itself.";
}
container node {
description
"Contains statistics attributes at the TE node level.";
leaf disables {
type yang:counter32;
description
"Number of times that a node was disabled.";
}
leaf enables {
type yang:counter32;
description
"Number of times that a node was enabled.";
}
leaf maintenance-sets {
type yang:counter32;
description
"Number of times that a node was put in maintenance.";
}
leaf maintenance-clears {
type yang:counter32;
description
"Number of times that a node was taken out of
maintenance.";
}
leaf modifies {
type yang:counter32;
description
"Number of times that a node was modified.";
}
}
// node
container connectivity-matrix-entry {
description
"Contains statistics attributes at the level of a
connectivity matrix entry.";
leaf creates {
type yang:counter32;
description
"Number of times that a connectivity matrix entry was
created.";
reference
"RFC 6241: Network Configuration Protocol (NETCONF),
Section 7.2, 'create' operation";
}
leaf deletes {
type yang:counter32;
description
"Number of times that a connectivity matrix entry was
deleted.";
reference
"RFC 6241: Network Configuration Protocol (NETCONF),
Section 7.2, 'delete' operation";
}
leaf disables {
type yang:counter32;
description
"Number of times that a connectivity matrix entry was
disabled.";
}
leaf enables {
type yang:counter32;
description
"Number of times that a connectivity matrix entry was
enabled.";
}
leaf modifies {
type yang:counter32;
description
"Number of times that a connectivity matrix entry was
modified.";
}
}
// connectivity-matrix-entry
}
// statistics-per-node
grouping statistics-per-ttp {
description
"Statistics attributes per TE TTP (Tunnel Termination Point).";
leaf discontinuity-time {
type yang:date-and-time;
description
"The time of the most recent occasion at which any one or
more of this interface's counters suffered a
discontinuity. If no such discontinuities have occurred
since the last re-initialization of the local management
subsystem, then this node contains the time the local
management subsystem re-initialized itself.";
}
container tunnel-termination-point {
description
"Contains statistics attributes at the TE TTP level.";
/* Administrative attributes */
leaf disables {
type yang:counter32;
description
"Number of times that a TTP was disabled.";
}
leaf enables {
type yang:counter32;
description
"Number of times that a TTP was enabled.";
}
leaf maintenance-clears {
type yang:counter32;
description
"Number of times that a TTP was taken out of maintenance.";
}
leaf maintenance-sets {
type yang:counter32;
description
"Number of times that a TTP was put in maintenance.";
}
leaf modifies {
type yang:counter32;
description
"Number of times that a TTP was modified.";
}
/* Operational attributes */
leaf downs {
type yang:counter32;
description
"Number of times that a TTP was set to an operational state
of 'down'.";
}
leaf ups {
type yang:counter32;
description
"Number of times that a TTP was set to an operational state
of 'up'.";
}
leaf in-service-clears {
type yang:counter32;
description
"Number of times that a TTP was taken out of service
(TE tunnel was released).";
}
leaf in-service-sets {
type yang:counter32;
description
"Number of times that a TTP was put in service by a TE
tunnel (TE tunnel was set up).";
}
}
// tunnel-termination-point
container local-link-connectivity {
description
"Contains statistics attributes at the TE LLCL (Local Link
Connectivity List) level.";
leaf creates {
type yang:counter32;
description
"Number of times that an LLCL entry was created.";
reference
"RFC 6241: Network Configuration Protocol (NETCONF),
Section 7.2, 'create' operation";
}
leaf deletes {
type yang:counter32;
description
"Number of times that an LLCL entry was deleted.";
reference
"RFC 6241: Network Configuration Protocol (NETCONF),
Section 7.2, 'delete' operation";
}
leaf disables {
type yang:counter32;
description
"Number of times that an LLCL entry was disabled.";
}
leaf enables {
type yang:counter32;
description
"Number of times that an LLCL entry was enabled.";
}
leaf modifies {
type yang:counter32;
description
"Number of times that an LLCL entry was modified.";
}
}
// local-link-connectivity
}
// statistics-per-ttp
grouping te-link-augment {
description
"Augmentation for a TE link.";
uses te-link-config;
uses te-link-state-derived;
container statistics {
config false;
description
"Statistics data.";
uses statistics-per-link;
}
}
// te-link-augment
grouping te-link-config {
description
"TE link configuration grouping.";
choice bundle-stack-level {
description
"The TE link can be partitioned into bundled links or
component links.";
case bundle {
container bundled-links {
description
"A set of bundled links.";
reference
"RFC 4201: Link Bundling in MPLS Traffic
Engineering (TE)";
list bundled-link {
key "sequence";
description
"Specifies a bundled interface that is
further partitioned.";
leaf sequence {
type uint32;
description
"Identifies the sequence in the bundle.";
}
}
}
}
case component {
container component-links {
description
"A set of component links.";
list component-link {
key "sequence";
description
"Specifies a component interface that is
sufficient to unambiguously identify the
appropriate resources.";
leaf sequence {
type uint32;
description
"Identifies the sequence in the bundle.";
}
leaf src-interface-ref {
type string;
description
"Reference to a component link interface on the
source node.";
}
leaf des-interface-ref {
type string;
description
"Reference to a component link interface on the
destination node.";
}
}
}
}
}
// bundle-stack-level
leaf-list te-link-template {
if-feature "template";
type leafref {
path "../../../../te/templates/link-template/name";
}
description
"The reference to a TE link template.";
}
uses te-link-config-attributes;
}
// te-link-config
grouping te-link-config-attributes {
description
"Link configuration attributes in a TE topology.";
container te-link-attributes {
description
"Link attributes in a TE topology.";
leaf access-type {
type te-types:te-link-access-type;
description
"Link access type, which can be point-to-point or
multi-access.";
}
container external-domain {
description
"For an inter-domain link, specifies the attributes of
the remote end of the link, to facilitate the signaling at
the local end.";
uses nw:network-ref;
leaf remote-te-node-id {
type te-types:te-node-id;
description
"Remote TE node identifier, used together with
'remote-te-link-tp-id' to identify the remote Link
Termination Point (LTP) in a different domain.";
}
leaf remote-te-link-tp-id {
type te-types:te-tp-id;
description
"Remote TE LTP identifier, used together with
'remote-te-node-id' to identify the remote LTP in a
different domain.";
}
}
leaf is-abstract {
type empty;
description
"Present if the link is abstract.";
}
leaf name {
type string;
description
"Link name.";
}
container underlay {
if-feature "te-topology-hierarchy";
description
"Attributes of the TE link underlay.";
reference
"RFC 4206: Label Switched Paths (LSP) Hierarchy with
Generalized Multi-Protocol Label Switching (GMPLS)
Traffic Engineering (TE)";
uses te-link-underlay-attributes;
}
leaf admin-status {
type te-types:te-admin-status;
description
"The administrative state of the link.";
}
uses te-link-info-attributes;
}
// te-link-attributes
}
// te-link-config-attributes
grouping te-link-info-attributes {
description
"Advertised TE information attributes.";
leaf link-index {
type uint64;
description
"The link identifier. If OSPF is used, this object
represents an ospfLsdbID. If IS-IS is used, this object
represents an isisLSPID. If a locally configured link is
used, this object represents a unique value, which is
locally defined in a router.";
}
leaf administrative-group {
type te-types:admin-groups;
description
"Administrative group or color of the link.
This attribute covers both administrative groups (defined
in RFCs 3630 and 5305) and Extended Administrative Groups
(defined in RFC 7308).";
reference
"RFC 3630: Traffic Engineering (TE) Extensions to OSPF
Version 2
RFC 5305: IS-IS Extensions for Traffic Engineering
RFC 7308: Extended Administrative Groups in MPLS Traffic
Engineering (MPLS-TE)";
}
uses interface-switching-capability-list;
uses te-types:label-set-info;
leaf link-protection-type {
type identityref {
base te-types:link-protection-type;
}
description
"Link Protection Type desired for this link.";
reference
"RFC 4202: Routing Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)";
}
container max-link-bandwidth {
uses te-types:te-bandwidth;
description
"Maximum bandwidth that can be seen on this link in this
direction. Units are in bytes per second.";
reference
"RFC 3630: Traffic Engineering (TE) Extensions to OSPF
Version 2
RFC 5305: IS-IS Extensions for Traffic Engineering";
}
container max-resv-link-bandwidth {
uses te-types:te-bandwidth;
description
"Maximum amount of bandwidth that can be reserved in this
direction in this link. Units are in bytes per second.";
reference
"RFC 3630: Traffic Engineering (TE) Extensions to OSPF
Version 2
RFC 5305: IS-IS Extensions for Traffic Engineering";
}
list unreserved-bandwidth {
key "priority";
max-elements 8;
description
"Unreserved bandwidth for priority levels 0-7. Units are in
bytes per second.";
reference
"RFC 3630: Traffic Engineering (TE) Extensions to OSPF
Version 2
RFC 5305: IS-IS Extensions for Traffic Engineering";
leaf priority {
type uint8 {
range "0..7";
}
description
"Priority.";
}
uses te-types:te-bandwidth;
}
leaf te-default-metric {
type uint32;
description
"Traffic Engineering metric.";
reference
"RFC 3630: Traffic Engineering (TE) Extensions to OSPF
Version 2
RFC 5305: IS-IS Extensions for Traffic Engineering";
}
leaf te-delay-metric {
type uint32;
description
"Traffic Engineering delay metric.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions";
}
leaf te-igp-metric {
type uint32;
description
"IGP metric used for Traffic Engineering.";
reference
"RFC 3785: Use of Interior Gateway Protocol (IGP) Metric as a
second MPLS Traffic Engineering (TE) Metric";
}
container te-srlgs {
description
"Contains a list of SRLGs.";
leaf-list value {
type te-types:srlg;
description
"SRLG value.";
reference
"RFC 4202: Routing Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)";
}
}
container te-nsrlgs {
if-feature "nsrlg";
description
"Contains a list of NSRLGs (Non-Shared Risk Link Groups).
When an abstract TE link is configured, this list specifies
the request that underlay TE paths need to be mutually
disjoint with other TE links in the same groups.";
leaf-list id {
type uint32;
description
"NSRLG ID, uniquely configured within a topology.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery";
}
}
}
// te-link-info-attributes
grouping te-link-iscd-attributes {
description
"TE link ISCD attributes.";
reference
"RFC 4203: OSPF Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS), Section 1.4";
list max-lsp-bandwidth {
key "priority";
max-elements 8;
description
"Maximum Label Switched Path (LSP) bandwidth at
priorities 0-7.";
leaf priority {
type uint8 {
range "0..7";
}
description
"Priority.";
}
uses te-types:te-bandwidth;
}
}
// te-link-iscd-attributes
grouping te-link-state-derived {
description
"Link state attributes in a TE topology.";
leaf oper-status {
type te-types:te-oper-status;
config false;
description
"The current operational state of the link.";
}
leaf is-transitional {
type empty;
config false;
description
"Present if the link is transitional; used as an
alternative approach in lieu of 'inter-layer-lock-id'
for path computation in a TE topology covering multiple
layers or multiple regions.";
reference
"RFC 5212: Requirements for GMPLS-Based Multi-Region and
Multi-Layer Networks (MRN/MLN)
RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions
for Multi-Layer and Multi-Region Networks (MLN/MRN)";
}
uses information-source-per-link-attributes;
list information-source-entry {
key "information-source information-source-instance";
config false;
description
"A list of information sources learned, including the source
that is used.";
uses information-source-per-link-attributes;
uses te-link-info-attributes;
}
container recovery {
config false;
description
"Status of the recovery process.";
leaf restoration-status {
type te-types:te-recovery-status;
description
"Restoration status.";
}
leaf protection-status {
type te-types:te-recovery-status;
description
"Protection status.";
}
}
container underlay {
if-feature "te-topology-hierarchy";
config false;
description
"State attributes for the TE link underlay.";
leaf dynamic {
type boolean;
description
"'true' if the underlay is dynamically created.";
}
leaf committed {
type boolean;
description
"'true' if the underlay is committed.";
}
}
}
// te-link-state-derived
grouping te-link-underlay-attributes {
description
"Attributes for the TE link underlay.";
reference
"RFC 4206: Label Switched Paths (LSP) Hierarchy with
Generalized Multi-Protocol Label Switching (GMPLS)
Traffic Engineering (TE)";
leaf enabled {
type boolean;
description
"'true' if the underlay is enabled.
'false' if the underlay is disabled.";
}
container primary-path {
description
"The service path on the underlay topology that
supports this link.";
uses nw:network-ref;
list path-element {
key "path-element-id";
description
"A list of path elements describing the service path.";
leaf path-element-id {
type uint32;
description
"To identify the element in a path.";
}
uses te-path-element;
}
}
// primary-path
list backup-path {
key "index";
description
"A list of backup service paths on the underlay topology that
protect the underlay primary path. If the primary path is
not protected, the list contains zero elements. If the
primary path is protected, the list contains one or more
elements.";
leaf index {
type uint32;
description
"A sequence number to identify a backup path.";
}
uses nw:network-ref;
list path-element {
key "path-element-id";
description
"A list of path elements describing the backup service
path.";
leaf path-element-id {
type uint32;
description
"To identify the element in a path.";
}
uses te-path-element;
}
}
// backup-path
leaf protection-type {
type identityref {
base te-types:lsp-protection-type;
}
description
"Underlay protection type desired for this link.";
}
container tunnel-termination-points {
description
"Underlay TTPs desired for this link.";
leaf source {
type binary;
description
"Source TTP identifier.";
}
leaf destination {
type binary;
description
"Destination TTP identifier.";
}
}
container tunnels {
description
"Underlay TE tunnels supporting this TE link.";
leaf sharing {
type boolean;
default "true";
description
"'true' if the underlay tunnel can be shared with other
TE links;
'false' if the underlay tunnel is dedicated to this
TE link.
This leaf is the default option for all TE tunnels
and may be overridden by the per-TE-tunnel value.";
}
list tunnel {
key "tunnel-name";
description
"Zero, one, or more underlay TE tunnels that support this
TE link.";
leaf tunnel-name {
type string;
description
"A tunnel name uniquely identifies an underlay TE tunnel,
used together with the 'source-node' value for this
link.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
}
leaf sharing {
type boolean;
description
"'true' if the underlay tunnel can be shared with other
TE links;
'false' if the underlay tunnel is dedicated to this
TE link.";
}
}
// tunnel
}
// tunnels
}
// te-link-underlay-attributes
grouping te-node-augment {
description
"Augmentation for a TE node.";
uses te-node-config;
uses te-node-state-derived;
container statistics {
config false;
description
"Statistics data.";
uses statistics-per-node;
}
list tunnel-termination-point {
key "tunnel-tp-id";
description
"A termination point can terminate a tunnel.";
leaf tunnel-tp-id {
type binary;
description
"TTP identifier.";
}
uses te-node-tunnel-termination-point-config;
leaf oper-status {
type te-types:te-oper-status;
config false;
description
"The current operational state of the TTP.";
}
uses geolocation-container;
container statistics {
config false;
description
"Statistics data.";
uses statistics-per-ttp;
}
// Relationship to other TTPs
list supporting-tunnel-termination-point {
key "node-ref tunnel-tp-ref";
description
"Identifies the TTPs on which this TTP depends.";
leaf node-ref {
type inet:uri;
description
"This leaf identifies the node in which the supporting
TTP is present.
This node is either the supporting node or a node in
an underlay topology.";
}
leaf tunnel-tp-ref {
type binary;
description
"Reference to a TTP that is in either the supporting node
or a node in an underlay topology.";
}
}
// supporting-tunnel-termination-point
}
// tunnel-termination-point
}
// te-node-augment
grouping te-node-config {
description
"TE node configuration grouping.";
leaf-list te-node-template {
if-feature "template";
type leafref {
path "../../../../te/templates/node-template/name";
}
description
"The reference to a TE node template.";
}
uses te-node-config-attributes;
}
// te-node-config
grouping te-node-config-attributes {
description
"Configuration node attributes in a TE topology.";
container te-node-attributes {
description
"Contains node attributes in a TE topology.";
leaf admin-status {
type te-types:te-admin-status;
description
"The administrative state of the link.";
}
uses te-node-connectivity-matrices;
uses te-node-info-attributes;
}
}
// te-node-config-attributes
grouping te-node-config-attributes-template {
description
"Configuration node attributes for a template in a TE
topology.";
container te-node-attributes {
description
"Contains node attributes in a TE topology.";
leaf admin-status {
type te-types:te-admin-status;
description
"The administrative state of the link.";
}
uses te-node-info-attributes;
}
}
// te-node-config-attributes-template
grouping te-node-connectivity-matrices {
description
"Connectivity matrix on a TE node.";
container connectivity-matrices {
description
"Contains a connectivity matrix on a TE node.";
leaf number-of-entries {
type uint16;
description
"The number of connectivity matrix entries.
If this number is specified in the configuration request,
the number is the requested number of entries, which may
not all be listed in the list;
if this number is reported in the state data,
the number is the current number of operational entries.";
}
uses te-types:label-set-info;
uses connectivity-matrix-entry-path-attributes;
list connectivity-matrix {
key "id";
description
"Represents a node's switching limitations, i.e.,
limitations in the interconnecting network TE links
across the node.";
reference
"RFC 7579: General Network Element Constraint Encoding
for GMPLS-Controlled Networks";
leaf id {
type uint32;
description
"Identifies the connectivity matrix entry.";
}
}
// connectivity-matrix
}
// connectivity-matrices
}
// te-node-connectivity-matrices
grouping te-node-connectivity-matrix-attributes {
description
"Termination point references of a connectivity matrix entry.";
container from {
description
"Reference to a source LTP.";
leaf tp-ref {
type leafref {
path "../../../../../../nt:termination-point/nt:tp-id";
}
description
"Relative reference to a termination point.";
}
uses te-types:label-set-info;
}
container to {
description
"Reference to a destination LTP.";
leaf tp-ref {
type leafref {
path "../../../../../../nt:termination-point/nt:tp-id";
}
description
"Relative reference to a termination point.";
}
uses te-types:label-set-info;
}
uses connectivity-matrix-entry-path-attributes;
}
// te-node-connectivity-matrix-attributes
grouping te-node-info-attributes {
description
"Advertised TE information attributes.";
leaf domain-id {
type uint32;
description
"Identifies the domain to which this node belongs.
This attribute is used to support inter-domain links.";
reference
"RFC 5152: A Per-Domain Path Computation Method for
Establishing Inter-Domain Traffic Engineering (TE)
Label Switched Paths (LSPs)
RFC 5316: ISIS Extensions in Support of Inter-Autonomous
System (AS) MPLS and GMPLS Traffic Engineering
RFC 5392: OSPF Extensions in Support of Inter-Autonomous
System (AS) MPLS and GMPLS Traffic Engineering";
}
leaf is-abstract {
type empty;
description
"Present if the node is abstract; not present if the node
is actual.";
}
leaf name {
type string;
description
"Node name.";
}
leaf-list signaling-address {
type inet:ip-address;
description
"The node's signaling address.";
}
container underlay-topology {
if-feature "te-topology-hierarchy";
description
"When an abstract node encapsulates a topology, the
attributes in this container point to said topology.";
uses nw:network-ref;
}
}
// te-node-info-attributes
grouping te-node-state-derived {
description
"Node state attributes in a TE topology.";
leaf oper-status {
type te-types:te-oper-status;
config false;
description
"The current operational state of the node.";
}
uses geolocation-container;
leaf is-multi-access-dr {
type empty;
config false;
description
"The presence of this attribute indicates that this TE node
is a pseudonode elected as a designated router.";
reference
"RFC 1195: Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments
RFC 3630: Traffic Engineering (TE) Extensions to OSPF
Version 2";
}
uses information-source-per-node-attributes;
list information-source-entry {
key "information-source information-source-instance";
config false;
description
"A list of information sources learned, including the source
that is used.";
uses information-source-per-node-attributes;
uses te-node-connectivity-matrices;
uses te-node-info-attributes;
}
}
// te-node-state-derived
grouping te-node-tunnel-termination-point-config {
description
"Termination capability of a TTP on a TE node.";
uses te-node-tunnel-termination-point-config-attributes;
container local-link-connectivities {
description
"Contains an LLCL for a TTP on a TE node.";
leaf number-of-entries {
type uint16;
description
"The number of LLCL entries.
If this number is specified in the configuration request,
the number is the requested number of entries, which may
not all be listed in the list;
if this number is reported in the state data,
the number is the current number of operational entries.";
}
uses te-types:label-set-info;
uses connectivity-matrix-entry-path-attributes;
}
}
// te-node-tunnel-termination-point-config
grouping te-node-tunnel-termination-point-config-attributes {
description
"Configuration attributes of a TTP on a TE node.";
leaf admin-status {
type te-types:te-admin-status;
description
"The administrative state of the TTP.";
}
leaf name {
type string;
description
"A descriptive name for the TTP.";
}
leaf switching-capability {
type identityref {
base te-types:switching-capabilities;
}
description
"Switching capability for this interface.";
}
leaf encoding {
type identityref {
base te-types:lsp-encoding-types;
}
description
"Encoding supported by this interface.";
}
leaf-list inter-layer-lock-id {
type uint32;
description
"Inter-layer lock ID, used for path computation in a TE
topology covering multiple layers or multiple regions.";
reference
"RFC 5212: Requirements for GMPLS-Based Multi-Region and
Multi-Layer Networks (MRN/MLN)
RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions
for Multi-Layer and Multi-Region Networks (MLN/MRN)";
}
leaf protection-type {
type identityref {
base te-types:lsp-protection-type;
}
description
"The protection type that this TTP is capable of.";
}
container client-layer-adaptation {
description
"Contains capability information to support a client-layer
adaptation in a multi-layer topology.";
list switching-capability {
key "switching-capability encoding";
description
"List of supported switching capabilities.";
reference
"RFC 4202: Routing Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)
RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions
for Multi-Layer and Multi-Region Networks (MLN/MRN)";
leaf switching-capability {
type identityref {
base te-types:switching-capabilities;
}
description
"Switching capability for the client-layer adaptation.";
}
leaf encoding {
type identityref {
base te-types:lsp-encoding-types;
}
description
"Encoding supported by the client-layer adaptation.";
}
uses te-types:te-bandwidth;
}
}
}
// te-node-tunnel-termination-point-config-attributes
grouping te-node-tunnel-termination-point-llc-list {
description
"LLCL of a TTP on a TE node.";
list local-link-connectivity {
key "link-tp-ref";
description
"The termination capabilities between the TTP and the LTP.
This capability information can be used to compute
the tunnel path.
The Interface Adjustment Capability Descriptors (IACDs)
(defined in RFC 6001) on each LTP can be derived from
this list.";
reference
"RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions
for Multi-Layer and Multi-Region Networks (MLN/MRN)";
leaf link-tp-ref {
type leafref {
path "../../../../../nt:termination-point/nt:tp-id";
}
description
"LTP.";
}
uses te-types:label-set-info;
uses connectivity-matrix-entry-path-attributes;
}
}
// te-node-tunnel-termination-point-llc-list
grouping te-path-element {
description
"A group of attributes defining an element in a TE path,
such as a TE node, TE link, TE atomic resource, or label.";
uses te-types:explicit-route-hop;
}
// te-path-element
grouping te-termination-point-augment {
description
"Augmentation for a TE termination point.";
leaf te-tp-id {
type te-types:te-tp-id;
description
"An identifier that uniquely identifies a TE termination
point.";
}
container te {
must '../te-tp-id';
presence "TE support";
description
"Indicates TE support.";
uses te-termination-point-config;
leaf oper-status {
type te-types:te-oper-status;
config false;
description
"The current operational state of the LTP.";
}
uses geolocation-container;
}
}
// te-termination-point-augment
grouping te-termination-point-config {
description
"TE termination point configuration grouping.";
leaf admin-status {
type te-types:te-admin-status;
description
"The administrative state of the LTP.";
}
leaf name {
type string;
description
"A descriptive name for the LTP.";
}
uses interface-switching-capability-list;
leaf inter-domain-plug-id {
type binary;
description
"A network-wide unique number that identifies on the
network a connection that supports a given inter-domain
TE link. This is a more flexible alternative to specifying
'remote-te-node-id' and 'remote-te-link-tp-id' on a TE link
when the provider either does not know 'remote-te-node-id'
and 'remote-te-link-tp-id' or needs to give the client the
flexibility to mix and match multiple topologies.";
}
leaf-list inter-layer-lock-id {
type uint32;
description
"Inter-layer lock ID, used for path computation in a TE
topology covering multiple layers or multiple regions.";
reference
"RFC 5212: Requirements for GMPLS-Based Multi-Region and
Multi-Layer Networks (MRN/MLN)
RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions
for Multi-Layer and Multi-Region Networks (MLN/MRN)";
}
}
// te-termination-point-config
grouping te-topologies-augment {
description
"Augmentation for TE topologies.";
container te {
presence "TE support";
description
"Indicates TE support.";
container templates {
description
"Configuration parameters for templates used for a TE
topology.";
list node-template {
if-feature "template";
key "name";
leaf name {
type te-types:te-template-name;
description
"The name to identify a TE node template.";
}
description
"The list of TE node templates used to define sharable
and reusable TE node attributes.";
uses template-attributes;
uses te-node-config-attributes-template;
}
// node-template
list link-template {
if-feature "template";
key "name";
leaf name {
type te-types:te-template-name;
description
"The name to identify a TE link template.";
}
description
"The list of TE link templates used to define sharable
and reusable TE link attributes.";
uses template-attributes;
uses te-link-config-attributes;
}
// link-template
}
// templates
}
// te
}
// te-topologies-augment
grouping te-topology-augment {
description
"Augmentation for a TE topology.";
uses te-types:te-topology-identifier;
container te {
must '../te-topology-identifier/provider-id'
+ ' and ../te-topology-identifier/client-id'
+ ' and ../te-topology-identifier/topology-id';
presence "TE support";
description
"Indicates TE support.";
uses te-topology-config;
uses geolocation-container;
}
}
// te-topology-augment
grouping te-topology-config {
description
"TE topology configuration grouping.";
leaf name {
type string;
description
"Name of the TE topology. This attribute is optional and can
be specified by the operator to describe the TE topology,
which can be useful when 'network-id' (RFC 8345) is not
descriptive and not modifiable because of being generated
by the system.";
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
leaf preference {
type uint8 {
range "1..255";
}
description
"Specifies a preference for this topology. A lower number
indicates a higher preference.";
}
leaf optimization-criterion {
type identityref {
base te-types:objective-function-type;
}
description
"Optimization criterion applied to this topology.";
reference
"RFC 3272: Overview and Principles of Internet Traffic
Engineering";
}
list nsrlg {
if-feature "nsrlg";
key "id";
description
"List of NSRLGs (Non-Shared Risk Link Groups).";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery";
leaf id {
type uint32;
description
"Identifies the NSRLG entry.";
}
leaf disjointness {
type te-types:te-path-disjointness;
description
"The type of resource disjointness.";
}
}
// nsrlg
}
// te-topology-config
grouping template-attributes {
description
"Common attributes for all templates.";
leaf priority {
type uint16;
description
"The preference value for resolving conflicts between
different templates. When two or more templates specify
values for one configuration attribute, the value from the
template with the highest priority is used.
A lower number indicates a higher priority. The highest
priority is 0.";
}
leaf reference-change-policy {
type enumeration {
enum no-action {
description
"When an attribute changes in this template, the
configuration node referring to this template does
not take any action.";
}
enum not-allowed {
description
"When any configuration object has a reference to this
template, changing this template is not allowed.";
}
enum cascade {
description
"When an attribute changes in this template, the
configuration object referring to this template applies
the new attribute value to the corresponding
configuration.";
}
}
description
"This attribute specifies the action taken for a
configuration node that has a reference to this template.";
}
}
// template-attributes
/*
* Data nodes
*/
augment "/nw:networks/nw:network/nw:network-types" {
description
"Introduces a new network type for a TE topology.";
container te-topology {
presence "Indicates a TE topology";
description
"Its presence identifies the TE topology type.";
}
}
augment "/nw:networks" {
description
"Augmentation parameters for TE topologies.";
uses te-topologies-augment;
}
augment "/nw:networks/nw:network" {
when 'nw:network-types/tet:te-topology' {
description
"Augmentation parameters apply only for networks with a
TE topology type.";
}
description
"Configuration parameters for a TE topology.";
uses te-topology-augment;
}
augment "/nw:networks/nw:network/nw:node" {
when '../nw:network-types/tet:te-topology' {
description
"Augmentation parameters apply only for networks with a
TE topology type.";
}
description
"Configuration parameters for TE at the node level.";
leaf te-node-id {
type te-types:te-node-id;
description
"The identifier of a node in the TE topology.
A node is specific to a topology to which it belongs.";
}
container te {
must '../te-node-id' {
description
"'te-node-id' is mandatory.";
}
must 'count(../nw:supporting-node)<=1' {
description
"For a node in a TE topology, there cannot be more
than one supporting node. If multiple nodes are
abstracted, the 'underlay-topology' field is used.";
}
presence "TE support";
description
"Indicates TE support.";
uses te-node-augment;
}
}
augment "/nw:networks/nw:network/nt:link" {
when '../nw:network-types/tet:te-topology' {
description
"Augmentation parameters apply only for networks with a
TE topology type.";
}
description
"Configuration parameters for TE at the link level.";
container te {
must 'count(../nt:supporting-link)<=1' {
description
"For a link in a TE topology, there cannot be more
than one supporting link. If one or more link paths are
abstracted, the underlay is used.";
}
presence "TE support";
description
"Indicates TE support.";
uses te-link-augment;
}
}
augment "/nw:networks/nw:network/nw:node/"
+ "nt:termination-point" {
when '../../nw:network-types/tet:te-topology' {
description
"Augmentation parameters apply only for networks with a
TE topology type.";
}
description
"Configuration parameters for TE at the termination point
level.";
uses te-termination-point-augment;
}
augment "/nw:networks/nw:network/nt:link/te/bundle-stack-level/"
+ "bundle/bundled-links/bundled-link" {
when '../../../../nw:network-types/tet:te-topology' {
description
"Augmentation parameters apply only for networks with a
TE topology type.";
}
description
"Augmentation for a TE bundled link.";
leaf src-tp-ref {
type leafref {
path "../../../../../nw:node[nw:node-id = "
+ "current()/../../../../nt:source/"
+ "nt:source-node]/"
+ "nt:termination-point/nt:tp-id";
require-instance true;
}
description
"Reference to another TE termination point on the
same source node.";
}
leaf des-tp-ref {
type leafref {
path "../../../../../nw:node[nw:node-id = "
+ "current()/../../../../nt:destination/"
+ "nt:dest-node]/"
+ "nt:termination-point/nt:tp-id";
require-instance true;
}
description
"Reference to another TE termination point on the
same destination node.";
}
}
augment "/nw:networks/nw:network/nw:node/te/"
+ "information-source-entry/connectivity-matrices/"
+ "connectivity-matrix" {
when '../../../../../nw:network-types/tet:te-topology' {
description
"Augmentation parameters apply only for networks with a
TE topology type.";
}
description
"Augmentation for the TE node connectivity matrix.";
uses te-node-connectivity-matrix-attributes;
}
augment "/nw:networks/nw:network/nw:node/te/te-node-attributes/"
+ "connectivity-matrices/connectivity-matrix" {
when '../../../../../nw:network-types/tet:te-topology' {
description
"Augmentation parameters apply only for networks with a
TE topology type.";
}
description
"Augmentation for the TE node connectivity matrix.";
uses te-node-connectivity-matrix-attributes;
}
augment "/nw:networks/nw:network/nw:node/te/"
+ "tunnel-termination-point/local-link-connectivities" {
when '../../../../nw:network-types/tet:te-topology' {
description
"Augmentation parameters apply only for networks with a
TE topology type.";
}
description
"Augmentation for TE node TTP LLCs (Local Link
Connectivities).";
uses te-node-tunnel-termination-point-llc-list;
}
}]]>Security Considerations
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF or RESTCONF . The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) . The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
.
The Network Configuration Access Control Model (NACM)
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.
There are a number of data nodes defined in this YANG module 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 and
their sensitivity/vulnerability:
/nw:networks/nw:network/nw:network-types/tet:te-topology
This subtree specifies the TE topology type. Modifying the
configurations can render the TE topology type invalid. By making such
modifications, a malicious attacker may disable the TE
capabilities on the related networks and cause traffic to be disrupted
or misrouted.
/nw:networks/tet:te
This subtree specifies the TE node templates and TE link
templates. Modifying the configurations in this subtree will change the
related future TE configurations. By making such modifications, a
malicious attacker may change TE capabilities scheduled at a
future time and cause traffic to be disrupted or misrouted.
/nw:networks/nw:network
This subtree specifies the topology-wide configurations, including
the TE topology ID and topology-wide policies. Modifying the
configurations in this subtree can add, remove, or modify TE
topologies. By adding a TE topology, a malicious attacker may
create an unauthorized traffic network. By removing or modifying a
TE topology, a malicious attacker may cause traffic to be disabled or
misrouted in the specified TE topology. Such traffic changes may
also affect the traffic in the connected TE topologies.
/nw:networks/nw:network/nw:node
This subtree specifies the configurations for TE nodes. Modifying
the configurations in this subtree can add, remove, or modify TE
nodes. By adding a TE node, a malicious attacker may create an
unauthorized traffic path. By removing or modifying a TE node, a
malicious attacker may cause traffic to be disabled or misrouted in the
specified TE node. Such traffic changes may also affect the
traffic on the surrounding TE nodes and TE links in this TE
topology and the connected TE topologies.
/nw:networks/nw:network/nt:link/tet:te
This subtree specifies the configurations for TE links. Modifying
the configurations in this subtree can add, remove, or modify TE
links. By adding a TE link, a malicious attacker may create an
unauthorized traffic path. By removing or modifying a TE link, a
malicious attacker may cause traffic to be disabled or misrouted on the
specified TE link. Such traffic changes may also affect the
traffic on the surrounding TE nodes and TE links in this TE
topology and the connected TE topologies.
/nw:networks/nw:network/nw:node/nt:termination-point
This subtree specifies the configurations of TE LTPs.
Modifying the configurations in this subtree can add,
remove, or modify TE LTPs. By adding a TE LTP, a malicious
attacker may create an unauthorized traffic path. By removing
or modifying a TE LTP, a malicious attacker may cause traffic to be
disabled or misrouted on the specified TE LTP. Such traffic
changes may also affect the traffic on the surrounding TE nodes
and TE links in this TE topology and the connected TE topologies.
Some of the readable data nodes in this 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:
/nw:networks/nw:network/nw:network-types/tet:te-topology
Unauthorized access to this subtree can disclose the TE topology
type.
/nw:networks/tet:te
Unauthorized access to this subtree can disclose the TE node
templates and TE link templates.
/nw:networks/nw:network
Unauthorized access to this subtree can disclose the topology-wide
configurations, including the TE topology ID, the topology-wide
policies, and the topology geolocation.
/nw:networks/nw:network/nw:node
Unauthorized access to this subtree can disclose the operational
state information of TE nodes.
/nw:networks/nw:network/nt:link/tet:te
Unauthorized access to this subtree can disclose the operational
state information of TE links.
/nw:networks/nw:network/nw:node/nt:termination-point
Unauthorized access to this subtree can disclose the operational
state information of TE LTPs.
IANA Considerations
IANA has registered the following URIs in the "ns" subregistry within the
"IETF XML Registry" .