[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

TEAS Working Group                                               K. Lam
Internet Draft                                                 E. Varma
Intended status: Informational                                    Nokia
Intended status: Informational                                P. Doolan
Expires: April 2017                                             Coriant
                                                                N. Davis
                                                                   Ciena
                                                               B. Zeuner
                                                        Deutsche Telekom
                                                                M. Betts
                                                                     ZTE
                                                                 I. Busi
                                                                  Huawei
                                                            S. Mansfield
                                                                Ericsson
                                                              R. Vilalta
                                                                    CTTC
                                                                V. Lopez
                                                              Telefonica
                                                       October 27, 2016




    Usage of IM for network topology to support TE Topology YANG Module
                                Development
            draft-lam-teas-usage-info-model-net-topology-04.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



Lam                     Expires April 28, 2017                 [Page 1]


Internet-Draft   Usage of an IM for network topology       October 2016


   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.

   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 April 28, 2017.

   Copyright Notice

   Copyright (c) 2016 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



Lam                     Expires April 28, 2017                 [Page 2]


Internet-Draft   Usage of an IM for network topology       October 2016


   for complex networking domains, has been described in draft-betts-
   netmod-framework-data-schema-uml.  This draft describes existing
   information model relevant to Network Topology and illustrates how it
   can be used to help ensure the consistency and completeness of the
   YANG data modeling for TE topologies solutions work in TEAS.

Table of Contents


   1. Introduction...................................................4
   2. Background and Motivation......................................4
   3. The Common Information Model...................................6
      3.1. Core Model................................................7
         3.1.1. Core Network Model...................................7
         3.1.2. Core Foundation Model................................9
         3.1.3. Core Physical Model.................................12
         3.1.4. Core Specification Model............................13
      3.2. Other Models.............................................15
   4. High Level Description of the Topology Subset of the CNM......15
      4.1. Object Classes of the CNM Topology Subset................16
         4.1.1. LogicalTerminationPoint (LTP) and LayerProtocol (LP)16
         4.1.2. ForwardingDomain (FD)...............................16
         4.1.3. Link and Link Port..................................17
         4.1.4. Network Element (NE)................................18
      4.2. Relationships between Object Classes of the Topology Subset18
         4.2.1. ForwardingDomain Recursive Aggregation
         (HigherLevelFdEncompassesLowerLevelFds Aggregation)........18
         4.2.2. Network Elements encompassing ForwardingDomains
         (NeEncompassesFds Aggregation).............................19
         4.2.3. ForwardingDomain association with LTPs (FdAggregatesLtps
         Composition)...............................................21
         4.2.4. ForwardingDomain aggregating Links (FdEncompassesLinks)
         ...........................................................21
         4.2.5. ForwardingDomain aggregating NEs....................21
   5. Detailed Description of the Topology Subset...................21
      5.1. Forwarding Entity........................................24
      5.2. Characteristics of Topological Entity....................25
         5.2.1. Risk (RiskParameter_Pac)............................26
         5.2.2. TransferCost_Pac....................................27
         5.2.3. TransferTiming_Pac..................................28
         5.2.4. TransferIntegrity_Pac...............................29


Lam                     Expires April 28, 2017                 [Page 3]


Internet-Draft   Usage of an IM for network topology       October 2016


         5.2.5. TransferCapcity_Pac.................................30
         5.2.6. Validation_Pac......................................31
         5.2.7. LayerProtocolTransition_Pac.........................31
   6. Purpose Specific IM Example - Transport API Topology Service..32
      6.1. T-API IM Constructs......................................32
      6.2. T-API Topology Service IM................................34
   7. Usage of the IM Topology Subset regarding TE Topology DM......35
   8. Security Considerations.......................................36
   9. IANA Considerations...........................................36
   10. Conclusions..................................................36
   11. References...................................................36
      11.1. Normative References....................................36
      11.2. Informative References..................................36
   12. Contributors.................................................38
   13. Acknowledgments..............................................38

1. Introduction

   This draft describes existing information modeling (IM) relevant to
   Network Topology [ONF TR-512] [OSSDN SNOWMASS] 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


Lam                     Expires April 28, 2017                 [Page 4]


Internet-Draft   Usage of an IM for network topology       October 2016


   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.

   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 first 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.  It also
   describes an transport application-specific IM [OSSDN SNOWMASS],
   derived from CIM pruning and refactoring as explained in [I-D.betts],
   that is intended to enable further clarity in understanding the
   modeling.  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.





Lam                     Expires April 28, 2017                 [Page 5]


Internet-Draft   Usage of an IM for network topology       October 2016


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 (see
   [ONF TR-512]), to provide an overall context for the topology
   relevant subset. The ONF-CIM has been developed through collaboration
   among several SDOs, including ITU-T, TM Forum, and ONF, and also
   published as ITU-T Recommendation G.7711 [G.7711].

   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
   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-514 [ONF TR-514]).

   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-515 [ONF TR-515]). 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,
   associations, 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 sub-models. This modeling
   approach enables application specific and forwarding technology
   specific extensions to be developed by domain experts with
   appropriate independence.  This approach is further articulated in
   ONF TR-513 [ONF TR-513] and [I-D.betts].


