1 module tapi-topology {
\r
2 namespace "urn:onf:otcc:yang:tapi-topology";
\r
3 prefix tapi-topology;
\r
7 organization "ONF OTCC (Open Transport Configuration & Control) Project";
\r
9 Project Web: <https://urldefense.com/v3/__https://wiki.opennetworking.org/display/OTCC/TAPI__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_yiFzE6g$ >
\r
10 Project List: <mailto:transport-api@opennetworking.org>
\r
11 Editor: Karthik Sethuraman <mailto:karthik.sethuraman@necam.com>
\r
12 Andrea Mazzin <mailto:andrea.mazzini@nokia.com>
\r
13 Arturo Mayoral <mailto:arturo.mayoral@telefonica.com>
\r
14 Nigel Davis <mailto:ndavis@ciena.com>";
\r
16 This module contains TAPI Topology Model definitions.
\r
17 Source: TapiTopology.uml
\r
18 - The TAPI YANG models included in this TAPI release are a *normative* part of the TAPI SDK.
\r
19 - The YANG specifications have been generated from the corresponding UML model using the [ONF EAGLE UML2YANG mapping tool]
\r
20 <https://urldefense.com/v3/__https://github.com/OpenNetworkingFoundation/EagleUmlYang__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_6pxiNxl$ >
\r
21 and further edited manually to comply with the [ONF IISOMI UML2YANG mapping guidelines]
\r
22 <https://urldefense.com/v3/__https://wiki.opennetworking.org/display/OIMT/UML*-*YANG*Guidelines__;Kysr!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_wxKUbJ_$ >
\r
23 - Status of YANG model artifacts can be determined by referring to the corresponding UML artifacts.
\r
24 As described in the UML models, some artifacts are considered *experimental*, and thus the corresponding YANG artifacts.
\r
25 - The ONF TAPI release process does not guarantee backward compatibility of YANG models across major versions of TAPI releases.
\r
26 The YANG model backward compatibility criteria are outlined in section 11 of <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7950__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_zcAY1P4$ >.
\r
27 YANG models included in this release may not be backward compatible with previous TAPI releases.
\r
28 Copyright (c) 2018 Open Networking Foundation (ONF). All rights reserved.
\r
29 License: This module is distributed under the Apache License 2.0.";
\r
30 revision 2020-04-23 {
\r
31 description "ONF Transport API version 2.1.3.
\r
32 Changes included in this TAPI release (v2.1.3) are listed in
\r
33 <https://urldefense.com/v3/__https://github.com/OpenNetworkingFoundation/TAPI/blob/develop_v2_1/CHANGE_LOG/change-log.2.1.3.md__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_xm1nx_D$ >";
\r
34 reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 7950, RFC 6087 and ONF TAPI UML model
\r
35 <https://urldefense.com/v3/__https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.0/UML__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_8UH3XnH$ >";
\r
37 revision 2019-07-16 {
\r
38 description "ONF Transport API version 2.1.2.
\r
39 Changes included in this TAPI release (v2.1.2) are listed in
\r
40 <https://urldefense.com/v3/__https://github.com/OpenNetworkingFoundation/TAPI/blob/develop_v2_1/CHANGE_LOG/change-log.2.1.2.md__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_0xFu4bN$ >";
\r
41 reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 7950, RFC 6087 and ONF TAPI UML model
\r
42 <https://urldefense.com/v3/__https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.0/UML__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_8UH3XnH$ >";
\r
44 revision 2018-12-10 {
\r
45 description "ONF Transport API version 2.1.1.
\r
46 Changes included in this TAPI release (v2.1.1) are listed in
\r
47 <https://urldefense.com/v3/__https://github.com/OpenNetworkingFoundation/TAPI/blob/develop/CHANGE_LOG/change-log.2.1.1.md__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur__2p0od1$ >";
\r
48 reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 7950, RFC 6087 and ONF TAPI UML model
\r
49 <https://urldefense.com/v3/__https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.0/UML__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_8UH3XnH$ >";
\r
51 revision 2018-10-16 {
\r
52 description "ONF Transport API version 2.1.0.
\r
53 Changes included in this TAPI release (v2.1.0) are listed in
\r
54 <https://urldefense.com/v3/__https://github.com/OpenNetworkingFoundation/TAPI/blob/develop/CHANGE_LOG/change-log.2.1.0.md__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_4DGi8ul$ >";
\r
55 reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 7950, RFC 6087 and ONF TAPI UML model
\r
56 <https://urldefense.com/v3/__https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.0/UML__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_8UH3XnH$ >";
\r
58 revision 2018-03-07 {
\r
59 description "ONF Transport API version 2.0.2
\r
60 This YANG module has been generated from the TAPI UML Model using the IISOMI-Eagle xmi2yang mapping tool.
\r
61 Changes in this revision: <https://urldefense.com/v3/__https://github.com/OpenNetworkingFoundation/TAPI/blob/develop/CHANGE_LOG/change-log.2.0.2.md__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_8KlxwJZ$ >";
\r
62 reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 6020, RFC 6087 and ONF TAPI UML model
\r
63 <https://urldefense.com/v3/__https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.0.2/UML__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_-hMD5Xl$ >";
\r
65 revision 2018-02-16 {
\r
66 description "ONF Transport API version 2.0.1
\r
67 This YANG module has been generated from the TAPI UML Model using the IISOMI-Eagle xmi2yang mapping tool.
\r
68 Changes in this revision: <https://urldefense.com/v3/__https://github.com/OpenNetworkingFoundation/TAPI/blob/develop/CHANGE_LOG/change-log.2.0.1.md__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur__C1vuym$ >";
\r
69 reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 6020, RFC 6087 and ONF TAPI UML model
\r
70 <https://urldefense.com/v3/__https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.0.1/UML__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_5DYNwzZ$ >";
\r
72 revision 2018-01-02 {
\r
73 description "ONF Transport API version 2.0.0
\r
74 This YANG module has been generated from the TAPI UML Model using the IISOMI-Eagle xmi2yang mapping tool.
\r
75 Changes in this revision: <https://urldefense.com/v3/__https://github.com/OpenNetworkingFoundation/TAPI/blob/develop/CHANGE_LOG/change-log.2.0.0.md__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_1xZSBRA$ >";
\r
76 reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 6020, RFC 6087 and ONF TAPI UML model
\r
77 <https://urldefense.com/v3/__https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.0.0/UML__;!!OSsGDw!bx-l35NqfQHpJ8R_DmXfi2NX2ll5dMl9VbK5aS_m3ZShiVoz74Ur_xt-GtqY$ >";
\r
79 augment "/tapi-common:context" {
\r
80 container topology-context {
\r
81 uses topology-context;
\r
82 description "Augments the base TAPI Context with TopologyService information";
\r
84 description "Augments the base TAPI Context with TopologyService information";
\r
87 /**************************
\r
88 * definitions of refrences
\r
89 **************************/
\r
90 grouping topology-ref {
\r
91 leaf topology-uuid {
\r
93 path '/tapi-common:context/tapi-topology:topology-context/tapi-topology:topology/tapi-topology:uuid';
\r
103 path '/tapi-common:context/tapi-topology:topology-context/tapi-topology:topology/tapi-topology:link/tapi-topology:uuid';
\r
105 description "none";
\r
107 description "none";
\r
109 grouping node-ref {
\r
113 path '/tapi-common:context/tapi-topology:topology-context/tapi-topology:topology/tapi-topology:node/tapi-topology:uuid';
\r
115 description "none";
\r
117 description "none";
\r
119 grouping node-edge-point-ref {
\r
121 leaf node-edge-point-uuid {
\r
123 path '/tapi-common:context/tapi-topology:topology-context/tapi-topology:topology/tapi-topology:node/tapi-topology:owned-node-edge-point/tapi-topology:uuid';
\r
125 description "none";
\r
127 description "none";
\r
129 grouping node-rule-group-ref {
\r
131 leaf node-rule-group-uuid {
\r
133 path '/tapi-common:context/tapi-topology:topology-context/tapi-topology:topology/tapi-topology:node/tapi-topology:node-rule-group/tapi-topology:uuid';
\r
135 description "none";
\r
137 description "none";
\r
140 /**************************
\r
141 * package object-classes
\r
142 **************************/
\r
144 list node-edge-point {
\r
145 uses node-edge-point-ref;
\r
146 key 'topology-uuid node-uuid node-edge-point-uuid';
\r
149 description "none";
\r
151 leaf-list layer-protocol-name {
\r
152 type tapi-common:layer-protocol-name;
\r
155 description "none";
\r
158 type tapi-common:forwarding-direction;
\r
160 description "The directionality of the Link.
\r
161 Is applicable to simple Links where all LinkEnds are BIDIRECTIONAL (the Link will be BIDIRECTIONAL) or UNIDIRECTIONAL (the Link will be UNIDIRECTIONAL).
\r
162 Is not present in more complex cases.";
\r
164 container resilience-type {
\r
165 uses resilience-type;
\r
166 description "none";
\r
168 uses tapi-common:resource-spec;
\r
169 uses tapi-common:admin-state-pac;
\r
170 uses tapi-common:capacity-pac;
\r
171 uses transfer-cost-pac;
\r
172 uses transfer-integrity-pac;
\r
173 uses transfer-timing-pac;
\r
174 uses risk-parameter-pac;
\r
175 uses validation-pac;
\r
176 uses layer-protocol-transition-pac;
\r
177 description "The Link object class models effective adjacency between two or more ForwardingDomains (FD). ";
\r
180 list owned-node-edge-point {
\r
183 uses node-edge-point;
\r
184 description "none";
\r
186 list aggregated-node-edge-point {
\r
187 uses node-edge-point-ref;
\r
188 key 'topology-uuid node-uuid node-edge-point-uuid';
\r
190 description "none";
\r
192 list node-rule-group {
\r
194 uses node-rule-group;
\r
195 description "none";
\r
197 container encap-topology {
\r
200 description "none";
\r
202 leaf-list layer-protocol-name {
\r
203 type tapi-common:layer-protocol-name;
\r
206 description "none";
\r
208 uses tapi-common:resource-spec;
\r
209 uses tapi-common:admin-state-pac;
\r
210 uses tapi-common:capacity-pac;
\r
211 uses transfer-cost-pac;
\r
212 uses transfer-integrity-pac;
\r
213 uses transfer-timing-pac;
\r
214 description "The ForwardingDomain (FD) object class models the ForwardingDomain topological component which is used to effect forwarding of transport characteristic information and offers the potential to enable forwarding.
\r
215 At the lowest level of recursion, an FD (within a network element (NE)) represents a switch matrix (i.e., a fabric). Note that an NE can encompass multiple switch matrices (FDs). ";
\r
217 grouping topology {
\r
222 description "none";
\r
228 description "none";
\r
230 leaf-list layer-protocol-name {
\r
231 type tapi-common:layer-protocol-name;
\r
234 description "none";
\r
236 uses tapi-common:resource-spec;
\r
237 description "The ForwardingDomain (FD) object class models the ForwardingDomain topological component which is used to effect forwarding of transport characteristic information and offers the potential to enable forwarding.
\r
238 At the lowest level of recursion, an FD (within a network element (NE)) represents a switch matrix (i.e., a fabric). Note that an NE can encompass multiple switch matrices (FDs). ";
\r
240 grouping layer-protocol-transition-pac {
\r
241 leaf-list transitioned-layer-protocol-name {
\r
244 description "Provides the ordered structure of layer protocol transitions encapsulated in the TopologicalEntity. The ordering relates to the LinkPort role.";
\r
246 description "Relevant for a Link that is formed by abstracting one or more LTPs (in a stack) to focus on the flow and deemphasize the protocol transformation.
\r
247 This abstraction is relevant when considering multi-layer routing.
\r
248 The layer protocols of the LTP and the order of their application to the signal is still relevant and need to be accounted for. This is derived from the LTP spec details.
\r
249 This Pac provides the relevant abstractions of the LTPs and provides the necessary association to the LTPs involved.
\r
250 Links that included details in this Pac are often referred to as Transitional Links.";
\r
252 grouping node-edge-point {
\r
253 leaf layer-protocol-name {
\r
254 type tapi-common:layer-protocol-name;
\r
256 description "none";
\r
258 leaf-list supported-cep-layer-protocol-qualifier {
\r
259 type tapi-common:layer-protocol-qualifier;
\r
261 description "none";
\r
263 list aggregated-node-edge-point {
\r
264 uses node-edge-point-ref;
\r
265 key 'topology-uuid node-uuid node-edge-point-uuid';
\r
267 description "none";
\r
269 list mapped-service-interface-point {
\r
270 uses tapi-common:service-interface-point-ref;
\r
271 key 'service-interface-point-uuid';
\r
273 description "NodeEdgePoint mapped to more than ServiceInterfacePoint (slicing/virtualizing) or a ServiceInterfacePoint mapped to more than one NodeEdgePoint (load balancing/Resilience) should be considered experimental";
\r
275 leaf link-port-direction {
\r
276 type tapi-common:port-direction;
\r
278 description "The orientation of defined flow at the LinkEnd.";
\r
280 leaf link-port-role {
\r
281 type tapi-common:port-role;
\r
283 description "Each LinkEnd of the Link has a role (e.g., symmetric, hub, spoke, leaf, root) in the context of the Link with respect to the Link function. ";
\r
285 uses tapi-common:resource-spec;
\r
286 uses tapi-common:admin-state-pac;
\r
287 uses tapi-common:termination-pac;
\r
288 uses tapi-common:capacity-pac;
\r
289 description "The LogicalTerminationPoint (LTP) object class encapsulates the termination and adaptation functions of one or more transport layers.
\r
290 The structure of LTP supports all transport protocols including circuit and packet forms.";
\r
292 grouping risk-parameter-pac {
\r
293 list risk-characteristic {
\r
294 key 'risk-characteristic-name';
\r
297 uses risk-characteristic;
\r
298 description "A list of risk characteristics for consideration in an analysis of shared risk. Each element of the list represents a specific risk consideration.";
\r
300 description "The risk characteristics of a TopologicalEntity come directly from the underlying physical realization.
\r
301 The risk characteristics propagate from the physical realization to the client and from the server layer to the client layer, this propagation may be modified by protection.
\r
302 A TopologicalEntity may suffer degradation or failure as a result of a problem in a part of the underlying realization.
\r
303 The realization can be partitioned into segments which have some relevant common failure modes.
\r
304 There is a risk of failure/degradation of each segment of the underlying realization.
\r
305 Each segment is a part of a larger physical/geographical unit that behaves as one with respect to failure (i.e. a failure will have a high probability of impacting the whole unit (e.g. all cables in the same duct).
\r
306 Disruptions to that larger physical/geographical unit will impact (cause failure/errors to) all TopologicalEntities that use any part of that larger physical/geographical entity.
\r
307 Any TopologicalEntity that uses any part of that larger physical/geographical unit will suffer impact and hence each TopologicalEntity shares risk.
\r
308 The identifier of each physical/geographical unit that is involved in the realization of each segment of a Topological entity can be listed in the RiskParameter_Pac of that TopologicalEntity.
\r
309 A segment has one or more risk characteristic.
\r
310 Shared risk between two TopologicalEntities compromises the integrity of any solution that use one of those TopologicalEntity as a backup for the other.
\r
311 Where two TopologicalEntities have a common risk characteristic they have an elevated probability of failing simultaneously compared to two TopologicalEntities that do not share risk characteristics.";
\r
313 grouping transfer-cost-pac {
\r
314 list cost-characteristic {
\r
318 uses cost-characteristic;
\r
319 description "The list of costs where each cost relates to some aspect of the TopologicalEntity.";
\r
321 description "The cost characteristics of a TopologicalEntity not necessarily correlated to the cost of the underlying physical realization.
\r
322 They may be quite specific to the individual TopologicalEntity e.g. opportunity cost. Relates to layer capacity.
\r
323 There may be many perspectives from which cost may be considered for a particular TopologicalEntity and hence many specific costs and potentially cost algorithms.
\r
324 Using an entity will incur a cost. ";
\r
326 grouping transfer-integrity-pac {
\r
327 leaf error-characteristic {
\r
330 description "Describes the degree to which the signal propagated can be errored.
\r
331 Applies to TDM systems as the errored signal will be propagated and not packet as errored packets will be discarded.";
\r
333 leaf loss-characteristic {
\r
336 description "Describes the acceptable characteristic of lost packets where loss may result from discard due to errors or overflow.
\r
337 Applies to packet systems and not TDM (as for TDM errored signals are propagated unless grossly errored and overflow/underflow turns into timing slips).";
\r
339 leaf repeat-delivery-characteristic {
\r
342 description "Primarily applies to packet systems where a packet may be delivered more than once (in fault recovery for example).
\r
343 It can also apply to TDM where several frames may be received twice due to switching in a system with a large differential propagation delay.";
\r
345 leaf delivery-order-characteristic {
\r
348 description "Describes the degree to which packets will be delivered out of sequence.
\r
349 Does not apply to TDM as the TDM protocols maintain strict order.";
\r
351 leaf unavailable-time-characteristic {
\r
354 description "Describes the duration for which there may be no valid signal propagated.";
\r
356 leaf server-integrity-process-characteristic {
\r
359 description "Describes the effect of any server integrity enhancement process on the characteristics of the TopologicalEntity.";
\r
361 description "Transfer intergrity characteristic covers expected/specified/acceptable characteristic of degradation of the transfered signal.
\r
362 It includes all aspects of possible degradation of signal content as well as any damage of any form to the total TopologicalEntity and to the carried signals.
\r
363 Note that the statement is of total impact to the TopologicalEntity so any partial usage of the TopologicalEntity (e.g. a signal that does not use full capacity) will only suffer its portion of the impact.";
\r
365 grouping transfer-timing-pac {
\r
366 list latency-characteristic {
\r
367 key 'traffic-property-name';
\r
370 uses latency-characteristic;
\r
371 description "The effect on the latency of a queuing process. This only has significant effect for packet based systems and has a complex characteristic.";
\r
373 description "A TopologicalEntity will suffer effects from the underlying physical realization related to the timing of the information passed by the TopologicalEntity.";
\r
375 grouping validation-pac {
\r
376 list validation-mechanism {
\r
377 key 'validation-mechanism';
\r
380 uses validation-mechanism;
\r
381 description "Provides details of the specific validation mechanism(s) used to confirm the presence of an intended topologicalEntity.";
\r
383 description "Validation covers the various adjacenct discovery and reachability verification protocols. Also may cover Information source and degree of integrity.";
\r
385 grouping network-topology-service {
\r
388 key 'topology-uuid';
\r
390 description "none";
\r
392 uses tapi-common:service-spec;
\r
393 description "none";
\r
395 grouping topology-context {
\r
396 container nw-topology-service {
\r
398 uses network-topology-service;
\r
399 description "none";
\r
405 description "none";
\r
407 description "none";
\r
409 grouping inter-rule-group {
\r
415 description "The list of rules of the InterRuleGroup.";
\r
417 list associated-node-rule-group {
\r
418 uses node-rule-group-ref;
\r
419 key 'topology-uuid node-uuid node-rule-group-uuid';
\r
422 description "The NodeRuleGroups that the InterRuleGroup constrains interconnection between.
\r
423 The CEPs of the NEPs of a referenced NodeRuleGroup can interconnect to the CEPs of the NEPs of another referenced NodeRuleGroup constrained by the rules of the InterRuleGroup.";
\r
425 uses tapi-common:resource-spec;
\r
426 uses tapi-common:capacity-pac;
\r
427 uses transfer-cost-pac;
\r
428 uses transfer-timing-pac;
\r
429 uses risk-parameter-pac;
\r
430 description "Rules that apply between groups of NEPs.";
\r
432 grouping node-rule-group {
\r
438 description "The list of rules of the NodeRuleGroup.";
\r
440 list node-edge-point {
\r
441 uses node-edge-point-ref;
\r
442 key 'topology-uuid node-uuid node-edge-point-uuid';
\r
445 description "NEPs and their client CEPs that the rules apply to.";
\r
447 list node-rule-group {
\r
448 uses node-rule-group-ref;
\r
449 key 'topology-uuid node-uuid node-rule-group-uuid';
\r
451 description "NodeRuleGroups may be nested such that finer grained rules may be applied.
\r
452 A nested rule group should have a subset of the NEPs of the superior rule group.";
\r
454 list inter-rule-group {
\r
456 uses inter-rule-group;
\r
458 description "Nested NodeRuleGroups may have InterRuleGroups. The Superior NodeRuleGroup contains the nested NodeRuleGroups and their associated InterRuleGroups.
\r
459 This is equivalent to the Node-Topology hierarchy.";
\r
461 uses tapi-common:resource-spec;
\r
462 uses tapi-common:capacity-pac;
\r
463 uses transfer-cost-pac;
\r
464 uses transfer-timing-pac;
\r
465 uses risk-parameter-pac;
\r
466 description "Rules that apply to a group of NEPs.
\r
473 description "The focus of the rule.";
\r
475 leaf forwarding-rule {
\r
476 type forwarding-rule;
\r
478 description "Rule that restricts the creation/deletion of a Connection between points in the node rule group or related by the inter rule group between node rule groups.";
\r
480 leaf override-priority {
\r
483 description "The overridePriority allows for one rule in a rule group to override another.
\r
484 Priority n rules override priority n+1 rules.
\r
485 Rules of the same priority override as follows (n overrides n+1):
\r
490 Within a rule the flexibility rules (signal, port role...) override as follows (n overriedes n+1):
\r
494 Where there are two or more 'Same' rules, they will form an intersection where all must be met.
\r
497 leaf-list cep-direction {
\r
498 type tapi-common:port-direction;
\r
500 description "cep direction is a list of port directions that the rule applies to.
\r
501 No entry means all cep directions.";
\r
503 list cep-port-role {
\r
504 uses port-role-rule;
\r
506 description "Indicates the port role to which the rule applies.
\r
507 The port role is interpreted in the context of the connection type which is identified by the connection spec.
\r
508 The port role is not meaningful in the absence of a connection spec reference.
\r
509 If a node rule group carries a port role, that role applies also to the associated inter rule where the combination of the roles in the node rule groups at the ends of the inter group rule define the connection orientation.
\r
510 For example a root-and-leaf connection may be used in a node where a node rule group collects one set of NEPs has the port role 'root' and another node rule group collects another set of NEPs has the port role 'leaf' where these are joined by an inter rule group. This combination specifies an allowed orientation of the root-and-leaf connection.
\r
511 No port role statement means all port roles are allowed.";
\r
513 list connection-spec-reference {
\r
515 uses connection-spec-reference;
\r
516 description "Identifies the type of connection that the rule applies to.
\r
517 If the attribute is not present then the rule applies to all types of connection supported by the device.";
\r
519 leaf-list layer-protocol-qualifier {
\r
520 type tapi-common:layer-protocol-qualifier;
\r
522 description "Qualifies a rule for a particular layerProtocol identifying the qualifiers that the rule apples to.
\r
523 If the attribute is not present then the rule applies to all relevant qualifiers of the layer protocol of the parent entity.";
\r
525 container signal-property {
\r
527 uses signal-property-rule;
\r
528 description "The rule only applies to signals with the properties listed.
\r
529 If the attribute is not present then the rule applies to all signals.";
\r
531 leaf-list complex-rule {
\r
534 description "Allows for more complex rules where the basic rule system is not sufficient.";
\r
536 uses tapi-common:local-class;
\r
537 description "Single complex rule statememt.
\r
538 A Node with no rule group has no restrictions and is essentially May/Any
\r
539 A node rule group constrain the CEP connectability in the Node.
\r
540 A connection from a NEP must abide by all rules that relate to that NEP
\r
541 Rules that are for a particular layerProtocolQualifier, connectionSpecReference, cepPortRole and cepDirection combination must be abided by in combination as dictated by overridePriority.
\r
543 - connectionSpecReference does not have any rule statements then it is not supported and connections of that type are not possible within the rule group.
\r
544 - cepPortRole of a particular connectionSpecReference does not have any rule statements then it is not supported and connections of that connectionSpecReference (type) cannot have that cepPortRole for CEPs from NEPs in that rule group.
\r
545 - cepDirection for a particular connectionSpecReference does not have any rule statements then it is not supported and connections of that connectionSpecReference (type) cannot have that cepPortDirection for CEPs from NEPs in that rule group.
\r
546 Rules that are for different layerProtocolQualifiers or connectionSpecReferences are independent and provide options for connection in the rule group.
\r
547 Some rules may apply to multiple connectionSpecReferences and all cepPortRoles and all cepDirections.";
\r
550 /**************************
\r
551 * package type-definitions
\r
552 **************************/
\r
553 identity PORT_ROLE_RULE_OPTION {
\r
554 description "none";
\r
556 identity PORT_ROLE_RULE_OPTION_SAME_ROLE {
\r
557 base PORT_ROLE_RULE_OPTION;
\r
558 description "The ports of the connection to which the rule applies must have the same role from the list in port role.";
\r
560 identity PORT_ROLE_RULE_OPTION_DIFFERENT_ROLE {
\r
561 base PORT_ROLE_RULE_OPTION;
\r
562 description "The ports of the connection to which the rule applies must have different roles from the list in port role.";
\r
564 identity PORT_ROLE_RULE_OPTION_ANY_ROLE {
\r
565 base PORT_ROLE_RULE_OPTION;
\r
566 description "The ports of the connection to which the rule applies may take any identified role.";
\r
568 identity PORT_ROLE_RULE_OPTION_NOT_ROLE {
\r
569 base PORT_ROLE_RULE_OPTION;
\r
570 description "The ports of the connection to which the rule applies must not have any of the listed roles.";
\r
572 identity SIGNAL_PROPERTY_VALUE_RULE {
\r
573 description "none";
\r
575 identity SIGNAL_PROPERTY_VALUE_RULE_SAME_VALUE {
\r
576 base SIGNAL_PROPERTY_VALUE_RULE;
\r
577 description "The signal property of the cep to which the rule applies must have the same value from the identied list.";
\r
579 identity SIGNAL_PROPERTY_VALUE_RULE_ANY_VALUE {
\r
580 base SIGNAL_PROPERTY_VALUE_RULE;
\r
581 description "The signal property of the cep to which the rule applies may take any identified value.";
\r
583 identity SIGNAL_PROPERTY_VALUE_RULE_DIFFERENT_VALUE {
\r
584 base SIGNAL_PROPERTY_VALUE_RULE;
\r
585 description "The signal property of the cep to which the rule applies each must have different values from the identified list.";
\r
587 identity SIGNAL_PROPERTY_VALUE_RULE_NOT_VALUE {
\r
588 base SIGNAL_PROPERTY_VALUE_RULE;
\r
589 description "The signal property of the cep to which the rule applies must not have any of the identified values.";
\r
591 grouping cost-characteristic {
\r
594 description "The cost characteristic will related to some aspect of the TopologicalEntity (e.g. $ cost, routing weight). This aspect will be conveyed by the costName.";
\r
598 description "The specific cost.";
\r
600 leaf cost-algorithm {
\r
602 description "The cost may vary based upon some properties of the TopologicalEntity. The rules for the variation are conveyed by the costAlgorithm.";
\r
604 description "The information for a particular cost characteristic.";
\r
606 grouping latency-characteristic {
\r
607 leaf traffic-property-name {
\r
609 description "The identifier of the specific traffic property to which the queuing latency applies.";
\r
611 leaf fixed-latency-characteristic {
\r
614 description "A TopologicalEntity suffers delay caused by the realization of the servers (e.g. distance related; FEC encoding etc.) along with some client specific processing. This is the total average latency effect of the TopologicalEntity";
\r
616 leaf queing-latency-characteristic {
\r
618 description "The specific queuing latency for the traffic property.";
\r
620 leaf jitter-characteristic {
\r
623 description "High frequency deviation from true periodicity of a signal and therefore a small high rate of change of transfer latency.
\r
624 Applies to TDM systems (and not packet).";
\r
626 leaf wander-characteristic {
\r
629 description "Low frequency deviation from true periodicity of a signal and therefore a small low rate of change of transfer latency.
\r
630 Applies to TDM systems (and not packet).";
\r
632 description "Provides information on latency characteristic for a particular stated trafficProperty.";
\r
634 grouping risk-characteristic {
\r
635 leaf risk-characteristic-name {
\r
637 description "The name of the risk characteristic. The characteristic may be related to a specific degree of closeness.
\r
638 For example a particular characteristic may apply to failures that are localized (e.g. to one side of a road) where as another characteristic may relate to failures that have a broader impact (e.g. both sides of a road that crosses a bridge).
\r
639 Depending upon the importance of the traffic being routed different risk characteristics will be evaluated.";
\r
641 leaf-list risk-identifier-list {
\r
644 description "A list of the identifiers of each physical/geographic unit (with the specific risk characteristic) that is related to a segment of the TopologicalEntity.";
\r
646 description "The information for a particular risk characteristic where there is a list of risk identifiers related to that characteristic.";
\r
648 grouping validation-mechanism {
\r
649 leaf validation-mechanism {
\r
651 description "Name of mechanism used to validate adjacency";
\r
653 leaf layer-protocol-adjacency-validated {
\r
655 description "State of validatiion";
\r
657 leaf validation-robustness {
\r
659 description "Quality of validation (i.e. how likely is the stated validation to be invalid)";
\r
661 description "Identifies the validation mechanism and describes the characteristics of that mechanism";
\r
663 typedef forwarding-rule {
\r
665 enum MAY_FORWARD_ACROSS_GROUP {
\r
666 description "NEPs referenced by the node rule group (or indirectly by the inter rule group between node rule groups) may have connections created between them unless some other rule overrides this.
\r
667 For an inter rule group points in a node rule group at one end of the inter rule group may be connected to points in an node rule group at an other end of the inter rule group.";
\r
669 enum MUST_FORWARD_ACROSS_GROUP {
\r
670 description "NEPs referenced by the node rule group (or indirectly by the inter rule group between node rule groups) MUST have connections created between them unless some other rule overrides this.
\r
671 For an inter rule group points in a node rule group at one end of the inter rule group MUST be connected to points in an node rule group at an other end of the inter rule group.";
\r
673 enum CANNOT_FORWARD_ACROSS_GROUP {
\r
674 description "NEPs referenced by the node rule group (or indirectly by the inter rule group between node rule groups) MUST NOT have connections created between them.
\r
675 For an inter rule group points in a node rule group at one end of the inter rule group MUST NOT be connected to points in an node rule group at an other end of the inter rule group.";
\r
677 enum NO_STATEMENT_ON_FORWARDING {
\r
678 description "The rule group makes no statement on forwarding.";
\r
680 enum INTER_CONNECTION_CONTENTION {
\r
681 description "Connections to NEPs in the rule group contend for resources based upon a constraint of some signal property.
\r
682 For example, each connection to a NEP in the group must use a different value of the signal property from all other connections to NEPs in the rule group.
\r
683 For example, each connection to a NEP in the group must use a same value of the signal property as all other connections to NEPs in the rule group. In this case the first connection created in the rule group sets the value and the group constraint is freed when the last connection is deleted.";
\r
686 description "Rule that restricts the creation/deletion of an connection between points referenced by rule groups.";
\r
688 typedef rule-type {
\r
691 description "The rule applies to the creation of connections.";
\r
694 description "The rule applies to capacity limitations.";
\r
697 description "The rule applies to the cost of the creation of connections.";
\r
700 description "The rule applies to timing constraints across the group.";
\r
703 description "The rule applies to risk considerations across the group so as to express shared risk.";
\r
706 description "The rule is simply for grouping related to other rules.";
\r
709 description "The focus of the rule.";
\r
711 grouping resilience-type {
\r
712 leaf restoration-policy {
\r
713 type restoration-policy;
\r
714 description "none";
\r
716 leaf protection-type {
\r
717 type protection-type;
\r
718 description "none";
\r
720 description "none";
\r
722 typedef restoration-policy {
\r
724 enum PER_DOMAIN_RESTORATION {
\r
725 description "none";
\r
727 enum END_TO_END_RESTORATION {
\r
728 description "none";
\r
731 description "none";
\r
734 description "none";
\r
736 typedef protection-type {
\r
738 enum NO_PROTECTON {
\r
739 description "none";
\r
741 enum ONE_PLUS_ONE_PROTECTION {
\r
742 description "none";
\r
744 enum ONE_PLUS_ONE_PROTECTION_WITH_DYNAMIC_RESTORATION {
\r
745 description "none";
\r
747 enum PERMANENT_ONE_PLUS_ONE_PROTECTION {
\r
748 description "none";
\r
750 enum ONE_FOR_ONE_PROTECTION {
\r
751 description "none";
\r
753 enum DYNAMIC_RESTORATION {
\r
754 description "none";
\r
756 enum PRE_COMPUTED_RESTORATION {
\r
757 description "none";
\r
759 enum ONE_PLUS_ONE_PROTECTION_WITH_PRE_COMPUTED_RESTORATION {
\r
760 description "none";
\r
763 description "none";
\r
765 grouping connection-spec-reference {
\r
766 leaf connection-spec-name {
\r
769 description "The name of the connection type spec.
\r
770 This can be used as a reference to a paper document where full formal machine interpretable specs are not supported.";
\r
772 leaf connection-spec-id {
\r
773 type tapi-common:uuid;
\r
775 description "The reference to a formal spec.
\r
776 This reference need not be provided (e.g., where there is no formal machine interpretable spec for the type of connection).";
\r
778 description "The definition of the type of connection.
\r
779 This definition will explain the flows in the connections and how they relate to the port roles.";
\r
781 typedef port-role {
\r
783 description "The role of a port in the context of the connection spec referenced in the rule.";
\r
785 grouping port-role-rule {
\r
786 leaf-list port-role {
\r
789 description "The role(s) of the port(s) considered in the rule.";
\r
791 leaf-list port-role-rule {
\r
792 type port-role-rule-option;
\r
794 description "Where the rule references more than one port role or where there are rule intersections either as a result of overlay of rules or inter rule group usage indicates role matching criteria for a connection following the rules.
\r
795 For example if two port roles, 'a' and 'b', are listed and the port role rule is 'different', this means that a connection connecting points in that group must have port roles that are different for each CEP in that group.
\r
796 In the example if a connection can have n ports of role 'a' and m ports of role 'b' then a maximum of two ports can be drawn from the NEPs of the group and where there are two, one must be role 'a' and one must be role 'b'.";
\r
798 description "Constrains which port roles the rule applies to.";
\r
800 typedef port-role-rule-option {
\r
802 base PORT_ROLE_RULE_OPTION;
\r
804 description "Indicates how to interpret the port role list.";
\r
806 grouping signal-property-rule {
\r
807 leaf signal-property-name {
\r
810 description "The name of the signal property to which the rule applies.";
\r
812 leaf signal-property-value-rule {
\r
813 type signal-property-value-rule;
\r
815 description "Indicates how the signal properties should be accounted for.";
\r
817 leaf-list applicable-signal-value {
\r
820 description "Specific values of the signal property to which the rule applies.";
\r
822 leaf number-of-signal-values {
\r
825 description "The number of instances of this specific property that can be supported by the group.";
\r
827 description "Rule related to an identified signal property.";
\r
829 typedef signal-property-value-rule {
\r
831 base SIGNAL_PROPERTY_VALUE_RULE;
\r
833 description "Indicates how to interpret the signal property value rule.";
\r
836 /**************************
\r
837 * package interfaces
\r
838 **************************/
\r
839 rpc get-topology-details {
\r
840 description "none";
\r
842 leaf topology-id-or-name {
\r
844 description "none";
\r
848 container topology {
\r
850 description "none";
\r
854 rpc get-node-details {
\r
855 description "none";
\r
857 leaf topology-id-or-name {
\r
859 description "none";
\r
861 leaf node-id-or-name {
\r
863 description "none";
\r
869 description "none";
\r
873 rpc get-node-edge-point-details {
\r
874 description "none";
\r
876 leaf topology-id-or-name {
\r
878 description "none";
\r
880 leaf node-id-or-name {
\r
882 description "none";
\r
884 leaf ep-id-or-name {
\r
886 description "none";
\r
890 container node-edge-point {
\r
891 uses node-edge-point;
\r
892 description "none";
\r
896 rpc get-link-details {
\r
897 description "none";
\r
899 leaf topology-id-or-name {
\r
901 description "none";
\r
903 leaf link-id-or-name {
\r
905 description "none";
\r
911 description "none";
\r
915 rpc get-topology-list {
\r
916 description "none";
\r
921 description "none";
\r
Code Review / sim / o1-interface.git / blob