Skip to end of metadata
Go to start of metadata

General Areas to be worked on (a brief contribution should be provided)

Updated  

TAPI Reference Implementation Agreement (scheduled)

  • TR-547 1.1 - Mid/end of September
  • TR-548 1.1 - End of September
    • Streaming RIA
  • TR-547 1.2 - November
    • Including also features applicable to TAPI 2.3
    • RESTCONF Response codes for use cases
    • Security: identity, authentication, authorization, confidentiality
      • TLS, SSH
      • NACM
  • TR-548 1.2 - November
    • Update wrt TAPI 2.3 features
    • Security

TAPI SDK release (scheduled)

  • 2.1.4 - No longer planned.
    • 2.1.3 patch version only if required/agreed.


  • 2.3 - End of May (RC1 available v2.3-RC1)
    • Resilience enhancements (already available on 2.1.x branch for review)
    • ENNI Plug-In model formalized (NEP SAPI)
    • OTS-OMS model
      • Flexibility to allow base/unspecified and/or OTS and/or OMS encapsulations, i.e. a single CEP instance may include all "layers" or two ones or single one.
      • OTS, OMS, MC are essentially different aggregations of Media Channels, agreed to keep only MediaChannelConnectionEndPointSpec class, with OTS/OMS/MC specific packages.
    • DIGITAL_OTN replaces ODU Layer Protocol Name.
    • Connectivity Service Provisioning - see related scenarios in otcc2020.AM.001_TAPI_Photonic_Model_Evolution.pptx
      • OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning

      • DSR/ODU multiplexing over ODU (server layer constraints for simple provisioning scenarios).
      • ENNI/INNI Asymmetric service provisioning for simple multi-domain scenarios.

      • ServerConstraint package for more complex scenarios.
      • Layer Protocol Name and Qualifier added to the Connectivity Service
    • OAM enhancements: Digital OTN OAM
    • OtsiCapabilityPac augments NEP (through new OtsiNodeEdgePointSpec). Added maxNumOfOtsi, integer.
    • More options for OTSi and MC provisioning, e.g. either central frequency or spectrum or capacity or floating bandwidth.
    • Decoupling of Alarm/TCA model from OAM model, new TapiFm module (TR-547 V1.1 - UC 16a, 16b)
    • Quality, e.g. add missing comments to UML
    • Streaming Nigel Davis - replicate feature from TAPI 2.1.3
    • Equipment Model Nigel Davis - Feature alignment wiith TAPI 2.1.3
      • Check eqp object types for notification
    • Routing Constraint enhancement
      • Connection (existing flows)
      • "Explicit route" flag (declarative option)
    • Simplified transmission capability feature - otcc2020.AM.002-Transmission_Capability.pptx
      • Added to the NEP:
        a. supportedMuxSequences: MultiplexingSequence [1..]
        b. availableMuxSequences: MultiplexingSequence [1..]
        c. baseLayerProtocolQualifier: LayerProtocolQualifier [1]
    • Move to "deprecated" state all the RPCs
    • Remove the "presence" statement (of context container) from YANG TapiCommon module.
    • Edit the YAML Connectivity module to amend the POST body.
    • See also otcc2020.AM.005_TAPI_Enhancements.pptx for a snapshot of the agreements


  • 2.3 - Mid of August (v2.3)
    • Integration of Streaming and Fault Management
      • Same Alarm/TCA data types augment Notification and Streaming classes.
      • For TAPI 2.3 the Object Creation model will still be different for Notification and Streaming. Postpone to TAPI 2.4 further discussion.
    • Quality: diagram adjustments, Gendoc PDF file (TapiUmlGendoc_v2_3.pdf) now includes also associations.


  • 2.3.1 - End of September
    • Integration of Streaming and Fault Management
      • Now TapiStreaming behaves similarly to TapiNotification, i.e. it is positioned at the core of the TAPI model.

      • TapiStreaming has been disaggregated: Each technology agnostic module specifies its own augments to Streaming (and Notification).
      • All technology agnostic modules will import both TapiNotification and TapiStreaming.
      • Object Creation model is now aligned for both Notification and Streaming.
        • Generic "object content" attribute has been kept for backward compatibility.
    • Bug fixings


  • 2.4 - October/November
    • Integration of Streaming/Notification related to Object Creation contents
    • Optical Impairments (GNPy) - related to Physical Route
    • 3R - See IETF related works
    • Replace all ENUM with IDENTITY, to enable bkw compatible vendor extensions within the release
    • Candidate refinements (Nigel Davis to refine/itemize)
    • Loopback - OAM Job on CEP/NEP, "internal/including most device/contradirectional" and "external/including minimal device/codirectional".
    • Remove all RPCs - moving the specification of required operations to RIA (through Restconf API spec).
    • Enhance Streaming UML for the automatic generation of feature/if-feature statements.
      • Explore the definition of topology/connectivity/oam features.
    • Quality, e.g. add descriptions to UML - Technology specific modules.
    • Consider introduction of Administrative State for physical context objects.
      • Consider also more general subject of state propagation behavior.

        For the below listed items contributions are necessary

    • Verify otcc2021.ND.001_TapiLayers.pptx possible impacts on model and/or RIA.
    • Physical Route for correlation and for routing diversity
      • SRG - besides link, include nodal group, e.g. power and air conditioning, etc.
    • OAM enhancements:
    • Path Computation Service / Connectivity Service enhancements
    • UNI Client interfaces modelling Nigel Davis 

      • Layer stack model
      • SIP model, possibly including internal SIP - ServiceInterfacePoint as role/view of NodeEdgePoint
        • Conceptual major change?
      • Using the spec model approach to simplify the SIP layering and also enhance its information opportunity.
    • Broader application of spec model Nigel Davis 
      • Determine what the correct Spec reference is (UUID etc.)
      • Ensure that all model elements can refer to a spec
      • Develop spec for each entity through value-justified-steps
    • Further development of transmission capability feature
    • Manual switch operations on protection/restoration schemes - depending on RIA UCs
    • Multiple Contexts Nigel Davis
      • Note that this has been moved up from "Next Major Release" as it does not appear to need TAPI changes and is more of a usage description.
      • As Context is the root of the tree, there can clearly only be one context per provider connection
        • There could be multiple alternative connections that would be separately secured where each would provide a context with a specific view (slice etc.).
      • Enhancement of Documentation (e.g. future versions of TR5xx Reference Implementation)
    • OAM Job and generalized Task Nigel Davis 
      • Generalize the model of OamJob so it can be used for any Tasks


  • No specific delivery
    • Updated OAS (tooling)
      • Target is improve the quality of OAS modules - either improving the tool or manually if feasible.
      • Necessary to find resources within OIMT/OTCC. Note that the "Restconf compliance" is not still well specified, subject to local/bounded agreements. No external authority.
      • In general, no open source tool available to generate code from YANG schema. Issue is interoperability.


