AUTHORS: Nigel Davis, Ciena / Ramon Casellas, CTTC / Andrea Mazzini, Nokia

Highlights

TAPI is a RESTCONF YANG interface for application between SDN controllers, orchestrators, traditional management systems and OSS solutions (see TAPI Overview and section 8 of TR-547 v2.0 for definitions and abbreviations).

TAPI v2.4.0 (including two Reference Implementation Agreements TR-547 v2.0 and TR-548 v2.0) progresses beyond TAPI v2.1.3 bringing key advances and providing extended and new use cases in many areas delivering:

• Major enhancement to photonic impairment models to support rich multi-vendor planning capability
• Refinements to network layer modeling enabling full support of complex network structures
• Extensive OAM enhancements including support for simplified Network Connection Monitoring
• Detailed scenarios addressing integrated and partial disaggregated management and control 
• Consolidation of, and enhancement to, alarm and PM structures for notification and streaming
• Addition of a server connection association to improve navigation down the layer stack
• Support for physical route describing equipments used by a connection through a complex device
• A powerful generalized profile model to group common attributes (e.g., amplification profile)
• Enhancements to NEP/SIP relationships to better support service creation
• Opportunity to state resiliency-route-constraint to enable enhanced protection route requests
• Expansion of UNI and ENNI models to cover key patterns
• Clarification of tapi-notification usage to improve interoperability consistency
• Extensive enhancements to the provisioning scenarios to deal with broader network variety
• Major clarification of conditional property statements to improve compliance opportunity

The combination of the above features along with other enhancements and existing capabilities makes TAPI the right choice for Photonic, OTN and Ethernet control integration.

Read on for Testimonial Quotes more details on TAPI in general and on the TAPI v2.4.0 features.

Join the team to further advance TAPI

https://wiki.opennetworking.org/display/OTCC/TAPI+Call-in+Details+and+Notes 

Testimonial Quotes

TIP MUST

