TEAS Working Group K. Lam
Internet Draft E. Varma
Intended status: Informational Alcatel-Lucent
Intended status: Informational P. Doolan
Expires: January 2016 Coriant
N. Davis
Ciena
B. Zeuner
Deutsche Telekom
M. Betts
ZTE
I. Busi
Huawei
S. Mansfield
Ericsson
July 3, 2015
Usage of IM for network topology to support TE Topology YANG Module
Development
draft-lam-teas-usage-info-model-net-topology-01.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Lam Expires January 3, 2016 [Page 1]
Internet-Draft Usage of an IM for network topology July 2015
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 3, 2009.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
The benefits of using a common Information Model (IM) as a foundation
for deriving purpose and protocol specific interfaces, particularly
for complex networking domains, has been described in draft-betts-
netmod-framework-data-schema-uml. This draft describes an existing
information model relevant to Network Topology and illustrates how it
Lam Expires January 3, 2016 [Page 2]
Internet-Draft Usage of an IM for network topology July 2015
can be used to help ensure the consistency and completeness of the
YANG data model for TE topologies solutions work in TEAS.
Table of Contents
1. Introduction...................................................4
2. Background and Motivation......................................4
3. The Common Information Model...................................5
3.1. Core Model Fragment.......................................6
3.1.1. Core Network Module..................................6
3.1.2. Core Foundation Module...............................8
3.2. Other Fragments..........................................11
4. High Level Description of the Topology Subset of the CNM......11
4.1. Object Classes of the CNM Topology Subset................12
4.1.1. LogicalTerminationPoint (LTP) and LayerProtocol (LP)12
4.1.2. ForwardingDomain (FD)...............................13
4.1.3. Link and Link End (LE)..............................13
4.1.4. Network Element (NE)................................14
4.2. Relationships between Object Classes of the Topology Subset15
4.2.1. ForwardingDomain Recursive Aggregation
(HigherLevelFdEncompassesLowerLevelFds Aggregation)........15
4.2.2. Network Elements encompassing ForwardingDomains
(NeEncompassesFds Aggregation).............................16
4.2.3. ForwardingDomain association with LTPs (FdAggregatesLtps
Composition)...............................................17
4.2.4. ForwardingDomain aggregating Links (FdEncompassesLinks)
...........................................................17
4.2.5. ForwardingDomain aggregating NEs....................18
5. Detailed Description of the Topology Subset...................18
5.1. Topological Entity.......................................20
5.2. Characteristics of Topological Entity....................21
5.2.1. Risk (RiskParameter_Pac)............................22
5.2.2. TransferCost_Pac....................................24
5.2.3. TransferTiming_Pac..................................25
5.2.4. TransferIntegrity_Pac...............................25
5.2.5. TransferCapcity_Pac.................................26
5.2.6. Validation_Pac......................................28
5.2.7. LayerProtocolTransition_Pac.........................28
6. Usage of the CNM Topology Subset regarding TE Topology DM.....28
7. Security Considerations.......................................29
Lam Expires January 3, 2016 [Page 3]
Internet-Draft Usage of an IM for network topology July 2015
8. IANA Considerations...........................................29
9. Conclusions...................................................29
10. References...................................................29
10.1. Normative References....................................29
10.2. Informative References..................................29
11. Acknowledgments..............................................30
Appendix A. Example YANG from the CNM Topology Subset............31
A.1. Link YANG Specification..................................31
A.2. Tree-Style Summary of the Link YANG Specification........36
1. Introduction
This draft describes an existing information model (IM) relevant to
Network Topology [ONF TR-512] and illustrates how it can be used to
help ensure the consistency and completeness of the YANG data model
(DM) for TE topologies solutions development work in TEAS.
2. Background and Motivation
Information Models (IM) and Data Models (DM) are related but
different. An IM provides an abstract, conceptual view of the system
being modeled in terms of its constituent parts (objects),
independent of any specific implementations or protocols used to
transport the data; it hides all protocol and implementation details
(RFC 3444, TM Forum/NGCOR, ITU-T SG 15). A DM is a concrete
specification in a particular language of an interface to, in this
case, a controlled/managed system. The intention of the distinction
between IMs and DMs has been to separate the modeling of problem
space semantics from the modeling of the implementation of those
semantics (though the dividing line has not always been clearly
articulated).
A DM may be derived from an IM though it is often created without
(explicit or obviously implicit) reference to one. When a DM is
derived from an IM, the DM and the components of the system it
provides control/management access to are traceable to the
definitions provided in the IM. There is no ambiguity between
designer, developer, user or operator regarding the name, function,
and information elements that are associated with a particular
managed object.
Lam Expires January 3, 2016 [Page 4]
Internet-Draft Usage of an IM for network topology July 2015
As described in [I-D.betts], when DMs are created ''in isolation''
solely for the purpose of encoding specific interfaces, they may do
that job adequately for any particular interface but in complex
domains may create opportunities for confusion, duplication of
effort, lack of interoperability, and lack of extensibility. In the
past, ad-hoc development of DMs has caused significant operational
and implementation inefficiencies in our industry.
Since March 2014, upon IESG recommendation that SNMP no longer be
used for new work re configuration and that NETCONF/YANG be used
instead, there has been an explosion of YANG DM development in IETF.
It has consequently been recognized as essential to assure proper
coordination of YANG DM development (including reaching out to
different SDOs/consortia), as well as to assure that the YANG modules
themselves provide a good representation of what is being modeled, to
meet expectations of functionality, quality, and interoperability.
In order to facilitate this objective, guidance from available
pertinent IMs can be valuable.
This draft describes an existing information model relevant to
Network Topology [ONF TR-512], which is part of the Common
Information Model (ONF-CIM) of network resources (as described in [I-
D.betts]), that can be leveraged to assess the consistency and
completeness of related YANG modules under development. Being part
of a Common Information Model, it will not lead to development of
incompatible/uncoordinated models that can be difficult to maintain
as other purpose-specific interfaces are developed.
3. The Common Information Model
This section provides a high level introduction to the ONF Common
Information Model (ONF-CIM), and in particular its Core Model
Fragment (see [ONF TR-512]), to provide an overall context for the
topology relevant subset.
An information model describes the things in a domain in terms of
objects, their properties (represented as attributes), and their
relationships.
The ONF-CIM is expressed in a formal language called UML (Unified
Modeling Language). UML has a number of basic model elements, called
Lam Expires January 3, 2016 [Page 5]
Internet-Draft Usage of an IM for network topology July 2015
UML artifacts. In order to assure a consistent and harmonized
modeling approach, only a selected subset of these UML artifacts were
used in the development of the ONF-CIM according to guidelines for
creating an information model expressed in UML (see the UML
Guidelines document in the ONF TR-512 [ONF TR-512]).
The ONF-CIM has been developed using the Papyrus open source UML
Tool, for which a detailed guidelines document is available (see the
Papyrus Guidelines document in the ONF TR-512 [ONF TR-512]). This
guidelines document also describes how the modelers constructing the
ONF-CIM can cooperate in the GitHub environment to allow for separate
and still coordinated development of the ONF-CIM fragments.
The OMF-CIM includes all of the artifacts (objects, attributes,
relationships, etc.) that are necessary to describe the domain for
the applications being developed.
It will be necessary to continually expand and refine the ONF-CIM
over time as, for example to add, new applications, capabilities or
forwarding technologies, or to refine the ONF-CIM as new insights are
gained. To allow these extensions to be made in a seamless manner,
the ONF-CIM is structured into a number of model fragments. This
modeling process allows the fragments that contain these extensions
to be developed, by the domain experts, with as much independence as
possible. This process is further articulated in [I-D.betts].
3.1. Core Model Fragment
The Core Model Fragment of the ONF-CIM consists of model artifacts
that are intended for use by multiple applications and/or forwarding
technologies.
For navigability, the Core Model Fragment is further sub-structured
into modules. Currently, these consist of a Core Network Module and a
Core Foundation Module.
3.1.1. Core Network Module
The Core Network Module (CNM) consists of artifacts that model the
essential network aspects that are neutral to the forwarding
technology of the network. The CNM currently encompasses Topology,
Lam Expires January 3, 2016 [Page 6]
Internet-Draft Usage of an IM for network topology July 2015
Termination, and Forwarding aspects (subsets of the CNM) as described
below:
- Topology Subset of CNM
The Topology subset of the CNM supports the modeling of network
topology information, which can be used to build the topology
database and depict the topology. Object classes representing
topological entities include:
o Forwarding Domain (FD): Offers the potential to enable
forwarding of information.
o Link (L): Models the adjacency between two or more FDs. A Link
has LinkEnds (LE).
o Logical Termination Point (LTP): Models the ports of a link. It
encapsulates the termination, adaptation, and OAM functions of
one or more transport layers.
o Network Element (NE): While not actually part of topology, a NE
brings meaning to the FD and the LTP contexts (and hence the
links). A NE represents physical equipment ''bundling'' to
provide a view of management scope, management access, and
session.
The Topology subset of the CNM supports network topology
abstraction and virtualization. FD abstraction is supported via
recursive aggregation and virtualization via partitioning of
resources according to the resource dedication criterion.
- Forwarding Subset of CNM
The Forwarding subset of the CNM (not covered in detail in this
draft) supports configuration of forwarding entities, including
their setup, modification, and tear down. Artifacts representing
the forwarding construct include:
o ForwardingConstruct (FC): In conjunction with the EndPoint, FC
models the enabled forwarding between two EPs across a FD.
Lam Expires January 3, 2016 [Page 7]
Internet-Draft Usage of an IM for network topology July 2015
o EndPoint (EP): Models the access to the FC, and associates the
FC to the LTP. When the FC supports protection, the EP also
indicates its role in the protection scheme, i.e., whether it
is a working or protection EP.
o FcRoute: Also known as SncRoute. It models the individual
routes of an FC.
o FcSwitch: Also known as SncSwitch. It models the switched
forwarding of traffic (traffic flow) between EPs and is present
where there is protection functionality in the FD.
- Termination Subset of CNM
The Termination subset of the CNM (not covered in detail in this
draft) supports modeling of the processing of transport
characteristic information, such as termination, adaptation, OAM,
etc. Artifacts representing the termination and adaptation and OAM
construct include:
o Logical Termination Point (LTP): See the LTP description in the
Topology Subset
o Layer Protocol (LP): This identifies the type of signal and is
the anchor for transport layer protocol specific definitions,
which are modeled as conditional packages, e.g., for OTN,
ODUk_TTP_Pac, OCh_TTP_Pac, etc.
3.1.2. Core Foundation Module
To communicate about an entity, it is important to have some way of
referring to that entity, i.e., to have some way of referencing it.
The Core Foundation module defines the artifacts for referencing
entities; i.e.:
- Global Unique ID (GUID):
An identifier that is globally unique where an identifier is a
property of an entity/role with a value that is unique within an
identifier space, where the identifier space is itself unique, and
immutable. The identifier therefore represents the identity of the
Lam Expires January 3, 2016 [Page 8]
Internet-Draft Usage of an IM for network topology July 2015
entity/role. An identifier carries no semantics with respect to
the purpose of the entity.)
- Local ID:
An identifier that is unique in the context of some scope that is
less than the global scope (where an identifier is as defined in
GUID above).
- Name:
A property of an entity with a value that is unique in some
namespace but may change during the life of the entity. A name
carries no semantics with respect to the purpose of the entity.
- Label:
A property of an entity with a value that is not expected to be
unique and is allowed to change. A label carries no semantics with
respect to the purpose of the entity and has no effect on the
entity behavior or state.
The Core Foundation module also provides the opportunity to extend
any entity using the Extension structure.
The module also defines two foundation object classes:
- GlobalClass:
Super class of object classes for which their instances can exist
on their own right, e.g. NE, LTP, FD, Link, and FC. Global classes
shall have one and only one globally unique identifier (GUID) and
may have zero or more local identifiers, zero or more names, zero
or more labels, zero or more extensions.
- LocalClass:
Super class of object classes for which the existence of their
instances depends on instances of global classes; e.g., LP (of
LTP), EP (of FC), and LE (of Link). Local classes shall have at
Lam Expires January 3, 2016 [Page 9]
Internet-Draft Usage of an IM for network topology July 2015
least one local identifier, may have zero or more names, zero or
more labels, zero or more extensions.
--------------------------------------------------------------------
I I
I I
I I
I I
I Artifacts for Referencing of Entities I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 3-1 Artifacts for Referencing of Entities
The Core Foundation module also defines a State_Pac artifact, which
is a package of state attributes. The State_Pac is inherited by
GlobalClass and LocalClass object classes. The State_Pac consists of
the following state-related attributes:
- Operational State:
Read-only with values: DISABLED, ENABLED
- Administrative State:
Read-only with values: LOCKED, UNLOCKED
- Usage State:
Lam Expires January 3, 2016 [Page 10]
Internet-Draft Usage of an IM for network topology July 2015
Read-only with values: IDLE, ACTIVE, BUSY
--------------------------------------------------------------------
I I
I I
I I
I States of Objects I
I I
I I
I (only in PDF version) I
I I
I I
I I
--------------------------------------------------------------------
Figure 3-2 States of Objects
3.2. Other Fragments
In addition to the Core Fragment, the ONF-CIM contains forwarding
technology and application specific fragments. The Optical Transport
Fragment of the ONF-CIM (see [ONF TR-512]) encompasses transport
technology layers 0, 1, and 2.
4. High Level Description of the Topology Subset of the CNM
This section provides a high-level overview of the Topology Subset of
the CNM. Figure 4-1 below is a skeleton class diagram illustrating
the key object classes. To avoid cluttering the figure, not all
associations have been shown and all of the attributes were omitted.
--------------------------------------------------------------------
I I
I I
I I
I I
Lam Expires January 3, 2016 [Page 11]
Internet-Draft Usage of an IM for network topology July 2015
I Overview of the CNM Topology Subset I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 4-1 Overview of the CNM Topology Subset
4.1. Object Classes of the CNM Topology Subset
This section describes the object classes of the Topology Subset of
the CNM. Relationships between these classes are described in section
4.2 below
4.1.1. LogicalTerminationPoint (LTP) and LayerProtocol (LP)
The LogicalTerminationPoint (LTP) object class encapsulates the
termination, adaptation and OAM functions of one or more transport
protocol layers. The structure of the LTP supports all transport
protocols including circuit and packet forms. Each transport layer is
represented by a LayerProtocol (LP) instance. The LayerProtocol
instances of the LTP can be used for controlling the termination and
OAM functionality of that layer. It can also be used for controlling
the adaptation (i.e. encapsulation and/or multiplexing of client
signal). Where the client/server relationship is fixed 1:1 and
immutable, the different layers can be encapsulated in a single LTP
instance. Where there is a n:1 relationship between client and
server, the layers must be split over separate instances of LTP.
The LP object class is defined with generic attributes
''layerProtocolName'' for indicating the supported transport layer
protocol.
Lam Expires January 3, 2016 [Page 12]
Internet-Draft Usage of an IM for network topology July 2015
Transport layer specific properties (such as layer-specific
termination and adaptation properties) are modeled as attributes of
conditional packages (called ''_Pacs'' in the UML notation of the
ONF-CIM) associated with the LP object class.
4.1.2. ForwardingDomain (FD)
The ForwardingDomain (FD) object class models the switching and
routing capabilities (see ''subnetwork'' topological component in
[G.852.2] and [TMF612]), which is used to effect forwarding of
transport characteristic information and offers the potential to
enable forwarding. It represents the resource that supports flows
across the FD. The FD object can hold zero or more instances of
ForwardingConstruct (FC) (representing constrained forwarding, not
discussed further in this document, covering connections, VLANs etc)
of one or more layer networks; e.g., OCh, ODU, ETH, and MPLS-TP. The
FD object provides the context for operations that
create/modify/delete FCs.
The FD object class supports a recursive aggregation relationship
such that the internal construction of an FD can be exposed as
multiple lower level FDs and associated Links (partitioning) (see
section 4.2.1.)
At the lowest level of recursion, a FD (within a network element)
could represent a switch matrix (i.e., a fabric).
Note that an NE can encompass multiple switch matrices (FDs), as
described in section 4.2.2. An instance of FD is associated with zero
or more LTP objects, as described in section 4.2.3.
4.1.3. Link and Link End (LE)
The Link object class models the adjacency between two or more
ForwardingDomains (FDs).
In its basic form (i.e., point-to-point Link) it associates a set of
LTP clients on one FD with an equivalent set of LTP clients on
another FD. Like the FC, the Link has endpoints (LinkEnd) which take
roles in the context of the function of the Link. A point-to-point
Link can be a TE Link and support parameters such as capacity, delay
Lam Expires January 3, 2016 [Page 13]
Internet-Draft Usage of an IM for network topology July 2015
etc. These parameters depend on the type of technology that supports
the link.
A Link can be terminated on two or more FDs. This provides support
for technologies such as PON and Layer 2 MAC in MAC configurations.
The LinkEnd further details the relationship between FD and Link for
asymmetric cases.
A FD may aggregate Links (see section 4.2.5).
The Link can support multiple transport layers via the associated LTP
object. An instance of Link can be formed with the necessary
properties according to the degree of virtualization. For
implementation optimization, multiple layer-specific links can be
merged and represented as a single Link instance.
4.1.4. Network Element (NE)
The NetworkElement (NE) object class represents a network element
(traditional NE) in the data plane or a virtual network element
visible in an interface where virtualization is used.
In the direct interface from a SDN controller to a network element in
the data plane, the NE object defines the scope of control for the
resources within the network element, e.g., internal transfer of user
information between the external terminations (ports), encapsulation,
multiplexing/demultiplexing, and OAM functions, etc. The NE provides
the scope of the naming space for identifying objects representing
the resources within the network element.
Where virtualization is employed, the NE object represents a virtual
NE (VNE). The mapping of the VNE to the NEs is the internal matter of
the SDN controller that offers the view of the VNE. Via the interface
between hierarchical SDN controllers, NE instances can be created (or
deleted) for providing (or removing) virtual views of the combination
of slices of network elements in the data plane.
Lam Expires January 3, 2016 [Page 14]
Internet-Draft Usage of an IM for network topology July 2015
4.2. Relationships between Object Classes of the Topology Subset
4.2.1. ForwardingDomain Recursive Aggregation
(HigherLevelFdEncompassesLowerLevelFds Aggregation)
Figure 4-2 below provides a pictorial example of ForwardingDomain
(FD) recursion with Links.
--------------------------------------------------------------------
I I
I I
I I
I I
I ForwardingDomain recursion with Links I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 4-2 ForwardingDomain recursion with Links
Figure 4-2 shows a UML fragment including the Link and
ForwardingDomain (FD). For simplicity it is assumed here that the
Links and FDs are for a single LayerProtocol (LP) although it can be
seen from the detailed figure earlier in this section that both a FD
and link can support a list of LPs.
Lam Expires January 3, 2016 [Page 15]
Internet-Draft Usage of an IM for network topology July 2015
The pictorial form shows a number of instances of FD interconnected
by Links and shows nesting of FDs. The recursive aggregation
"HigherLevelFdEncompassesLowerLevelFds" relationship (represented by
an open diamond) supports the FD nesting but it should be noted that
this is intentionally showing no lifecycle dependency between the
lower FDs and the higher ones that nest them (to do this composition,
a black diamond would have been used instead of the open diamond).
This is to allow for rearrangements of the FD hierarchy (e.g. when
regions of a network are split or merged). This emphasizes that the
nesting is an abstraction rather than decomposition. The underlying
network still operates regardless of how it is perceived in terms of
aggregating FDs. The model allows for only one hierarchy.
4.2.2. Network Elements encompassing ForwardingDomains (NeEncompassesFds
Aggregation)
Figure 4-3 below provides a pictorial example of ForwardingDomain
(FD) recursion with Links and NEs.
--------------------------------------------------------------------
I I
I I
I I
I I
I ForwardingDomain recursion with Links and NEs I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 4-3 ForwardingDomain recursion with Links and NEs
Lam Expires January 3, 2016 [Page 16]
Internet-Draft Usage of an IM for network topology July 2015
Figure 4-3 above shows an overlay of NetworkElement (NE) on the
ForwardingDomains and a corresponding fragment of UML showing only
the ForwardingDomain and NetworkElement classes.
The figure emphasizes that one level of abstraction of
ForwardingDomain is bounded by an NE. This is represented in the UML
fragment by the composition association (black diamond) that explains
that there is a lifecycle dependency in that the ForwardingDomain at
this level that cannot exist without the NE. The figure also shows
that a ForwardingDomain need not be bounded by an NE (as explained in
the UML fragment by the 0..1 composition) and that a ForwardingDomain
may have smaller scope than the whole NE (even when considering only
a single LayerProtocol as described below).
In one of the cases depicted (e.g., the right hand side NE
encompassing two FDs), the two ForwardingDomains in the NE are
completely independent. In the other cases depicted (e.g., the left
hand side NE encompassing three FDs) the subordinate
ForwardingDomains are themselves joined by Links emphasizing that the
NE does not necessarily represent the lowest level of relevant
network decomposition.
The figure also emphasizes that just because one ForwardingDomain at
a particular level of decomposition of the network happens to be the
one bounded by an NE does not mean that all ForwardingDomains at that
level are also bounded by NEs.
4.2.3. ForwardingDomain association with LTPs (FdAggregatesLtps
Composition)
An instance of FD is associated with zero or more LTP objects via the
"FdAggregatesLtps" composition.
4.2.4. ForwardingDomain aggregating Links (FdEncompassesLinks)
A ForwardingDomain can aggregate links. An example of
ForwardingDomain Recursive Aggregation with Links is shows in section
4.2.1 above.
However, the FdAggregatesLink association is not modeled because this
association can be inferred from the
Lam Expires January 3, 2016 [Page 17]
Internet-Draft Usage of an IM for network topology July 2015
higherLevelFdContainsLowerLevelFd association together with the
linkHasAssociatedFds association.
4.2.5. ForwardingDomain aggregating NEs
A ForwardingDomain can aggregate Network Elements. An example of
ForwardingDomain Recursive Aggregation with Links and NEs is shown in
section 4.2.2 above.
However, the FdAggregatesNe association is not modeled because this
association can be inferred from higherLevelFdContainsLowerLevelFd
association and together with the NeEncompassesFd association.
5. Detailed Description of the Topology Subset
The two key classes related to Topology are the ForwardingDomain (FD)
and the Link. For simple cases the FD represents the switching
capability in the network and the Link represents adjacency. These
are depicted in the context of other model classes in Figure 5-1.
--------------------------------------------------------------------
I I
I I
I I
I I
I Object Classes and Relationships in the Topology Subset I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Lam Expires January 3, 2016 [Page 18]
Internet-Draft Usage of an IM for network topology July 2015
Figure 5-1 Object Classes and Relationships in the Topology Subset
Figure 5-1 shows a lightweight view of the model omitting the
attributes (where appropriate these will be described later in this
section).
The FD and Link will be described in detail later in the document.
Figure 5-1 focuses on interrelationships and these will be the focus
of this section. The figure shows that:
- An FD may be a subordinate part of a NetworkElement (NE) or may
be larger than, and independent of, any NE.
- An FD may encompass lower level FDs. This may be such that:
o A FD directly contained in an NE is divided into smaller
parts
o A FD not encompassed by an NE is divided into smaller
parts some of which may be encompassed by NEs
o The FD represents the whole network
- An FD encompasses Links that interconnect any FDs encompassed
by the FD
- A Link may aggregate Links in several ways
o In parallel where several links are considered as one
o In series where Links chain to form a Link of a greater
span
. Note that this case requires further development in
the model
- A Link has associated FDs that it interconnects
o A Link may interconnect 2 or more FDs
Lam Expires January 3, 2016 [Page 19]
Internet-Draft Usage of an IM for network topology July 2015
. Note that it is usual for a Link to interconnect 2 FDs
but there are cases where many FDs may be
interconnected by a Link
- A Link has LinkEnds (LE)that represent the ports of the Link
itself
o LEs are especially relevant for multi-ended asymmetric
Link
- An LE aggregates LogicalTerminationPoints (LTPs) that bound the
Link. The LTP represent a stack LayerProtocol terminations
where the details of each is held in the LayerProtocol (LP).
The LTP may be:
o Part of an NE
o Conceptually independent from any NE
- An LE references LTPs on which the Link associated to the LE
terminates
Both the Link and FD are TopologicalEntities (an abstract class, i.e.
a class that will never instantiate) and hence they can acquire
contents from the conditional packages (_Pacs). The conditional
packages provide all key topology properties.
5.1. Topological Entity
As noted in the previous section the two key topology classes are
Forwarding Domain (FD) and Link (L).
The FD topological component is used to show the potential to enable
forwarding. At the lowest level of recursion, an FD (within a network
element (NE)) represents a switch matrix (e.g., a fabric). Note that
an NE can encompass multiple switch matrices (FDs).
As noted earlier the Link models adjacency between two or more
Forwarding Domains (FD).
Lam Expires January 3, 2016 [Page 20]
Internet-Draft Usage of an IM for network topology July 2015
Both the link and the FD have the potential to handle more than one
layerProtocol (both have a layerProtocolNameList attribute).
As shown in Figure 5-1 an object class ''TopologicalEntity'' has been
defined to collect topology-related properties (characteristics etc.)
that are common for FD and Link.
A TopologicalEntity is an abstract representation of the emergent
effect of the combined functioning of an arrangement of components
(running hardware, software running on hardware, etc). The effect can
be considered as the realization of the potential for apparent
communication adjacency for entities that are bound to the
terminations at the boundary of the TopologicalEntity.
The TopologicalEntity enables the creation of constrained forwarding
to achieve the apparent adjacency. The apparent adjacency has
intended performance degraded from perfect adjacency and a statement
of that degradation is conveyed via the attributes of the packages
associated with this class. In the model both ForwardingDomain and
Link are TopologicalEntities.
This abstract class is used as a modeling approach to apply packages
of attributes to both Link and ForwardingDomain. Link and
ForwardingDomain are the key TopologicalEntities.
5.2. Characteristics of Topological Entity
As noted above the characteristic of a TopologicalEnity are covered
by the conditional packages (_PACs).
Lam Expires January 3, 2016 [Page 21]
Internet-Draft Usage of an IM for network topology July 2015
--------------------------------------------------------------------
I I
I I
I I
I I
I Conditional Packages of Topological Entity I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 5-2 Conditional Packages of Topological Entity
5.2.1. Risk (RiskParameter_Pac)
The risk characteristics of a TopologicalEntity come directly from
the underlying physical realization.
The risk characteristics propagate from the physical realization to
the client and from the server layer to the client layer, this
propagation may be modified by protection.
A TopologicalEntity may suffer degradation or failure as a result of
a problem in a part of the underlying realization.
The realization can be partitioned into segments which have some
relevant common failure modes.
Lam Expires January 3, 2016 [Page 22]
Internet-Draft Usage of an IM for network topology July 2015
There is a risk of failure/degradation of each segment of the
underlying realization.
Each segment is a part of a larger physical/geographical unit that
behaves as one with respect to failure (i.e. a failure will have a
high probability of impacting the whole unit (e.g. all fibers in the
same cable).
Disruptions to that larger physical/geographical unit will impact
(cause failure/errors to) all TopologicalEntities that use any part
of that larger physical/geographical entity.
Any TopologicalEntity that uses any part of that larger
physical/geographical unit will suffer impact and hence each
TopologicalEntity shares risk.
The identifier of each physical/geographical unit that is involved in
the realization of each segment of a Topological entity can be listed
in the RiskParameter_Pac of that TopologicalEntity.
A segment has one or more risk characteristic.
Shared risk between two TopologicalEntities compromises the integrity
of any solution that use one of those TopologicalEntity as a backup
for the other.
Where two TopologicalEntities have a common risk characteristic they
have an elevated probability of failing simultaneously compared to
two TopologicalEntities that do not share risk characteristics.
- riskCharacteristicList: A list of risk characteristics
(RiskCharacteristic) for consideration in an analysis of shared
risk. Each element of the list represents a specific risk
consideration.
- RiskCharacteristic: The information for a particular risk
characteristic where there is a list of risk identifiers
related to that characteristic. It includes:
o riskCharacteristicName: The name of the risk
characteristic. The characteristic may be related to a
Lam Expires January 3, 2016 [Page 23]
Internet-Draft Usage of an IM for network topology July 2015
specific degree of closeness. For example a particular
characteristic may apply to failures that are localized
(e.g. to one side of a road) where as another
characteristic may relate to failures that have a broader
impact (e.g. both sides of a road that crosses a bridge).
Depending upon the importance of the traffic being routed
different risk characteristics will be evaluated.
o riskIdentifierList: A list of the identifiers of each
physical/geographic unit (with the specific risk
characteristic) that is related to a segment of the
TopologicalEntity.
5.2.2. TransferCost_Pac
The cost characteristics of a TopologicalEntity not necessarily
correlated to the cost of the underlying physical realization.
They may be quite specific to the individual TopologicalEntity e.g.
opportunity cost. Relates to layer capacity
There may be many perspectives from which cost may be considered for
a particular TopologicalEntity and hence many specifc costs and
potentially cost algorithms.
Using an entity will incur a cost.
- costCharcteristicList: The list of costs (CostCharacteristic)
where each cost relates to some aspect of the Link
o CostCharcteristic: The information for a particular cost
characteristic
. costName: The cost characteristic will related to some
aspect of the TopologicalEntity (e.g. $ cost, routing
weight). This aspect will be conveyed by the costName
. costValue: The specific cost.
Lam Expires January 3, 2016 [Page 24]
Internet-Draft Usage of an IM for network topology July 2015
. costAlgorithm: The cost may vary based upon some
properties of the TopologicalEntity. The rules for the
variation are conveyed by the costAlgorithm.
5.2.3. TransferTiming_Pac
A link will suffer effects from the underlying physical realization
related to the timing of the information passed by the link.
- fixedLatencyCharacteristic: A TopologicalEntity suffers delay
caused by the realization of the servers (e.g. distance
related; FEC encoding etc.) along with some client specific
processing. This is the total average latency effect of the
TopologicalEntity
- jitterCharacteristic: High frequency deviation from true
periodicity of a signal and therefore a small high rate of
change of transfer latency. Applies to TDM systems (and not
packet).
- wanderCharacteristics: Low frequency deviation from true
periodicity of a signal and therefore a small low rate of
change of transfer latency. Applies to TDM systems (and not
packet).
- queuingLatencyList: The effect on the latency of a queuing
process. This only has significant effect for packet based
systems and has a complex characteristic (QueuingLatency).
o QueuingLatency: Provides information on latency
characteristic for a particular stated trafficProperty.
5.2.4. TransferIntegrity_Pac
Transfer integrity characteristic covers expected (specified) error,
loss and duplicaion signal content as well as any damage of any form
to total link and to the client signals.
- errorCharacteristic: describes the degree to which the signal
propagated can be errored. Applies to TDM systems as the
Lam Expires January 3, 2016 [Page 25]
Internet-Draft Usage of an IM for network topology July 2015
errored signal will be propagated and not packet as errored
packets will be discarded.
- lossCharacteristic: Describes the acceptable characteristic of
lost packets where loss may result from discard due to errors
or overflow. Applies to packet systems and not TDM (as for TDM
errored signals are propagated unless grossly errored and
overflow/underflow turns into timing slips).
- repeatDeliveryCharacteristic: Primarily applies to packet
systems where a packet may be delivered more than once (in
fault recovery for example). It can also apply to TDM where
several frames may be received twice due to switching in a
system with a large differential propagation delay.
- deliveryOrderCharacteristic: Describes the degree to which
packets will be delivered out of sequence. Does not apply to
TDM as the TDM protocols maintain strict order.
- unavailableTimeCharacteristic: Describes the duration for which
there may be no valid signal propagated.
- serverIntegrityProcessCharacteristic: Describes the effect of
any server integrity enhancement process on the characteristics
of the TopologicalEntity.
5.2.5. TransferCapcity_Pac
The TopologicalEntity derives capacity from the underlying
realization.
A TopologicalEntity may be an abstraction and virtualization of a
subset of the underlying capability offered in a view or may be
directly reflecting the underlying realization.
A TopologicalEntity may be directly used in the view or may be
assigned to another view for use.
The clients supported by a multi-layer TopologicalEntity may interact
such that the resources used by one client may impact those available
to another. This is derived from the LTP spec details.
Lam Expires January 3, 2016 [Page 26]
Internet-Draft Usage of an IM for network topology July 2015
A TopologicalEntity represents the capacity available to user
(client) along with client interaction and usage.
A TopologicalEntity may reflect one or more client protocols and one
or more members for each profile.
- totalPotentialCapacity: A ''best case'' view of the capacity of
the TopologicalEntity assuming that any shared capacity is
available to be taken.
Note that this area is still under development to cover concepts such
as:
- exclusiveCapacityList: The capacity allocated to this
TopologicalEntity for its exclusive use
- sharedCapacityList: The capacity allocated to this
TopologicalEntity that is not exclusively available as it is
shared with others.
- assignedAsExclusiveCapacityList: The capacity assigned from
this TopologicalEnity to another TopologicalEntity for its
exclusive use
- assignedAsSharedCapacityList: The capacity assigned to one or
more other TopologicalEntities for shared use where the
interaction follows some stated algorithm.
- Capacity which includes:
o totalSize
o numberOfUsageInstances
o maximumUsageSize
o numberingRange
Lam Expires January 3, 2016 [Page 27]
Internet-Draft Usage of an IM for network topology July 2015
5.2.6. Validation_Pac
Validation covers the various adjacenct discovery and reachability
verification protocols. Also may cover Information source and degree
of integrity.
- validationMechanismList: Provides details of the specific
validation mechanism(s) used to confirm the presence of an
intended topologicalEntity.
5.2.7. LayerProtocolTransition_Pac
Relevant for a Link that is formed by abstracting one or more LTPs
(in a stack) to focus on the flow and deemphasize the protocol
transformation.
This abstraction is relevant when considering multi-layer routing.
The layer protocols of the LTP and the order of their application to
the signal is still relevant and need to be accounted for. This is
derived from the LTP spec details.
This Pac provides the relevant abstractions of the LTPs and provides
the necessary association to the LTPs involved.
Links that included details in this Pac are often referred to as
Transitional Links.
- transitionedLayerProtocolList: Provides the ordered structure
of layer protocol transitions encapsulated in the
TopologicalEntity. The ordering relates to the LinkEnd role.
6. Usage of the CNM Topology Subset regarding TE Topology DM
As discussed earlier, a data model (DM) may be derived from an IM.
It is possible to leverage the CNM Topology Subset to assess the
consistency and completeness of related YANG modules under
development. Appendix A provides a simple example of such a
derivation.
Lam Expires January 3, 2016 [Page 28]
Internet-Draft Usage of an IM for network topology July 2015
7. Security Considerations
This informational document is intended only to provide a description
of an interface-protocol-neutral information model, and the security
concerns are therefore out of the scope of this document.
8. IANA Considerations
This document includes no request to IANA.
9. Conclusions
The information model described in this draft, which is relevant to
Network Topology [ONF TR-512], can be leveraged in assessing the
consistency and completeness of related YANG modules under
development.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[I-D.betts] Betts, M., Davis, N., Lam, K., Zeuner, B., Mansfield, S.
and P. Doolan, ''Framework for Deriving Interface Data Schema
from UML Information Models'', draft-betts-netmod-framework-
data-schema-uml-01 (work in progress), March 2015
[ONF TR-512] ONF TR-512 ''ONF-CIM Core Model base document 1.0''
(https://www.opennetworking.org/images/stories/downloads/sdn-
resources/technical-reports/Core_Information_Model_V1.0.pdf) +
Model 1.0
(https://www.opennetworking.org/images/stories/downloads/sdn-
resources/technical-reports/CoreInformationModel.V1.0.zip),
March 2015
[G.852.2] Recommendation ITU-T G.852.2 ''Enterprise viewpoint
description of transport network resource model'', March 1999
Lam Expires January 3, 2016 [Page 29]
Internet-Draft Usage of an IM for network topology July 2015
[TMF612] TM Forum 612 ''MTOSI Information Agreement'', October 2014
11. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Lam Expires January 3, 2016 [Page 30]
Internet-Draft Usage of an IM for network topology July 2015
Appendix A. Example YANG from the CNM Topology Subset
Shown below is the YANG specification for the Link object class. To
also illustrate the concept of pruning (see [I-D.betts-netmod-
framework-data-schema-uml]), not all of the attributes of the Link
object class (see Section 5.2) defined in the ONF-CIM CNM are taken
for mapping to YANG.
The YANG module has been created using the simple mapping rules
listed below. Note: ONF is currently working on UML to YANG mapping
guideline technical recommendation.
UML artifact YANG artifact
identifiable object class list statement
attribute leaf statement
attribute list leaf-list statement
non-identifiable object class container statement
(Pac)
attribute referring to data container statement
type
data type grouping statement
attribute multiplicity min/max-elements substatements
A.1. Link YANG Specification
<CODE BEGINS> file "ONF_TR-512_CoreModel_Link.yang"
// Contents of "Topology IM Draft for IETF-93"
module ietf-TopologyIM {
namespace "urn:ietf:params:xml:ns:yang:ietf-TopologyIM";
// replace with iana namespace when assigned
prefix "TopIM";
organization "IETF";
contact
"WG Web: <http://tools.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
WG Chair: Vishnu Pavan Beeram
<mailto:vbeeram@juniper.net>
Lam Expires January 3, 2016 [Page 31]
Internet-Draft Usage of an IM for network topology July 2015
WG Chair: Lou Berger
<mailto:lberger@labn.net>
Editor: Kam Lam
<mailto:kam.lam@alcatel-lucent.com>";
description
"Brief YANG example for Link object class in the Core
Model (ONF::TR-512).";
revision 2015-07-02 {
description
"Initial version";
}
list Link {
key "guid";
leaf guid {
type string;
}
uses TopologicalEntity;
leaf-list layerProtocolNameList {
type string;
min-elements "1";
}
leaf-list aggregatedLinkList {
type leafref {
path "Link/guid";
// Mapping of recursion still to be agreed
}
}
list LinkEnd {
key "localId";
leaf localId {
type string;
}
min-elements "2";
leaf role {
type string; // Undefined in the model
mandatory true;
}
leaf-list localIdList {
type string; // YANG data type for name-value-pair?
min-elements "1";
}
leaf offNetworkAddress {
Lam Expires January 3, 2016 [Page 32]
Internet-Draft Usage of an IM for network topology July 2015
type string;
}
leaf-list ltpRefList {
type leafref {
path ""; /* Path to LTP definition
"??/LogicalTerminationPoint/name" */
}
}
}
}
// Groupings
grouping TopologicalEntity {
// Conditional Pacs associated to TopologicalEntity
container RiskParameter_Pac {
presence "<condition for RiskParameter_Pac attributes>";
list riskCharacteristicList {
key "riskCharacteristicName";
leaf riskCharacteristicName {
type string;
}
leaf-list riskIdentifierList {
type string;
min-elements "1";
}
min-elements "1";
}
}
container TransferCost_Pac {
presence "<condition for TransferCost_Pac attributes>";
list costCharacteristicList {
key "costName";
leaf costName {
type string;
}
leaf costValue {
type string;
mandatory true;
}
leaf costAlgorithm {
type string; // Undefined in the model
}
min-elements "1";
Lam Expires January 3, 2016 [Page 33]
Internet-Draft Usage of an IM for network topology July 2015
}
}
container TransferTiming_Pac {
presence "<condition for TransferTiming_Pac attributes>";
leaf fixedLatencyCharacteristic {
type string;
mandatory true;
}
leaf jitterCharacteristic {
type string;
}
leaf wanderCharacteristic {
type string;
}
list queuingLatencyList {
key "trafficProperty";
leaf trafficProperty {
type string;
}
leaf latencyForTrafficWithProperty {
type string;
mandatory true;
}
}
}
container TransferIntegrity_Pac {
presence "<condition for TransferIntegrity_Pac attributes>";
leaf errorCharacteristic {
type string;
}
leaf lossCharacteristic {
type string;
}
leaf repeatDeliveryCharacteristic {
type string;
}
leaf deliveryOrderCharacteristic {
type string;
}
leaf unavailableTimeCharacteristic {
type string;
mandatory true;
}
leaf serverIntegrityProcessCharacteristic {
type string;
Lam Expires January 3, 2016 [Page 34]
Internet-Draft Usage of an IM for network topology July 2015
}
}
container TransferCapacity_Pac {
presence "<condition for TransferCapacity_Pac attributes>";
container totalPotentialCapacity {
uses Capacity;
}
container availableCapacity {
uses Capacity;
}
container capacityAssignedToUserView {
// Don't know how to make this attribute multi-valued
uses Capacity;
}
leaf capacityInteractionAlgorithm {
type string;
}
}
container Validation_Pac {
presence "<condition for Validation_Pac attributes>";
list validationMechanismList {
key "validationMechanism";
leaf validationMechanism {
type string;
}
leaf layerProtocolAdjacencyValidated {
type string;
mandatory true;
}
leaf validationRobustness {
type string;
mandatory true;
}
min-elements "1";
}
}
container LayerProtocolTransition_Pac {
// Don't know how to make this Pac multi-valued
presence "<condition for LayerProtocolTransition_Pac
attributes>";
leaf-list transitionedLayerProtocolList {
type string;
min-elements "1";
}
Lam Expires January 3, 2016 [Page 35]
Internet-Draft Usage of an IM for network topology July 2015
}
}
grouping Capacity {
leaf totalSize {
type string;
mandatory true;
}
leaf numberOfClientInstances {
type string;
}
leaf maximumClientSize {
type string;
}
leaf numberingRange {
type string;
}
}
} <CODE ENDS>
A.2. Tree-Style Summary of the Link YANG Specification
module: ietf-TopologyIM
+--rw Link* [guid]
+--rw guid string
+--rw RiskParameter_Pac!
| +--rw riskCharacteristicList* [riskCharacteristicName]
| +--rw riskCharacteristicName string
| +--rw riskIdentifierList* string
+--rw TransferCost_Pac!
| +--rw costCharacteristicList* [costName]
| +--rw costName string
| +--rw costValue string
| +--rw costAlgorithm? string
+--rw TransferTiming_Pac!
| +--rw fixedLatencyCharacteristic string
| +--rw jitterCharacteristic? string
| +--rw wanderCharacteristic? string
| +--rw queuingLatencyList* [trafficProperty]
| +--rw trafficProperty string
| +--rw latencyForTrafficWithProperty string
+--rw TransferIntegrity_Pac!
| +--rw errorCharacteristic? string
| +--rw lossCharacteristic? string
| +--rw repeatDeliveryCharacteristic? string
Lam Expires January 3, 2016 [Page 36]
Internet-Draft Usage of an IM for network topology July 2015
| +--rw deliveryOrderCharacteristic? string
| +--rw unavailableTimeCharacteristic string
| +--rw serverIntegrityProcessCharacteristic? string
+--rw TransferCapacity_Pac!
| +--rw totalPotentialCapacity
| | +--rw totalSize string
| | +--rw numberOfClientInstances? string
| | +--rw maximumClientSize? string
| | +--rw numberingRange? string
| +--rw availableCapacity
| | +--rw totalSize string
| | +--rw numberOfClientInstances? string
| | +--rw maximumClientSize? string
| | +--rw numberingRange? string
| +--rw capacityAssignedToUserView
| | +--rw totalSize string
| | +--rw numberOfClientInstances? string
| | +--rw maximumClientSize? string
| | +--rw numberingRange? string
| +--rw capacityInteractionAlgorithm? string
+--rw Validation_Pac!
| +--rw validationMechanismList* [validationMechanism]
| +--rw validationMechanism string
| +--rw layerProtocolAdjacencyValidated string
| +--rw validationRobustness string
+--rw LayerProtocolTransition_Pac!
| +--rw transitionedLayerProtocolList* string
+--rw layerProtocolNameList* string
+--rw aggregatedLinkList* -> Link/guid
+--rw LinkEnd* [localId]
+--rw localId string
+--rw role string
+--rw localIdList* string
+--rw offNetworkAddress? string
+--rw ltpRefList* ->
Lam Expires January 3, 2016 [Page 37]
Internet-Draft Usage of an IM for network topology July 2015
Authors' Addresses
Kam Lam
Alcatel-Lucent, USA
Phone: +1 732 331 3476
Email: kam.lam@alcatel-lucent.com
Eve Varma
Alcatel-Lucent, USA
Email: eve.varma@alcatel-lucent.com
Paul Doolan
Coriant, Germany
Phone: +1 972 357 5822
Email: paul.doolan@coriant.com
Malcolm Betts
ZTE, China
Phone: +1 678 534 2542
Email: malcolm.betts@zte.com.cn
Nigel Davis
Ciena, UK
Email: ndavis@ciena.com
Bernd Zeuner
Deutsche Telekom, Germany
Phone: +49 6151 58 12086
Email: b.zeuner@telekom.de
Lam Expires January 3, 2016 [Page 38]
Internet-Draft Usage of an IM for network topology July 2015
Italo Busi
Huawei, China
Email: Italo.Busi@huawei.com
Scott Mansfield
Ericsson, Sweden
Phone: 1 724 931 9316
Email: scott.mansfield@ericsson.com
Yuji Tochio
Fujitsu, Japan
Phone: 81 44 754 8829
Email: tochio@jp.fujitsu.com
Lam Expires January 3, 2016 [Page 39]