Assign image keyname and pubkey at vnf level

[ccsdk/apps.git] / sdnr / wireless-transport / code-Carbon-SR1 / apps / devicemodel / src / main / yang / CoreModel-CoreNetworkModule-ObjectClasses@2016-08-11.yang

module CoreModel-CoreNetworkModule-ObjectClasses {
    namespace "uri:onf:CoreModel-CoreNetworkModule-ObjectClasses";
    prefix CoreModel-CoreNetworkModule-ObjectClasses;

    import CoreModel-CoreFoundationModule-SuperClassesAndCommonPackages {
        prefix CoreModel-CoreFoundationModule-SuperClassesAndCommonPackages;
    }
    import CoreModel-CoreNetworkModule-TypeDefinitions {
        prefix CoreModel-CoreNetworkModule-TypeDefinitions;
    }

    organization 
        'ONF (Open Networking Foundation) Open Transport Working Group - Wireless Transport Project';

    contact 
        'WG Web:   <https://www.opennetworking.org/technical-communities/areas/specification/1931-optical-transport>
         WG List:  <mailto:wireless-transport@login.opennetworking.org >
         WG Chair: Lyndon Ong
                   <mailto:lyong@ciena.com>
         WG Chair: Giorgio Cazzaniga
                   <mailto:giorgio.cazzaniga@sm-optics.com>';

    description 
        'This module contains a collection of YANG definitions for 
         managing microwave transport networks.';

    revision 2016-08-11 {
        description 
            "Initial revision."; 
        reference 
            "ONF TR xyz: A YANG Data Model for Microwave Transport Networks."; 
    }