Lam                     Expires April 28, 2017                 [Page 6]


Internet-Draft   Usage of an IM for network topology       October 2016


3.1. Core Model

   The Core Model 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 is further sub-structured into sub-
   models. Currently, these consist of the Core Network Model (CNM),
   Core Foundation Model, Core Physical Model, and the Core
   Specification Model. The following sub-sections provide an overview
   of these sub-models. A detailed description is contained in ONF TR-
   512 [ONF TR-512].

3.1.1. Core Network Model

   The Core Network Model (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,
   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 LinkPorts.

      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



Lam                     Expires April 28, 2017                 [Page 7]


Internet-Draft   Usage of an IM for network topology       October 2016


        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): Also known as SNC. In conjunction
        with the FcPort, FC models the enabled forwarding between two
        FcPorts across a FD.

      o FcPort: Models the access to the FC, and associates the FC to
        the LTP. When the FC supports protection, the FcPort also
        indicates its role in the protection scheme, i.e., whether it
        is a working or protection FcPort.

      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



Lam                     Expires April 28, 2017                 [Page 8]


Internet-Draft   Usage of an IM for network topology       October 2016


      o Layer Protocol (LP): This identifies the type of signal and is
        the anchor for transport layer protocol specific definitions,
        which are modeled in, e.g., [G.874.1] for OTN, [G.8052] for
        transport Ethernet, and [G.8152] for MPLS-TP.

   -  Resilience Subset of CNM

      The Resilience subset provides a view of the model for resilience
      (including protection and restoration) and encompasses:

      o The basic resilience model structure

      o The key attributes relevant to resilience

      o The application of the resilience model to various cases

3.1.2. Core Foundation Model

   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 model 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
      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:





Lam                     Expires April 28, 2017                 [Page 9]


Internet-Draft   Usage of an IM for network topology       October 2016


      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 model also provides the opportunity to extend
   any entity using the Extension structure.

   The model 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
      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



Lam                     Expires April 28, 2017                [Page 10]


Internet-Draft   Usage of an IM for network topology       October 2016


   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 model 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-write with values: LOCKED, UNLOCKED

   -  Lifecycle State:

      Read-write with values: PLANNED, POTENTIAL, INSTALLED,
      PENDING_REMOVAL







   --------------------------------------------------------------------
   I                                                                  I
   I                                                                  I


Lam                     Expires April 28, 2017                [Page 11]


Internet-Draft   Usage of an IM for network topology       October 2016


   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.1.3. Core Physical Model

   The Physical model provides a view of the model for physical entities
   (including equipment, holders and connectors). This model also
   specifies the relationship between the connector and the LTP, and the
   relationship between physical and functional views.










   --------------------------------------------------------------------
   I                                                                  I
   I                                                                  I
   I                                                                  I
   I                                                                  I
   I                       Basic Equipment Pattern                    I
   I                                                                  I
   I                                                                  I
   I                                                                  I
   I                                                                  I
   I                     (only in PDF version)                        I
   I                                                                  I


Lam                     Expires April 28, 2017                [Page 12]


Internet-Draft   Usage of an IM for network topology       October 2016


   I                                                                  I
   I                                                                  I
   I                                                                  I
   I                                                                  I
   --------------------------------------------------------------------




                    Figure 3-3 Basic Equipment Pattern

