Internet DRAFT - draft-contreras-supa-yang-network-topo

draft-contreras-supa-yang-network-topo



Network Working Group                                     L.Contreras  
Internet Draft                                          Telefonica I+D  
Intended status: Standard Track                                 J. Bi  
Expires: August 2015                               Tsinghua University 
                                                              Andrew Qu 
                                                               Mediatek 
                                                           Yiyong Zha 
                                                     Huawei Technologies 
                                                      February 6, 2015 
                                   
 
                                      
                  A YANG Data Model for Network Topologies 
                 draft-contreras-supa-yang-network-topo-03 


Status of this Memo 

   This Internet-Draft is submitted to IETF in full conformance with the 
   provisions of BCP 78 and BCP 79.  

   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 August 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 
 
 
 
Contreras, et al.      Expires August 6, 2015                 [Page 1] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

   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 

   This document defines a YANG data model for network topologies.    

Table of Contents 

   1.   Introduction .......................................'...... 2 
   2.   Conventions used in this document ......................... 3 
   3.   Terminology ...............................'............... 4 
   4.   Network topology model overview ........................... 4 
      4.1. Topology information model ............................. 4 
      4.2. Topology data model .................................... 6 
      4.3. Topology data model structure .......................... 7 
      4.4. Main building blocks ................................... 9 
      4.4.1.  Virtual topology ................................... 10 
   5.   SUPA topology YANG model ................................. 11 
   6.   Security Considerations .................................. 25 
   7.   IANA Considerations ...................................... 25 
   8.   Acknowledgments '......................................... 25 
   9.   References ..'............................................ 25 
      9.1. Normative References .................................. 25 
      9.2. Informative References ................................ 25 
    
1. Introduction 

   This document introduces a YANG data model for network topologies. 
   The model allows an application to have a holistic view of an entire 
   network. In order to capture information that is specific to a 
   particular type of network topology, the data model contains elements 
   such as nodes and links that constitute a topology graph, as well as 
   termination points which are contained in the nodes that actually 
   terminate links of the graph, more specifically, termination points 
   can also be gathered in the clients as well as servers. Besides, in 
   order to provide views at different network layers, the network 
   topology information model has a "layer" property to indicate the 
   layer where the topology underlays. Now the "layer" property has 
   three values: [editor's note: wireless is also important, and will be 
   taken into account later], physical, datalink and network including 
   IP and MPLS can be extended to layer 4, 5 and 7. The data model is 
   generic in nature and can depict the network topology in the specific 
   network layer as the application expects. As a result, the data model 
   can be applied to any type of network topology. 
 
 
Contreras, et al.      Expires August 6, 2015                 [Page 2] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

   Topology model abstracts the elements of a network, and provides a 
   holistic view of the whole network to applications. Based on the 
   topology model and vendor-neutral policy configurations, service 
   management can configure policies based on the service request at the 
   network level rather than the device level. SUPA (Simplified Use of 
   Policy Abstractions) could translate the policy configuration from 
   network level to device level, and deploy the policy configuration to 
   the network. 

   More specifically, from service management's point of view: 

   With knowledge of the underlying network such as the topology of the 
   infrastructure, either physical or logical, service management can 
   deploy a policy/service to the network devices. Here the topology 
   data model is the information of the underlying network that from 
   controller.  

   From the controller's point of view: 

   The controller is responsible for maintaining the infrastructure 
   information, and it provides this information to service management 
   with the topology information model. The detail procedure of how to 
   use the topology information when mapping the service to device can 
   be found in SUPA mapping draft. 

   The data model is mainly defined in a YANG module named "topology", 
   which contains a generic network topology model. It models a graph 
   set of "connected" network elements, such as links, nodes, 
   termination points, external nodes, external termination points, and 
   external links. External nodes, external termination points and 
   external links may not exist in a specific topology. Technically, a 
   subset of the topology can be virtualized as one node, shown as the 
   node container in the next few sections. The model is also capable of 
   depicting the topology at different layers, thus a network can be 
   represented in the way as applications expect. In another word, 
   different users or applications may have different views of the 
   topology. 

