2 namespace "urn:onf:otcc:yang:tapi-common";
\r
4 organization "ONF OTCC (Open Transport Configuration & Control) Project";
\r
6 Project Web: <https://wiki.opennetworking.org/display/OTCC/TAPI>
\r
7 Project List: <mailto:transport-api@opennetworking.org>
\r
8 Editor: Karthik Sethuraman <mailto:karthik.sethuraman@necam.com>
\r
9 Andrea Mazzin <mailto:andrea.mazzini@nokia.com>
\r
10 Arturo Mayoral <mailto:arturo.mayoral@telefonica.com>
\r
11 Nigel Davis <mailto:ndavis@ciena.com>";
\r
13 This module contains TAPI Common Model definitions.
\r
14 Source: TapiCommon.uml
\r
15 - The TAPI YANG models included in this TAPI release are a *normative* part of the TAPI SDK.
\r
16 - The YANG specifications have been generated from the corresponding UML model using the [ONF EAGLE UML2YANG mapping tool]
\r
17 <https://github.com/OpenNetworkingFoundation/EagleUmlYang>
\r
18 and further edited manually to comply with the [ONF IISOMI UML2YANG mapping guidelines]
\r
19 <https://wiki.opennetworking.org/display/OIMT/UML+-+YANG+Guidelines>
\r
20 - Status of YANG model artifacts can be determined by referring to the corresponding UML artifacts.
\r
21 As described in the UML models, some artifacts are considered *experimental*, and thus the corresponding YANG artifacts.
\r
22 - The ONF TAPI release process does not guarantee backward compatibility of YANG models across major versions of TAPI releases.
\r
23 The YANG model backward compatibility criteria are outlined in section 11 of <https://tools.ietf.org/html/rfc7950>.
\r
24 YANG models included in this release may not be backward compatible with previous TAPI releases.
\r
25 Copyright (c) 2018 Open Networking Foundation (ONF). All rights reserved.
\r
26 License: This module is distributed under the Apache License 2.0.";
\r
27 revision 2020-04-23 {
\r
28 description "ONF Transport API version 2.1.3.
\r
29 Changes included in this TAPI release (v2.1.3) are listed in
\r
30 <https://github.com/OpenNetworkingFoundation/TAPI/blob/develop_v2_1/CHANGE_LOG/change-log.2.1.3.md>";
\r
31 reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 7950, RFC 6087 and ONF TAPI UML model
\r
32 <https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.0/UML>";
\r
34 revision 2019-07-16 {
\r
35 description "ONF Transport API version 2.1.2.
\r
36 Changes included in this TAPI release (v2.1.2) are listed in
\r
37 <https://github.com/OpenNetworkingFoundation/TAPI/blob/develop_v2_1/CHANGE_LOG/change-log.2.1.2.md>";
\r
38 reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 7950, RFC 6087 and ONF TAPI UML model
\r
39 <https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.0/UML>";
\r
41 revision 2018-12-10 {
\r
42 description "ONF Transport API version 2.1.1.
\r
43 Changes included in this TAPI release (v2.1.1) are listed in
\r
44 <https://github.com/OpenNetworkingFoundation/TAPI/blob/develop/CHANGE_LOG/change-log.2.1.1.md>";
\r
45 reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 7950, RFC 6087 and ONF TAPI UML model
\r
46 <https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.0/UML>";
\r
48 revision 2018-10-16 {
\r
49 description "ONF Transport API version 2.1.0.
\r
50 Changes included in this TAPI release (v2.1.0) are listed in
\r
51 <https://github.com/OpenNetworkingFoundation/TAPI/blob/develop/CHANGE_LOG/change-log.2.1.0.md>";
\r
52 reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 7950, RFC 6087 and ONF TAPI UML model
\r
53 <https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.0/UML>";
\r
55 revision 2018-03-07 {
\r
56 description "ONF Transport API version 2.0.2
\r
57 This YANG module has been generated from the TAPI UML Model using the IISOMI-Eagle xmi2yang mapping tool.
\r
58 Changes in this revision: <https://github.com/OpenNetworkingFoundation/TAPI/blob/develop/CHANGE_LOG/change-log.2.0.2.md>";
\r
59 reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 6020, RFC 6087 and ONF TAPI UML model
\r
60 <https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.0.2/UML>";
\r
62 revision 2018-02-16 {
\r
63 description "ONF Transport API version 2.0.1
\r
64 This YANG module has been generated from the TAPI UML Model using the IISOMI-Eagle xmi2yang mapping tool.
\r
65 Changes in this revision: <https://github.com/OpenNetworkingFoundation/TAPI/blob/develop/CHANGE_LOG/change-log.2.0.1.md>";
\r
66 reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 6020, RFC 6087 and ONF TAPI UML model
\r
67 <https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.0.1/UML>";
\r
69 revision 2018-01-02 {
\r
70 description "ONF Transport API version 2.0.0
\r
71 This YANG module has been generated from the TAPI UML Model using the IISOMI-Eagle xmi2yang mapping tool.
\r
72 Changes in this revision: <https://github.com/OpenNetworkingFoundation/TAPI/blob/develop/CHANGE_LOG/change-log.2.0.0.md>";
\r
73 reference "ONF-TR-527, ONF-TR-512, ONF-TR-531, RFC 6020, RFC 6087 and ONF TAPI UML model
\r
74 <https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.0.0/UML>";
\r
76 /**************************
\r
77 * definitions of refrences
\r
78 **************************/
\r
79 grouping service-interface-point-ref {
\r
80 leaf service-interface-point-uuid {
\r
82 path '/tapi-common:context/tapi-common:service-interface-point/tapi-common:uuid';
\r
89 /**************************
\r
90 * package object-classes
\r
91 **************************/
\r
92 grouping admin-state-pac {
\r
93 leaf administrative-state {
\r
94 type administrative-state;
\r
97 leaf operational-state {
\r
98 type operational-state;
\r
100 description "none";
\r
102 leaf lifecycle-state {
\r
103 type lifecycle-state;
\r
105 description "none";
\r
107 description "Provides state attributes that are applicable to an entity that can be administered. Such an entity also has operational and lifecycle aspects.";
\r
109 grouping global-class {
\r
112 description "UUID: An identifier that is universally unique within an identifier space, where the identifier space is itself globally unique, and immutable. An UUID carries no semantics with respect to the purpose or state of the entity.
\r
113 UUID here uses string representation as defined in RFC 4122. The canonical representation uses lowercase characters.
\r
114 Pattern: [0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-' + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}
\r
115 Example of a UUID in string representation: f81d4fae-7dec-11d0-a765-00a0c91e6bf6";
\r
119 uses name-and-value;
\r
120 description "List of names. A property of an entity with a value that is unique in some namespace but may change during the life of the entity. A name carries no semantics with respect to the purpose of the entity.";
\r
122 description "The TAPI GlobalComponent serves as the super class for all TAPI entities that can be directly retrieved by their ID. As such, these are first class entities and their ID is expected to be globally unique. ";
\r
124 grouping lifecycle-state-pac {
\r
125 leaf lifecycle-state {
\r
126 type lifecycle-state;
\r
128 description "none";
\r
130 description "Provides state attributes for an entity that has lifeccycle aspects only.";
\r
132 grouping local-class {
\r
135 description "none";
\r
139 uses name-and-value;
\r
140 description "List of names. A property of an entity with a value that is unique in some namespace but may change during the life of the entity. A name carries no semantics with respect to the purpose of the entity.";
\r
142 description "The TAPI GlobalComponent serves as the super class for all TAPI entities that can be directly retrieved by their ID. As such, these are first class entities and their ID is expected to be globally unique. ";
\r
144 grouping operational-state-pac {
\r
145 leaf operational-state {
\r
146 type operational-state;
\r
148 description "none";
\r
150 leaf lifecycle-state {
\r
151 type lifecycle-state;
\r
153 description "none";
\r
155 description "Provides state attributes that are applicable to an entity that reflects operational aspects. Such an entity is expected to also have lifecycle aspects.";
\r
157 container context {
\r
159 presence "Root container for all TAPI interaction";
\r
160 description "none";
\r
162 grouping tapi-context {
\r
163 list service-interface-point {
\r
165 uses service-interface-point;
\r
166 description "none";
\r
169 description "The Network Control Domain (NCD) object class represents the scope of control that a particular SDN controller has with respect to a particular network, (i.e., encompassing a designated set of interconnected (virtual) network elements).";
\r
171 grouping resource-spec {
\r
173 description "none";
\r
175 grouping service-spec {
\r
177 description "none";
\r
179 grouping service-interface-point {
\r
180 leaf layer-protocol-name {
\r
181 type layer-protocol-name;
\r
183 description "Usage of layerProtocolName [>1] in the ServiceInterfacePoint should be considered experimental";
\r
185 leaf-list supported-layer-protocol-qualifier {
\r
186 type layer-protocol-qualifier;
\r
189 description "none";
\r
192 type port-direction;
\r
193 description "If direction attribute is missing the SIP instance is to be intended as 'BIDIRECTIONAL'";
\r
195 uses resource-spec;
\r
196 uses admin-state-pac;
\r
198 description "The LogicalTerminationPoint (LTP) object class encapsulates the termination and adaptation functions of one or more transport layers.
\r
199 The structure of LTP supports all transport protocols including circuit and packet forms.";
\r
201 grouping capacity-pac {
\r
202 container total-potential-capacity {
\r
205 description "An optimistic view of the capacity of the TopologicalEntity assuming that any shared capacity is available to be taken.";
\r
207 container available-capacity {
\r
210 description "Capacity available to be assigned.";
\r
212 description "The TopologicalEntity derives capacity from the underlying realization.
\r
213 A TopologicalEntity may be an abstraction and virtualization of a subset of the underlying capability offered in a view or may be directly reflecting the underlying realization.
\r
214 A TopologicalEntity may be directly used in the view or may be assigned to another view for use.
\r
215 The clients supported by a multi-layer TopologicalEntity may interact such that the resources used by one client may impact those available to another. This is derived from the LTP spec details.
\r
216 Represents the capacity available to user (client) along with client interaction and usage.
\r
217 A TopologicalEntity may reflect one or more client protocols and one or more members for each profile.";
\r
219 grouping termination-pac {
\r
220 leaf termination-direction {
\r
221 type termination-direction;
\r
223 description "The overall directionality of the LP.
\r
224 - A BIDIRECTIONAL LP will have some SINK and/or SOURCE flowss.
\r
225 - A SINK LP can only contain elements with SINK flows or CONTRA_DIRECTION_SOURCE flows
\r
226 - A SOURCE LP can only contain SOURCE flows or CONTRA_DIRECTION_SINK flows";
\r
228 leaf termination-state {
\r
229 type termination-state;
\r
231 description "Indicates whether the layer is terminated and if so how.";
\r
233 description "Each transport layer is represented by a LayerProtocol (LP) instance. The LayerProtocol instances it can be used for controlling termination and monitoring functionality.
\r
234 It can also be used for controlling the adaptation (i.e. encapsulation and/or multiplexing of client signal), tandem connection monitoring, traffic conditioning and/or shaping functionality at an intermediate point along a connection.
\r
235 Where the client – server relationship is fixed 1:1 and immutable, the layers can be encapsulated in a single LTP instance. Where the is a n:1 relationship between client and server, the layers must be split over two separate instances of LTP. ";
\r
238 /**************************
\r
239 * package type-definitions
\r
240 **************************/
\r
241 identity LAYER_PROTOCOL_QUALIFIER {
\r
242 description "none";
\r
244 identity LAYER_PROTOCOL_QUALIFIER_UNSPECIFIED {
\r
245 base LAYER_PROTOCOL_QUALIFIER;
\r
246 description "none";
\r
248 typedef administrative-state {
\r
251 description "Users are administratively prohibited from making use of the resource.";
\r
254 description "Users are allowed to use the resource";
\r
257 description "The possible values of the administrativeState.";
\r
259 typedef date-and-time {
\r
261 description "This primitive type defines the date and time according to the following structure:
\r
262 yyyyMMddhhmmss.s[Z|{+|-}HHMm] where:
\r
263 yyyy 0000..9999 year
\r
269 s .0...9 tenth of second (set to .0 if EMS or NE cannot support this granularity)
\r
270 Z Z indicates UTC (rather than local time)
\r
271 {+|-} + or - delta from UTC
\r
272 HH 00..23 time zone difference in hours
\r
273 Mm 00..59 time zone difference in minutes.";
\r
275 typedef directive-value {
\r
278 description "none";
\r
281 description "none";
\r
284 description "none";
\r
287 description "none";
\r
290 description "none";
\r
293 description "none";
\r
295 typedef forwarding-direction {
\r
297 enum BIDIRECTIONAL {
\r
298 description "The Fowarding entity supports both BIDIRECTIONAL flows at all Ports (i.e. all Ports have both an INPUT flow and an OUTPUT flow defined)";
\r
300 enum UNIDIRECTIONAL {
\r
301 description "The Forwarding entity has Ports that are either INPUT or OUTPUT. It has no BIDIRECTIONAL Ports.";
\r
303 enum UNDEFINED_OR_UNKNOWN {
\r
304 description "Not a normal state. The system is unable to determine the correct value.";
\r
307 description "The directionality of a Forwarding entity.";
\r
309 typedef layer-protocol-name {
\r
312 description "Models the ODU layer as per ITU-T G.872";
\r
315 description "Models the ETH layer as per ITU-T G.8010";
\r
318 description "Models a Digital Signal of an unspecified rate. This value can be used when the intent is to respresent an generic digital layer signal without making any statement on its format or overhead (processing) capabilities.";
\r
320 enum PHOTONIC_MEDIA {
\r
321 description "Models the OCH, OTSi, OTSiA, OTSiG, OMS, OTS and Media channels as per ITU-T G.872 (2017) version 4";
\r
324 description "Provides a controlled list of layer protocol names and indicates the naming authority.
\r
325 Note that it is expected that attributes will be added to this structure to convey the naming authority name, the name of the layer protocol using a human readable string and any particular standard reference.
\r
326 Layer protocol names include:
\r
327 - Layer 1 (L1): OTU, ODU
\r
328 - Layer 2 (L2): Carrier Grade Ethernet (ETY, ETH), MPLS-TP (MT)
\r
331 typedef lifecycle-state {
\r
334 description "The resource is planned but is not present in the network.";
\r
336 enum POTENTIAL_AVAILABLE {
\r
337 description "The supporting resources are present in the network but are shared with other clients; or require further configuration before they can be used; or both.
\r
338 o When a potential resource is configured and allocated to a client it is moved to the installed state for that client.
\r
339 o If the potential resource has been consumed (e.g. allocated to another client) it is moved to the planned state for all other clients.";
\r
341 enum POTENTIAL_BUSY {
\r
342 description "The supporting resources are present in the network but are shared with other clients; or require further configuration before they can be used; or both.
\r
343 o When a potential resource is configured and allocated to a client it is moved to the installed state for that client.
\r
344 o If the potential resource has been consumed (e.g. allocated to another client) it is moved to the planned state for all other clients.";
\r
347 description "The resource is present in the network and is capable of providing the service expected.";
\r
349 enum PENDING_REMOVAL {
\r
350 description "The resource has been marked for removal";
\r
353 description "The possible values of the lifecycleState.";
\r
355 grouping name-and-value {
\r
358 description "The name of the value. The value need not have a name.";
\r
362 description "The value";
\r
364 description "A scoped name-value pair";
\r
366 typedef operational-state {
\r
369 description "The resource is unable to meet the SLA of the user of the resource. If no (explicit) SLA is defined the resource is disabled if it is totally inoperable and unable to provide service to the user.";
\r
372 description "The resource is partially or fully operable and available for use";
\r
375 description "The possible values of the operationalState.";
\r
377 typedef port-direction {
\r
379 enum BIDIRECTIONAL {
\r
380 description "The Port has both an INPUT flow and an OUTPUT flow defined.";
\r
383 description "The Port only has definition for a flow into the Forwarding entity, (i.e. an ingress flow of the Link or Connection, hence egress flow of NEP or CEP, CSEP etc.)";
\r
386 description "The Port only has definition for a flow out of the Forwarding entity ((i.e. an egress flow of the Link or Connection, hence ingress flow of NEP or CEP, CSEP etc.)";
\r
388 enum UNIDENTIFIED_OR_UNKNOWN {
\r
389 description "Not a normal state. The system is unable to determine the correct value.";
\r
392 description "The orientation of flow at the Port of a Forwarding entity";
\r
394 typedef port-role {
\r
397 description "none";
\r
400 description "none";
\r
403 description "none";
\r
406 description "none";
\r
409 description "none";
\r
412 description "The role of an end in the context of the function of the forwarding entity that it bounds";
\r
414 typedef termination-direction {
\r
416 enum BIDIRECTIONAL {
\r
417 description "A Termination with both SINK and SOURCE flows.";
\r
420 description "The flow is up the layer stack from the server side to the client side.
\r
421 Considering an example of a Termination function within the termination entity, a SINK flow:
\r
422 - will arrive at at the base of the termination function (the server side) where it is essentially at an INPUT to the termination component
\r
423 - then will be decoded and deconstructed
\r
424 - then relevant parts of the flow will be sent out of the termination function (the client side) where it is essentially at an OUTPUT from the termination component
\r
425 A SINK termination is one that only supports a SINK flow.
\r
426 A SINK termiation can be bound to an OUTPUT Port of a Forwarding entity";
\r
429 description "The flow is down the layer stack from the server side to the client side.
\r
430 Considering an example of a Termination function within the termination entity, a SOURCE flow:
\r
431 - will arrive at at the top of the termination function (the client side) where it is essentially at an INPUT to the termination component
\r
432 - then will be assembled with various overheads etc and will be coded
\r
433 - then coded form of the assembly of flow will be sent out of the termination function (the server side) where it is essentially at an OUTPUT from the termination component
\r
434 A SOURCE termination is one that only supports a SOURCE flow.
\r
435 A SOURCE termiation can be bound to an INPUT Port of a Forwarding entity";
\r
437 enum UNDEFINED_OR_UNKNOWN {
\r
438 description "Not a normal state. The system is unable to determine the correct value.";
\r
441 description "The directionality of a termination entity";
\r
443 typedef termination-state {
\r
445 enum LP_CAN_NEVER_TERMINATE {
\r
446 description "A non-flexible case that can never be terminated.";
\r
448 enum LT_NOT_TERMINATED {
\r
449 description "A flexible termination that can terminate but is currently not terminated.";
\r
451 enum TERMINATED_SERVER_TO_CLIENT_FLOW {
\r
452 description "A flexible termination that is currently terminated for server to client flow only.";
\r
454 enum TERMINATED_CLIENT_TO_SERVER_FLOW {
\r
455 description "A flexible termination that is currently terminated for client to server flow only.";
\r
457 enum TERMINATED_BIDIRECTIONAL {
\r
458 description "A flexible termination that is currently terminated in both directions of flow.";
\r
460 enum LT_PERMENANTLY_TERMINATED {
\r
461 description "A non-flexible termination that is always terminated (in both directions of flow for a bidirectional case and in the one direction of flow for both unidirectional cases).";
\r
463 enum TERMINATION_STATE_UNKNOWN {
\r
464 description "There TerminationState cannot be determined.";
\r
467 description "Provides support for the range of behaviours and specific states that an LP can take with respect to termination of the signal.
\r
468 Indicates to what degree the LayerTermination is terminated.";
\r
472 description "The univeral ID value where the mechanism for generation is defned by some authority not directly referenced in the structure.
\r
473 UUID here uses string representation as defined in RFC 4122. The canonical representation uses lowercase characters.
\r
474 Pattern: [0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-' + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}
\r
475 Example of a UUID in string representation: f81d4fae-7dec-11d0-a765-00a0c91e6bf6";
\r
477 grouping capacity {
\r
478 container total-size {
\r
479 uses capacity-value;
\r
480 description "Total capacity of the TopologicalEntity in MB/s. In case of bandwidthProfile, this is expected to same as the committedInformationRate.";
\r
482 container bandwidth-profile {
\r
483 uses bandwidth-profile;
\r
484 description "none";
\r
486 description "Information on capacity of a particular TopologicalEntity.";
\r
488 grouping bandwidth-profile {
\r
489 leaf bw-profile-type {
\r
490 type bandwidth-profile-type;
\r
491 description "none";
\r
493 container committed-information-rate {
\r
494 uses capacity-value;
\r
495 description "none";
\r
497 container committed-burst-size {
\r
498 uses capacity-value;
\r
499 description "none";
\r
501 container peak-information-rate {
\r
502 uses capacity-value;
\r
503 description "none";
\r
505 container peak-burst-size {
\r
506 uses capacity-value;
\r
507 description "none";
\r
511 description "none";
\r
513 leaf coupling-flag {
\r
515 description "none";
\r
517 description "none";
\r
519 grouping capacity-value {
\r
522 description "none";
\r
525 type capacity-unit;
\r
526 description "none";
\r
528 description "The Capacity (Bandwidth) values that are applicable for digital layers.";
\r
530 typedef capacity-unit {
\r
533 description "Indicates that the integer CapacityValue is in TeraBytes";
\r
536 description "Indicates that the integer CapacityValue is in Terabit-per-second";
\r
539 description "Indicates that the integer CapacityValue is in GigaBytes";
\r
542 description "Indicates that the integer CapacityValue is in Gigabit-per-second";
\r
545 description "Indicates that the integer CapacityValue is in MegaBytes";
\r
548 description "Indicates that the integer CapacityValue is in Megabit-per-second";
\r
551 description "Indicates that the integer CapacityValue is in KiloBytes";
\r
554 description "Indicates that the integer CapacityValue is in Kilobit-per-second";
\r
557 description "none";
\r
560 description "none";
\r
563 description "none";
\r
565 typedef bandwidth-profile-type {
\r
568 description "none";
\r
571 description "none";
\r
574 description "none";
\r
577 description "none";
\r
580 description "none";
\r
582 grouping time-range {
\r
584 type date-and-time;
\r
585 description "none";
\r
588 type date-and-time;
\r
589 description "none";
\r
591 description "none";
\r
593 grouping time-period {
\r
596 description "none";
\r
600 description "none";
\r
602 description "none";
\r
604 typedef time-unit {
\r
607 description "none";
\r
610 description "none";
\r
613 description "none";
\r
616 description "none";
\r
619 description "none";
\r
622 description "none";
\r
624 enum MILLISECONDS {
\r
625 description "none";
\r
627 enum MICROSECONDS {
\r
628 description "none";
\r
631 description "none";
\r
634 description "none";
\r
637 description "none";
\r
639 grouping time-interval {
\r
645 description "none";
\r
647 description "none";
\r
649 typedef layer-protocol-qualifier {
\r
651 base LAYER_PROTOCOL_QUALIFIER;
\r
653 description "This enumeration is used to qualify the sub-layers (if applicable) for a specific LayerProtocol.
\r
654 This extensible enumeration is intentionally empty in the common module and will be augmented with layer-specific values in the respective technology-specific modules.
\r
656 - LayerProtocolName := OPTICAL_DATA_UNIT
\r
657 LayerProtocolQualifier := 'ODU_FLEX', 'ODU_0', 'ODU_1', 'ODU_2', 'ODU_2E', 'ODU_3', 'ODU_4'', 'ODU_CBR'', 'ODU_GFP'', 'ODU_GFP_HAO', etc
\r
658 - LayerProtocolName := DIGITAL_SIGNAL_RATE
\r
659 LayerProtocolQualifier := 'GBE', '10_GBE_WAN', '10_GBE_LAN', '100_GBE', 'FC_100', 'FC_200', 'FC_400', 'FC_800', 'FC_1200', 'FC_1600', 'FC_3200', 'STM_1', 'STM_4', 'STM_16', 'STM_64', 'STM_256', 'OC_3', 'OC_12', 'OC_48', 'OC_192', 'OC_768', 'OTU_1', 'OTU_2', 'OTU_2E', 'OTU_3', 'OTU_4', 'GPON', 'XGPON', 'IB_SDR', 'IB_DDR', 'IB_QDR', 'SBCON_ESCON', 'DVB_ASI', 'SDI', 'SDI_1G5', 'SDI_3G', etc
\r
660 - LayerProtocolName := PHOTONIC_MEDIA
\r
661 LayerProtocolQualifier := OCH, OTSi, OTSiA, NMC, NMCA, SMC, SMCA, OMS, OTS
\r
665 /**************************
\r
666 * package interfaces
\r
667 **************************/
\r
668 rpc get-service-interface-point-details {
\r
669 description "none";
\r
671 leaf sip-id-or-name {
\r
673 description "none";
\r
678 uses service-interface-point;
\r
679 description "none";
\r
683 rpc get-service-interface-point-list {
\r
684 description "none";
\r
687 uses service-interface-point;
\r
688 description "none";
\r
692 rpc update-service-interface-point {
\r
693 description "none";
\r
695 leaf sip-id-or-name {
\r
697 description "none";
\r
700 type administrative-state;
\r
701 description "none";
\r