3.1.4. Core Specification Model

   There are several related needs that have given rise to the
   Specification model:

   -  Provide machine readable form of specific localized behavior:

      o Representing rules related to restrictions of specific cases of
        use of the model

      o Representing capabilities of specific cases of use

   -  Enable the introduction of run time schema where the essential
      structure of the model is known up front (at compile time) but
      the details are not

   -  Reduce the clutter in a representation where a set of details take
      the same values for all instances that are related to a specific
      case

   -  Allow leverage of existing standards definitions (e.g.,
      technology/application specific) in a machine readable language

   The combination of the above resulted in a separation in the model of
   definitions of structure and content such that an instance of a class
   from one model fragment could have an association instance to another
   model fragment to enable the provision of a fragment of definition of
   the class and of subordinates.

   The aim of all specification definitions is that they be rigorous
   definitions of specific cases of usage and enable machine


Lam                     Expires April 28, 2017                [Page 13]


Internet-Draft   Usage of an IM for network topology       October 2016


   interpretation where traditional interface designs would only allow
   human interpretation.

   The following dedicated spec structures have been considered:

   -  FC spec: Main focus to provide a representation of the effective
      internal structure of a ForwardingConstruct (FC)

   -  LTP and LP spec: Main focus to provide a representation of Layer
      Protocol (LP) specific parameters for the Logical Termination
      Point (LTP)

   -  FD and Link spec: Main focus on capacity and forwarding enablement
      restrictions

   -  Equipment spec: Main focus to provide a representation of
      equipping constraints





   --------------------------------------------------------------------
   I                                                                  I
   I                                                                  I
   I                                                                  I
   I                                                                  I
   I          Class Diagram of the Spec Model of LTP and LP           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 April 28, 2017                [Page 14]


Internet-Draft   Usage of an IM for network topology       October 2016




         Figure 3-4 Class Diagram of the Spec Model of LTP and LP

3.2. Other Models

   In addition to the Core Model, the ONF-CIM includes forwarding
   technology and application specific models. The forwarding technology
   models 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
   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







Lam                     Expires April 28, 2017                [Page 15]


Internet-Draft   Usage of an IM for network topology       October 2016


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.

   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



Lam                     Expires April 28, 2017                [Page 16]


Internet-Draft   Usage of an IM for network topology       October 2016


   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 Port

   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 (LinkPort) 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
   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 LinkPort 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.



Lam                     Expires April 28, 2017                [Page 17]


Internet-Draft   Usage of an IM for network topology       October 2016


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.

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


Lam                     Expires April 28, 2017                [Page 18]


Internet-Draft   Usage of an IM for network topology       October 2016


   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.

   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.




Lam                     Expires April 28, 2017                [Page 19]


Internet-Draft   Usage of an IM for network topology       October 2016






   --------------------------------------------------------------------
   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

   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



Lam                     Expires April 28, 2017                [Page 20]


Internet-Draft   Usage of an IM for network topology       October 2016


   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
   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



Lam                     Expires April 28, 2017                [Page 21]


Internet-Draft   Usage of an IM for network topology       October 2016


   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
   --------------------------------------------------------------------




    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



Lam                     Expires April 28, 2017                [Page 22]


Internet-Draft   Usage of an IM for network topology       October 2016


          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

               . 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 LinkPorts that represent the ports of the Link
        itself

          o  LinkPorts are especially relevant for multi-ended
             asymmetric Link

     -  A LinkPort 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




Lam                     Expires April 28, 2017                [Page 23]


Internet-Draft   Usage of an IM for network topology       October 2016


     -  A LinkPort references LTPs on which the Link associated to the
        LE terminates

   Both the Link and FD are subclasses of ForwardingEntity (an abstract
   class, i.e. a class that will never be instantiated) and hence they
   can acquire contents from the conditional packages (_Pacs). The
   conditional packages provide all key topology properties.

5.1. Forwarding 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).

   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 "ForwardingEntity" has been
   defined to collect topology-related properties (characteristics etc.)
   that are common for FD and Link.

   A ForwardingEntity 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 ForwardingEntity.

   The ForwardingEntity 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 ForwardingEntities.



Lam                     Expires April 28, 2017                [Page 24]


Internet-Draft   Usage of an IM for network topology       October 2016


   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 ForwardingEntities.

5.2. Characteristics of Topological Entity

   As noted above the characteristic of a TopologicalEnity are covered
   by the conditional packages (_PACs).





















   --------------------------------------------------------------------
   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



Lam                     Expires April 28, 2017                [Page 25]