2. Conventions used in this document 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC-2119.  

   In this document, these words will appear with that interpretation   
   only when in ALL CAPS. Lower case uses of these words are not to be    
   interpreted as carrying RFC-2119 significance. 
 
 
Contreras, et al.      Expires August 6, 2015                 [Page 3] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

3. Terminology 

   NETCONF: Network Configuration Protocol 

   SUPA: Simplified Use of Policy Abstractions 

   YANG: A data modeling language used to model configuration and state 
   data manipulated by the NETCONF protocol. 

4. Network topology model overview 

4.1. Topology information model 

   This section provides an overview of the network topology information 
   model. 

   As shown in figure 1, the information model is mainly focused on the 
   hierarchy of the topology information. Topology information may be 
   originated from network elements from different layers. Furthermore, 
   SDN operation is basically the manipulation of managed object 
   instances, the information model of network topology should be 
   organized into a hierarchical manner in order to capture information 
   that is specific to different network topology types. The scope of 
   this document is focused on the generic and abstract topology model 
   with certain typical models for specific topologies. Other topology 
   models can be derived from the abstract one. 

    


















 
 
Contreras, et al.      Expires August 6, 2015                 [Page 4] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

                  +--------------------------------+ 
                  |                                | 
                  |       SUPA topologies          | 
                  |                                | 
                  +---^----------------^-------^---+ 
                      |                |       |  
                      |                |       | 
    +-----------------+--------------+ |       | 
    |    Network topology model      | |       | 
    |                                | |       | 
    |         IP           MPLS      | |       | 
    |------+------+------------------| |       | 
    |      |      |                  | |       | 
    |      |      |                  | |  +----+-----------------------+ 
    |     IGP    BGP                 | |  |                            | 
    |      ^      ^                  | |  |   Datalink topology model  | 
    |      |      |                  | |  |----------------------------| 
    |      |      |                  <----+ IEEE802.3   Ethernet   PPP | 
    |     OSPF   ISIS                | |  |                            | 
    |      ^      ^                  | |  | ATM   token ring    X.25   | 
    |      |      |                  | |  |                            | 
    |      |      |                  | |  +-------^--------------------+ 
    |         TE                     | |          | 
    +--------------------------^-----+ |          | 
                               |       |          | 
                               |       |          | 
                          +----+-------+----------+---+ 
                          |                           | 
                          |  Physical topology model  | 
                          |---------------------------| 
                          |  optical    copper   hub  | 
                          |                           | 
                          |  adapter    repeater      | 
                          |                           | 
                          +---------------------------+ 
    
           Figure 1  Topology information model structure 
    
      Physical topology: This type of topology consists of physical 
   devices and the transmission medium among them such as physical link, 
   optical and so on. Besides topology information those electrical and 
   electronic specifications are also the components of this physical 
   topology. Physical topology model is the base of all other topology 
   models over physical topology model. 

      Data-link topology: This type of topology focuses on network 
   elements that are visible with the help of different data-link 
 
 
Contreras, et al.      Expires August 6, 2015                 [Page 5] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

   protocols and their characteristics. Meanwhile, virtual/logical link 
   is running on this level to support the control plane which does not 
   care physical media. It is over physical topology model and on the 
   other hand, both IP and non-IP topology model can be over data link 
   topology model. 

      Network topology: This type of topology emphasizes network elements 
   and connections that can be discovered by protocols in network stack. 
   It can be further classified into different subordinate topologies 
   according to the protocol used. Virtual topology will also be 
   discussed in the section 4.4.1. 

