Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • TAPI Roadmap 2021/2022
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)

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 - Mid of October (pre-release available v2.3.1)
    • 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.
    • Loopback - added LOOPBACK_TERMINAL and LOOPBACK_FACILITY Oam Job Types, applicable to Connection End Points.
      • The provisioning of loopback on NEPs ("port" loopback) is postponed.
    • Bug fixings
    • For more details see TAPI213vs23rc1Vs23Vs231.pdf


  • 2.4 - to be delivered together with RIA 2.0 - March 2022
    • New Use Cases
      • OAM Provisioning
      • DSR over OTSi (skip OTN)
      • Navigation across layers (otcc2021.ND.004_LayerNavigation.pptx)
      • Optical Impairments (CCAMP/GNPy)
        • Including introduction (bkw compatible) of profiles/templates.
      • Physical Route
        • based on recursion of logical topology/connectivity model or
        • to a more equipment oriented model.
      • Path Computation
    • Consolidate/Adapt existing Use Cases to model 2.3.x
      • OTU layer management vs. OTSi
      • OTS/OMS layers
      • Detected Condition
    • Link between OTSi and MC/OTSiMC (transponder line ports - ROADM add/drop ports)
    • UNI Client interfaces modelling - contributions are necessary, see UNI Client Model
    • 3R Scenarios
      • In relationship with Asymmetric Service model
      • See IETF related works
    • Remove all RPCs - leaving the specification of required operations to RIA (through Restconf API spec).
    • Formalize in the model the Alarm dictionary TAPI_Alarm_TCA_List_v1.0.0.xlsx


  • 2.4 - Tentative additional features?
    • Multiband management
    • OTSiG on multiple line ports
    • Replace all ENUM with IDENTITY, to allow the correct distribution of identities across the proper modules, to maintain the modularity.
    • Candidate refinements (Nigel Davis to refine/itemize)
    • 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

    • Integration of Streaming/Notification related to Object Creation contents
    • 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:
      • Media Channel OAM
      • PM enhancements for Streaming
    • Temporal Model - available reference material on OIMT/Core IM
    • 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 (connection sets) that would be separately secured where each would provide a context with a specific view (slice etc.).
    • OAM Job and generalized Task Nigel Davis 
      • Generalize the model of OamJob so it can be used for any Tasks
    • Documentation enhancements Nigel Davis
      • Document the extension mechanism
        • Extension mechanism: This is not documented visibly:
          • Determine what degree of extension is allowed and where (especially accounting for the spec work – a vendor must be enabled to insert a spec that expresses their precise equipment capability as a replacement for the standard spec (e.g., Ethernet port)
          • Ensure that we document the approach and define some level of “enforcement”
      • Overall document structure
        • may want to separate out informative/explanatory model text from normative text (as per core)
        • may want to separate out definitions (such as top level connection)
    • All properties, augments etc. should be conditional mandatory where clear conditions are identified. Nigel Davis  
      • This allows for use of the objects:
        • In notification and streaming to represent any delta (as it is conformant to include only a single attribute)
        • In specifications
        • In other patterns
      • Conditions include feature based control
      • CEP/NEP/etc. augments should be conditional on layer etc.
        • This should also allow vendor specific augments (that are perhaps narrower than the formal layer augment)


  • 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