Internet-Draft   Usage of an IM for network topology       October 2016


   --------------------------------------------------------------------




           Figure 5-2 Conditional Packages of Topological Entity

5.2.1. Risk (RiskParameter_Pac)

   The risk characteristics of a ForwardingEntity 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 ForwardingEntity 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.

   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 ForwardingEntities that use any part of
   that larger physical/geographical entity.

   Any ForwardingEntity that uses any part of that larger
   physical/geographical unit will suffer impact and hence each
   ForwardingEntity 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 ForwardingEntity.



Lam                     Expires April 28, 2017                [Page 26]


Internet-Draft   Usage of an IM for network topology       October 2016


   A segment has one or more risk characteristic.

   Shared risk between two ForwardingEntities compromises the integrity
   of any solution that use one of those ForwardingEntity as a backup
   for the other.

   Where two ForwardingEntities have a common risk characteristic they
   have an elevated probability of failing simultaneously compared to
   two ForwardingEntities 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
             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
             ForwardingEntity.

5.2.2. TransferCost_Pac

   The cost characteristics of a ForwardingEntity not necessarily
   correlated to the cost of the underlying physical realization.

   They may be quite specific to the individual ForwardingEntity e.g.
   opportunity cost. Relates to layer capacity


Lam                     Expires April 28, 2017                [Page 27]


Internet-Draft   Usage of an IM for network topology       October 2016


   There may be many perspectives from which cost may be considered for
   a particular ForwardingEntity 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 ForwardingEntity (e.g. $ cost, routing
                  weight). This aspect will be conveyed by the costName

               . costValue: The specific cost.

               . costAlgorithm: The cost may vary based upon some
                  properties of the ForwardingEntity. 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 ForwardingEntity 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
        ForwardingEntity

     -  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 (i.e., not
        packet based systems).

     -  wanderCharacteristics: Low frequency deviation from true
        periodicity of a signal and therefore a small low rate of



Lam                     Expires April 28, 2017                [Page 28]


Internet-Draft   Usage of an IM for network topology       October 2016


        change of transfer latency. Applies to TDM systems (i.e., not
        packet based systems).

     -  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 duplication 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
        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.




Lam                     Expires April 28, 2017                [Page 29]


Internet-Draft   Usage of an IM for network topology       October 2016


     -  serverIntegrityProcessCharacteristic: Describes the effect of
        any server integrity enhancement process on the characteristics
        of the ForwardingEntity.

5.2.5. TransferCapcity_Pac

   The ForwardingEntity derives capacity from the underlying
   realization.

   A ForwardingEntity 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 ForwardingEntity may be directly used in the view or may be
   assigned to another view for use.

   The clients supported by a multi-layer ForwardingEntity may interact
   such that the resources used by one client may impact those available
   to another. This is derived from the LTP spec details.

   A ForwardingEntity represents the capacity available to user (client)
   along with client interaction and usage.

   A ForwardingEntity 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 ForwardingEntity 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
        ForwardingEntity for its exclusive use

     -  sharedCapacityList: The capacity allocated to this
        ForwardingEntity that is not exclusively available as it is
        shared with others.





Lam                     Expires April 28, 2017                [Page 30]


Internet-Draft   Usage of an IM for network topology       October 2016


     -  assignedAsExclusiveCapacityList: The capacity assigned from
        this TopologicalEnity to another ForwardingEntity for its
        exclusive use

     -  assignedAsSharedCapacityList: The capacity assigned to one or
        more other ForwardingEntities for shared use where the
        interaction follows some stated algorithm.

     -  Capacity which includes:

          o  totalSize

          o  numberOfUsageInstances

          o  maximumUsageSize

          o  numberingRange

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 ForwardingEntity.

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.





Lam                     Expires April 28, 2017                [Page 31]


Internet-Draft   Usage of an IM for network topology       October 2016


   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
        ForwardingEntity. The ordering relates to the LinkEnd role.

6. Purpose Specific IM Example - Transport API Topology Service

   In order to provide some further clarity, this section provides a
   high level introduction to a Purpose Specific IM, the Transport API
   (T-API) Topology service, which has been derived from the ONF Common
   Information Model (ONF-CIM) according to the principles in [I-
   D.betts].

   The context of the T-API refers to the scope and control and naming
   that a particular SDN controller, manager or a client application has
   with respect to the information it operates on internally or
   exchanges over an interface.  The following sections further describe
   this purpose specific IM and relationship to the ONF-CIM.