TAPI SDK release (completed)

  • 2.1.3 -  End of May 2020 Andrea Mazzini
  • 2.2.0 - 2019 July-end
    • Equipment inventory model (new feature)
    • Routing & Resilience Constraints fixes/updates
      • Some of the constraints were changed to read-write from read-only
      • Minor structural changes (related Topology/Connectivity constraints)
    • OAM, Notification Framework updates
      • OAM Job structure refactoring and renaming
      • OAM/Threshold profile
      • Threshold/PM parameter
      • Alarm/TCA linkage to Threshold/PM parameter
    • Topology Model update
      • added TopologyAggregatesNEP association
      • marked NodeAggregatesNEP as deprecated
      • renamed Node.ownedNodeEdgePoint to Node.nodeEdgePoint
    • ETH Technology model updates
      • mainly OAM based on MEF NRM-OAM requirements, review and feedback
    • Photonic model updates
      • mainly power control management & photonic-layer-qualifier labels
  • 2.1.0 - 2018 July-end
    • OTSi Spec Model Updates to include OMS/OTS Media
    • ETH Spec Model Updates to include OAM
    • DSR Spec Model
    • OAM Model Updates to align with MEF NRM-OAM
    • OpenAPI updates for RESTConf compliance
  • 2.0.2 - 2018 Mar-end
  • 2.0.1 - 2018 Feb-mid
  • 2.0.0 - 2018 Jan-start