4.2. Topology data model 

   The topology data model in figure 2 defines a network topology at a 
   general level of abstraction. It models aspects such as nodes, links 
   and termination point. The universal elements of the data model are 
   as follows: 

      A network at any layer can contain multiple topologies. Each 
   topology is captured in its own list elements, distinguished via a 
   topology ID.  

      Topology: A topology is used to describe network entities and their 
   relationships. Usually a topology may contain different nodes, links 
   and termination point. A topology can be uniquely identified by its 
   topology ID. A network can be represented by several different 
   topologies which may be organized into hierarchical manners. Also, 
   hierarchical fashioned controller architecture is equipped. In this 
   way, the multi-controller case can be handled that different 
   controller fetch the different layer of topology based on its demand.  

      Node: A node, uniquely identified by its node ID in this topology, 
   can represent one network entity either physical or logical. 
   According to the controller scope that the nodes belong to, they can 
   be referred as (internal) nodes or external nodes respectively.  

      Link: A link, uniquely identified by its link ID, is a 
   demonstration of the point-to-point connectivity between two nodes. 
   It is expressed in a unidirectional manner and defines its direction 
   with the help of its source and destination termination points. 
   Similarly as nodes, links can be subcategorized into (internal) links 
   or external links according to their controller scope. 

      Termination point: A termination point is used to describe the 
   attachment relationship between a node and one of its links. It can 
   be uniquely identified by the termination point ID in the 
 
 
Contreras, et al.      Expires August 6, 2015                 [Page 6] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

   corresponding node. One node may contain multiple termination points 
   but one termination point only associates one link to the node. 

   ExtNode, extLink and extTerminationPoint of a topology are also 
   defined to depict nodes, links and terminationPoints which are not 
   under the control of the controller in the topology. These elements 
   have the same attributes as the internal elements of the topology. 

   The node, link, and termination point also should be capable of being 
   defined at different network layer. The design method of such 
   elements will be described in following sections. 

   An overview of the YANG module for topology is illustrated in the 
   figure below. 

                  +-------------------------+ 
                  |                         | 
                  |       Topology          | 
                  |                         | 
                  +-+-+----+---------+--+-+-+ 
                    | |    |         |  | | 
                    | |    |         |  | | 
                    | |    |         |  | | 
                    | |    |         |  | | 
       +------------+ |    |         |  | | 
       |              |    |         |  | +------------------+ 
       |        +-----+    |         |  +--------+           | 
       |        |          |         +-+         |           | 
       |        |          |           |         |           | 
    +--+---+ +--+---+ +----+------++---+---+ +---+---+ +-----+-----+ 
    |link  | |node  | |termination||extLink| |extNode| |extTerminat| 
    +------+ +------+ |Point      |+-------+ +-------+ |ionPoint   | 
                      +-----------+                    +-----------+ 
           
                        Figure 2   Topology data model structure 

4.3. Topology data model structure 

   The structure of the topology data model, as defined in the YANG 
   module "SUPA- topology ", is described as follow. Brackets denote 
   list keys, "rw" denotes configuration data, "ro" denotes operational 
   state data, "*" denotes the parameter that can have multiple 
   instances, and "?" denotes optional parameters. The figure is 
   intended to provide an overall structure of the topology data model. 

    
   module: SUPA-topology 
 
 
Contreras, et al.      Expires August 6, 2015                 [Page 7] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

      +--rw topologies 
      |  +--rw topology* [topoId] 
      |     +--rw topoId      string 
      |     +--rw topoName?   string 
      |     +--rw layer       enumeration 
      +--rw nodes 
      |  +--rw node* [nodeId] 
      |     +--rw nodeId          string 
      |     +--rw nodeName?       string 
      |     +--rw nodeType?       enumeration 
      |     +--rw adminStatus?    enumeration 
      |     +--ro operStatus?     enumeration 
      |     +--rw parentTopoID?   string 
      +--rw extnodes 
      |  +--rw extnode* [nodeId] 
      |     +--rw nodeId          string 
      |     +--rw nodeName?       string 
      |     +--rw nodeType?       enumeration 
      |     +--rw adminStatus?    enumeration 
      |     +--ro operStatus?     enumeration 
      |     +--rw parentTopoID?   string 
      +--rw terminationpoints 
      |  +--rw terminationpoint* [tpId] 
      |     +--rw tpId      string 
      |     +--rw tpName?   string 
      |     +--rw nodeId?   string 
      +--rw extterminationpoints 
      |  +--rw extterminationpoint* [tpId] 
      |     +--rw tpId            string 
      |     +--rw tpName?         string 
      |     +--rw nodeId?         string 
      |     +--rw parentTopoID?   string 
      +--rw links 
      |  +--rw link* [linkId] 
      |     +--rw linkId               string 
      |     +--rw linkName?            string 
      |     +--rw linkType?            enumeration 
      |     +--rw direction?           enumeration 
      |     +--rw adminStatus?         enumeration 
      |     +--ro operStatus?          enumeration 
      |     +--rw sourceNodeId         string 
      |     +--rw sourceTpId           string 
      |     +--rw destinationNodeId    string 
      |     +--rw destinationTpId      string 
      |     +--rw parentTopoID?        string 
      |     +--rw linkTeAttrCfg 
      |     |  +--rw maxReservableBandwidth?   uint32 
 
 