6.1. T-API IM Constructs

   The T-API IM uses terminology that is considered to be more familiar
   to the transport network management community and maps to the
   constructs defined in the ONF-CIM CNM Topology model. The following
   table provides a high level summary of the mapping of the constructs
   relevant to the T-API Topology Service.

                   Mapping of CIM and T-API IM Constructs
              ONF-CIM CNM Terminology      T-API IM Terminology
           NetworkControlDomain         Context
                                      Topology                 ForwardingDomain (FD)        Node
                                      Link                 Link                       TransitionalLink
                                      NodeEdgePoint                 LogicalTerminationPoint (LTP) ServideEndPoint



Lam                     Expires April 28, 2017                [Page 32]


Internet-Draft   Usage of an IM for network topology       October 2016


   The following provides a brief description of these T-API IM
   constructs.

     o  Link: A Link is an abstract representation of the effective
        adjacency between two or more associated Nodes in a Topology.
        It is terminated by Node-Edge-Points of the associated Nodes.

     o  Node: A Node is an abstract representation of the forwarding-
        capabilities of a particular set of Network Resources. It is
        described in terms of an aggregation of set of ports (Node-
        Edge-Point) belonging to those Network Resources and the
        potential to enable forwarding of information between those
        edge ports.

     o  Node-Edge-Point: A Node-Edge-Point represents the inward
        network-facing aspects of the edge-port functions that access
        the forwarding capabilities provided by the Node. Hence it
        provides an encapsulation of addressing, mapping, termination,
        adaptation and OAM functions of one or more transport layers
        (including circuit and packet forms) performed at the entry and
        exit points of the Node.

     o  Topology: A Topology is an abstract representation of the
        topological-aspects of a particular set of Network Resources.
        It is described in terms of a network of set of Nodes and Links
        that enable the forwarding-capabilities of that particular set
        of Network Resources.

     o  Service-End-Point: A Service-End-Point represents the outward
        customer-facing aspects of the edge-port functions that access
        the forwarding capabilities provided by the Node. Hence it
        provides a limited, simplified view of interest to external
        clients (e.g. shared addressing, capacity, resource
        availability, etc) that enable the clients to request
        connectivity without the need to understand the provider
        network internals.

     o  Transitional Link: A topological component that consists of the
        link port at the edge of one node and a corresponding link port
        at the edge of another node that operates on different layers
        or whose layer is the same but with different Layer


Lam                     Expires April 28, 2017                [Page 33]


Internet-Draft   Usage of an IM for network topology       October 2016


        Information. A transitional link is supported/implemented by
        transport processing functions (e.g., adaptation/termination).
        A transitional link can be partitioned into parallel
        transitional links, or a concatenation of transitional links.
        It can also be partitioned into a concatenation of transitional
        links and zero or more links.

6.2. T-API Topology Service IM

   The resultant high-level description for the T-API Topology Service
   constructs, based upon the pruned and refactored ONF-CIM, and the
   related Topology Service APIs are provided in Figure 6-1 below.













   --------------------------------------------------------------------
   I                                                                  I
   I                                                                  I
   I                                                                  I
   I                                                                  I
   I                    Topology Service Skeleton                       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 April 28, 2017                [Page 34]


Internet-Draft   Usage of an IM for network topology       October 2016




                   Figure 6-1 Topology Service Skeleton

   The T-API Topology Service API enables the API client to, for
   example, retrieve Topology, Node, Link, and Edge-Point details.

     o  Topology details: returns attributes of the Topology identified
        by the provided input ID.  This includes references to lower-
        level Nodes and Links encompassed by that Topology. A NULL
        input value is expected to return the top-most Topology that
        corresponds to the scope of the entire Context including any
        Off-Network-Links.

     o  Node details: Returns attributes of the Node identified by the
        provided input ID.  Includes references to Node-Edge-Points
        aggregated by the Node, and attributes representing the
        identification, naming, states and forwarding capabilities of
        the Node.

     o  Link details: Returns attributes of the Link identified by the
        provided input ID.  Includes references to Node-Edge-Points
        terminating the Link, and references to the Nodes associated by
        the Link.

     o  Node-Edge-Point details: Returns attributes of the Node-Edge-
        Point identified by the provided input ID, including references
        to Service-End-Points mapped to this Node-Edge-Point.

   The API supports a retrieve-scope filter: LayerProtocol list. If
   set, the API call will return output that is relevant to the
   specified Layer only.

