idnits 2.17.1 draft-lam-teas-usage-info-model-net-topology-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 41 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2016) is 2731 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'OSSDN SNOMASS' is mentioned on line 1346, but not defined == Unused Reference: 'RFC2119' is defined on line 1373, but no explicit reference was found in the text == Unused Reference: 'I-D.mansfield' is defined on line 1383, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group K. Lam 2 Internet Draft E. Varma 3 Intended status: Informational Nokia 4 Intended status: Informational P. Doolan 5 Expires: April 2017 Coriant 6 N. Davis 7 Ciena 8 B. Zeuner 9 Deutsche Telekom 10 M. Betts 11 ZTE 12 I. Busi 13 Huawei 14 S. Mansfield 15 Ericsson 16 R. Vilalta 17 CTTC 18 V. Lopez 19 Telefonica 20 October 27, 2016 22 Usage of IM for network topology to support TE Topology YANG Module 23 Development 24 draft-lam-teas-usage-info-model-net-topology-04.txt 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 This document may contain material from IETF Documents or IETF 32 Contributions published or made publicly available before November 33 10, 2008. The person(s) controlling the copyright in some of this 34 material may not have granted the IETF Trust the right to allow 35 modifications of such material outside the IETF Standards Process. 36 Without obtaining an adequate license from the person(s) controlling 37 the copyright in such materials, this document may not be modified 38 outside the IETF Standards Process, and derivative works of it may 39 not be created outside the IETF Standards Process, except to format 40 it for publication as an RFC or to translate it into languages other 41 than English. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as Internet- 46 Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/ietf/1id-abstracts.txt 56 The list of Internet-Draft Shadow Directories can be accessed at 57 http://www.ietf.org/shadow.html 59 This Internet-Draft will expire on April 28, 2017. 61 Copyright Notice 63 Copyright (c) 2016 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Abstract 78 The benefits of using a common Information Model (IM) as a foundation 79 for deriving purpose and protocol specific interfaces, particularly 80 for complex networking domains, has been described in draft-betts- 81 netmod-framework-data-schema-uml. This draft describes existing 82 information model relevant to Network Topology and illustrates how it 83 can be used to help ensure the consistency and completeness of the 84 YANG data modeling for TE topologies solutions work in TEAS. 86 Table of Contents 88 1. Introduction...................................................4 89 2. Background and Motivation......................................4 90 3. The Common Information Model...................................6 91 3.1. Core Model................................................7 92 3.1.1. Core Network Model...................................7 93 3.1.2. Core Foundation Model................................9 94 3.1.3. Core Physical Model.................................12 95 3.1.4. Core Specification Model............................13 96 3.2. Other Models.............................................15 97 4. High Level Description of the Topology Subset of the CNM......15 98 4.1. Object Classes of the CNM Topology Subset................16 99 4.1.1. LogicalTerminationPoint (LTP) and LayerProtocol (LP)16 100 4.1.2. ForwardingDomain (FD)...............................16 101 4.1.3. Link and Link Port..................................17 102 4.1.4. Network Element (NE)................................18 103 4.2. Relationships between Object Classes of the Topology Subset18 104 4.2.1. ForwardingDomain Recursive Aggregation 105 (HigherLevelFdEncompassesLowerLevelFds Aggregation)........18 106 4.2.2. Network Elements encompassing ForwardingDomains 107 (NeEncompassesFds Aggregation).............................19 108 4.2.3. ForwardingDomain association with LTPs (FdAggregatesLtps 109 Composition)...............................................21 110 4.2.4. ForwardingDomain aggregating Links (FdEncompassesLinks) 111 ...........................................................21 112 4.2.5. ForwardingDomain aggregating NEs....................21 113 5. Detailed Description of the Topology Subset...................21 114 5.1. Forwarding Entity........................................24 115 5.2. Characteristics of Topological Entity....................25 116 5.2.1. Risk (RiskParameter_Pac)............................26 117 5.2.2. TransferCost_Pac....................................27 118 5.2.3. TransferTiming_Pac..................................28 119 5.2.4. TransferIntegrity_Pac...............................29 120 5.2.5. TransferCapcity_Pac.................................30 121 5.2.6. Validation_Pac......................................31 122 5.2.7. LayerProtocolTransition_Pac.........................31 123 6. Purpose Specific IM Example - Transport API Topology Service..32 124 6.1. T-API IM Constructs......................................32 125 6.2. T-API Topology Service IM................................34 126 7. Usage of the IM Topology Subset regarding TE Topology DM......35 127 8. Security Considerations.......................................36 128 9. IANA Considerations...........................................36 129 10. Conclusions..................................................36 130 11. References...................................................36 131 11.1. Normative References....................................36 132 11.2. Informative References..................................36 133 12. Contributors.................................................38 134 13. Acknowledgments..............................................38 136 1. Introduction 138 This draft describes existing information modeling (IM) relevant to 139 Network Topology [ONF TR-512] [OSSDN SNOWMASS] and illustrates how it 140 can be used to help ensure the consistency and completeness of the 141 YANG data model (DM) for TE topologies solutions development work in 142 TEAS. 144 2. Background and Motivation 146 Information Models (IM) and Data Models (DM) are related but 147 different. An IM provides an abstract, conceptual view of the system 148 being modeled in terms of its constituent parts (objects), 149 independent of any specific implementations or protocols used to 150 transport the data; it hides all protocol and implementation details 151 (RFC 3444, TM Forum/NGCOR, ITU-T SG 15). A DM is a concrete 152 specification in a particular language of an interface to, in this 153 case, a controlled/managed system. The intention of the distinction 154 between IMs and DMs has been to separate the modeling of problem 155 space semantics from the modeling of the implementation of those 156 semantics (though the dividing line has not always been clearly 157 articulated). 159 A DM may be derived from an IM though it is often created without 160 (explicit or obviously implicit) reference to one. When a DM is 161 derived from an IM, the DM and the components of the system it 162 provides control/management access to are traceable to the 163 definitions provided in the IM. There is no ambiguity between 164 designer, developer, user or operator regarding the name, function, 165 and information elements that are associated with a particular 166 managed object. 168 As described in [I-D.betts], when DMs are created "in isolation" 169 solely for the purpose of encoding specific interfaces, they may do 170 that job adequately for any particular interface but in complex 171 domains may create opportunities for confusion, duplication of 172 effort, lack of interoperability, and lack of extensibility. In the 173 past, ad-hoc development of DMs has caused significant operational 174 and implementation inefficiencies in our industry. 176 Since March 2014, upon IESG recommendation that SNMP no longer be 177 used for new work re configuration and that NETCONF/YANG be used 178 instead, there has been an explosion of YANG DM development in IETF. 179 It has consequently been recognized as essential to assure proper 180 coordination of YANG DM development (including reaching out to 181 different SDOs/consortia), as well as to assure that the YANG modules 182 themselves provide a good representation of what is being modeled, to 183 meet expectations of functionality, quality, and interoperability. 184 In order to facilitate this objective, guidance from available 185 pertinent IMs can be valuable. 187 This draft first describes an existing information model relevant to 188 Network Topology [ONF TR-512], which is part of the Common 189 Information Model (ONF-CIM) of network resources (as described in [I- 190 D.betts]), that can be leveraged to assess the consistency and 191 completeness of related YANG modules under development. It also 192 describes an transport application-specific IM [OSSDN SNOWMASS], 193 derived from CIM pruning and refactoring as explained in [I-D.betts], 194 that is intended to enable further clarity in understanding the 195 modeling. Being part of a Common Information Model, it will not lead 196 to development of incompatible/uncoordinated models that can be 197 difficult to maintain as other purpose-specific interfaces are 198 developed. 200 3. The Common Information Model 202 This section provides a high level introduction to the ONF Common 203 Information Model (ONF-CIM), and in particular its Core Model (see 204 [ONF TR-512]), to provide an overall context for the topology 205 relevant subset. The ONF-CIM has been developed through collaboration 206 among several SDOs, including ITU-T, TM Forum, and ONF, and also 207 published as ITU-T Recommendation G.7711 [G.7711]. 209 An information model describes the things in a domain in terms of 210 objects, their properties (represented as attributes), and their 211 relationships. 213 The ONF-CIM is expressed in a formal language called UML (Unified 214 Modeling Language). UML has a number of basic model elements, called 215 UML artifacts. In order to assure a consistent and harmonized 216 modeling approach, only a selected subset of these UML artifacts were 217 used in the development of the ONF-CIM according to guidelines for 218 creating an information model expressed in UML (see the UML 219 Guidelines document in the ONF TR-514 [ONF TR-514]). 221 The ONF-CIM has been developed using the Papyrus open source UML 222 Tool, for which a detailed guidelines document is available (see the 223 Papyrus Guidelines document in the ONF TR-515 [ONF TR-515]). This 224 guidelines document also describes how the modelers constructing the 225 ONF-CIM can cooperate in the GitHub environment to allow for separate 226 and still coordinated development of the ONF-CIM fragments. 228 The OMF-CIM includes all of the artifacts (objects, attributes, 229 associations, etc.) that are necessary to describe the domain for the 230 applications being developed. 232 It will be necessary to continually expand and refine the ONF-CIM 233 over time as, for example to add, new applications, capabilities or 234 forwarding technologies, or to refine the ONF-CIM as new insights are 235 gained. To allow these extensions to be made in a seamless manner, 236 the ONF-CIM is structured into a number of sub-models. This modeling 237 approach enables application specific and forwarding technology 238 specific extensions to be developed by domain experts with 239 appropriate independence. This approach is further articulated in 240 ONF TR-513 [ONF TR-513] and [I-D.betts]. 242 3.1. Core Model 244 The Core Model of the ONF-CIM consists of model artifacts that are 245 intended for use by multiple applications and/or forwarding 246 technologies. 248 For navigability, the Core Model is further sub-structured into sub- 249 models. Currently, these consist of the Core Network Model (CNM), 250 Core Foundation Model, Core Physical Model, and the Core 251 Specification Model. The following sub-sections provide an overview 252 of these sub-models. A detailed description is contained in ONF TR- 253 512 [ONF TR-512]. 255 3.1.1. Core Network Model 257 The Core Network Model (CNM) consists of artifacts that model the 258 essential network aspects that are neutral to the forwarding 259 technology of the network. The CNM currently encompasses Topology, 260 Termination, and Forwarding aspects (subsets of the CNM) as described 261 below: 263 - Topology Subset of CNM 265 The Topology subset of the CNM supports the modeling of network 266 topology information, which can be used to build the topology 267 database and depict the topology. Object classes representing 268 topological entities include: 270 o Forwarding Domain (FD): Offers the potential to enable 271 forwarding of information. 273 o Link (L): Models the adjacency between two or more FDs. A Link 274 has LinkPorts. 276 o Logical Termination Point (LTP): Models the ports of a link. It 277 encapsulates the termination, adaptation, and OAM functions of 278 one or more transport layers. 280 o Network Element (NE): While not actually part of topology, a NE 281 brings meaning to the FD and the LTP contexts (and hence the 282 links). A NE represents physical equipment "bundling" to 283 provide a view of management scope, management access, and 284 session. 286 The Topology subset of the CNM supports network topology 287 abstraction and virtualization. FD abstraction is supported via 288 recursive aggregation and virtualization via partitioning of 289 resources according to the resource dedication criterion. 291 - Forwarding Subset of CNM 293 The Forwarding subset of the CNM (not covered in detail in this 294 draft) supports configuration of forwarding entities, including 295 their setup, modification, and tear down. Artifacts representing 296 the forwarding construct include: 298 o ForwardingConstruct (FC): Also known as SNC. In conjunction 299 with the FcPort, FC models the enabled forwarding between two 300 FcPorts across a FD. 302 o FcPort: Models the access to the FC, and associates the FC to 303 the LTP. When the FC supports protection, the FcPort also 304 indicates its role in the protection scheme, i.e., whether it 305 is a working or protection FcPort. 307 o FcRoute: Also known as SncRoute. It models the individual 308 routes of an FC. 310 o FcSwitch: Also known as SncSwitch. It models the switched 311 forwarding of traffic (traffic flow) between EPs and is present 312 where there is protection functionality in the FD. 314 - Termination Subset of CNM 316 The Termination subset of the CNM (not covered in detail in this 317 draft) supports modeling of the processing of transport 318 characteristic information, such as termination, adaptation, OAM, 319 etc. Artifacts representing the termination and adaptation and OAM 320 construct include: 322 o Logical Termination Point (LTP): See the LTP description in the 323 Topology Subset 325 o Layer Protocol (LP): This identifies the type of signal and is 326 the anchor for transport layer protocol specific definitions, 327 which are modeled in, e.g., [G.874.1] for OTN, [G.8052] for 328 transport Ethernet, and [G.8152] for MPLS-TP. 330 - Resilience Subset of CNM 332 The Resilience subset provides a view of the model for resilience 333 (including protection and restoration) and encompasses: 335 o The basic resilience model structure 337 o The key attributes relevant to resilience 339 o The application of the resilience model to various cases 341 3.1.2. Core Foundation Model 343 To communicate about an entity, it is important to have some way of 344 referring to that entity, i.e., to have some way of referencing it. 345 The Core Foundation model defines the artifacts for referencing 346 entities; i.e.: 348 - Global Unique ID (GUID): 350 An identifier that is globally unique where an identifier is a 351 property of an entity/role with a value that is unique within an 352 identifier space, where the identifier space is itself unique, and 353 immutable. The identifier therefore represents the identity of the 354 entity/role. An identifier carries no semantics with respect to 355 the purpose of the entity.) 357 - Local ID: 359 An identifier that is unique in the context of some scope that is 360 less than the global scope (where an identifier is as defined in 361 GUID above). 363 - Name: 365 A property of an entity with a value that is unique in some 366 namespace but may change during the life of the entity. A name 367 carries no semantics with respect to the purpose of the entity. 369 - Label: 371 A property of an entity with a value that is not expected to be 372 unique and is allowed to change. A label carries no semantics with 373 respect to the purpose of the entity and has no effect on the 374 entity behavior or state. 376 The Core Foundation model also provides the opportunity to extend 377 any entity using the Extension structure. 379 The model also defines two foundation object classes: 381 - GlobalClass: 383 Super class of object classes for which their instances can exist 384 on their own right, e.g. NE, LTP, FD, Link, and FC. Global classes 385 shall have one and only one globally unique identifier (GUID) and 386 may have zero or more local identifiers, zero or more names, zero 387 or more labels, zero or more extensions. 389 - LocalClass: 391 Super class of object classes for which the existence of their 392 instances depends on instances of global classes; e.g., LP (of 393 LTP), EP (of FC), and LE (of Link). Local classes shall have at 394 least one local identifier, may have zero or more names, zero or 395 more labels, zero or more extensions. 397 -------------------------------------------------------------------- 398 I I 399 I I 400 I I 401 I I 402 I Artifacts for Referencing of Entities I 403 I I 404 I I 405 I I 406 I I 407 I (only in PDF version) I 408 I I 409 I I 410 I I 411 I I 412 I I 413 -------------------------------------------------------------------- 415 Figure 3-1 Artifacts for Referencing of Entities 417 The Core Foundation model also defines a State_Pac artifact, which is 418 a package of state attributes. The State_Pac is inherited by 419 GlobalClass and LocalClass object classes. The State_Pac consists of 420 the following state-related attributes: 422 - Operational State: 424 Read-only with values: DISABLED, ENABLED 426 - Administrative State: 428 Read-write with values: LOCKED, UNLOCKED 430 - Lifecycle State: 432 Read-write with values: PLANNED, POTENTIAL, INSTALLED, 433 PENDING_REMOVAL 435 -------------------------------------------------------------------- 436 I I 437 I I 438 I I 439 I States of Objects I 440 I I 441 I I 442 I (only in PDF version) I 443 I I 444 I I 445 I I 446 -------------------------------------------------------------------- 448 Figure 3-2 States of Objects 450 3.1.3. Core Physical Model 452 The Physical model provides a view of the model for physical entities 453 (including equipment, holders and connectors). This model also 454 specifies the relationship between the connector and the LTP, and the 455 relationship between physical and functional views. 457 -------------------------------------------------------------------- 458 I I 459 I I 460 I I 461 I I 462 I Basic Equipment Pattern I 463 I I 464 I I 465 I I 466 I I 467 I (only in PDF version) I 468 I I 469 I I 470 I I 471 I I 472 I I 473 -------------------------------------------------------------------- 475 Figure 3-3 Basic Equipment Pattern 477 3.1.4. Core Specification Model 479 There are several related needs that have given rise to the 480 Specification model: 482 - Provide machine readable form of specific localized behavior: 484 o Representing rules related to restrictions of specific cases of 485 use of the model 487 o Representing capabilities of specific cases of use 489 - Enable the introduction of run time schema where the essential 490 structure of the model is known up front (at compile time) but 491 the details are not 493 - Reduce the clutter in a representation where a set of details take 494 the same values for all instances that are related to a specific 495 case 497 - Allow leverage of existing standards definitions (e.g., 498 technology/application specific) in a machine readable language 500 The combination of the above resulted in a separation in the model of 501 definitions of structure and content such that an instance of a class 502 from one model fragment could have an association instance to another 503 model fragment to enable the provision of a fragment of definition of 504 the class and of subordinates. 506 The aim of all specification definitions is that they be rigorous 507 definitions of specific cases of usage and enable machine 508 interpretation where traditional interface designs would only allow 509 human interpretation. 511 The following dedicated spec structures have been considered: 513 - FC spec: Main focus to provide a representation of the effective 514 internal structure of a ForwardingConstruct (FC) 516 - LTP and LP spec: Main focus to provide a representation of Layer 517 Protocol (LP) specific parameters for the Logical Termination 518 Point (LTP) 520 - FD and Link spec: Main focus on capacity and forwarding enablement 521 restrictions 523 - Equipment spec: Main focus to provide a representation of 524 equipping constraints 526 -------------------------------------------------------------------- 527 I I 528 I I 529 I I 530 I I 531 I Class Diagram of the Spec Model of LTP and LP I 532 I I 533 I I 534 I I 535 I I 536 I (only in PDF version) I 537 I I 538 I I 539 I I 540 I I 541 I I 542 -------------------------------------------------------------------- 543 Figure 3-4 Class Diagram of the Spec Model of LTP and LP 545 3.2. Other Models 547 In addition to the Core Model, the ONF-CIM includes forwarding 548 technology and application specific models. The forwarding technology 549 models of the ONF-CIM (see [ONF TR-512]) encompasses transport 550 technology layers 0, 1, and 2. 552 4. High Level Description of the Topology Subset of the CNM 554 This section provides a high-level overview of the Topology Subset of 555 the CNM. Figure 4-1 below is a skeleton class diagram illustrating 556 the key object classes. To avoid cluttering the figure, not all 557 associations have been shown and all of the attributes were omitted. 559 -------------------------------------------------------------------- 560 I I 561 I I 562 I I 563 I I 564 I Overview of the CNM Topology Subset I 565 I I 566 I I 567 I I 568 I I 569 I (only in PDF version) I 570 I I 571 I I 572 I I 573 I I 574 I I 575 -------------------------------------------------------------------- 577 Figure 4-1 Overview of the CNM Topology Subset 579 4.1. Object Classes of the CNM Topology Subset 581 This section describes the object classes of the Topology Subset of 582 the CNM. Relationships between these classes are described in section 583 4.2 below 585 4.1.1. LogicalTerminationPoint (LTP) and LayerProtocol (LP) 587 The LogicalTerminationPoint (LTP) object class encapsulates the 588 termination, adaptation and OAM functions of one or more transport 589 protocol layers. The structure of the LTP supports all transport 590 protocols including circuit and packet forms. Each transport layer is 591 represented by a LayerProtocol (LP) instance. The LayerProtocol 592 instances of the LTP can be used for controlling the termination and 593 OAM functionality of that layer. It can also be used for controlling 594 the adaptation (i.e. encapsulation and/or multiplexing of client 595 signal). Where the client/server relationship is fixed 1:1 and 596 immutable, the different layers can be encapsulated in a single LTP 597 instance. Where there is a n:1 relationship between client and 598 server, the layers must be split over separate instances of LTP. 600 The LP object class is defined with generic attributes 601 "layerProtocolName" for indicating the supported transport layer 602 protocol. 604 Transport layer specific properties (such as layer-specific 605 termination and adaptation properties) are modeled as attributes of 606 conditional packages (called "_Pacs" in the UML notation of the 607 ONF-CIM) associated with the LP object class. 609 4.1.2. ForwardingDomain (FD) 611 The ForwardingDomain (FD) object class models the switching and 612 routing capabilities (see "subnetwork" topological component in 613 [G.852.2] and [TMF612]), which is used to effect forwarding of 614 transport characteristic information and offers the potential to 615 enable forwarding. It represents the resource that supports flows 616 across the FD. The FD object can hold zero or more instances of 617 ForwardingConstruct (FC) (representing constrained forwarding, not 618 discussed further in this document, covering connections, VLANs etc) 619 of one or more layer networks; e.g., OCh, ODU, ETH, and MPLS-TP. The 620 FD object provides the context for operations that 621 create/modify/delete FCs. 623 The FD object class supports a recursive aggregation relationship 624 such that the internal construction of an FD can be exposed as 625 multiple lower level FDs and associated Links (partitioning) (see 626 section 4.2.1.) 628 At the lowest level of recursion, a FD (within a network element) 629 could represent a switch matrix (i.e., a fabric). 631 Note that an NE can encompass multiple switch matrices (FDs), as 632 described in section 4.2.2. An instance of FD is associated with zero 633 or more LTP objects, as described in section 4.2.3. 635 4.1.3. Link and Link Port 637 The Link object class models the adjacency between two or more 638 ForwardingDomains (FDs). 640 In its basic form (i.e., point-to-point Link) it associates a set of 641 LTP clients on one FD with an equivalent set of LTP clients on 642 another FD. Like the FC, the Link has endpoints (LinkPort) which take 643 roles in the context of the function of the Link. A point-to-point 644 Link can be a TE Link and support parameters such as capacity, delay 645 etc. These parameters depend on the type of technology that supports 646 the link. 648 A Link can be terminated on two or more FDs. This provides support 649 for technologies such as PON and Layer 2 MAC in MAC configurations. 651 The LinkPort further details the relationship between FD and Link for 652 asymmetric cases. 654 A FD may aggregate Links (see section 4.2.5). 656 The Link can support multiple transport layers via the associated LTP 657 object. An instance of Link can be formed with the necessary 658 properties according to the degree of virtualization. For 659 implementation optimization, multiple layer-specific links can be 660 merged and represented as a single Link instance. 662 4.1.4. Network Element (NE) 664 The NetworkElement (NE) object class represents a network element 665 (traditional NE) in the data plane or a virtual network element 666 visible in an interface where virtualization is used. 668 In the direct interface from a SDN controller to a network element in 669 the data plane, the NE object defines the scope of control for the 670 resources within the network element, e.g., internal transfer of user 671 information between the external terminations (ports), encapsulation, 672 multiplexing/demultiplexing, and OAM functions, etc. The NE provides 673 the scope of the naming space for identifying objects representing 674 the resources within the network element. 676 Where virtualization is employed, the NE object represents a virtual 677 NE (VNE). The mapping of the VNE to the NEs is the internal matter of 678 the SDN controller that offers the view of the VNE. Via the interface 679 between hierarchical SDN controllers, NE instances can be created (or 680 deleted) for providing (or removing) virtual views of the combination 681 of slices of network elements in the data plane. 683 4.2. Relationships between Object Classes of the Topology Subset 685 4.2.1. ForwardingDomain Recursive Aggregation 686 (HigherLevelFdEncompassesLowerLevelFds Aggregation) 688 Figure 4-2 below provides a pictorial example of ForwardingDomain 689 (FD) recursion with Links. 691 -------------------------------------------------------------------- 692 I I 693 I I 694 I I 695 I I 696 I ForwardingDomain recursion with Links I 697 I I 698 I I 699 I I 700 I I 701 I (only in PDF version) I 702 I I 703 I I 704 I I 705 I I 706 I I 707 -------------------------------------------------------------------- 709 Figure 4-2 ForwardingDomain recursion with Links 711 Figure 4-2 shows a UML fragment including the Link and 712 ForwardingDomain (FD). For simplicity it is assumed here that the 713 Links and FDs are for a single LayerProtocol (LP) although it can be 714 seen from the detailed figure earlier in this section that both a FD 715 and link can support a list of LPs. 717 The pictorial form shows a number of instances of FD interconnected 718 by Links and shows nesting of FDs. The recursive aggregation 719 "HigherLevelFdEncompassesLowerLevelFds" relationship (represented by 720 an open diamond) supports the FD nesting but it should be noted that 721 this is intentionally showing no lifecycle dependency between the 722 lower FDs and the higher ones that nest them (to do this composition, 723 a black diamond would have been used instead of the open diamond). 724 This is to allow for rearrangements of the FD hierarchy (e.g. when 725 regions of a network are split or merged). This emphasizes that the 726 nesting is an abstraction rather than decomposition. The underlying 727 network still operates regardless of how it is perceived in terms of 728 aggregating FDs. The model allows for only one hierarchy. 730 4.2.2. Network Elements encompassing ForwardingDomains (NeEncompassesFds 731 Aggregation) 733 Figure 4-3 below provides a pictorial example of ForwardingDomain 734 (FD) recursion with Links and NEs. 736 -------------------------------------------------------------------- 737 I I 738 I I 739 I I 740 I I 741 I ForwardingDomain recursion with Links and NEs I 742 I I 743 I I 744 I I 745 I I 746 I (only in PDF version) I 747 I I 748 I I 749 I I 750 I I 751 I I 752 -------------------------------------------------------------------- 754 Figure 4-3 ForwardingDomain recursion with Links and NEs 756 Figure 4-3 above shows an overlay of NetworkElement (NE) on the 757 ForwardingDomains and a corresponding fragment of UML showing only 758 the ForwardingDomain and NetworkElement classes. 760 The figure emphasizes that one level of abstraction of 761 ForwardingDomain is bounded by an NE. This is represented in the UML 762 fragment by the composition association (black diamond) that explains 763 that there is a lifecycle dependency in that the ForwardingDomain at 764 this level that cannot exist without the NE. The figure also shows 765 that a ForwardingDomain need not be bounded by an NE (as explained in 766 the UML fragment by the 0..1 composition) and that a ForwardingDomain 767 may have smaller scope than the whole NE (even when considering only 768 a single LayerProtocol as described below). 770 In one of the cases depicted (e.g., the right hand side NE 771 encompassing two FDs), the two ForwardingDomains in the NE are 772 completely independent. In the other cases depicted (e.g., the left 773 hand side NE encompassing three FDs) the subordinate 774 ForwardingDomains are themselves joined by Links emphasizing that the 775 NE does not necessarily represent the lowest level of relevant 776 network decomposition. 778 The figure also emphasizes that just because one ForwardingDomain at 779 a particular level of decomposition of the network happens to be the 780 one bounded by an NE does not mean that all ForwardingDomains at that 781 level are also bounded by NEs. 783 4.2.3. ForwardingDomain association with LTPs (FdAggregatesLtps 784 Composition) 786 An instance of FD is associated with zero or more LTP objects via the 787 "FdAggregatesLtps" composition. 789 4.2.4. ForwardingDomain aggregating Links (FdEncompassesLinks) 791 A ForwardingDomain can aggregate links. An example of 792 ForwardingDomain Recursive Aggregation with Links is shows in section 793 4.2.1 above. 795 However, the FdAggregatesLink association is not modeled because this 796 association can be inferred from the 797 higherLevelFdContainsLowerLevelFd association together with the 798 linkHasAssociatedFds association. 800 4.2.5. ForwardingDomain aggregating NEs 802 A ForwardingDomain can aggregate Network Elements. An example of 803 ForwardingDomain Recursive Aggregation with Links and NEs is shown in 804 section 4.2.2 above. 806 However, the FdAggregatesNe association is not modeled because this 807 association can be inferred from higherLevelFdContainsLowerLevelFd 808 association and together with the NeEncompassesFd association. 810 5. Detailed Description of the Topology Subset 812 The two key classes related to Topology are the ForwardingDomain (FD) 813 and the Link. For simple cases the FD represents the switching 814 capability in the network and the Link represents adjacency. These 815 are depicted in the context of other model classes in Figure 5-1. 817 -------------------------------------------------------------------- 818 I I 819 I I 820 I I 821 I I 822 I Object Classes and Relationships in the Topology Subset I 823 I I 824 I I 825 I I 826 I I 827 I (only in PDF version) I 828 I I 829 I I 830 I I 831 I I 832 I I 833 -------------------------------------------------------------------- 835 Figure 5-1 Object Classes and Relationships in the Topology Subset 837 Figure 5-1 shows a lightweight view of the model omitting the 838 attributes (where appropriate these will be described later in this 839 section). 841 The FD and Link will be described in detail later in the document. 842 Figure 5-1 focuses on interrelationships and these will be the focus 843 of this section. The figure shows that: 845 - An FD may be a subordinate part of a NetworkElement (NE) or may 846 be larger than, and independent of, any NE. 848 - An FD may encompass lower level FDs. This may be such that: 850 o A FD directly contained in an NE is divided into smaller 851 parts 853 o A FD not encompassed by an NE is divided into smaller 854 parts some of which may be encompassed by NEs 856 o The FD represents the whole network 858 - An FD encompasses Links that interconnect any FDs encompassed 859 by the FD 861 - A Link may aggregate Links in several ways 863 o In parallel where several links are considered as one 865 o In series where Links chain to form a Link of a greater 866 span 868 . Note that this case requires further development in 869 the model 871 - A Link has associated FDs that it interconnects 873 o A Link may interconnect 2 or more FDs 875 . Note that it is usual for a Link to interconnect 2 FDs 876 but there are cases where many FDs may be 877 interconnected by a Link 879 - A Link has LinkPorts that represent the ports of the Link 880 itself 882 o LinkPorts are especially relevant for multi-ended 883 asymmetric Link 885 - A LinkPort aggregates LogicalTerminationPoints (LTPs) that 886 bound the Link. The LTP represent a stack LayerProtocol 887 terminations where the details of each is held in the 888 LayerProtocol (LP). The LTP may be: 890 o Part of an NE 892 o Conceptually independent from any NE 894 - A LinkPort references LTPs on which the Link associated to the 895 LE terminates 897 Both the Link and FD are subclasses of ForwardingEntity (an abstract 898 class, i.e. a class that will never be instantiated) and hence they 899 can acquire contents from the conditional packages (_Pacs). The 900 conditional packages provide all key topology properties. 902 5.1. Forwarding Entity 904 As noted in the previous section the two key topology classes are 905 Forwarding Domain (FD) and Link (L). 907 The FD topological component is used to show the potential to enable 908 forwarding. At the lowest level of recursion, an FD (within a network 909 element (NE)) represents a switch matrix (e.g., a fabric). Note that 910 an NE can encompass multiple switch matrices (FDs). 912 As noted earlier the Link models adjacency between two or more 913 Forwarding Domains (FD). 915 Both the link and the FD have the potential to handle more than one 916 layerProtocol (both have a layerProtocolNameList attribute). 918 As shown in Figure 5-1 an object class "ForwardingEntity" has been 919 defined to collect topology-related properties (characteristics etc.) 920 that are common for FD and Link. 922 A ForwardingEntity is an abstract representation of the emergent 923 effect of the combined functioning of an arrangement of components 924 (running hardware, software running on hardware, etc). The effect can 925 be considered as the realization of the potential for apparent 926 communication adjacency for entities that are bound to the 927 terminations at the boundary of the ForwardingEntity. 929 The ForwardingEntity enables the creation of constrained forwarding 930 to achieve the apparent adjacency. The apparent adjacency has 931 intended performance degraded from perfect adjacency and a statement 932 of that degradation is conveyed via the attributes of the packages 933 associated with this class. In the model both ForwardingDomain and 934 Link are ForwardingEntities. 936 This abstract class is used as a modeling approach to apply packages 937 of attributes to both Link and ForwardingDomain. Link and 938 ForwardingDomain are the key ForwardingEntities. 940 5.2. Characteristics of Topological Entity 942 As noted above the characteristic of a TopologicalEnity are covered 943 by the conditional packages (_PACs). 945 -------------------------------------------------------------------- 946 I I 947 I I 948 I I 949 I I 950 I Conditional Packages of Topological Entity I 951 I I 952 I I 953 I I 954 I I 955 I (only in PDF version) I 956 I I 957 I I 958 I I 959 I I 960 I I 961 -------------------------------------------------------------------- 963 Figure 5-2 Conditional Packages of Topological Entity 965 5.2.1. Risk (RiskParameter_Pac) 967 The risk characteristics of a ForwardingEntity come directly from the 968 underlying physical realization. 970 The risk characteristics propagate from the physical realization to 971 the client and from the server layer to the client layer, this 972 propagation may be modified by protection. 974 A ForwardingEntity may suffer degradation or failure as a result of a 975 problem in a part of the underlying realization. 977 The realization can be partitioned into segments which have some 978 relevant common failure modes. 980 There is a risk of failure/degradation of each segment of the 981 underlying realization. 983 Each segment is a part of a larger physical/geographical unit that 984 behaves as one with respect to failure (i.e. a failure will have a 985 high probability of impacting the whole unit (e.g. all fibers in the 986 same cable). 988 Disruptions to that larger physical/geographical unit will impact 989 (cause failure/errors to) all ForwardingEntities that use any part of 990 that larger physical/geographical entity. 992 Any ForwardingEntity that uses any part of that larger 993 physical/geographical unit will suffer impact and hence each 994 ForwardingEntity shares risk. 996 The identifier of each physical/geographical unit that is involved in 997 the realization of each segment of a Topological entity can be listed 998 in the RiskParameter_Pac of that ForwardingEntity. 1000 A segment has one or more risk characteristic. 1002 Shared risk between two ForwardingEntities compromises the integrity 1003 of any solution that use one of those ForwardingEntity as a backup 1004 for the other. 1006 Where two ForwardingEntities have a common risk characteristic they 1007 have an elevated probability of failing simultaneously compared to 1008 two ForwardingEntities that do not share risk characteristics. 1010 - riskCharacteristicList: A list of risk characteristics 1011 (RiskCharacteristic) for consideration in an analysis of shared 1012 risk. Each element of the list represents a specific risk 1013 consideration. 1015 - RiskCharacteristic: The information for a particular risk 1016 characteristic where there is a list of risk identifiers 1017 related to that characteristic. It includes: 1019 o riskCharacteristicName: The name of the risk 1020 characteristic. The characteristic may be related to a 1021 specific degree of closeness. For example a particular 1022 characteristic may apply to failures that are localized 1023 (e.g. to one side of a road) where as another 1024 characteristic may relate to failures that have a broader 1025 impact (e.g. both sides of a road that crosses a bridge). 1026 Depending upon the importance of the traffic being routed 1027 different risk characteristics will be evaluated. 1029 o riskIdentifierList: A list of the identifiers of each 1030 physical/geographic unit (with the specific risk 1031 characteristic) that is related to a segment of the 1032 ForwardingEntity. 1034 5.2.2. TransferCost_Pac 1036 The cost characteristics of a ForwardingEntity not necessarily 1037 correlated to the cost of the underlying physical realization. 1039 They may be quite specific to the individual ForwardingEntity e.g. 1040 opportunity cost. Relates to layer capacity 1041 There may be many perspectives from which cost may be considered for 1042 a particular ForwardingEntity and hence many specifc costs and 1043 potentially cost algorithms. 1045 Using an entity will incur a cost. 1047 - costCharcteristicList: The list of costs (CostCharacteristic) 1048 where each cost relates to some aspect of the Link 1050 o CostCharcteristic: The information for a particular cost 1051 characteristic 1053 . costName: The cost characteristic will related to some 1054 aspect of the ForwardingEntity (e.g. $ cost, routing 1055 weight). This aspect will be conveyed by the costName 1057 . costValue: The specific cost. 1059 . costAlgorithm: The cost may vary based upon some 1060 properties of the ForwardingEntity. The rules for the 1061 variation are conveyed by the costAlgorithm. 1063 5.2.3. TransferTiming_Pac 1065 A link will suffer effects from the underlying physical realization 1066 related to the timing of the information passed by the link. 1068 - fixedLatencyCharacteristic: A ForwardingEntity suffers delay 1069 caused by the realization of the servers (e.g. distance 1070 related; FEC encoding etc.) along with some client specific 1071 processing. This is the total average latency effect of the 1072 ForwardingEntity 1074 - jitterCharacteristic: High frequency deviation from true 1075 periodicity of a signal and therefore a small high rate of 1076 change of transfer latency. Applies to TDM systems (i.e., not 1077 packet based systems). 1079 - wanderCharacteristics: Low frequency deviation from true 1080 periodicity of a signal and therefore a small low rate of 1081 change of transfer latency. Applies to TDM systems (i.e., not 1082 packet based systems). 1084 - queuingLatencyList: The effect on the latency of a queuing 1085 process. This only has significant effect for packet based 1086 systems and has a complex characteristic (QueuingLatency). 1088 o QueuingLatency: Provides information on latency 1089 characteristic for a particular stated trafficProperty. 1091 5.2.4. TransferIntegrity_Pac 1093 Transfer integrity characteristic covers expected (specified) error, 1094 loss and duplication signal content as well as any damage of any form 1095 to total link and to the client signals. 1097 - errorCharacteristic: describes the degree to which the signal 1098 propagated can be errored. Applies to TDM systems as the 1099 errored signal will be propagated and not packet as errored 1100 packets will be discarded. 1102 - lossCharacteristic: Describes the acceptable characteristic of 1103 lost packets where loss may result from discard due to errors 1104 or overflow. Applies to packet systems and not TDM (as for TDM 1105 errored signals are propagated unless grossly errored and 1106 overflow/underflow turns into timing slips). 1108 - repeatDeliveryCharacteristic: Primarily applies to packet 1109 systems where a packet may be delivered more than once (in 1110 fault recovery for example). It can also apply to TDM where 1111 several frames may be received twice due to switching in a 1112 system with a large differential propagation delay. 1114 - deliveryOrderCharacteristic: Describes the degree to which 1115 packets will be delivered out of sequence. Does not apply to 1116 TDM as the TDM protocols maintain strict order. 1118 - unavailableTimeCharacteristic: Describes the duration for which 1119 there may be no valid signal propagated. 1121 - serverIntegrityProcessCharacteristic: Describes the effect of 1122 any server integrity enhancement process on the characteristics 1123 of the ForwardingEntity. 1125 5.2.5. TransferCapcity_Pac 1127 The ForwardingEntity derives capacity from the underlying 1128 realization. 1130 A ForwardingEntity may be an abstraction and virtualization of a 1131 subset of the underlying capability offered in a view or may be 1132 directly reflecting the underlying realization. 1134 A ForwardingEntity may be directly used in the view or may be 1135 assigned to another view for use. 1137 The clients supported by a multi-layer ForwardingEntity may interact 1138 such that the resources used by one client may impact those available 1139 to another. This is derived from the LTP spec details. 1141 A ForwardingEntity represents the capacity available to user (client) 1142 along with client interaction and usage. 1144 A ForwardingEntity may reflect one or more client protocols and one 1145 or more members for each profile. 1147 - totalPotentialCapacity: A "best case" view of the capacity of 1148 the ForwardingEntity assuming that any shared capacity is 1149 available to be taken. 1151 Note that this area is still under development to cover concepts such 1152 as: 1154 - exclusiveCapacityList: The capacity allocated to this 1155 ForwardingEntity for its exclusive use 1157 - sharedCapacityList: The capacity allocated to this 1158 ForwardingEntity that is not exclusively available as it is 1159 shared with others. 1161 - assignedAsExclusiveCapacityList: The capacity assigned from 1162 this TopologicalEnity to another ForwardingEntity for its 1163 exclusive use 1165 - assignedAsSharedCapacityList: The capacity assigned to one or 1166 more other ForwardingEntities for shared use where the 1167 interaction follows some stated algorithm. 1169 - Capacity which includes: 1171 o totalSize 1173 o numberOfUsageInstances 1175 o maximumUsageSize 1177 o numberingRange 1179 5.2.6. Validation_Pac 1181 Validation covers the various adjacenct discovery and reachability 1182 verification protocols. Also may cover Information source and degree 1183 of integrity. 1185 - validationMechanismList: Provides details of the specific 1186 validation mechanism(s) used to confirm the presence of an 1187 intended ForwardingEntity. 1189 5.2.7. LayerProtocolTransition_Pac 1191 Relevant for a Link that is formed by abstracting one or more LTPs 1192 (in a stack) to focus on the flow and deemphasize the protocol 1193 transformation. 1195 This abstraction is relevant when considering multi-layer routing. 1197 The layer protocols of the LTP and the order of their application to 1198 the signal is still relevant and need to be accounted for. This is 1199 derived from the LTP spec details. 1201 This Pac provides the relevant abstractions of the LTPs and provides 1202 the necessary association to the LTPs involved. 1204 Links that included details in this Pac are often referred to as 1205 Transitional Links. 1207 - transitionedLayerProtocolList: Provides the ordered structure 1208 of layer protocol transitions encapsulated in the 1209 ForwardingEntity. The ordering relates to the LinkEnd role. 1211 6. Purpose Specific IM Example - Transport API Topology Service 1213 In order to provide some further clarity, this section provides a 1214 high level introduction to a Purpose Specific IM, the Transport API 1215 (T-API) Topology service, which has been derived from the ONF Common 1216 Information Model (ONF-CIM) according to the principles in [I- 1217 D.betts]. 1219 The context of the T-API refers to the scope and control and naming 1220 that a particular SDN controller, manager or a client application has 1221 with respect to the information it operates on internally or 1222 exchanges over an interface. The following sections further describe 1223 this purpose specific IM and relationship to the ONF-CIM. 1225 6.1. T-API IM Constructs 1227 The T-API IM uses terminology that is considered to be more familiar 1228 to the transport network management community and maps to the 1229 constructs defined in the ONF-CIM CNM Topology model. The following 1230 table provides a high level summary of the mapping of the constructs 1231 relevant to the T-API Topology Service. 1233 Mapping of CIM and T-API IM Constructs 1234 ONF-CIM CNM Terminology T-API IM Terminology 1235 NetworkControlDomain Context 1236 Topology ForwardingDomain (FD) Node 1237 Link Link TransitionalLink 1238 NodeEdgePoint LogicalTerminationPoint (LTP) ServideEndPoint 1240 The following provides a brief description of these T-API IM 1241 constructs. 1243 o Link: A Link is an abstract representation of the effective 1244 adjacency between two or more associated Nodes in a Topology. 1245 It is terminated by Node-Edge-Points of the associated Nodes. 1247 o Node: A Node is an abstract representation of the forwarding- 1248 capabilities of a particular set of Network Resources. It is 1249 described in terms of an aggregation of set of ports (Node- 1250 Edge-Point) belonging to those Network Resources and the 1251 potential to enable forwarding of information between those 1252 edge ports. 1254 o Node-Edge-Point: A Node-Edge-Point represents the inward 1255 network-facing aspects of the edge-port functions that access 1256 the forwarding capabilities provided by the Node. Hence it 1257 provides an encapsulation of addressing, mapping, termination, 1258 adaptation and OAM functions of one or more transport layers 1259 (including circuit and packet forms) performed at the entry and 1260 exit points of the Node. 1262 o Topology: A Topology is an abstract representation of the 1263 topological-aspects of a particular set of Network Resources. 1264 It is described in terms of a network of set of Nodes and Links 1265 that enable the forwarding-capabilities of that particular set 1266 of Network Resources. 1268 o Service-End-Point: A Service-End-Point represents the outward 1269 customer-facing aspects of the edge-port functions that access 1270 the forwarding capabilities provided by the Node. Hence it 1271 provides a limited, simplified view of interest to external 1272 clients (e.g. shared addressing, capacity, resource 1273 availability, etc) that enable the clients to request 1274 connectivity without the need to understand the provider 1275 network internals. 1277 o Transitional Link: A topological component that consists of the 1278 link port at the edge of one node and a corresponding link port 1279 at the edge of another node that operates on different layers 1280 or whose layer is the same but with different Layer 1281 Information. A transitional link is supported/implemented by 1282 transport processing functions (e.g., adaptation/termination). 1283 A transitional link can be partitioned into parallel 1284 transitional links, or a concatenation of transitional links. 1285 It can also be partitioned into a concatenation of transitional 1286 links and zero or more links. 1288 6.2. T-API Topology Service IM 1290 The resultant high-level description for the T-API Topology Service 1291 constructs, based upon the pruned and refactored ONF-CIM, and the 1292 related Topology Service APIs are provided in Figure 6-1 below. 1294 -------------------------------------------------------------------- 1295 I I 1296 I I 1297 I I 1298 I I 1299 I Topology Service Skeleton I 1300 I I 1301 I I 1302 I I 1303 I I 1304 I (only in PDF version) I 1305 I I 1306 I I 1307 I I 1308 I I 1309 I I 1310 -------------------------------------------------------------------- 1311 Figure 6-1 Topology Service Skeleton 1313 The T-API Topology Service API enables the API client to, for 1314 example, retrieve Topology, Node, Link, and Edge-Point details. 1316 o Topology details: returns attributes of the Topology identified 1317 by the provided input ID. This includes references to lower- 1318 level Nodes and Links encompassed by that Topology. A NULL 1319 input value is expected to return the top-most Topology that 1320 corresponds to the scope of the entire Context including any 1321 Off-Network-Links. 1323 o Node details: Returns attributes of the Node identified by the 1324 provided input ID. Includes references to Node-Edge-Points 1325 aggregated by the Node, and attributes representing the 1326 identification, naming, states and forwarding capabilities of 1327 the Node. 1329 o Link details: Returns attributes of the Link identified by the 1330 provided input ID. Includes references to Node-Edge-Points 1331 terminating the Link, and references to the Nodes associated by 1332 the Link. 1334 o Node-Edge-Point details: Returns attributes of the Node-Edge- 1335 Point identified by the provided input ID, including references 1336 to Service-End-Points mapped to this Node-Edge-Point. 1338 The API supports a retrieve-scope filter: LayerProtocol list. If 1339 set, the API call will return output that is relevant to the 1340 specified Layer only. 1342 7. Usage of the IM Topology Subset regarding TE Topology DM 1344 As discussed earlier, a data model (DM) may be derived from an IM. 1345 Examples of YANG DMs derived according to automated translation tools 1346 based upon mapping guidelines are provided in [OSSDN SNOMASS] at 1347 https://github.com/OpenNetworkingFoundation/Snowmass- 1348 ONFOpenTransport/tree/develop/YANG. It is possible to leverage the IM 1349 Topology Subset to assess the consistency and completeness of related 1350 YANG modules under development. 1352 8. Security Considerations 1354 This informational document is intended only to provide a description 1355 of an interface-protocol-neutral information model, and the security 1356 concerns are therefore out of the scope of this document. 1358 9. IANA Considerations 1360 This document includes no request to IANA. 1362 10. Conclusions 1364 The information modeling described in this draft, which is relevant 1365 to Network Topology [ONF TR-512] [OSSDN SNOWMASS], can be leveraged 1366 in assessing the consistency and completeness of related YANG modules 1367 under development. 1369 11. References 1371 11.1. Normative References 1373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1374 Requirement Levels", BCP 14, RFC 2119, March 1997. 1376 11.2. Informative References 1378 [I-D.betts] Betts, M., Davis, N., Lam, K., Zeuner, B., Mansfield, S. 1379 and P. Doolan, "Framework for Deriving Interface Data Schema 1380 from UML Information Models", draft-betts-netmod-framework- 1381 data-schema-uml-04 (work in progress), October 2016 1383 [I-D.mansfield] Mansfield, S., Zeuner, B., Davis, N., Yun, X., 1384 Tochio, Y., Lam, K. and E. Varma, "Guidelines for Translation 1385 of UML Information Model to YANG Data Model", draft-mansfield- 1386 netmod-uml-to-yang-03 (work in progress), October 2016 1388 [ONF TR-512] ONF TR-512 "ONF-CIM Core Model base document 1.2" 1389 (https://www.opennetworking.org/images/stories/downloads/sdn- 1390 resources/technical-reports/TR-512_CIM_(CoreModel)_1.2.zip), 1391 September 2016 1393 [ONF TR-513] ONF TR-513 " Common Information Model Overview 1.2" 1394 (https://www.opennetworking.org/images/stories/downloads/sdn- 1395 resources/technical-reports/TR-513_CIM_Overview_1.2.pdf), 1396 September 2016 1398 [ONF TR-514] ONF TR-514 "UML Modeling Guidelines 1.2" 1399 (https://www.opennetworking.org/images/stories/downloads/sdn- 1400 resources/technical-reports/TR- 1401 514_UML_Modeling_Guidelines_v1.2.pdf), September 2016 1403 [ONF TR-515] ONF TR-515 "Papyrus Guidelines 1.2" 1404 (https://www.opennetworking.org/images/stories/downloads/sdn- 1405 resources/technical-reports/TR- 1406 515_Papyrus_Guidelines_v1.2.pdf), September 2016 1408 [OSSDN SNOWMASS] Open Source SDN SNOWMASS/Open Transport API 1409 Specifications 1410 (https://github.com/OpenNetworkingFoundation/Snowmass- 1411 ONFOpenTransport) 1413 [G.7711] Recommendation ITU-T G.7711/Y.17022 "Generic protocol- 1414 neutral information model for transport resources", 1415 September 2016 1417 [G.874.1] Recommendation ITU-T G.874.1 "Optical transport network: 1418 Protocol-neutral management information model for the 1419 network element view", September 2016 1421 [G.8052] Recommendation ITU-T G.8052/Y.1346 "Protocol-neutral 1422 management information model for the Ethernet Transport 1423 capable network element", September 2016 1425 [G.8152] Recommendation ITU-T G.8152/Y.1375 "Protocol-neutral 1426 management information model for the MPLS-TP network 1427 element", September 2016 1429 [G.852.2] Recommendation ITU-T G.852.2 "Enterprise viewpoint 1430 description of transport network resource model", March 1999 1432 [TMF612] TM Forum 612 "MTOSI Information Agreement", October 2014 1434 12. Contributors 1436 Karthik Sethuraman 1437 NEC 1439 Email: karthik.sethuraman@necam.com 1441 13. Acknowledgments 1443 This document was prepared using 2-Word-v2.0.template.dot. 1445 Authors' Addresses 1447 Kam Lam 1448 Alcatel-Lucent, USA 1450 Phone: +1 732 331 3476 1451 Email: kam.lam@alcatel-lucent.com 1453 Eve Varma 1454 Alcatel-Lucent, USA 1456 Email: eve.varma@alcatel-lucent.com 1458 Paul Doolan 1459 Coriant, Germany 1461 Phone: +1 972 357 5822 1462 Email: paul.doolan@coriant.com 1464 Malcolm Betts 1465 ZTE, China 1467 Phone: +1 678 534 2542 1468 Email: malcolm.betts@zte.com.cn 1470 Nigel Davis 1471 Ciena, UK 1473 Email: ndavis@ciena.com 1475 Bernd Zeuner 1476 Deutsche Telekom, Germany 1478 Phone: +49 6151 58 12086 1479 Email: b.zeuner@telekom.de 1480 Italo Busi 1481 Huawei, China 1483 Email: Italo.Busi@huawei.com 1485 Scott Mansfield 1486 Ericsson, Sweden 1488 Phone: 1 724 931 9316 1489 Email: scott.mansfield@ericsson.com 1491 Yuji Tochio 1492 Fujitsu, Japan 1494 Phone: 81 44 754 8829 1495 Email: tochio@jp.fujitsu.com 1497 Ricard Vilalta 1498 CTTC, Spain 1500 Phone: 1501 Email: ricard.vilalta@cttc.es 1503 Victor Lopez 1504 Telefonica, Spain 1506 Phone: 1507 Email: victor.lopezalvarez@telefonica.com