A YANG Data Model for Network TopologiesCiscoalex@cisco.comJuniper Networkshanantha@juniper.netCiscojmedved@cisco.comCiscottkacik@cisco.comPantheon Technologies SROrobert.varga@pantheon.skJuniper Networksnitinb@juniper.net
This document defines a YANG data model for network topologies.
This document introduces a YANG
data model for network topologies.
The model allows an application to have a holistic view of
an entire network, all contained in a single conceptual YANG
datastore.
In order to capture information that is specific to
of a particular type of network topology, the basic model can be augmented
and adapted.
As a result, the data model is generic in nature and can be applied to many network
topologies. For this reason, it is suitable for use as a
general YANG data model framework to capture network topologies also
beyond the types that are introduced here.
Specific topology types that are covered in this document
include Layer 3 Unicast IGP, IS-IS ,
and OSPF . Adaptations and
extensions to other types of topologies are possible, using similar
model patterns to the ones that are illustrated.
There are multiple applications for such a data model. For example,
a network controller can use the data model to represent
the controller's view of a topology it controls and expose it to northbound
applications via Netconf or via a ReST Interface
.
Alternatively,
nodes within the network can use the data model to capture their understanding
of the overall network topology that they are contained in, as well as propagate
this understanding and compare it with that of other nodes.
The data model is generic in nature and can be applied to any type of network
topology.
The data model is defined in
several YANG modules:
Module "network-topology" contains a generic network topology model.
It defines a network topology at its most general level of
abstraction.
It models aspects such as the nodes and edges that a topology graph is
composed of, as well as termination points contained in the nodes that actually
terminate the edges of the graph. A network can contain multiple topologies,
for example topologies at different layers and overlay topologies.
The model therefore
allows also to capture the relationship between topologies, as well as the
dependencies between nodes and termination points across topologies.
Module "l3-unicast-igp-topology" applies the general network topology model
to Layer 3 Unicast IGP topologies. It augments the general topology with
information specific to Layer 3 Unicast IGP. In doing so, it also
illustrates the extension
patterns associated with extending respectively augmenting the
general topology model to meet the needs of a specific topology.
Module "ospf-topology" defines a topology model for OSPF, building on
and extending the Layer 3 Unicast IGP topology model.
It serves as an example of how the general topology model can be refined across multiple
levels.
Module "isis-topology" defines a topology model for IS-IS, again building on
and extending the Layer 3 Unicast IGP topology model.
Module "ted", finally, is a helper module, defining information kept in the
Traffic Engineering Database (TED) that is leveraged by IS-IS and OSPF topologies.
Datastore: A conceptual store of instantiated management information,
with individual data items represented by data nodes which are
arranged in hierarchical manner.
Data subtree: An instantiated data node and the data nodes that are
hierarchically contained within it.
HTTP: Hyper-Text Transfer Protocol
IGP: Interior Gateway Protocol
IS-IS: Intermediate System to Intermediate System protocol
LSP: Label Switched Path
NETCONF: Network Configuration Protocol
OSPF: Open Shortest Path First, a link state routing protocol
URI: Uniform Resource Identifier
ReST: Representational State Transfer, a style of stateless interface and protocol
that is generally carried over HTTP
SRLG: Shared Risk Link Group
TED: Traffic Engineering Database
YANG: A data definition language for NETCONF
This section provides an overview of the network topology model.
We start with the structure of the foundational model that
represents a generic topology. Subsequently, an overview of
the specific topologies is given - Layer 3 Unicast IGP,
OSPF, and IS-IS, respectively. During the course of
the discussion, sected design choices are explained and
the pattern that should be applied to extend the model
to new types of topologies is presented.
The network topology model is defined by the following YANG modules,
whose relationship is roughly depicted in the figure below.
YANG module network-topology defines the basic network topology model.
YANG module l3-unicast-igp-topology builds on top of this model,
augmenting network-topology with additional definitions needed to
represent Layer 3 Unicast IGP topologies. This module in turn is
augmented by YANG modules with additional definitions for OSPF
and for IS-IS topologies, ospf-topology
and isis-topology, respectively. Finally, YANG module "ted" contains
a set of auxiliary definitions used by both ospf-topology and isis-topology,
capturing data related to traffic engineering.
The structure of the network topology data model, as later defined in the
YANG module "network-topology", is depicted in
the following diagram. Brackets enclose list keys,
"rw" means configuration data, "ro" means operational state data,
and "?" designates optional nodes. The
figure does not depict all definitions; it is intended to illustrate
the overall structure.
A network can contain multiple topologies. Each topology is captured in its
own list element, distinguished via a topology-id.
This is captured by list "topology", contained underneath
the root container for this module, "network-topology".
A topology has a certain type, such as OSPF or IS-IS. A topology can even have
multiple types simultaneously. The type, or types, are captured
underneath container "topology-types". This serves as container for data nodes
that represent specific topology types. In this module, it serves merely as
an augmentation target; topology-specific modules will later introduce new
data nodes to represent new topology types below this target,
i.e. insert them below "topology-types" by
ways of augmentation.
Topology types SHOULD always be represented using containers,
not leafs of empty type. This allows to represent hierarchies of topology subtypes
within the instance information.
For example, an instance of an OSPF topology (which, at the same time,
is a layer 3 unicast IGP topology) would contain
underneath "topology-types" another container "l3-unicast-igp-topology", which in
turn would contain a container "ospf-topology".
A topology can in turn be part of a hierarchy of topologies, building on top of other
topologies. Any such topologies are captured in list "underlay-topology".
Furthermore, a topology contains nodes and links, each captured in their own list.
A node has a node-id. This distinguishes the node from other nodes in the list.
In addition, a node has a list of termination points, used to terminate links.
An examples of a termination point might be a physical or logical port or, more generally,
an interface. Also, a node can in turn map onto other nodes in an underlay topology.
This is captured in list "supporting-node".
A link is identified by a link-id, uniquely identifying the link within the topology.
Links are point-to-point and unidirectional. Accordingly, a link contains a source
and a destination. Both source and destination reference a corresponding node, as well
as a termination point on that node. Analogous to a node, a link can in turn map onto
other links an underlay topology. This is captured in list "supporting-link".
Rather than maintaining lists in separate containers, the model is kept relatively flat
in terms of its containment structure. This way, path specifiers used to refer to
specific nodes, be it in management operations or in specifications of constraints,
can remain relatively compact. Of course, this means there is no separate structure
in instance information that separates elements of different lists from one another.
Such structure is semantically not required, although it might enhance human readability
in some cases.
In an effort to minimize assumptions of what a topology might actually represent,
mappings between topologies, nodes, links, and termination points are kept strictly
generic. For example, no assumptions are made whether a termination point actually
refers to an interface, or whether a node refers to a specific "system" or device;
the model at this generic level makes no provisions for that.
Any greater specifics about mappings between upper and lower layers
can be captured in augmenting modules. For example, if a termination point maps
to an interface, an augmenting module can augment the termination point with
a leaf that references the corresponding interface
.
If a node maps to a particular device
or network element, an augmenting module can augment node with a leaf that references
the network element.
The model makes extensive use of groupings,
instead of simply defining data nodes "in-line".
This allows to more easily include the corresponding data nodes in notifications, which
then do not need to respecify each data node that is to be included.
The tradeoff for this is that it makes the specification of constraints more complex,
because constraints
involving data nodes outside the grouping need to be specified in conjunction with a
"uses" statement where the grouping is applied. This also means that constraints and
XPath-statmeents need to specified in such a way that the navigate "down"
first and select entire sets of nodes, as opposed to being able to simply specify them
against individual data nodes.
The topology model includes links that are point-to-point and unidirectional.
It does not directly support multipoint and bidirectional links. While this may appear
as a limitation, it does keep the model simple, generic, and allows it to very easily
be subjected applications that make use of graph algorithms. Birectional conections
can be represented through pairs of unidirectional links. By introducing hierarchies
of nodes, with nodes at one level mapping onto a set of other nodes at another level,
and the introducing new links for nodes at that level, topologies with connections
representing non-point-to-point communication patterns can be represented.
Links are terminated by a single termination point, not sets of termination points.
Connections involving multihoming or link aggregation schemes need to be represented using
multiple point-to-point links, then defining a link at a higher layer that is supported
by those individual links.
In a hierarchy of topologies, there are nodes mapping to nodes, links mapping to links, and
termination points mapping to termination points. Some of this information is redundant.
Specifically, with the link-to-links mapping known, and the termination points of each
link known, maintaining separate termination point mapping information is not needed
but can be derived via transitive closure. The model does provide for the option to
include this information explicitly, but does not allow for it to be configured to
avoid the potential to introduce (and having to validate) corresponding integrity issues.
A topology's topology types are represented using a container which
contains a data node
for each of its topology types.
A topology can encompass several types
of topology simultaneously, hence a container is used instead of a case
construct, with each topology type in turn represented by a dedicated
presence container itself. The reason for not simply using an empty leaf, or
even simpler, do away even with the topology container and just use
a leaf-list of topology-type instead,
is to be able to represent "class hierarchies" of topology types,
with one topology type refining the other.
Topology-type specific containers are to be
defined in the topology-specific modules, augmenting the topology-types
container.
YANG requires
data needs to be
designated as either configuration or operational data, but not
both, yet it is important to have all topology information,
including vertical cross-topology dependencies,
captured in one coherent model.
In most cases topology information
is discovered about a network; the topology is considered a
property of the network that is reflected in the model.
That said, it is conceivable that certain types of topology need
to also be configurable by an application.
There are several alternatives in which this can be addressed.
The alternative chosen in this draft does not restrict topology
information as read-only, but includes a flag that indicates
for each topology whether it should be considered as read-only
or configurable by applications.
An alternative would be to designate topology list elements
as read only. The read-only topology list includes each topology;
it is the complete reference. In parallel a second topology list
is introduced. This list serves the purpose of
being able to configure topologies which are then mirrored in the
read-only list. The configurable topology list
adheres to the same structure
and uses the same groupings as its read-only counterpart. As most
data is defined in those groupings, the amount of additional definitions
required will be limited.
A configurable topology will thus be represented twice: once in the read-only
list of all topologies, a second time in a configuration sandbox.
In order to represent a general Layer 3 Unicast IGP topology, the basic network topology
model needs to be extended. The corresponding extensions are introduced in a separate
YANG module "l3-unicast-igp-topology". The structure of those extensions
is depicted in the following diagram. Brackets enclose list keys, "rw" means
configuration, "ro" operational state data, "?" designates
optional nodes, "*" designates nodes that can have multiple instances.
Parantheses enclose choice and case nodes. Data nodes from the network-topology module
are omitted (indicated by "....."), as long as not required to indicate
containment structure. Notifications are not depicted.
The module augments the original network-topology module as follows:
A new topology type is introduced, l3-unicast-igp-topology-type. This
is represented by a container object, which is inserted under the
"topology-types" container of the network topology module.
Additional topology attributes are introduced, defined in a grouping,
which augments the "topology" list of the network topology module.
The attributes include an IGP name, as well as a set of flags
(represented through a leaf-list).
Each type of flag is represented by a separate identity. This allows
to introduce additional flags in augmenting modules that are associated
with specific IGP topologies, without needing to revise this module.
Additional data objects for nodes are introduced by augmenting the "node" list of
the network topology module. New objects include again a set of flags, as well
as a list of prefixes. Each prefix in turn includes an ip prefix, a metric, and
a prefix-specific set of flags.
Links are augmented as well with a set of parameters, allowing to associate
a link with an IGP name, another set of flags, and a link metric.
In addition, the module defines a set of notifications to alert clients of any
events concerning links, nodes, prefixes, and termination points.
Each notification includes an indication of the type of event, the topology
from which it originated, and the affected node, or link,
or prefix, or termination point.
In addition, as a convenience to applications, additional data of the affected
node, or link, or termination point (respectively) is included. While this makes
notifications larger in volume than they would need to be, it avoids the need
for subsequent retrieval of context information, which also might have changed
in the meantime.
OSPF is the next type of topology represented in the model.
OSPF represents a particular type of
Layer 3 Unicast IGP. Accordingly, this time the Layer 3 Unicast IGP topology
model needs to be extended. The corresponding extensions are introduced in a separate
YANG module "ospf-topology", whose structure is depicted in the
following diagram. For the most part, this module augments "l3-unicast-igp-topology".
Like before,
brackets enclose list keys, "rw" means
configuration, "ro" operational state data, "?" designates
optional nodes, "*" designates nodes that can have multiple instances.
Parantheses enclose choice and case nodes. Data nodes from the network-topology module
are omitted (indicated by "....."), as long as not required to indicate
containment structure. Notifications are not depicted.
The module augments "l3-unicast-igp-topology" as follows:
A new topology type for an OSPF topology is introduced.
This is represented by a container object, which is inserted
under the "l3-unicast-igp-topology" container of the
l3-unicast-igp-topology module. This way, an ospf topology
represents both a l3-unicast-igp topology and an ospf topology.
Additional topology attributes are
defined in a new grouping which augments
igp-topology-attributes of the l3-unicast-igp-topology module.
The attributes include an OSPF area-id identifying the OSPF area.
Additional data objects for nodes are introduced by augmenting
the igp-node-attributes of the l3-unicast-igp-topology module.
New objects include router-type, de-interface-id for pseudonodes,
list of multi-topology-ids, ospf node capabilities and
traffic engineering attributes.
Links are augmented with a multi-topology-id and
traffic engineering link attributes.
Prefixes are augmented with OSPF specific forwarding address.
In addition, the module extends IGP node, link and prefix
notifications with OSPF attributes.
IS-IS is another type of Layer 3 Unicast IGP.
Like OSPF topology, IS-IS topology is
defined in a separate module, "isis-topology",
which augments "l3-unicast-igp-topology".
The structure is depicted in the following diagram.
Like before,
brackets enclose list keys, "rw" means
configuration, "ro" operational state data, "?" designates
optional nodes, "*" designates nodes that can have multiple instances.
Parantheses enclose choice and case nodes. Data nodes from the network-topology module
are omitted (indicated by "....."), as long as not required to indicate
containment structure. Notifications are not depicted.
The module augments the l3-unicast-igp-topology as follows:
A new topology type is introduced, "isis-topology-type".
This is represented by a container object,
which is inserted under the "l3-unicast-igp-topology" container
of the l3-unicast-igp-topology module. This way, an isis topology
represents both a l3-unicast-igp-topology and an isis topology.
Additional topology attributes are introduced
in a new grouping which augments
"igp-topology-attributes" of the
l3-unicast-igp-topology module.
The attributes include an ISIS NET-id identifying the area.
Additional data objects for nodes are introduced by augmenting
"igp-node-attributes" of the l3-unicast-igp-topology module.
New objects include router-type, iso-system-id to
identify the router, a list of multi-topology-id,
a list of NET ids, and traffic engineering attributes.
Links are augmented with multi-topology-id and
traffic engineering link attributes.
In addition, the module augments IGP nodes and links with ISIS attributes.
Traffic Engineering Data is required both by OSPF and IS-IS,
which are defined in separate
modules.
Information shared by both is defined in another module, "ted".
This module defines a set of groupings with
auxiliary information required and shared
by those other modules.
This module details traffic-engineering node and link attributes:
TED node attributes include te-router-id for IPv4 and IPv6,
local IPv4 and IPv6 addresses and
path computation client capabilities.
The path computation client capabilities in turn include
a bit vector for various path computation capabilities.
TED link attributes comprise link color,
max-link-bandwidth, max-resv-link-bandwidth,
unreserved bandwidth and re-metric.
They also include SRLG attributes which contains
interface switching capabilities, a list of SRLG values,
and a link protection type.
The interface switching capabilities in turn contain
a list element for each switching capability, defining
encoding, max-lsp-bandwidth, and
interface switching specific attributes.
The transport protocol used for sending the topology data MUST support authentication and
SHOULD support encryption.
The data-model by itself does not create any security implications.
The model presented in this paper was contributed to by more people
than can be listed on the author list. Additional contributors include:
Ken Gray, Juniper Networks
Tom Nadeau, Juniper Networks
Aleksandr Zhdankin, Cisco
We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Ladislav Lhotka, Andy Bierman,
Carlos Pignataro, and Juergen Schoenwaelder.