modules/loader-resources/src/main/resources/assets/yang2xml/network-topology@2013-07-12.yang.xml

   1 <?xml version="1.0" encoding="UTF-8"?>\r
   2 <module name="network-topology"\r
   3         xmlns="urn:ietf:params:xml:ns:yang:yin:1"\r
   4         xmlns:nt="urn:TBD:params:xml:ns:yang:network-topology"\r
   5         xmlns:inet="urn:ietf:params:xml:ns:yang:ietf-inet-types">\r
   6   <yang-version value="1"/>\r
   7   <namespace uri="urn:TBD:params:xml:ns:yang:network-topology"/>\r
   8   <prefix value="nt"/>\r
   9   <import module="ietf-inet-types">\r
  10     <prefix value="inet"/>\r
  11   </import>\r
  12   <organization>\r
  13     <text>TBD</text>\r
  14   </organization>\r
  15   <contact>\r
  16     <text>WILL-BE-DEFINED-LATER</text>\r
  17   </contact>\r
  18   <revision date="2013-07-12">\r
  19     <description>\r
  20       <text>Initial revision.</text>\r
  21     </description>\r
  22   </revision>\r
  23   <typedef name="topology-id">\r
  24     <type name="inet:uri"/>\r
  25     <description>\r
  26       <text>An identifier for a topology.</text>\r
  27     </description>\r
  28   </typedef>\r
  29   <typedef name="node-id">\r
  30     <type name="inet:uri"/>\r
  31     <description>\r
  32       <text>An identifier for a node in a topology.  \r
  33 The identifier may be opaque.  \r
  34 The identifier SHOULD be chosen such that the same node in a \r
  35 real network topology will always be identified through the \r
  36 same identifier, even if the model is instantiated in separate \r
  37 datastores. An implementation MAY choose to capture semantics \r
  38 in the identifier, for example to indicate the type of node \r
  39 and/or the type of topology that the node is a part of.</text>\r
  40     </description>\r
  41   </typedef>\r
  42   <typedef name="link-id">\r
  43     <type name="inet:uri"/>\r
  44     <description>\r
  45       <text>An identifier for a link in a topology.  \r
  46 The identifier may be opaque.  \r
  47 The identifier SHOULD be chosen such that the same link in a \r
  48 real network topology will always be identified through the \r
  49 same identifier, even if the model is instantiated in separate \r
  50 datastores. An implementation MAY choose to capture semantics \r
  51 in the identifier, for example to indicate the type of link \r
  52 and/or the type of topology that the link is a part of.</text>\r
  53     </description>\r
  54   </typedef>\r
  55   <typedef name="tp-id">\r
  56     <type name="inet:uri"/>\r
  57     <description>\r
  58       <text>An identifier for termination points on a node. \r
  59 The identifier may be opaque.  \r
  60 The identifier SHOULD be chosen such that the same TP in a \r
  61 real network topology will always be identified through the \r
  62 same identifier, even if the model is instantiated in separate \r
  63 datastores. An implementation MAY choose to capture semantics \r
  64 in the identifier, for example to indicate the type of TP \r
  65 and/or the type of node and topology that the TP is a part of.</text>\r
  66     </description>\r
  67   </typedef>\r
  68   <typedef name="tp-ref">\r
  69     <type name="leafref">\r
  70       <path value="/network-topology/topology/node/termination-point/tp-id"/>\r
  71     </type>\r
  72     <description>\r
  73       <text>A type for an absolute reference to a termination point.\r
  74 (This type should not be used for relative references.\r
  75 In such a case, a relative path should be used instead.)</text>\r
  76     </description>\r
  77   </typedef>\r
  78   <typedef name="topology-ref">\r
  79     <type name="leafref">\r
  80       <path value="/network-topology/topology/topology-id"/>\r
  81     </type>\r
  82     <description>\r
  83       <text>A type for an absolute reference a topology instance.</text>\r
  84     </description>\r
  85   </typedef>\r
  86   <typedef name="node-ref">\r
  87     <type name="leafref">\r
  88       <path value="/network-topology/topology/node/node-id"/>\r
  89     </type>\r
  90     <description>\r
  91       <text>A type for an absolute reference to a node instance.\r
  92 (This type should not be used for relative references.\r
  93 In such a case, a relative path should be used instead.)</text>\r
  94     </description>\r
  95   </typedef>\r
  96   <typedef name="link-ref">\r
  97     <type name="leafref">\r
  98       <path value="/network-topology/topology/link/link-id"/>\r
  99     </type>\r
 100     <description>\r
 101       <text>A type for an absolute reference a link instance.\r
 102 (This type should not be used for relative references.\r
 103 In such a case, a relative path should be used instead.)</text>\r
 104     </description>\r
 105   </typedef>\r
 106   <grouping name="tp-attributes">\r
 107     <description>\r
 108       <text>The data objects needed to define a termination point.\r
 109 (This only includes a single leaf at this point, used\r
 110 to identify the termination point.)  \r
 111 Provided in a grouping so that in addition to the datastore,\r
 112 the data can also be included in notifications.</text>\r
 113     </description>\r
 114     <leaf name="tp-id">\r
 115       <type name="tp-id"/>\r
 116     </leaf>\r
 117     <leaf-list name="tp-ref">\r
 118       <type name="tp-ref"/>\r
 119       <config value="false"/>\r
 120       <description>\r
 121         <text>The leaf list identifies any termination points that the \r
 122 termination point is dependent on, or maps onto.  \r
 123 Those termination points will themselves be contained \r
 124 in a supporting node.  \r
 125 This dependency information can be inferred from \r
 126 the dependencies between links.  For this reason, \r
 127 this item is not separately configurable.  Hence no\r
 128 corresponding constraint needs to be articulated.  \r
 129 The corresponding information is simply provided by the\r
 130 implementing system.</text>\r
 131       </description>\r
 132     </leaf-list>\r
 133   </grouping>\r
 134   <grouping name="node-attributes">\r
 135     <description>\r
 136       <text>The data objects needed to define a node.\r
 137 The objects are provided in a grouping so that in addition to\r
 138 the datastore, the data can also be included in notifications\r
 139 as needed.</text>\r
 140     </description>\r
 141     <leaf name="node-id">\r
 142       <type name="node-id"/>\r
 143       <description>\r
 144         <text>The identifier of a node in the topology.  \r
 145 A node is specific to a topology to which it belongs.</text>\r
 146       </description>\r
 147     </leaf>\r
 148     <list name="supporting-node">\r
 149       <description>\r
 150         <text>This list defines vertical layering information for nodes. \r
 151 It allows to capture for any given node, which node (or nodes)\r
 152 in the corresponding underlay topology it maps onto.  \r
 153 A node can map to zero, one, or more nodes below it;\r
 154 accordingly there can be zero, one, or more elements in the list.\r
 155 If there are specific layering requirements, for example\r
 156 specific to a particular type of topology that only allows\r
 157 for certain layering relationships, the choice\r
 158 below can be augmented with additional cases.\r
 159 A list has been chosen rather than a leaf-list in order \r
 160 to provide room for augmentations, e.g. for \r
 161 statistics or priorization information associated with \r
 162 supporting nodes.</text>\r
 163       </description>\r
 164       <key value="node-ref"/>\r
 165       <leaf name="node-ref">\r
 166         <type name="node-ref"/>\r
 167       </leaf>\r
 168     </list>\r
 169   </grouping>\r
 170   <grouping name="link-attributes">\r
 171     <leaf name="link-id">\r
 172       <type name="link-id"/>\r
 173       <description>\r
 174         <text>The identifier of a link in the topology.  \r
 175 A link is specific to a topology to which it belongs.</text>\r
 176       </description>\r
 177     </leaf>\r
 178     <container name="source">\r
 179       <leaf name="source-node">\r
 180         <mandatory value="true"/>\r
 181         <type name="node-ref"/>\r
 182         <description>\r
 183           <text>Source node identifier, must be in same topology.</text>\r
 184         </description>\r
 185       </leaf>\r
 186       <leaf name="source-tp">\r
 187         <type name="tp-ref"/>\r
 188         <description>\r
 189           <text>Termination point within source node that terminates the link.</text>\r
 190         </description>\r
 191       </leaf>\r
 192     </container>\r
 193     <container name="destination">\r
 194       <leaf name="dest-node">\r
 195         <mandatory value="true"/>\r
 196         <type name="node-ref"/>\r
 197         <description>\r
 198           <text>Destination node identifier, must be in same topology.</text>\r
 199         </description>\r
 200       </leaf>\r
 201       <leaf name="dest-tp">\r
 202         <type name="tp-ref"/>\r
 203         <description>\r
 204           <text>Termination point within destination node that terminates the link.</text>\r
 205         </description>\r
 206       </leaf>\r
 207     </container>\r
 208     <list name="supporting-link">\r
 209       <key value="link-ref"/>\r
 210       <leaf name="link-ref">\r
 211         <type name="link-ref"/>\r
 212       </leaf>\r
 213     </list>\r
 214   </grouping>\r
 215   <container name="network-topology">\r
 216     <list name="topology">\r
 217       <description>\r
 218         <text>\r
 219 This is the model of an abstract topology.\r
 220 A topology contins nodes and links.  \r
 221 Each topology MUST be identified by\r
 222 unique topology-id for reason that a network could contain many\r
 223 topologies.\r
 224 </text>\r
 225       </description>\r
 226       <key value="topology-id"/>\r
 227       <leaf name="topology-id">\r
 228         <type name="topology-id"/>\r
 229         <description>\r
 230           <text>\r
 231 It is presumed that a datastore will contain many topologies. To\r
 232 distinguish between topologies it is vital to have UNIQUE\r
 233 topology identifiers.\r
 234 </text>\r
 235         </description>\r
 236       </leaf>\r
 237       <container name="topology-types">\r
 238         <description>\r
 239           <text>This container is used to identify the type, or types \r
 240 (as a topology can support several types simultaneously), \r
 241 of the topology.  \r
 242 Topology types are the subject of several integrity constraints \r
 243 that an implementing server can validate in order to \r
 244 maintain integrity of the datastore.  \r
 245 Topology types are indicated through separate data nodes; \r
 246 the set of topology types is expected to increase over time.\r
 247 To add support for a new topology, an augmenting module\r
 248 needs to augment this container with a new empty optional \r
 249 container to indicate the new topology type.  \r
 250 The use of a container allows to indicate a subcategorization\r
 251 of topology types.  \r
 252 The container SHALL NOT be augmented with any data nodes \r
 253 that serve a purpose other than identifying a particular \r
 254 topology type.  \r
 255 </text>\r
 256         </description>\r
 257       </container>\r
 258       <list name="underlay-topology">\r
 259         <key value="topology-ref"/>\r
 260         <leaf name="topology-ref">\r
 261           <type name="topology-ref"/>\r
 262         </leaf>\r
 263         <description>\r
 264           <text>Identifies the topology, or topologies, that this topology\r
 265 is dependent on.</text>\r
 266         </description>\r
 267       </list>\r
 268       <list name="node">\r
 269         <description>\r
 270           <text>The list of network nodes defined for the topology.</text>\r
 271         </description>\r
 272         <key value="node-id"/>\r
 273         <uses name="node-attributes"/>\r
 274         <must condition="boolean(../underlay-topology[*]/node[./supporting-nodes/node-ref])"/>\r
 275         <list name="termination-point">\r
 276           <description>\r
 277             <text>A termination point can terminate a link.  \r
 278 Depending on the type of topology, a termination point could, \r
 279 for example, refer to a port or an interface.</text>\r
 280           </description>\r
 281           <key value="tp-id"/>\r
 282           <uses name="tp-attributes"/>\r
 283         </list>\r
 284       </list>\r
 285       <list name="link">\r
 286         <description>\r
 287           <text>\r
 288 A Network Link connects a by Local (Source) node and\r
 289 a Remote (Destination) Network Nodes via a set of the \r
 290 nodes' termination points. \r
 291 As it is possible to have several links between the same\r
 292 source and destination nodes, and as a link could potentially\r
 293 be re-homed between termination points, to ensure that we \r
 294 would always know to distinguish between links, every link \r
 295 is identified by a dedicated link identifier.  \r
 296 Note that a link models a point-to-point link, not a multipoint\r
 297 link.  \r
 298 Layering dependencies on links in underlay topologies are\r
 299 not represented as the layering information of nodes and of \r
 300 termination points is sufficient.  \r
 301 </text>\r
 302         </description>\r
 303         <key value="link-id"/>\r
 304         <uses name="link-attributes"/>\r
 305         <must condition="boolean(../underlay-topology/link[./supporting-link])"/>\r
 306         <must condition="boolean(../node[./source/source-node])"/>\r
 307         <must condition="boolean(../node[./destination/dest-node])"/>\r
 308         <must condition="boolean(../node/termination-point[./source/source-tp])"/>\r
 309         <must condition="boolean(../node/termination-point[./destination/dest-tp])"/>\r
 310       </list>\r
 311     </list>\r
 312   </container>\r
 313 </module>\r