Contreras, et al.      Expires August 6, 2015                 [Page 8] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

      |     |  +--rw teIfMetric?               uint32 
      |     |  +--rw srlg-values* [srlg-value] 
      |     |  |  +--rw srlg-value    uint32 
      |     |  +--rw administrativeGroups 
      |     |     +--rw color?   uint32 
      |     +--rw linkAttrRun 
      |        +--ro physicalBandwidth?   uint32 
      +--rw extlinks 
         +--rw extlink* [linkId] 
            +--rw linkId               string 
            +--rw linkName?            string 
            +--rw linkType?            enumeration 
            +--rw direction?           enumeration 
            +--rw adminStatus?         enumeration 
            +--ro operStatus?          enumeration 
            +--rw sourceNodeId         string 
            +--rw sourceTpId           string 
            +--rw destinationNodeId    string 
            +--rw destinationTpId      string 
            +--rw parentTopoID?        string 
            +--rw linkTeAttrCfg 
            |  +--rw maxReservableBandwidth?   uint32 
            |  +--rw teIfMetric?               uint32 
            |  +--rw administrativeGroups 
            |     +--rw administrativeGroup* [affinityName] 
            |        +--rw affinityName    string 
            +--rw linkAttrRun 
               +--ro physicalBandwidth?   uint32 
    

4.4. Main building blocks 

   A network at any layer can contain multiple topologies. Each topology 
   is captured from its own list of elements, distinguished via a 
   topology ID. A network topology can also be consisted of multiple 
   layers, and one topology reflects all these layers which are 
   hierarchized.  

   A topology can be viewed from a certain layer, e.g., optical 
   indicates layer 0, physical indicates layer 1, datalink indicates 
   layer 2 and IP indicates layer 3. The layer is captured underneath 
   container "layer". This serves as container for a data model that 
   indicates the topology in which network layer. More specifically, the 
   relation of each topology model is that the up level topology model 
   can be constructed over lower level topology model and the network 
   topology model can use each of the topology model. All these layers 
   together construct a unified topology.  
 
 
Contreras, et al.      Expires August 6, 2015                 [Page 9] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

   A topology contains nodes, links, ternminationpoints, extNode, 
   extLink and extTerminationPoint, and each of them is captured in 
   their own lists. 

   A node has a node ID. Node ID distinguishes the node from other nodes 
   in the list. A node also has attributes such as nodeName, adminStatus, 
   operStatus, and topoID, and the meaning of them can be found in the 
   detailed topology YANG module in section 4. In addition, a node in a 
   topology has three types: physical node, virtual node and container 
   node. A "physical" node is a physical device, such as an actual 
   router, an actual switch, and etc. A "virtual" node here denotes an 
   abstraction of the physical node. More details of virtual node and 
   virtual topology are in next section. A "container" node is an 
   abstract node. A sub topology may be regarded as a container node to 
   simplify the parent topology. The parent topology has a container 
   node that maps a sub topology. The type is captured underneath 
   container "nodeType".  

   A termination point is a begin point or end point of a link, it is 
   identified by a termination point ID. A termination point also has 
   containers such as "topoId", "tpName", "tpType" and "tpId" whose 
   descriptions can be found in section 4. A node has one or more 
   termination points. A termination point can have different values 
   under different scenarios, e.g. "ip" means the value for termination 
   point is IP address. "interface" means interface name. "portId" means 
   port identifier. 

   A link is identified by a link ID, which uniquely identifies the link 
   within the topology. Links are bidirectional or unidirectional. A 
   link contains a "source" and a "destination". Both "source" and 
   "destination" reference to a corresponding node, as well as a 
   termination point on that node. 

   External objects such as extNode, extLink and extTerminationPoint of 
   a topology are objects not controlled by the controller which manage 
   the topology. For example, a link is an internal link between nodes 
   in the network managed by a SDN controller. An external link connects 
   a node in the network managed by a SDN controller to a node in the 
   network managed by the other SDN controller. A link is a connection 
   line in a topology. An external link is a connection line between two 
   different topologies. 

