1 module network-topology {
3 namespace "urn:TBD:params:xml:ns:yang:network-topology";
4 // replace with IANA namespace when assigned
7 import ietf-inet-types { prefix "inet"; revision-date 2013-07-15; }
11 contact "WILL-BE-DEFINED-LATER";
14 "This module defines a model for the topology of a network.
15 Key design decisions are as follows:
16 A topology consists of a set of nodes and links.
17 Links are point-to-point and unidirectional.
18 Bidirectional connections need to be represented through
20 Multipoint connections, broadcast domains etc can be represented
21 through a hierarchy of nodes, then connecting nodes at
22 upper layers of the hierarchy.";
32 "An identifier for a topology.";
38 "An identifier for a node in a topology.
39 The identifier may be opaque.
40 The identifier SHOULD be chosen such that the same node in a
41 real network topology will always be identified through the
42 same identifier, even if the model is instantiated in separate
43 datastores. An implementation MAY choose to capture semantics
44 in the identifier, for example to indicate the type of node
45 and/or the type of topology that the node is a part of.";
52 "An identifier for a link in a topology.
53 The identifier may be opaque.
54 The identifier SHOULD be chosen such that the same link in a
55 real network topology will always be identified through the
56 same identifier, even if the model is instantiated in separate
57 datastores. An implementation MAY choose to capture semantics
58 in the identifier, for example to indicate the type of link
59 and/or the type of topology that the link is a part of.";
65 "An identifier for termination points on a node.
66 The identifier may be opaque.
67 The identifier SHOULD be chosen such that the same TP in a
68 real network topology will always be identified through the
69 same identifier, even if the model is instantiated in separate
70 datastores. An implementation MAY choose to capture semantics
71 in the identifier, for example to indicate the type of TP
72 and/or the type of node and topology that the TP is a part of.";
77 path "/network-topology/topology/node/termination-point/tp-id";
80 "A type for an absolute reference to a termination point.
81 (This type should not be used for relative references.
82 In such a case, a relative path should be used instead.)";
84 typedef topology-ref {
86 path "/network-topology/topology/topology-id";
89 "A type for an absolute reference a topology instance.";
94 path "/network-topology/topology/node/node-id";
98 "A type for an absolute reference to a node instance.
99 (This type should not be used for relative references.
100 In such a case, a relative path should be used instead.)";
105 path "/network-topology/topology/link/link-id";
108 "A type for an absolute reference a link instance.
109 (This type should not be used for relative references.
110 In such a case, a relative path should be used instead.)";
113 grouping tp-attributes {
115 "The data objects needed to define a termination point.
116 (This only includes a single leaf at this point, used
117 to identify the termination point.)
118 Provided in a grouping so that in addition to the datastore,
119 the data can also be included in notifications.";
127 "The leaf list identifies any termination points that the
128 termination point is dependent on, or maps onto.
129 Those termination points will themselves be contained
130 in a supporting node.
131 This dependency information can be inferred from
132 the dependencies between links. For this reason,
133 this item is not separately configurable. Hence no
134 corresponding constraint needs to be articulated.
135 The corresponding information is simply provided by the
136 implementing system.";
140 grouping node-attributes {
142 "The data objects needed to define a node.
143 The objects are provided in a grouping so that in addition to
144 the datastore, the data can also be included in notifications
150 "The identifier of a node in the topology.
151 A node is specific to a topology to which it belongs.";
153 list supporting-node {
155 "This list defines vertical layering information for nodes.
156 It allows to capture for any given node, which node (or nodes)
157 in the corresponding underlay topology it maps onto.
158 A node can map to zero, one, or more nodes below it;
159 accordingly there can be zero, one, or more elements in the list.
160 If there are specific layering requirements, for example
161 specific to a particular type of topology that only allows
162 for certain layering relationships, the choice
163 below can be augmented with additional cases.
164 A list has been chosen rather than a leaf-list in order
165 to provide room for augmentations, e.g. for
166 statistics or priorization information associated with
168 // This is not what was published in the initial draft,
169 // added topology-ref leaf and added it to the key
170 key "topology-ref node-ref";
180 grouping link-attributes {
181 // This is a grouping, not defined inline with the link definition itself,
182 // so it can be included in a notification, if needed
186 "The identifier of a link in the topology.
187 A link is specific to a topology to which it belongs.";
194 "Source node identifier, must be in same topology.";
199 "Termination point within source node that terminates the link.";
203 container destination {
208 "Destination node identifier, must be in same topology.";
213 "Termination point within destination node that terminates the link.";
216 list supporting-link {
225 container network-topology {
228 This is the model of an abstract topology.
229 A topology contains nodes and links.
230 Each topology MUST be identified by
231 unique topology-id for reason that a network could contain many
238 It is presumed that a datastore will contain many topologies. To
239 distinguish between topologies it is vital to have UNIQUE
240 topology identifiers.
243 leaf server-provided {
247 Indicates whether the topology is configurable by clients,
248 or whether it is provided by the server. This leaf is
250 populated by the server implementing the model.
251 It is set to false for topologies that are created by a client;
252 it is set to true otherwise. If it is set to true, any
253 attempt to edit the topology MUST be rejected.
256 container topology-types {
258 "This container is used to identify the type, or types
259 (as a topology can support several types simultaneously),
261 Topology types are the subject of several integrity constraints
262 that an implementing server can validate in order to
263 maintain integrity of the datastore.
264 Topology types are indicated through separate data nodes;
265 the set of topology types is expected to increase over time.
266 To add support for a new topology, an augmenting module
267 needs to augment this container with a new empty optional
268 container to indicate the new topology type.
269 The use of a container allows to indicate a subcategorization
271 The container SHALL NOT be augmented with any data nodes
272 that serve a purpose other than identifying a particular
276 list underlay-topology {
281 // a list, not a leaf-list, to allow for potential augmentation
282 // with properties specific to the underlay topology,
283 // such as statistics, preferences, or cost.
285 "Identifies the topology, or topologies, that this topology
290 description "The list of network nodes defined for the topology.";
292 uses node-attributes;
293 must "boolean(../underlay-topology[*]/node[./supporting-nodes/node-ref])";
294 // This constraint is meant to ensure that a referenced node is in fact
295 // a node in an underlay topology.
296 list termination-point {
299 "A termination point can terminate a link.
300 Depending on the type of topology, a termination point could,
301 for example, refer to a port or an interface.";
309 A Network Link connects a by Local (Source) node and
310 a Remote (Destination) Network Nodes via a set of the
311 nodes' termination points.
312 As it is possible to have several links between the same
313 source and destination nodes, and as a link could potentially
314 be re-homed between termination points, to ensure that we
315 would always know to distinguish between links, every link
316 is identified by a dedicated link identifier.
317 Note that a link models a point-to-point link, not a multipoint
319 Layering dependencies on links in underlay topologies are
320 not represented as the layering information of nodes and of
321 termination points is sufficient.
324 uses link-attributes;
325 must "boolean(../underlay-topology/link[./supporting-link])";
326 // Constraint: any supporting link must be part of an underlay topology
327 must "boolean(../node[./source/source-node])";
328 // Constraint: A link must have as source a node of the same topology
329 must "boolean(../node[./destination/dest-node])";
330 // Constraint: A link must have as source a destination of the same topology
331 must "boolean(../node/termination-point[./source/source-tp])";
332 // Constraint: The source termination point must be contained in the source node
333 must "boolean(../node/termination-point[./destination/dest-tp])";
334 // Constraint: The destination termination point must be contained
335 // in the destination node