7. Usage of the IM Topology Subset regarding TE Topology DM

   As discussed earlier, a data model (DM) may be derived from an IM.
   Examples of YANG DMs derived according to automated translation tools
   based upon mapping guidelines are provided in [OSSDN SNOMASS] at
   https://github.com/OpenNetworkingFoundation/Snowmass-
   ONFOpenTransport/tree/develop/YANG. It is possible to leverage the IM




Lam                     Expires April 28, 2017                [Page 35]


Internet-Draft   Usage of an IM for network topology       October 2016


   Topology Subset to assess the consistency and completeness of related
   YANG modules under development.

8. 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.

9. IANA Considerations

   This document includes no request to IANA.

10. Conclusions

   The information modeling described in this draft, which is relevant
   to Network Topology [ONF TR-512] [OSSDN SNOWMASS], can be leveraged
   in assessing the consistency and completeness of related YANG modules
   under development.

11. References

11.1. Normative References

    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

11.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-04 (work in progress), October 2016

   [I-D.mansfield] Mansfield, S., Zeuner, B., Davis, N., Yun, X.,
        Tochio, Y., Lam, K. and E. Varma, "Guidelines for Translation
        of UML Information Model to YANG Data Model", draft-mansfield-
        netmod-uml-to-yang-03 (work in progress), October 2016







Lam                     Expires April 28, 2017                [Page 36]


Internet-Draft   Usage of an IM for network topology       October 2016


   [ONF TR-512] ONF TR-512 "ONF-CIM Core Model base document 1.2"
        (https://www.opennetworking.org/images/stories/downloads/sdn-
        resources/technical-reports/TR-512_CIM_(CoreModel)_1.2.zip),
        September 2016

   [ONF TR-513] ONF TR-513 " Common Information Model Overview 1.2"
        (https://www.opennetworking.org/images/stories/downloads/sdn-
        resources/technical-reports/TR-513_CIM_Overview_1.2.pdf),
        September 2016

   [ONF TR-514] ONF TR-514 "UML Modeling Guidelines 1.2"
        (https://www.opennetworking.org/images/stories/downloads/sdn-
        resources/technical-reports/TR-
        514_UML_Modeling_Guidelines_v1.2.pdf), September 2016

   [ONF TR-515] ONF TR-515 "Papyrus Guidelines 1.2"
        (https://www.opennetworking.org/images/stories/downloads/sdn-
        resources/technical-reports/TR-
        515_Papyrus_Guidelines_v1.2.pdf), September 2016

   [OSSDN SNOWMASS] Open Source SDN SNOWMASS/Open Transport API
        Specifications
        (https://github.com/OpenNetworkingFoundation/Snowmass-
        ONFOpenTransport)

   [G.7711] Recommendation ITU-T G.7711/Y.17022 "Generic protocol-
           neutral information model for transport resources",
           September 2016

   [G.874.1] Recommendation ITU-T G.874.1 "Optical transport network:
           Protocol-neutral management information model for the
           network element view", September 2016

   [G.8052] Recommendation ITU-T G.8052/Y.1346 "Protocol-neutral
           management information model for the Ethernet Transport
           capable network element", September 2016

   [G.8152] Recommendation ITU-T G.8152/Y.1375 "Protocol-neutral
           management information model for the MPLS-TP network
           element", September 2016




Lam                     Expires April 28, 2017                [Page 37]


Internet-Draft   Usage of an IM for network topology       October 2016


   [G.852.2] Recommendation ITU-T G.852.2 "Enterprise viewpoint
           description of transport network resource model", March 1999

   [TMF612] TM Forum 612 "MTOSI Information Agreement", October 2014

12. Contributors

   Karthik Sethuraman
   NEC

   Email: karthik.sethuraman@necam.com

13. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.
































Lam                     Expires April 28, 2017                [Page 38]


Internet-Draft   Usage of an IM for network topology       October 2016


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 April 28, 2017                [Page 39]


Internet-Draft   Usage of an IM for network topology       October 2016



   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


   Ricard Vilalta
   CTTC, Spain

   Phone:
   Email: ricard.vilalta@cttc.es


   Victor Lopez
   Telefonica, Spain

   Phone:
   Email: victor.lopezalvarez@telefonica.com











Lam                     Expires April 28, 2017                [Page 40]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/