4.4.1.  Virtual topology 

   Virtual topology is so important and has also been taken into account 
   in the unified topology model. In real network,"data link topology' 
   does not directly feed into control plane topology, since control 
 
 
Contreras, et al.      Expires August 6, 2015                [Page 10] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

   plane calculation does not care media. Control plane works on 
   logical/virtual links (software interface index with link capacity 
   such as p2p, or p2mp, or 10G etc). So the virtual topology is the 
   abstraction or aggregation of from the lower level topology to feed 
   the high level topology. In virtual topology, a virtual node is a 
   virtual isolated partition of a physical node or a group of physical 
   nodes. For example a router can be divided into several sub-routers, 
   each of which has external connections. In this way, from external 
   view, each sub-router can be treated as a "virtual" node which 
   simulates the pseudo node in the ISIS broadcast network. The pseudo 
   node is not an actual router. With the pseudo nodes, the network 
   topology is simplified and the LSP is shortened. 

5. SUPA topology YANG model 

   <Code Begin> 
   module SUPA-topology { 
     namespace "http://"; 
     prefix "SUPA-topology"; 
     organization " "; 
     contact " "; 
     description " "; 
     revision "2015-01-09"{ 
                description "Initial revision."; 
           } 
    
     container topologies { 
    
       list topology { 
    
         key "topoId"; 
         description "Network Topology"; 
     
         leaf topoId { 
           description "Topology ID"; 
           config true; 
           type string { 
             length "1..32"; 
           } 
         } 
         leaf topoName { 
           description "Topology Name"; 
           config true; 
           type string { 
             length "0..32"; 
           } 
         } 
 
 
Contreras, et al.      Expires August 6, 2015                [Page 11] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

         leaf layer { 
           description "layer"; 
           config true; 
           mandatory true; 
           type enumeration { 
              
             enum physical { 
               value 1; 
               description "L1"; 
             } 
             enum datalink { 
               value 2; 
               description "L2"; 
             } 
             enum network { 
               value 3; 
               description "L3"; 
             } 
           } 
         } 
       } 
    
     } 
    
     container nodes { 
    
       list node { 
    
         key "nodeId"; 
         description "Topology Node"; 
     
         leaf nodeId { 
           description "Node Id"; 
           config true; 
           type string { 
             length "0..32"; 
           } 
         } 
         leaf nodeName { 
           description "Node Name"; 
           config true; 
           type string { 
             length "0..32"; 
           } 
         } 
         leaf nodeType { 
           description "Node Type"; 
 
 
Contreras, et al.      Expires August 6, 2015                [Page 12] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

           config true; 
           default physical; 
           type enumeration { 
             enum physical { 
               value 0; 
               description "physical"; 
             } 
             enum virtual { 
               value 1; 
               description "virtual"; 
             } 
           } 
         } 
         leaf adminStatus { 
           description "administration status"; 
           config true; 
           default adminUp; 
           type enumeration { 
             enum adminDown { 
               value 0; 
               description "configured to be down"; 
             } 
             enum adminUp { 
               value 1; 
               description "configured to be up"; 
             } 
           } 
         } 
         leaf operStatus { 
           description "running status"; 
           config false; 
           type enumeration { 
             enum down { 
               value 0; 
               description "down"; 
             } 
             enum up { 
               value 1; 
               description "up"; 
             } 
           } 
         } 
         leaf parentTopoID { 
           description "topology ID the node belongs to";one 
   topology may belong to more than one parent topologies? 
           config true; 
           type string { 
 
 
Contreras, et al.      Expires August 6, 2015                [Page 13] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

             length "0..32"; 
           } 
         }      
       } 
    
     } 
    
     container extnodes { 
    
       list extnode { 
    
         key "nodeId"; 
         description "External Nodes"; 
     
         leaf nodeId { 
           description "Node Id"; 
           config true; 
           type string { 
             length "0..32"; 
           } 
         } 
         leaf nodeName { 
           description "Node Name"; 
           config true; 
           type string { 
             length "0..32"; 
           } 
         } 
         leaf nodeType { 
           description "Node Type"; 
           config true; 
           default physical; 
           type enumeration { 
             enum physical { 
               value 0; 
               description "physical"; 
             } 
             enum virtual { 
               value 1; 
               description "virtual"; 
             } 
           } 
         } 
         leaf adminStatus { 
           description "administration status"; 
           config true; 
           default adminUp; 
 
 
Contreras, et al.      Expires August 6, 2015                [Page 14] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

           type enumeration { 
             enum adminDown { 
               value 0; 
               description "configured to be down"; 
             } 
             enum adminUp { 
               value 1; 
               description "configured to be up"; 
             } 
           } 
         } 
         leaf operStatus { 
           description "running status"; 
           config false; 
           type enumeration { 
             enum down { 
               value 0; 
               description "down"; 
             } 
             enum up { 
               value 1; 
               description "up"; 
             } 
           } 
         } 
         leaf parentTopoID { 
           description "topology ID the node belongs to";    
     config true; 
           type string { 
             length "0..32"; 
           } 
         } 
       } 
    
     } 
      
     container terminationpoints { 
    
       list terminationpoint { 
    
         key "tpId"; 
         description " "; 
     
         leaf tpId { 
           description "ID"; 
           config true; 
           type string { 
 
 
Contreras, et al.      Expires August 6, 2015                [Page 15] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

             length "1..32"; 
           } 
         } 
         leaf tpType { 
           description "Type"; 
           config true; 
           type enumeration { 
             enum down { 
               value IP; 
               description " the value for termination point is IP 
   address"; 
               value interface; 
               description "interface name"; 
               value portID; 
               description "port identifier"; 
             } 
           } 
         } 
    
         leaf tpName { 
           description "Name"; 
           config true; 
           type string { 
             length "0..32"; 
           } 
         } 
         leaf nodeId { 
           description "the node ID the termination point belongs 
   to"; 
           config true; 
           type string { 
             length "1..32"; 
           } 
         } 
       } 
    
     } 
      
     container extterminationpoints { 
    
       list extterminationpoint { 
    
         key "tpId"; 
         description " "; 
     
         leaf tpId { 
           description "ID"; 
 
 
Contreras, et al.      Expires August 6, 2015                [Page 16] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

           config true; 
           type string { 
             length "1..32"; 
           } 
         } 
         leaf tpName { 
           description "Name"; 
           config true; 
           type string { 
             length "0..32"; 
           } 
         } 
         leaf nodeId { 
           description "the node ID the termination point belongs 
   to"; 
           config true; 
           type string { 
             length "1..32"; 
           } 
         } 
         leaf parentTopoID { 
           description "topology ID the termination point belongs 
   to"; 
           config true; 
           type string { 
             length "0..32"; 
           } 
         } 
       } 
    
     } 
    
     container links { 
    
       list link { 
    
         key "linkId"; 
         description "Link"; 
     
         leaf linkId { 
           description "Link Identifier"; 
           config true; 
           type string { 
             length "0..32"; 
           } 
         } 
         leaf linkName { 
 
 
Contreras, et al.      Expires August 6, 2015                [Page 17] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

           description "Link Name"; 
           config true; 
           type string { 
             length "0..32"; 
           } 
         } 
         leaf linkType { 
           description "Link Type"; 
           config true; 
           default physical; 
           type enumeration { 
             enum physical { 
               value 0; 
               description " "; 
             } 
             enum telink { 
               value 1; 
               description " "; 
             } 
           } 
         }      
         leaf direction { 
           description "tunnel direction"; 
           config true; 
           default unidirectional; 
           type enumeration { 
             enum unidirectional { 
               value 0; 
               description "unidirectional"; 
             } 
             enum bidirectional { 
               value 1; 
               description "bidirectional"; 
             } 
           } 
         } 
         leaf adminStatus { 
           description "administration status"; 
           config true; 
           default adminUp; 
           type enumeration { 
             enum adminDown { 
               value 0; 
               description "configured to be down"; 
             } 
             enum adminUp { 
               value 1; 
 
 
Contreras, et al.      Expires August 6, 2015                [Page 18] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

               description "configured to be up"; 
             } 
           } 
         } 
         leaf operStatus { 
           description "running status"; 
           config false; 
           type enumeration { 
             enum down { 
               value 0; 
               description "down"; 
             } 
             enum up { 
               value 1; 
               description "up"; 
             } 
           } 
         } 
         leaf sourceNodeId { 
           description "Node Id"; 
           config true; 
           mandatory true; 
           type string { 
             length "1..32"; 
           } 
         } 
         leaf sourceTpId { 
           description "Source Termination Point Id"; 
           config true; 
           mandatory true; 
           type string { 
             length "1..32"; 
           } 
         } 
         leaf destinationNodeId { 
           description "Node Id"; 
           config true; 
           mandatory true; 
           type string { 
             length "1..32"; 
           } 
         } 
         leaf destinationTpId { 
           description "Destination Termination Point Id"; 
           config true; 
           mandatory true; 
           type string { 
 
 
Contreras, et al.      Expires August 6, 2015                [Page 19] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

             length "1..32"; 
           } 
         } 
         leaf parentTopoID { 
           description "topology ID the link belongs to"; 
           config true; 
           type string { 
             length "0..32"; 
           } 
         } 
         container linkTeAttrCfg { 
    
           description "Link TE Attribute"; 
     
           leaf maxReservableBandwidth { 
             description "Max Reservable Bandwidth Attribute,kbps"; 
             config true; 
             default 0; 
             type uint32 { 
               range "0..4000000000"; 
             } 
           } 
           leaf teIfMetric { 
             description "TE-LINK metric"; 
             config true; 
             type uint32 { 
               range "1..16777215"; 
             } 
           } 
                   list srlg-values { 
                       description 
                           "List of Shared Risk Link Group this 
   interface belongs to."; 
                       key "srlg-value"; 
                       leaf srlg-value { 
                       description 
                         "Shared Risk Link Group value"; 
                       type uint32; 
                       } 
                   } 
    
           container administrativeGroups { 
                       leaf color { 
                           description 
                               "Administrative group or color of the 
   link"; 
                           type uint32; 
 
 
Contreras, et al.      Expires August 6, 2015                [Page 20] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

                           } 
           } 
    
         } 
    
         container linkAttrRun { 
    
           description "link value negotiated"; 
     
           leaf physicalBandwidth { 
             description "Physical Bandwidth,kbps"; 
             config false; 
             default 0; 
             type uint32 { 
               range "0..4000000000"; 
             } 
           } 
         } 
    
       } 
    
     } 
    
     container extlinks { 
    
       list extlink { 
    
         key "linkId"; 
         description "External Links"; 
     
         leaf linkId { 
           description "Link Identifier"; 
           config true; 
           type string { 
             length "0..32"; 
           } 
         } 
         leaf linkName { 
           description "Link Name"; 
           config true; 
           type string { 
             length "0..32"; 
           } 
         } 
         leaf linkType { 
           description "Link Type"; 
           config true; 
 
 
Contreras, et al.      Expires August 6, 2015                [Page 21] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

           default physical; 
           type enumeration { 
             enum physical { 
               value 0; 
               description " "; 
             } 
             enum telink { 
               value 1; 
               description " "; 
             } 
           } 
         }      
         leaf direction { 
           description "tunnel direction"; 
           config true; 
           default unidirectional; 
           type enumeration { 
             enum unidirectional { 
               value 0; 
               description "unidirectional"; 
             } 
             enum bidirectional { 
               value 1; 
               description "bidirectional"; 
             } 
           } 
         } 
         leaf adminStatus { 
           description "administration status"; 
           config true; 
           default adminUp; 
           type enumeration { 
             enum adminDown { 
               value 0; 
               description "configured to be down"; 
             } 
             enum adminUp { 
               value 1; 
               description "configured to be up"; 
             } 
           } 
         } 
         leaf operStatus { 
           description "running status"; 
           config false; 
           type enumeration { 
             enum down { 
 
 
Contreras, et al.      Expires August 6, 2015                [Page 22] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

               value 0; 
               description "down"; 
             } 
             enum up { 
               value 1; 
               description "up"; 
             } 
           } 
         } 
         leaf sourceNodeId { 
           description "Node Id"; 
           config true; 
           mandatory true; 
           type string { 
             length "1..32"; 
           } 
         } 
         leaf sourceTpId { 
           description "Source Termination Point Id"; 
           config true; 
           mandatory true; 
           type string { 
             length "1..32"; 
           } 
         } 
         leaf destinationNodeId { 
           description "Node Id"; 
           config true; 
           mandatory true; 
           type string { 
             length "1..32"; 
           } 
         } 
         leaf destinationTpId { 
           description "Destination Termination Point Id"; 
           config true; 
           mandatory true; 
           type string { 
             length "1..32"; 
           } 
         } 
         leaf parentTopoID { 
           description "topology ID the link belongs to"; 
           config true; 
           type string { 
             length "0..32"; 
           } 
 
 
Contreras, et al.      Expires August 6, 2015                [Page 23] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

         } 
         container linkTeAttrCfg { 
    
           description "Link TE Attribute"; 
     
           leaf maxReservableBandwidth { 
             description "Max Reservable Bandwidth Attribute,kbps"; 
             config true; 
             default 0; 
             type uint32 { 
               range "0..4000000000"; 
             } 
           } 
           leaf teIfMetric { 
             description "TE-LINK metric"; 
             config true; 
             type uint32 { 
               range "1..16777215"; 
             } 
           } 
    
           container administrativeGroups { 
    
             list administrativeGroup { 
    
               key "affinityName"; 
               description " A link may have one or more affinity 
   name. Here is a group of those affinity information."; 
     
               leaf affinityName { 
                 description "Affinity Name"; 
                 config true; 
                 type string { 
                   length "0..32"; 
                 } 
               } 
             } 
    
           } 
    
         } 
    
         container linkAttrRun { 
    
           description "link value negotiated"; 
     
           leaf physicalBandwidth { 
 
 
Contreras, et al.      Expires August 6, 2015                [Page 24] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

             description "Physical Bandwidth,kbps"; 
             config false; 
             default 0; 
             type uint32 { 
               range "0..4000000000"; 
             } 
           } 
         } 
    
       } 
    
     } 
   } 
   <Code End> 
    

