Updated 11 Jul 2022
Outline colors reflect backward compatibility, dotted ones are planned items Fill colors: red = do not use , green = candidate for production
GitHub Links:
RIA Links:
See here the Archived Deliveries
See here the Candidate Features for Future Releases of TAPI SDK and RIA
TAPI Reference Implementation Agreement TR-547 2.0 - October 2022 Reference Model version is 2.4 See ONF TAPI RIA for more details TR-548 2.0 - October 2022 Reference Model version is 2.4 TR-547 2.1 - February 2023 Progress on Path Computation Progress on 3R TR-548 2.1 - February 2023 TR-547 2.2 ? RESTCONF Response codes for use cases Security: identity, authentication, authorization, confidentiality TAPI SDK
2.4 - to be delivered together with RIA 2.0 - October 2022 RIA and other documents under development: ONF TAPI RIA Not backward compatible with Version 2.1.3 Candidate for adoption New Use Cases OAM Provisioning Optical Impairments (CCAMP/GNPy) Including introduction of profiles/templates. Physical Route Consolidate/Adapt existing Use Cases to model 2.4 OTU layer management vs. OTSi OTS/OMS layers Detected Condition Clarified the navigation across layers Clarification and improvement of asymmetric scenarios Clarification on Notifications considering the different object relationships Link between OTSi and MC/OTSiMC (transponder line ports - ROADM add/drop ports) Solution is based on deprecation of OTSi qualifier and adoption of OTSiMC qualifier on both ROADM and transponder UNI and ENNI interfaces modelling 3R Scenarios In relationship with Asymmetric Service model In relationship to Resiliency See IETF related works Remove all RPCs - leaving the specification of required operations to RIA (through Restconf API spec). Update the Alarm dictionary TAPI_Alarm_TCA_List_v1.0.0.xlsx and formalize it in the model
2.4.1 - likely to be adopted by RIA 2.1 - February 2023 Development of Path Computation UCs - which lead to model changesExplore reuse of Connectivity model Explore two distinct use cases:Planning, i.e. create a quasi static set of paths which can used to guide future connectivity services Connectivity Route Selection, i.e. at connectivity service creation, provide a set of alternative paths from which to select the preferred one Consider potential improvements to diversity-policy of connectivity-service. The current enumeration does no appear to allow necessary flexibility/coverage Review other work such as https://github.com/rvilalta/ietf-te-path-computation Further development of Optical Impairments UCs - which lead to model changes Further development of Connectivity UCs including 3R - which lead to model changes > 2.4.1 DSR over OTSi (skip OTN) 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. 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.