“The ONF Transport API (TAPI) release 2.4 means a significant step forward into the path of openness and disaggregation of the Optical Transport Networks promoted and pursued by the Telecom Infra Project (TIP's) MUST operator’s subgroup, including Telefónica, Vodafone, Orange, MTN, Telia Company and Colt Technologies among other partners. This new TAPI release, which has been contributed by some of the MUST active operator participants, successfully accommodates several MUST-defined use cases for optical transport such as the physical Impairment data retrieval for OTSi path planning and validation," said Oscar González de Dios, Technical Lead at Telefónica and Johan Hjortås, Head of IP, Optical & Fixed Access Network strategy and architecture at Telia Company, co-chairs of the Open Optical and Packet Transport program at Telecom Infra Project.

OIF

“TAPI has been of significant importance to the OIF given the need for a standardized interface between SDN applications and SDN networks.  The extension supporting optical link information is especially important given the shift away from digital switching to optical switching and the advent of disaggregated systems.  And the addition of streaming notifications assists an application with learning real-time changes to the state of the network.  The OIF has enjoyed working with ONF to validate these interfaces and their applicability to service provider networks,” said Jonathan Sadler (Infinera), Chair, OIF Networking Interop WG.

CTTC

“CTTC has participated in sixteen research projects addressing packet-optical transport networks for 5G and 6G, within the framework or the European 5GPPP and SNS work programmes. CTTC has been a long-term contributor to TAPI since its inception, based on the COP protocol defined in the FP7 STRAUSS project, and we continue to develop and test TAPI as an open and standard northbound Interface for disaggregated transport networks.  Currently, we use TAPI in several research projects such as Int5Gent, TeraFlow or B5G-OPEN,” said Raul Muñoz, head of the Packet Optical Networks and Services Research Unit at CTTC.

Orange

“Network Infrastructure automation is at stake for telco to improve our operational efficiency. In this respect, open and interoperable models such as ONF Transport API (TAPI)  are cornerstones. Orange is actively contributing to the standardization efforts and initiatives. Features introduced in this new release of TAPI, including impairment awareness, are an important step to support our use cases and short-term requirements. In this regard, we will continue to work on the functional and model convergence of standards, to cover the whole optical domain,” said M. Gilles Bourdon, Vice President, Wireline Networks and Infrastructure at Orange

Virgin Media O2

“As Virgin Media O2 expands its Network Automation capabilities, understanding the network topology, connectivity, and services across a multi-vendor, multi-service network would have been significantly more complex had it not been for vendor alignment to TAPI. We are looking forward to utilising the new capabilities of TAPI v2.4.0, particularly the OAM, Alarm and PM enhancements to underpin our existing developments,” said  Martin Singer, CEng | Senior Manager, Network OSS Architecture at Virgin Media O2.

TAPI Overview

TAPI is a RESTCONF YANG interface appropriate for use between SDN controllers and orchestrators as shown below.

TAPI provides a forwarding-technology-layer neutral model with forwarding-technology-layer specific augments supporting a multi-layer solution covering L0 (photonic), L1 (OTN) and L2 (Ethernet) networks.

TAPI includes the following key focused support:

• Topology: Node, Links etc.
• Connectivity: Connectivity Services, Connections etc.
• OAM: Jobs, Records etc.
• Path Computation: Paths, Constraints etc.
• Equipment: Devices, Physical Spans etc.
• Notification: Subscriptions, Events etc.
• Streaming: Stream definitions,  compacted log of events etc.
• Fault Management: Alarms structure, PM structures etc.

The above allows a TAPI client to gain and maintain alignment, via an ongoing flow of state updates, with the network controlled by the TAPI provider for all relevant network properties. 

TAPI v2.4.0 includes two Reference Implementation Agreements that specify the application of the TAPI models for various use cases:

• TR-547-TAPI-v2.4.0-Reference-Implementation-Agreement_v2.0 
• TR-548-TAPI-v2.4.0-ReferenceImplementationAgreement-Streaming_v2.0 

TAPI v2.4.0 Detail

TAPI v2.4.0 builds on previous releases enhancing existing capabilities and adding new capabilities.

Major enhancement to photonic impairment models to support rich multi-vendor planning capability

Intense work has been carried out to ensure alignment with ongoing IETF CCAMP models as well as existing practice such as GNPy. This has led to extensive additions to properties and improvements to structures in the photonic-media augments. Key use cases and application of the impairments model are detailed in TR-547 v2.0.

Refinements to network layer modeling enabling full support for complex network structures

The layer model has been refined to better reflect key network structure, improve navigation and enable support for complex cases (including networks with regeneration).

Key enhancements include:

• OTSiMC extended to the transponder, unifying OTSi and OTSiMC
• Introduction of DIGITAL_OTN layer protocol name and OTU qualifiers
• Exposure of explicit OMS and OTS_MEDIA qualifiers
• Deprecation of some redundant layer qualifiers

Extensive OAM enhancements including support for simplified Network Connection Monitoring

The OAM model has been refined to cover a broad range of OAM network scenarios and to simplify applications such as Network Connection Monitoring (NCM). The OAM use case coverage has been extended to include Provisioning of OAM jobs and Tandem monitoring. TR-547 provides rich detailed explanation of the OAM model usage.

Detailed scenarios addressing integrated and partial disaggregated management and control 

TR-547 v1.1 provided some description of control of integrated and partially disaggregated solutions. TR-547 v2.0 provides a far richer description of many more scenarios including details on the structure of the model for regenerated cases and also extensive examples of asymmetric cases (where the level of layer termination at one side of the network is less than that at the other side).

Figure 5-9 Scenario 1 : Optical Line System Controller, MC and OTSiMC CSs

Figure 5-34 Scenario 2 : Integrated Management, regeneration

Figure 6-16 Asymmetric Scenario 1: Handoff at ODU4 Layer, no ODU2 layer on ENNI

Consolidation of, and enhancement to, alarm and PM structures for notification and streaming

In TAPI v2.1.3 the notification solution and the streaming solution each used a distinctly different model for alarms/PMs. 

TAPI v2.4.0, TR-547 v2.0 and TR-548 v2.0 combine the best of those two distinct models to provide an enhanced unified model of alarms/PMs (in tapi-fm). This model supports advanced reporting opportunities covering intermittent and fleeting alarms as well as legacy alarm severity and acknowledge.

Both tapi-streaming and tapi-notification reference a companion documents that provides normalized alarm definitions for use with this new model.

Addition of server connection association to improve navigation down the layer stack

The solution now supports navigation via direct relationships from:

• connectivity-service to immediate supporting top-level connection
• any top-level connection to the immediate server top level connection and to its component lower connections
• any connection to its connection-end-points

These relationships enable enhanced systematic navigation down the layer hierarchy via identified connection retrieval complementing the navigation up the hierarchy from the bottom supported by the node-edge-point and connection-end-point relationships.

The server connection navigation removes the need for the connectivity-service to list all supporting top-level connections and bring significant improvements to model efficiency.

The use of top-level connection has also been clarified and a single partitioning hierarchy level between top-level connections and their lower connections has been adopted.

Support for physical route describing equipments used by a connection through a complex device

This new feature allows a client system to determine the equipments used to support a photonic connection as it passes through a device. This improves the opportunity for fault impact analysis and also better enables the operator to determine the impact on deployed connectivity-services of a planned equipment maintenance action.

A powerful generalized profile model to group common attributes (e.g., amplification profile).

A general profile structure has been added that is used in various use cases to allow direction specific application of property values common across many instances. The profile may be augmented with application specific properties identified in technology specific models. 

Specification of profiles for transceiver properties, OMS / OTS attributes, ROADM internal paths, amplification functions and fibers have been added.

Enhancements to NEP/SIP relationships to better support service creation

The relationship between the NEP and SIP has been clarified in TR-547 v2.0 and the representation of layer mapping opportunities has been enhanced via the supported and available payload structure properties.

Opportunity to state resiliency-route-constraint to enable enhanced protection route requests

TAPI v2.1.3 provided opportunities to state constraints on the overall connectivity service but not on individual routes supporting that service.

TAPI V2.4.0 supports resiliency-route-constraint where there is an opportunity for multiple instances per connectivity-service. This allows the client to state constraints per priority route and hence guide the layout of each route.

Expansion of UNI and ENNI models to cover key patterns

Many examples of provisioning scenarios explaining how to use the CSEPs, SIPs etc. at various points in the network illustrating several alternative UNI models with different degrees of simplification, enhanced ENNI structures and asymmetric network structures as well as structures including use of serial compound link connections.

Figure 6-16 Asymmetric Scenario 1: Handoff at ODU4 Layer, no ODU2 layer on ENNI

Clarification of tapi-notification usage to improve interoperability consistency

The definition in TAPI v2.1.3 TR-547 v1.1 provided a flexible approach to RESTCONF notifications but did not sufficiently guide/constrain the implementation. 

TAPI v2.4.0 TR-547 v2.0:

• Makes general updates to RESTCONF notification definition. 
• Provides improvements to RESTCONF stream discovery. 
• Enhances definition of notification generation including guidelines on which notifications should be generated and when they should be generated (provided in a companion document for both tapi-notification and tapi-streaming). 
• References a companion document on Notification and Streaming sequences.
• Uses a formal object creation approach now aligned with the approach used in TAPI v2.1.3 for tapi-streaming (for creations and change) where the notification structure is augmented with the object to be created.

Extensive enhancements to the provisioning scenarios to deal with broader network variety

Opportunity to apply constraints to connectivity-service requests have been enhanced. Structures have been added to allow for explicit layer protocol constraints, removing the need for CSEP-based workarounds. Further detailed scenarios and drawings of key structures have been added and there has been a review of SIP / NEP / CEP / CSEP parameters that has significantly improved the model.

Figure 6-8 ODUk Serial Compound Link Connection Connectivity Service

Network topology descriptions have been enhanced to explain support for a wider range of solutions with a variety of arrangements of media channel termination allowing for cases where there is only a single level of media channel including the case where there is an OTSiMC directly routed over an OMS.

Media Channel provisioning has been enhanced to enable specification based on ITU-T n and m parameters as an alternative to explicit spectrum statements.

Some existing use cases have been adjusted to drive service provisioning from the DSR/ODU perspective as opposed to OTSi/OTSiA. For example, use case 1d in TR-547 v2.0 is now “DIGITAL_OTN with PHOTONIC_MEDIA/OTSi Service Provisioning” whereas in TR-547 v1.1 it was “Unconstrained PHOTONIC_MEDIA/OTSi Service Provisioning”. The essential outcome of the use case is the same, but the change of focus recognizes the purpose of the use case as opposed to the underlying realization.

Major clarification of conditional property statements to improve compliance opportunity

Extensive improvements to Mandatory / Conditional statements in use cases in TR-547. Many previously mandatory properties have been clarified as conditional. Some improvements have also been made to conditional statements related to read/write properties. Conditional mandatory statements moved to YANG descriptions in tapi-equipment as part of an ongoing activity.

Other enhancements

• Several enumerations converted to identities to allow extension.
• Some RPCs removed and some deprecated (all RPCs will be removed in a later release).
• All frequencies in Hz.
• strand-joint added to allow detailed modeling of impairments at joints and junctions.
• Use of plug ID in OTN clarified
• access-port identifies supported SIP (in addition to NEP identifying supported SIP).
• Internal points added to connectivity service to allow specification of intermediate constraints.
• General improvements to structures of the model and RIAs.
• yang-version “1.1” used throughout.
• Comments improved throughout.
• Conditional constraints added to some yang descriptions (aim to add more in future releases).
• TAPI Data API list has been enhanced.
• Transitional Link is deprecated.
• Layer Protocol Constraints added for multi-layer provisioning (and workarounds deprecated).
• Global and local object usage clarified.
• RESTCONF root tree discovery clarified.

TAPI v2.4.0 is available at https://github.com/OpenNetworkingFoundation/TAPI/releases/tag/v2.4.0.

Acknowledgements

Thanks for the many contributions over the years by team members, from previous and related activities and from other bodies such as TIP and OIF.

Further Background Details

The ONF Transport API (TAPI) project charted under the ONF Open Transport Configuration & Control (OTCC) is responsible for the development of this SDK as an Open Source project.

TAPI is derived from the ONF Core model TR-512_v1.5_OnfCoreIm.

The TAPI project is an open community driven by contribution and collaboration between operators, vendors and other industry bodies.

TAPI features evolve from requirements through use cases to Information Model then YANG. The development sequence is not strict, so requirements are refined as the Information Model is developed etc.

TAPI is extensible to allow vendor proprietary features to be added as appropriate.

The previous widely deployed release of TAPI is TAPI v2.1.3 including:

• TR-547-TAPI-v2.1.3-ReferenceImplementationAgreement 
• TR-548-TAPI_v2.1.3_ReferenceImplementationAgreement-Streaming

Bios

Nigel Davis (Ciena)

Nigel Davis is a Systems Design Architect at Ciena and is a key innovator in multi-layer information modeling and standards.  He was recognized as a Ciena Technical Fellow in 2015 for his efforts within Ciena and in the industry.   Nigel has been active in the TeleManagement Forum, where he has been recognized as a Distinguished Fellow. He is now focusing on work in the Open Networking Foundation (ONF) where he co-leads the Open Information Model and Tooling (OIMT) project, is the editor of and a key contributor to the ONF Core Information Model, is an editor of and a key contributor to ONF Transport API (TAPI) specifications and is on the Technical Steering Team for the Open Networking Foundation (ONF) Open Transport Configuration and Control project. Nigel has several patents in the area of management and control.

Ramon Casellas (CTTC)

Ramon Casellas graduated in Telecommunications Engineering in 1999 both from UPC, Barcelona and ENST Paris, where he completed a PhD degree in 2002. After working as an Associate Professor (2002-2005) he joined CTTC in 2006, where he currently is a Research Director. He has participated in several R&D projects funded by EC, Spanish National Research programmes, and industrial contracts and published over 250 conference and journal papers in the field of Optical Networking. He has served as ONDM Program/General Chair (2018, 2020), and OFC2021 Program/General Chair (2021, 2023) and as JOCN Associate Editor. He has co-authored over 10 Internet Engineering Task Force (IETF) RFCs and drafts in the TEAS, PCE and CCAMP Working Groups. He is a contributor of the Open Networking Foundation (ONF) Open Transport Configuration & Control (OTCC) and a member of the Open Disaggregated Transport Networks (ODTN) project use case and software working groups. He has been an IEEE CommSoc and OFC short course instructor on the topic of SDN for Optical Networks. His research interest areas include GMPLS/PCE architecture, Software Defined Networking (SDN), Network Function Virtualization (NFV), Traffic Engineering and Distributed control schemes, with applications to Optical and Disaggregated Transport Networks.

Andrea Mazzini (Nokia)

Andrea Mazzini is a senior systems and standards engineer at Nokia. He has been working in telecom network management for almost 30 years. He has contributed to ITU-T, TM Forum, MEF and ONF organizations, mainly regarding network management for SDH, ASON/GMPLS, MPLS, Ethernet, DWDM/OTN technologies, while being involved in several integration projects, internal and multi-vendor, for common management interfaces enabling end-to-end provisioning solutions.
Contribution to TM Forum for a decade, designing MTNM and MTOSI standard management interfaces, most relevant model fragments Control Plane enhanced networks (ASON/GMPLS) and MPLS-TP networks.
Editor of MEF 59 (Resource Model: Ethernet Connectivity), MEF 72/72.1 (Resource Model: Subscriber and Operator Layer 1 Connectivity), MEF 83 (Resource Model: Ethernet OAM), MEF 89 (Resource Model Common).
Currently member of Technical Steering Team of Open Transport Configuration & Control Project at ONF. Editor and key contributor of ONF TAPI Information Model and Reference Implementation Agreement for the multi-layer management of Topology, Connectivity, Equipment and OAM for Ethernet, Digital OTN and Photonic Media technologies. Reviewer of ONF Core Info Model TR-512.