Child pages
  • TAPI Contributions and Presentations

Version 1.1 - 13 July 2020

Purpose of this document is to list the differences between YANG modules automatically generated from TAPI 2.1.3 and TAPI Next Major Release / Edge version.

Notes:

  1. 213: TAPI version 2.1.3
  2. E: Edge or Next Major Release
  3. resourceSpec removed from Edge, unclear how GlobalClass is inherited. Broken/ now restored .
  4. Local class is explicitly “used” in Edge: Rule, CSEP, Route, Switch
  5. E.g. SIP does not have the “uses global-class”, but in UML diagram there is inheritance. Note that Edge SIP has an “interface realization” while 213 SIP inherits ResourceSpec.
  6. Note that Edge does not have the “ interface realization ” association between context and service classes.
  7. Differences related to comments

1        Tapi Common

  1. Edge: copy streaming augment from 213
  2. 213: copy admin state pac comments from Edge
  3. 213: copy lifecycle state pac comments from Edge
  4. 213: copy global and local class comments from Edge
  5. 213: copy operational state pac comments from Edge
  6. 213: copy tapi-context and SIP class comments from Edge
  7. 213: copy capacity-pac and termination-pac comments from Edge
  8. E: copy key “uuid” to grouping tapi-context/list SIP but models seem equal!

    grouping tapi-context {

        list service-interface-point {

            key 'uuid';

            uses service-interface-point;

            description "none";

        }

  1. 213: delete resource and service spec
    1. Resource-spec in 213 is used by SIP, Link, Node, Topology, NEP, InterRuleGroup, NodeRuleGroup, CEP, SwitchControl,  Connection
    2. Service-spec in 213 is used by: NetworkTopologyService, ConnectivityService
  2. 213: grouping service-interface-point, copy comments from Edge
  3. 213: grouping termination-pac, copy comments from Edge
  4. Edge: copy to 213, no because is enum in 213 .

    identity OBJECT_TYPE {

        description "none";

    }

    identity OBJECT_TYPE_SERVICE_INTERFACE_POINT {

        base OBJECT_TYPE;

        description "none";

    }

  1. 213: lifecycle-state copy comments from Edge
  2. Edge:  grouping bandwidth-profile and bandwidth-profile-type were defined in 213, correctly removed from Edge (as Ethernet specific).
  3. 213: add the following types:

   typedef mac-address {

        type string;

        description "pattern '[0-9a-fA-F]{2}(-[0-9a-fA-F]{2}){5}'

            description

            'The mac-address type represents a MAC address in the canonical

            format and hexadecimal format specified by IEEE Std 802. The

            hexidecimal representation uses uppercase characters.'";

    }

    typedef binary {

        type string;

        description "Represents any binary data, i.e., a sequence of octets.

            A binary type can be restricted by a length which defines the number of octets it contains.";

    }

    typedef timeticks {

        type string;

        description "type uint32

            The timeticks type represents a non-negative integer that represents the time, modulo 2^32 (4294967296 decimal), in hundredths of a second between two epochs.";

    }

    typedef object-type {

        type identityref {

            base OBJECT_TYPE;

        }

        description "The list of TAPI Common Object types/classes.";

    }

  1. 213, rpc get/updated sip, copy UUID comments

2        Tapi Topology

  1. E: copy streaming augment from 213
  2. Edge: Link has protection-type and restoration-policy, while 213 has resilience-type.
  3. 213: copy admin state pac comments
  4. 213: copy lifecycle state pac
  5. E: missing key ‘uuid’: List NEP, NodeRuleGroup, Node, Link but models seem equal!
  6. Edge has Topology/boundary-node-edge-point, 213 not.
  7. 213: copy comment of transitioned-layer-protocol-name from Edge
  8. Edge: NEP/availableCepLayerProtocol is richer than simple 213 supportedLayers
  9. Edge: NodeRuleGroup, InterRuleGroup, add “config false” to all attributes ( done 7 July )
  10. E: copy inter-rule-group, node-rule-group, grouping-rule comments (class+attrs)
  11. E: copy PortRoleRule type from 213, while in E there is TopologyObjectType
  12. E: latency-characteristic, set the config false on attrs
  13. E: copy forwarding-rule and rule-type comments
  14. Edge: copy grouping connection-spec-reference from 213
  15. E: copy signal-property-value-rule type
  16. E: all rpcs have comments on uuid
  17. Edge has topology-object-type enum/identity

3        Tapi Connectivity

  1. Edge: connection/CEP list config false
  2. 213: copy connection/bounding-node from Edge
  3. E: connection/list switchControl add key uuid

        list switch-control {

            key 'uuid'; missing from edge, but UML seems equal

            config false;

            uses switch-control;

            description "none";

        }

  1. 2.1.3: Connection class, copy container connection-spec-reference to Edge?
  2. 2.1.3: Node/_ownedNodeEdgePoint, Edge: Node/_nodeEdgePoint
  3. 213: CEP/list CepRole (a string plus connection-spec-reference) while Edge: CEP/leaf protection-role
    • CepRole and ConnectionSpecReference not defined in Edge.
  4. ConnectivityConstraint, service-layer (layer-protocol-name) and connectivity-direction in 213, not in Edge.
  5. 213: copy service-level comment from Edge.
  6. No change needed: Edge: ConnectivityService, all references (connectivity-constraint; routing-constraint; topology-constraint; resilience-constraint) are StrictComposite , 213 are ExtendedComposite

        container connectivity-constraint {

            uses connectivity-constraint;

            description "none";

        }

  uses connectivity-constraint;

  • Edge: Note that with local-id the key is mapped:

        list topology-constraint {

            key 'local-id';

            uses tapi-path-computation:topology-constraint;

            description "none";

        }

  1. Edge has ConnectivityService/direction attribute, 2.1.3 not
  2. E: copy from 2.1.3 the comment of Resilience Route / and to _resilienceRoutePac attrib of Route class.
  3. E: connectivity-context/list connectivity-service and list connection, missing key ‘uuid’
  4. Edge: add the “config false” on switch/selected-route, selected-cep
  5. ResilienceConstraint, different model of protection/resilience type. Edge is more correct.
  6. 213: Selection control is in Switch class, while in Edge is in ResilienceConstraint class (more correct)
  7. 213: add fault-condition-determination to ResilienceConstraint class, plus related type
  8. Edge: add the “config false” on resilience-route/priority
  9. Cep-list, without key ‘uuid’ in Edge.
  10. ConnectivityObjectType not defined in 213 no change possible
  11. Edge: copy typedef route-state comment from 213
  12. Edge: all rpcs have comment on uuid in Edge we may either remove all rpcs or enhance .
  13. create-connectivity-service, Edge adds input params: no need to change 213
    • uuid
    • name
    • layer protocol name
    • topology constraint becomes a list
  14. update-connectivity-service, Edge adds input params:
    • uuid
    • name
    • topology constraint becomes a list
  15. 213: full hierarchy (see below), while in Edge just uuid. No need to change

    rpc get-connection-end-point-details {

        description "none";

        input {

            leaf topology-id-or-name {

                type string;

                description "none";

            }

            leaf node-id-or-name {

                type string;

                description "none";

            }

            leaf nep-id-or-name {

                type string;

                description "none";

            }

            leaf cep-id-or-name {

                type string;

            }

        }

4        Tapi Equipment

No differences ( 12 July, in Edge fixed the SupportingPhysicalSpan augmentation of Link )

 


5        Tapi OAM

  1. 2.1.3 uses tapi-common:resource-spec, Edge uses tapi-common:global-class
  2. 2.1.3 no import tapi-notification
  3. 2.1.3: pmCurrentData, PmHistoryData – Edge: currentData, historyData
    1. Edge: granularityPeriod and suspectIntervalFlag moved to a new class PmDataPac, conditional of both current and historyData.
    2. 2.1.3 timestamp – Edge periodStartTime
    3. Edge historyData adds periodStartTime
  4. 2.1.3: oam-service-end-point – Edge: oam-service-point
  5. Edge: MEP direction, mep-identifier and peer-mep-identifier moved to TapiEth.
  6. Edge: OamServicePoint direction, mep-identifier and peer-mep-identifier moved to TapiEth
  7. Edge: OamServicePoint has is-mip attribute
  8. 2.1.3 comment typo :

    grouping meg {

        list mep {

            key 'local-id';

            config false;

            uses mep;

            description "1. ME may have 0 MEPs (case of transit domains where at least 1 MIP is present)

                2. ME may have 1 MEP (case of edge domaind

  1. Edge: OamService has layer-protocol-name attribute, and the list is oam-service-point rather than end-point
  2. 2.1.3 OamService has association to OamProfile “OamServiceAppliesProfile”, Edge does not.
  3. 2.1.3 OamConstraints – Edge: class removed, because its attributes
    1. layerProtocolName: in Edge is in OamService,
    2. direction, megLevel: in Edge are in EthOamService, EthOamMeg/MepServicePoint.
  4. Edge OamProfile, pm-bin-data class removed (only attribute was granularityPeriod)
  5. Edge PmThresholdData has applicable-job-type and threshold-parameter attributes.
  6. Edge adds:
    1. grouping tca-info
    2. grouping  alarm-info
    3. identity OAM_NOTIFICATION_TYPE
    4. identity ALARM_CONDITION_NAME
    5. identity PM_PARAMETER_NAME
    6. identity OAM_OBJECT_TYPE
    7. typedef perceived-tca-severity
    8. typedef perceived-severity-type
    9. typedef service-affecting
    10. grouping pm-parameter {

        leaf pm-parameter-name {

            type pm-parameter-name;

            description "none";

        }

        container pm-parameter-value {

            uses pm-parameter-value;

            description "none";

        }

        description "none";

    }

    typedef pm-parameter-name {

        type identityref {

            base PM_PARAMETER_NAME;

        }

        description "none";

    }

  1. grouping threshold-parameter {

        leaf pm-parameter-name {

            type pm-parameter-name;

            description "none";

        }

        leaf threshold-location {

            type threshold-crossing-qualifier;

            description "none";

        }

        container pm-parameter-above-thrs {

            uses pm-parameter-value;

            description "none";

        }

        container pm-parameter-below-thrs {

            uses pm-parameter-value;

            description "none";

        }

        container pm-parameter-clear-thrs {

            uses pm-parameter-value;

            description "none";

        }

        description "none";

    }

 

  1. typedef threshold-crossing-qualifier

    grouping pm-parameter-value {

        leaf pm-parameter-int-value {

            type uint64;

            description "none";

        }

        leaf pm-parameter-real-value {

            type decimal64 {

                fraction-digits 7;

            }

            description "none";

        }

        description "none";

    }

 

  1. Edge has restructured RPCs

 


6        Tapi ODU

  1. 213 OduTcmMepPac/ codirectional is “config false”, while in Edge is readwrite because OduTcmMepPac augments, besides OduMepSpec/Mep, also OduOamMep Service Point/OamServicePoint (provisioning).
  2. 213: OduTcmMepPac inherits from OduTcmMipPac (only one attribute, tcmField), while in Edge the OduTcmMepPac does not inherit from OduTcmMipPac, and includes its tcmField. This likely because in Edge the OduTcmMipPac also includes codirectional attribute. Note also that in Edge the TcmMep/Mip tcmField is readwrite, while in 213 is “config false”. Is tcmField provisionable? Comment is “This attribute indicates the tandem connection monitoring field of the ODU OH”.
  3. Edge has
    • odu-oam-service
    • odu-meg-spec
    • odu-measurement-job
    • odu-oam-mep-service-point
    • odu-oam-mip-service-point
    • odu-delay-performance-data
    • odu-fec-performance-data
  4. Edge: odu-csep-ttp-pac/ configured-client-type is readwrite, 213 is “config false” – which seems wrong as it should be provisionable (through OduConnectivityServiceEndPointSpec)
  5. Edge has OTN_ALARM_CONDITION_NAME (all ODU related probable causes)
  6. Edge has OTN_FAULT_CONDITION_DETERMINATION, ODU_OAM_JOB_TYPE
  7. Edge has

    typedef otn-fault-condition-determination {

        type identityref {

            base OTN_FAULT_CONDITION_DETERMINATION;

        }

        description "ITU-T-REC-G.873.1-201710

            Optical transport network: Linear protection";

    }

    typedef odu-oam-job-type {

        type identityref {

            base ODU_OAM_JOB_TYPE;

        }

        description "none";

    }

    grouping odu-counters {

        leaf bbe {

            type uint64;

            description "none";

        }

        leaf ses {

            type uint64;

            description "none";

        }

        leaf uas {

            type uint64;

            description "none";

        }

        description "none";

    }