TEAS Working Group K. Lam Internet Draft E. Varma Intended status: Informational Alcatel-Lucent Intended status: Informational P. Doolan Expires: September 2015 Coriant N. Davis Ciena B. Zeuner Deutsche Telekom M. Betts ZTE I. Busi Huawei S. Mansfield Ericsson March 6, 2015 Usage of IM for network topology to support TE Topology YANG Module Development draft-lam-teas-usage-info-model-net-topology-00.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 September 6, 2015 [Page 1] Internet-Draft Usage of an IM for network topology March 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 September 6, 2015. 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 ([ONF Liaison] and illustrates how it can be used to help ensure the consistency and Lam Expires September 6, 2015 [Page 2] Internet-Draft Usage of an IM for network topology March 2015 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)..............................14 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)...............................................18 4.2.4. ForwardingDomain aggregating Links (FdEncompassesLinks) ...........................................................18 4.2.5. ForwardingDomain aggregating NEs....................18 5. Detailed Description of the Topology Subset...................18 5.1. Topological Entity.......................................21 5.2. Characteristics of Topological Entity....................22 5.2.1. Risk (RiskParameter_Pac)............................23 5.2.2. TransferCost_Pac....................................25 5.2.3. TransferTiming_Pac..................................26 5.2.4. TransferIntegrity_Pac...............................27 5.2.5. TransferCapcity_Pac.................................27 5.2.6. Validation_Pac......................................29 5.2.7. LayerProtocolTransition_Pac.........................29 6. Usage of the CNM Topology Subset regarding TE Topology DM.....30 7. Security Considerations.......................................30 Lam Expires September 6, 2015 [Page 3] Internet-Draft Usage of an IM for network topology March 2015 8. IANA Considerations...........................................30 9. Conclusions...................................................30 10. References...................................................30 10.1. Normative References....................................30 10.2. Informative References..................................30 11. Acknowledgments..............................................31 Appendix A. Example YANG from the CNM Topology Subset............32 A.1. Link YANG Specification..................................32 A.2. Tree-Style Summary of the Link YANG Specification........34 1. Introduction This draft describes an existing information model (IM) relevant to Network Topology [ONF Liaison] 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 September 6, 2015 [Page 4] Internet-Draft Usage of an IM for network topology March 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 Liaison], 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 Liaison]), 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 September 6, 2015 [Page 5] Internet-Draft Usage of an IM for network topology March 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 Liaison [ONF Liaison]). 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 Liaison [ONF liaison]). 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 September 6, 2015 [Page 6] Internet-Draft Usage of an IM for network topology March 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 September 6, 2015 [Page 7] Internet-Draft Usage of an IM for network topology March 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 September 6, 2015 [Page 8] Internet-Draft Usage of an IM for network topology March 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 September 6, 2015 [Page 9] Internet-Draft Usage of an IM for network topology March 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 September 6, 2015 [Page 10] Internet-Draft Usage of an IM for network topology March 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 Liaison]) 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. Lam Expires September 6, 2015 [Page 11] Internet-Draft Usage of an IM for network topology March 2015 -------------------------------------------------------------------- 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 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 Lam Expires September 6, 2015 [Page 12] Internet-Draft Usage of an IM for network topology March 2015 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 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. Lam Expires September 6, 2015 [Page 13] Internet-Draft Usage of an IM for network topology March 2015 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 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. Lam Expires September 6, 2015 [Page 14] Internet-Draft Usage of an IM for network topology March 2015 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 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 Lam Expires September 6, 2015 [Page 15] Internet-Draft Usage of an IM for network topology March 2015 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 September 6, 2015 [Page 16] Internet-Draft Usage of an IM for network topology March 2015 -------------------------------------------------------------------- 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 hand side NE encompassing three FDs) the subordinate ForwardingDomains are themselves joined by Links emphasizing that the Lam Expires September 6, 2015 [Page 17] Internet-Draft Usage of an IM for network topology March 2015 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 capability in the network and the Link represents adjacency. These are depicted in the context of other model classes in Figure 5-1. Lam Expires September 6, 2015 [Page 18] Internet-Draft Usage of an IM for network topology March 2015 -------------------------------------------------------------------- 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 o A FD not encompassed by an NE is divided into smaller parts some of which may be encompassed by NEs Lam Expires September 6, 2015 [Page 19] Internet-Draft Usage of an IM for network topology March 2015 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 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 Lam Expires September 6, 2015 [Page 20] Internet-Draft Usage of an IM for network topology March 2015 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). 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. Lam Expires September 6, 2015 [Page 21] Internet-Draft Usage of an IM for network topology March 2015 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 September 6, 2015 [Page 22] Internet-Draft Usage of an IM for network topology March 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. Lam Expires September 6, 2015 [Page 23] Internet-Draft Usage of an IM for network topology March 2015 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. 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. Lam Expires September 6, 2015 [Page 24] Internet-Draft Usage of an IM for network topology March 2015 - 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 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 Lam Expires September 6, 2015 [Page 25] Internet-Draft Usage of an IM for network topology March 2015 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. . 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. Lam Expires September 6, 2015 [Page 26] Internet-Draft Usage of an IM for network topology March 2015 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 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. Lam Expires September 6, 2015 [Page 27] Internet-Draft Usage of an IM for network topology March 2015 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. 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: Lam Expires September 6, 2015 [Page 28] Internet-Draft Usage of an IM for network topology March 2015 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 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. Lam Expires September 6, 2015 [Page 29] Internet-Draft Usage of an IM for network topology March 2015 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. 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 Liaison], 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 Liaison] ONF Liaison "Information modeling work in progress", March 2015 (https://datatracker.ietf.org/liaison/) Lam Expires September 6, 2015 [Page 30] Internet-Draft Usage of an IM for network topology March 2015 [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 11. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Lam Expires September 6, 2015 [Page 31] Internet-Draft Usage of an IM for network topology March 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 // Contents of "Topology IM Draft for IETF-92" module OnfCimCnmTopologyIM { namespace "urn:OnfCimCnmTopologyIM"; prefix "TopIM"; organization "IETF"; revision 2015-02-26 { description "Brief YANG example for Link object class of the ONF Common Information Model (ONF-CIM ) Core Network Module (CNM)."; } list Link { key "name"; Lam Expires September 6, 2015 [Page 32] Internet-Draft Usage of an IM for network topology March 2015 leaf name { type string; } leaf guid { type string; } leaf-list layerProtocolNameList { type string; min-elements "1"; } container TransferCapacity_Pac { container totalLinkCapacity { uses Capacity; } container availableLinkCapacity { uses Capacity; } leaf capacityInteractionAlgorithmen { type string; } container capacityAssignedToUserView { uses Capacity; } } container LinkValidation_Pac { leaf validationMechanismList { type string; } } container LayerTransition_Pac { leaf-list transitionedLayerList { type string; min-elements "1"; } } Lam Expires September 6, 2015 [Page 33] Internet-Draft Usage of an IM for network topology March 2015 } grouping Capacity { leaf bandwidth { type string; } leaf numberOfClientInstances { type string; } } } A.2. Tree-Style Summary of the Link YANG Specification module: OnfCimCnmTopologyIM +--rw Link* [name] +--rw name string +--rw guid? string +--rw layerProtocolNameList* string +--rw TransferCapacity_Pac | +--rw totalLinkCapacity | | +--rw bandwidth? string | | +--rw numberOfClientInstances? string | +--rw availableLinkCapacity | | +--rw bandwidth? string | | +--rw numberOfClientInstances? string | +--rw capacityInteractionAlgorithmen? string | +--rw capacityAssignedToUserView | +--rw bandwidth? string | +--rw numberOfClientInstances? string +--rw LinkValidation_Pac | +--rw validationMechanismList? string +--rw LayerTransition_Pac +--rw transitionedLayerList* string Lam Expires September 6, 2015 [Page 34] Internet-Draft Usage of an IM for network topology March 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 September 6, 2015 [Page 35] Internet-Draft Usage of an IM for network topology March 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 September 6, 2015 [Page 36]