    grouping ForwardingDomain {
        description "The ForwardingDomain (FD) object class models the topological component which represents the opportunity to enable forwarding (of specific transport characteristic information at one or more protocol layers) between points represented by the LTP in the model.
            The FD object provides the context for instructing the formation, adjustment and removal of FCs and hence offers the potential to enable forwarding. 
            The LTPs available are those defined at the boundary of the FD.
            At a lowere 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) and the FD representing the switch matrix can be further partitioned.
            ";
        uses CoreModel-CoreFoundationModule-SuperClassesAndCommonPackages:GlobalClass;
        leaf-list layerProtocolNameList {
            description "One or more protocol layers at which the FD represents the opportunity to enable forwarding between LTP that bound it.";
            ordered-by system;
            type CoreModel-CoreNetworkModule-TypeDefinitions:LayerProtocolName;
            min-elements 1;
        }
        leaf-list _lowerLevelFdRefList {
            description "The FD object class supports a recursive aggregation relationship (HigherLevelFdEncompassesLowerLevelFds) such that the internal construction of an FD can be exposed as multiple lower level FDs and associated Links (partitioning).
The aggregated FDs and Links form an interconnected topology that provides and describes the capability of the aggregating FD.
Note that the model actually represents aggregation of lower level FDs into higher level FDs as views rather than FD partition, and supports multiple views. 
Aggregation allow reallocation of capacity from lower level FDs to different higher level FDs as if the network is reorganized  (as the association is aggregation not composition).";
            ordered-by system;
            type leafref {
                path '/CoreModel-CoreNetworkModule-ObjectClasses:NetworkElement/CoreModel-CoreNetworkModule-ObjectClasses:_fdRefList/CoreModel-CoreNetworkModule-ObjectClasses:uuid';
            }
        }
        leaf-list _fcRefList {
            description "An FD contains one or more FCs. A contained FC connects LTPs that bound the FD.";
            ordered-by system;
            type leafref {
                path '/CoreModel-CoreNetworkModule-ObjectClasses:ForwardingConstruct/CoreModel-CoreNetworkModule-ObjectClasses:uuid';
            }
        }
        leaf-list _ltpRefList {
            description "An instance of FD is associated with zero or more LTP objects. 
The LTPs that bound the FD provide capacity for forwarding.";
            ordered-by system;
            type leafref {
                path '/CoreModel-CoreNetworkModule-ObjectClasses:NetworkElement/CoreModel-CoreNetworkModule-ObjectClasses:_ltpRefList/CoreModel-CoreNetworkModule-ObjectClasses:uuid';
            }
        }
    }
    list ForwardingConstruct {
        key 'uuid';
        config true;
        ordered-by system;
        uses CoreModel-CoreFoundationModule-SuperClassesAndCommonPackages:GlobalClass;
    }
    grouping ForwardingConstruct {
        description "The ForwardingConstruct (FC) object class models enabled potential for forwarding between two or more LTPs at a particular specific layerProtocol.
            Like the LTP the FC supports any transport protocol including all circuit and packet forms.
            It is used to effect forwarding of transport characteristic (layer protocol) information.
            An FC can be in only one FD.
            The ForwardingConstruct is a Forwarding entity.
            At a low level of the recursion, a FC represents a cross-connection within an NE. It may also represent a fragment of a cross-connection under certain circumstances.
            The FC object can be used to represent many different structures including point-to-point (P2P), point-to-multipoint (P2MP), rooted-multipoint (RMP) and multipoint-to-multipoint (MP2MP) bridge and selector structure for linear, ring or mesh protection schemes.";
        uses CoreModel-CoreFoundationModule-SuperClassesAndCommonPackages:GlobalClass;
        leaf layerProtocolName {
            type CoreModel-CoreNetworkModule-TypeDefinitions:LayerProtocolName;
            description "The layerProtocol at which the FC enables potential for forwarding.";
        }
        leaf-list _lowerLevelFcRefList {
            description "An FC object supports a recursive aggregation relationship such that the internal construction of an FC can be exposed as multiple lower level FC objects (partitioning).
Aggregation is used as for the FD to allow changes in hierarchy.
";
            ordered-by system;
            type leafref {
                path '/CoreModel-CoreNetworkModule-ObjectClasses:ForwardingConstruct/CoreModel-CoreNetworkModule-ObjectClasses:uuid';
            }
        }
        list _fcPortList {
            description "The association of the FC to LTPs is made via FcPorts (essentially the ports of the FC).";
            key 'uuid';
            config true;
            ordered-by system;
            uses FcPort;
            min-elements 2;
        }
        list _fcSwitchList {
            description "If an FC exposes protection (having two FcPorts that provide alternative identical inputs/outputs), the FC will have one or more associated FcSwitch objects.
                The arrangement of switches for a particular instance is described by a referenced FcSpec";
            key 'uuid';
            config true;
            ordered-by system;
            uses FcSwitch;
        }
        leaf forwardingDirection {
            type CoreModel-CoreNetworkModule-TypeDefinitions:ForwardingDirection;
            description "The directionality of the ForwardingConstruct. 
                Is applicable to simple ForwardingConstructs where all FcPorts are BIDIRECTIONAL (the ForwardingConstruct will be BIDIRECTIONAL) or UNIDIRECTIONAL (the ForwardingConstruct will be UNIDIRECTIONAL). 
                Is not present in more complex cases.";
        }
    }
    container NetworkElement {
        presence "Enables ONF CoreModel support";
        description "The Network Element (NE) object class represents a network element (traditional NE) in the data plane.
            A data plane network element is essentially a consolidation of capabilities that can be viewed and controlled through a 'single' management-control port.
            In the direct interface from an SDN controller to a network element in the data plane, the NetworkElement object defines the scope of control for the resources within the network element
            For example internal transfer of user information between the external terminations (ports of the NE), encapsulation, multiplexing/demultiplexing, and OAM functions, etc. 
            The NetworkElement provides the scope of the naming space for identifying objects representing the resources within the data plane network element.
            NE is really a product bundling or some view of management scope, management access, session. 
            The NE is not directly part of topology but brings meaning to the FD context and the LTP context (and hence the links). 
            lifecycle:LikelyToChange";
        config true;
        uses CoreModel-CoreFoundationModule-SuperClassesAndCommonPackages:GlobalClass;
        list _fdRefList {
            description "Represents the FD that is completely within the boundary of the NE.
                At a low 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) and the FD representing the switch matrix can be further partitioned.
                Where an FD is referenced by the NeEncompassesFd association, any FDs that it encompasses (i.e., that are associated with it by HigherLevelFdEncompassesLowerLevelFds), must also be encompassed by the NE and hence must have the NeEncompassesFd association.
                ";
            key 'uuid';
            config true;
            ordered-by system;
            uses ForwardingDomain;
        }
        list _ltpRefList {
            description "An NE has associated LTPs that are at its boundary.
                The NeEncompassesFd association occurs for FDs that are within the bounds of the NetworkElement definition such that the FD is bounded by LTPs, all of which are on the boundary of the NetworkElement or are within the NetworkElement. 
                An LTP can be independent of an NE.";
            key 'uuid';
            config true;
            ordered-by system;
            uses LogicalTerminationPoint;
        }
    }
    grouping FcPort {
        description "The association of the FC to LTPs is made via FcPorts.
            The FcPort object class models the access to the FC function. 
            The traffic forwarding between the associated FcPorts of the FC depends upon the type of FC and may be associated with FcSwitch object instances.  
            In cases where there is resilience the FcPort may convey the resilience role of the access to the FC. 
            It can represent a protected (resilient/reliable) point or a protecting (unreliable working or protection) point.
            The FcPort replaces the Protection Unit of a traditional protection model. 
            The ForwadingConstruct can be considered as a component and the FcPort as a Port on that component";
        uses CoreModel-CoreFoundationModule-SuperClassesAndCommonPackages:LocalClass;
        leaf-list _ltpRefList {
            description "The FcPort may be associated with more than one LTP when the FcPort is bidirectional and the LTPs are unidirectional.
Multiple Ltp
- Bidirectional FcPort to two Uni Ltps
Zero Ltp
- BreakBeforeMake transition
- Planned Ltp not yet in place
- Off-network LTP referenced through other mechanism";
            ordered-by system;
            type leafref {
                path '/CoreModel-CoreNetworkModule-ObjectClasses:NetworkElement/CoreModel-CoreNetworkModule-ObjectClasses:_ltpRefList/CoreModel-CoreNetworkModule-ObjectClasses:uuid';
            }
            max-elements 2;
        }
        leaf role {
            type CoreModel-CoreNetworkModule-TypeDefinitions:PortRole;
            description "Each FcPort of the FC has a role (e.g., working, protection, protected, symmetric, hub, spoke, leaf, root)  in the context of the FC with respect to the FC function. ";
        }
        leaf fcPortDirection {
            type CoreModel-CoreNetworkModule-TypeDefinitions:PortDirection;
            description "The orientation of defined flow at the FcPort.";
        }
    }
    grouping LayerProtocol {
        description "Each transport layer is represented by a LayerProtocol (LP) instance. The LayerProtocol instances it can be used for controlling termination and monitoring functionality. 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. 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. ";
        uses CoreModel-CoreFoundationModule-SuperClassesAndCommonPackages:LocalClass;
        leaf layerProtocolName {
            type CoreModel-CoreNetworkModule-TypeDefinitions:LayerProtocolName;
            description "Indicate the specific layer-protocol described by the LayerProtocol entity.";
        }
        leaf configuredClientCapacity {
            type string;
            description "Provides a summarized view of the client capacity that is configurable for use.
                Note the cleint LTP association should provide all necessary detail hence this attribute is questionable.";
        }
        leaf lpDirection {
            type CoreModel-CoreNetworkModule-TypeDefinitions:TerminationDirection;
            description "The overall directionality of the LP. 
                - A BIDIRECTIONAL LP will have some SINK and/or SOURCE flowss.
                - A SINK LP can only contain elements with SINK flows or CONTRA_DIRECTION_SOURCE flows
                - A SOURCE LP can only contain SOURCE flows or CONTRA_DIRECTION_SINK flows";
        }
        leaf terminationState {
            type boolean;
            description "Indicates whether the layer is terminated and if so how.";
        }
    }
    grouping LogicalTerminationPoint {
        description "The LogicalTerminationPoint (LTP) object class encapsulates the termination and adaptation functions of one or more transport layers. 
            The structure of LTP supports all transport protocols including circuit and packet forms.";
        uses CoreModel-CoreFoundationModule-SuperClassesAndCommonPackages:GlobalClass;
        leaf-list _serverLtpRefList {
            description "References contained LTPs representing servers of this LTP in an inverse multiplexing configuration (e.g. VCAT).";
            ordered-by system;
            type leafref {
                path '/CoreModel-CoreNetworkModule-ObjectClasses:NetworkElement/CoreModel-CoreNetworkModule-ObjectClasses:_ltpRefList/CoreModel-CoreNetworkModule-ObjectClasses:uuid';
            }
        }
        leaf-list _clientLtpRefList {
            description "References contained LTPs representing client traffic of this LTP for normal cases of multiplexing.";
            ordered-by system;
            type leafref {
                path '/CoreModel-CoreNetworkModule-ObjectClasses:NetworkElement/CoreModel-CoreNetworkModule-ObjectClasses:_ltpRefList/CoreModel-CoreNetworkModule-ObjectClasses:uuid';
            }
        }
        list _lpList {
            description "Ordered list of LayerProtocols that this LTP is comprised of where the first entry in the list is the lowest server layer (e.g. physical)";
            key 'uuid';
            config true;
            ordered-by system;
            uses LayerProtocol;
            min-elements 1;
        }
        leaf _connectedLtpRef {
            type leafref {
                path '/CoreModel-CoreNetworkModule-ObjectClasses:NetworkElement/CoreModel-CoreNetworkModule-ObjectClasses:_ltpRefList/CoreModel-CoreNetworkModule-ObjectClasses:uuid';
            }
            description "Applicable in a simple context where two LTPs are associated via a non-adjustable enabled forwarding.
                Reduces clutter removing the need for two additional LTPs and an FC with a pair of FcPorts.";
        }
        leaf _peerLtpRef {
            type leafref {
                path '/CoreModel-CoreNetworkModule-ObjectClasses:NetworkElement/CoreModel-CoreNetworkModule-ObjectClasses:_ltpRefList/CoreModel-CoreNetworkModule-ObjectClasses:uuid';
            }
            description "References contained LTPs representing the reversal of orientation of flow where two LTPs are associated via a non-adjustable enabled forwarding and where the referenced LTP is fully dependent on the this LTP.";
        }
        leaf-list physicalPortReference {
            description "One or more text labels for the unmodelled physical port associated with the LTP.
In many cases there is no associated physical port";
            ordered-by system;
            type string;
        }
        leaf-list _ltpRefList {
            description "References one or more LTPs in other views that represent this LTP. 
The referencing LTP is the rovider of capability.";
            ordered-by system;
            type leafref {
                path '/CoreModel-CoreNetworkModule-ObjectClasses:NetworkElement/CoreModel-CoreNetworkModule-ObjectClasses:_ltpRefList/CoreModel-CoreNetworkModule-ObjectClasses:uuid';
            }
        }
        leaf ltpDirection {
            type CoreModel-CoreNetworkModule-TypeDefinitions:TerminationDirection;
            description "The overall directionality of the LTP. 
                - A BIDIRECTIONAL LTP must have at least some LPs that are BIDIRECTIONAL but may also have some SINK and/or SOURCE LPs.
                - A SINK LTP can only contain SINK LPs
                - A SOURCE LTP can only contain SOURCE LPs";
        }
    }
    grouping FcSwitch {
        description "The FcSwitch object class models the switched forwarding of traffic (traffic flow) between FcPorts and is present where there is protection functionality in the FC. 
            If an FC exposes protection (having two FcPorts that provide alternative identical inputs/outputs), the FC will have one or more associated FcSwitch objects to represent the alternative flow choices visible at the edge of the FC.
            The FC switch represents and defines a protection switch structure encapsulated in the FC. 
            Essentially performs the functoion of the Protection Group in a traditional model. 
            Associates to 2 or more FcPorts each playing the role of a Protection Unit. 
            One or more protection FcPorts (standby/backup) provide protection for one or more working (i.e. regular/main/preferred) FcPorts where eith protection or working can feed one or more protected FcPort.
            May be used in revertive or non-revertive (symmetric) mode. 
            When in revertive mode may define waitToRestore time.
            May be used in one of several modes including source switch, destination switched, source and destination switched etc (covering cases such as  1+1 ane 1:1).. 
            May be lockout (prevented from switching), force switched or manual switched.
            Will indicate switch state and change of state.";
        uses CoreModel-CoreFoundationModule-SuperClassesAndCommonPackages:LocalClass;
        leaf holdOffTime {
            type int32;
            description "This attribute indicates the time, in seconds, between declaration of unacceptable quality of signal on the currently selected FcPort, and the initialization of the protection switching algorithm. ";
        }
        leaf waitToRestoreTime {
            type int32;
            description "If the protection system is revertive, this attribute specifies the amount of time, in seconds, to wait after the preferred FcPort returns to an acceptable state of operaion (e.g a fault has cleared) before restoring traffic to that preferred FcPort. ";
        }
        leaf protType {
            type CoreModel-CoreNetworkModule-TypeDefinitions:ProtectionType;
            description "Indicates the protection scheme that is used for the ProtectionGroup.";
        }
        leaf operType {
            type CoreModel-CoreNetworkModule-TypeDefinitions:OperType;
            description "This attribute whether or not the protection scheme is revertive or non-revertive. ";
        }
        leaf-list _selectedFcPortRefList {
            description "Indicates which points are selected by the switch.";
            ordered-by system;
            type leafref {
                path '/CoreModel-CoreNetworkModule-ObjectClasses:ForwardingConstruct/CoreModel-CoreNetworkModule-ObjectClasses:_fcPortList/CoreModel-CoreNetworkModule-ObjectClasses:uuid';
            }
            min-elements 1;
        }
    }
}