A YANG Data Model for
Layer 3 TopologiesCiscoalex@cisco.comCiscojmedved@cisco.comPantheon Technologies SROrobert.varga@pantheon.sktony.tkacik@gmail.comEricssonxliu@kuatrotech.comHuaweiIgor.Bryskin@huawei.comAdva Opticalaguo@advaoptical.comPacket Designhari@packetdesign.comBracket Computingnitin_bahadur@yahoo.comJuniper Networksvbeeram@juniper.netThis document defines a YANG data model for layer 3 network
topologies.
This document introduces a YANG
data model for Layer 3 network topologies, specifically Layer 3 Unicast.
The model
allows an application to have a holistic view of the topology of a Layer
3 network, all contained in a single conceptual YANG datastore.
The data
model builds on top of, and augments, the data model for network
topologies defined in
. An earlier revision
of that Internet Draft contained not just the general model for network
topologies, but also the model for layer 3 network topologies that is
being specified here. However, we decided to "split" the earlier draft
to separate the truly general aspects of a topology data model, which
apply to any type of topology, from the application of this model to a
particular domain, here: a Layer 3 network.The document also shows how the model can be further refined to cover different
Layer 3 Unicast topology types. For this purpose, example models are
introduced that cover IS-IS and OSPF . Those examples are intended purely for illustrative purposes;
we expect that full-blown IS-IS and OSPF models will be more comprehensive
and refined than the examples shown here. There are multiple applications for a topology data model.
A number of
use cases have been defined in section 6 of
.
For example,
nodes within the network can use the data model to capture their
understanding of the overall network topology and expose it to a network
controller. A network controller can then use the instantiated topology
data to compare and reconcile its own view of the network topology with
that of the network elements that it controls. Alternatively, nodes
within the network could propagate this understanding to compare and
reconcile this understanding either amongst themselves or with help of a
controller. Beyond the network element itself, a network controller
might even use the data model to represent its view of the topology that
it controls and expose it to applications north of itself.
There are several reasons to choose YANG to define the data model.
Data defined using YANG can be exposed by a server to client
applications and controllers via Netconf .
The fact that YANG can potentially be used with different
protocols and interfaces
provides for a degree of "future-proofing" of model implementations.
Also, YANG can serve as the basis for model-driven toolchains, such as
used in the Open Daylight project .
The data model for Layer 3 Unicast topologies defined in this document
is specified
in a YANG module "ietf-l3-unicast-topology".
To do so, it augments general network
topology model defined in
with
information specific to Layer 3 Unicast. This way, the general
topology model is extended to be able to meet the needs
of Layer 3 Unicast topologies.Information that is kept in the Traffic Engineering Database (TED) is
specified in a separate model and outside the scope of this
specification.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 ProtocolIGP: Interior Gateway ProtocolIS-IS: Intermediate System to Intermediate System protocolLSP: Label Switched PathNETCONF: Network Configuration ProtocolOSPF: Open Shortest Path First, a link state routing protocolURI: Uniform Resource IdentifierReST: Representational State Transfer, a style of stateless interface
and protocol that is generally carried over HTTPSRLG: Shared Risk Link GroupTED: Traffic Engineering DatabaseYANG: A data definition language for NETCONFThe Layer 3 Unicast topology model is defined by YANG module
"l3-unicast-topology". The relationship of this module with
other YANG modules is roughly depicted in the figure below.
YANG modules "ietf-network" and "ietf-network-topology"
collectively define the basic network topology
model. YANG module "ietf-l3-unicast-topology" augments those models
with additional definitions needed to represent Layer 3 Unicast
topologies. This module in turn can be augmented by YANG modules with
additional definitions for specific types of Layer 3 Unicast topologies,
such as OSPF and for IS-IS topologies. The Layer 3 Unicast topology model is defined by YANG module
"ietf-l3-unicast-topology" and 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. The prefix "nd:" refers to the YANG module for networks;
the prefix "lnk:" refers to
the YANG module for network topology.
In the interest of brevity,
notifications are not depicted.
The module augments the original ietf-network and
ietf-network-topology modules as
follows: A new network topology type is introduced,
l3-unicast-topology. The corresponding container
augments the network-types of the ietf-network module. Additional topology attributes are introduced, defined in a
grouping, which augments the "network" list of the network
module. The attributes include a name for the topology, 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 using additional identities
without needing to revise this module.Additional data objects for nodes are introduced by augmenting
the "node" list of the network 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 (in the ietf-network-topology module) are augmented
with a set of parameters as well, allowing
to associate a link with a link name, another set of flags, and a
link metric.Termination points (in the ietf-network-topology module as well)
are augmented with a choice of IP address or
identifier.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.
The model can be extended for specific Layer 3 Unicast types.
Examples include OSPF and IS-IS topologies.
In the following, two additional YANG modules are introduced
that define simple
topology models for OSPF and IS-IS, respectively.
These modules intended to serve as examples that illustrate
how the general topology model can be refined across multiple levels;
they do not constitute full-fledged OSPF and IS-IS topology models
which may be more comprehensive and refined than the models
that are described here.The following model shows how the Layer 3 Unicast topology model can be
extended to cover OSFP topologies.
For this purpose, a set of augmentations are introduced
in a separate YANG module, "ietf-ospf-topology", whose 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. A "+" at the end of a line indicates a line break.
The module augments "ietf-l3-unicast-topology" as follows: A new topology type for an OSPF topology is introduced.Additional topology attributes are defined in a new grouping
which augments l3-topology-attributes of the
ietf-l3-unicast-topology module. The attributes include an OSPF
area-id identifying the OSPF area.Additional data objects for nodes are introduced by augmenting
the l3-node-attributes of the l3-unicast-topology module. New
objects include router-type, dr-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 notifications for events
concerning Layer 3
nodes, links, termination points, and prefixes
with OSPF attributes.
It should be noted that the model defined here
represents topology and is intended as an example.
It does not define how to configure
OSPF routers or interfaces.
IS-IS topologies are another type of Layer 3 Unicast topology.
Like in the case of OSPF topology,
a model for IS-IS topology can be defined in a separate module which
augments "ietf-l3-unicast-igp-topology". The structure of a corresponding
model, "ietf-isis-topology", 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.
A "+" at the end of a line indicates a line break.
The module augments the ietf-l3-unicast-topology as follows:
A new topology type is introduced for isis.Additional topology attributes are introduced in a new grouping
which augments "topology-attributes" of the
ietf-l3-unicast-topology module. The attributes include an ISIS
NET-id identifying the area.Additional data objects for nodes are introduced by augmenting
"node-attributes" of the ietf-l3-unicast-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 nodes and links with
IS-IS attributes.
Again, it should be noted that the model defined here
represents topology and is intended as an example.
It does not define how to configure
IS-IS routers or interfaces.
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 NetworksTom Nadeau, BrocadeAleksandr Zhdankin, CiscoWe wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Ladislav Lhotka, Andy Bierman,
Carlos Pignataro, Joel Halpern, Juergen Schoenwaelder, Alia
Atlas, Susan Hares, Benoit Claise, and Carl Moberg.Use of OSI IS-IS for Routing in TCP/IP and Dual
EnvironmentsOSPF Version 2YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)Network Configuration Protocol (NETCONF)Common YANG Data TypesA YANG Data Model for Interface ManagementA YANG Data Model for Network TopologiesThe YANG 1.1 Data Modeling LanguageSummary of I2RS Use Case RequirementsOpenDaylight: Towards a Model-Driven SDN Controller architecture