6. Security Considerations 

   It will be considered in a future revision. 

7. IANA Considerations 

8. Acknowledgments 

   The author would like to thank colleagues from China Mobile for their 
   contributions on this work.  
    
9. References 

9.1.  Normative References 

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

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the           
             Network Configuration Protocol (NETCONF)", RFC 6020,              
             October 2010. 

   [RFC6021]  Schoenwaelder, J., "Common YANG Data Types", RFC 6021,            
             October 2010. 

    
9.2. Informative References 




 
 
Contreras, et al.      Expires August 6, 2015                [Page 25] 

Internet-Draft  A YANG Data Model for Network Topologies  February 2015 
    

   [APONF-architecture] C. Zhou, T. Tsou, Q. Sun, D. Lopez, G. 
   Karagiannis, "APONF Architecture", IETF Internet draft, draft-zhou-
   aponf-architecture-00, June 2014 

 
Authors' Addresses 

   Luis M. Contreras 
   Telefonica I+D 
   Ronda de la Comunicacion, Sur-3 building, 3rd floor 
   Madrid  28050 
   Spain 
   Email: luismiguel.contrerasmurillo@telefonica.com 
   URI:   http://people.tid.es/LuisM.Contreras/ 
    
   Jun Bi 
   Tsinghua University 
   Network Research Center, Tsinghua University 
   Beijing  100084, China 
   Email: junbi@tsinghua.edu.cn 
    
   Andrew Qu 
   MediaTek 
   Email: andrew.qu@mediatek.com 
 
   Yiyong Zha 
   Huawei Technologies 
   Email: zhayiyong@huawei.com 
    

















 
 
Contreras, et al.      Expires August 6, 2015                [Page 26]