T-API taps into the transport layer

This article originally appeared on Gazettabyte by editor Roy Rubenstein: http://www.gazettabyte.com/home/2018/8/20/t-api-taps-into-the-transport-layer.html

The Optical Internetworking Forum (OIF) in collaboration with the Open Networking Foundation (ONF) and the Metro Ethernet Forum (MEF) have tested the second-generation transport application programming interface (T-API 2.0).

SK Telecom’s Park Jin-hyo

T-API 2.0 is a standardised interface, released in late 2017 by the ONF, that enables the dynamic allocation of transport resources using software-defined networking (SDN) technology.

The interface has been created so that when a service provider, or one of its customers, requests a service, the required resources including the underlying transport are configured promptly.

The OIF-led interoperability demonstration tested T-API 2.0 in dynamic use cases involving equipment from several systems vendors. Four service providers – CenturyLink, Telefonica, China Telecom and SK Telecom – provided their networking labs, located in three continents, for the testing.

Packets and transport 

SDN technology is generally associated with the packet layer but there is also a need for transport links, from fibre and wavelength-division multiplexing technology at Layer 0 through to Layer 2 Ethernet.

Transport SDN differs from packet-based SDN in several ways. Transport SDN sets up dedicated pipes whereas a path is only established when packets flow for packet SDN. “When you order a 100-gigabit connection in the transport network, you get 100 gigabits,” says Jonathan Sadler, the OIF’s vice president and Networking Interoperability Working Group chair. “You are not sharing it with anyone else.”

Another difference is that at the packet layer with its manipulation of packet headers is a digital domain whereas the photonic layer is analogue. “A lot of the details of how a signal interacts with a fibre, with the wavelength-selective switches, and with the different componentry that is used at Layer 0, are important in order to characterise whether the signal makes it through the network,” says Sadler.

T-API 1.0 is a configure and step-away deployment, T-API 2.0 is where the dynamic reactions to things happening in the network become possible

Prior to SDN, control functions resided on a platform as part of a network’s distributed control plane. Each vendor had their own interface between the control and the optical domain embedded within their platforms. T-API has been created to expose and standardise that interface such that applications can request transport resources independent of the underlying vendor equipment.

NBI refers to a northbound interface while SBI stands for a southbound interface. Source: OIF.

To fulfil a connection across an operator’s network involves a hierarchy of SDN controllers. An application’s request is first handled by a multi-domain SDN controller that decomposes the request for the various domain controllers associated with the vendor-specific platforms. T-API 2.0’s role is to link the multi-domain controller to the application layer’s orchestrator and also connect the individual domain controllers to the multi-domain SDN controller (see diagram above). T-API is an example of a northbound interface.

The same T-API 2.0 interface is used at both SDN controller levels, what differs is the information each handles. Sadler compares the upper T-API 2.0 interface to a high-level map whereas the individual TAPI 2.0 domain interfaces can be seen as maps with detailed ‘local’ data.  “Both [interfaces] work on topology information and both direct the setting-up of connections,” says Sadler. “But the way they are doing it is with different abstractions of the information.”

T-API 2.0

The ONF developed the first T-API interface as part of its Common Information Model (CIM) work. The interface was tested in 2016 as part of a previous interoperability demonstration involving the OIF and the ONF.

One important shortfall revealed during the 2016 demonstrations, and which has slowed its deployment, is that the T-API 1.0 interface didn’t fully define how to notify an upper controller of events in the lower domains. For example, if a link is congested, or worst, lost, it couldn’t inform the upper controller to re-route traffic. This has been put right with T-API 2.0.

“T-API 1.0 is a configure and step-away deployment, T-API 2.0 is where the dynamic reactions to things happening in the network become possible,” says Sadler.

When it comes to the orchestrator tying into the transport network, we do believe T-API will be one of the main approaches for these APIs

Interoperability demonstration

In addition to the four service providers, six systems vendors took part in the recent interoperability demonstration: ADVA Optical Networking, Coriant, Infinera, NEC/ Netcracker, Nokia and SM Optics.

The recent tests focussed on the performance of the TAPI-2.0 interface under dynamic network conditions. Another change since the 2016 tests was the involvement of the MEF. The MEF has adopted and extended T-API as part of its Network Resource Modeling (NRM) and Network Resource Provisioning (NRP) projects, elements of the MEF’s Lifecycle Service Orchestration (LSO) architecture. The LSO allows for service provisioning using T-API extensions that support the MEF’s Carrier Ethernet services.

Three aspects of the T-API 2.0 interface were tested as part of the use cases: connectivity, topology and notification.

Setting up a service requires both connectivity and topology. Topology refers to how a service is represented in terms of the node edge points and the links. Notification refers to the northbound aspect of the interface, pushing information upwards to the orchestrator at the application layer. This allows the orchestrator in a multi-domain network to re-route connectivity services across domains.

The four use cases tested included multi-layer network connections whereby topology information is retrieved from a multi-domain network with services provisioned across domains.

T-API 2.0 was also used to show the successful re-routing of traffic when network situations change such as a fault, congestion, or to accommodate maintenance work. Re-routing can be performed across the same layer such as the IP, Ethernet or optical layer, or, more optimally, across two or more layers. Such a capability promises operators the ability to automate re-routing using SDN technology.

The two other use cases tested during the recent demonstration were the orchestrator performing network restoration across two or more domains, and the linking of data centres’ network functions virtualisation infrastructure (NFVI).  Such NFVI interconnect is a complex use case involving SDN controllers using T-API to create a set of wide area networks connecting the NFV sites. The use case set up is shown in the diagram below.

Source: OIF

SK Telecom, one of the operators that participated in the interoperability demonstration, welcomes the advent of T-API 2.0 and says how such APIs will allow operators to enable services more promptly.

“It has been difficult to provide services such as bandwidth-on-demand and networking services for enterprise customers enabled using a portal,” says Park Jin-hyo, executive vice president of the ICT R&D Centre at SK Telecom. “These services will be provided within minutes, according to the needs, using the graphical user interface of SK Telecom’s network-as-service platform.”

SK Telecom stresses the importance of open APIs in general as part of its network transformation plans. As well as implementing a 5G Standalone (SA) Core, SK Telecom aims to provide NFV and SDN-based services across its network infrastructure including optical transport, IP, data centres, wired access as well as networks for enterprise customers.

“Our final goal is to open the network itself to enterprise customers via an open API,” says Park. “Our mission is to create 5G-enabled network-slicing-based business models and services for vertical markets.”

Takeways

The OIF says the use cases have shown that T-API 2.0 enables real-time orchestration and that the main shortcomings identified with the first T-API interface have been addressed with T-API 2.0.

The OIF recognises that while T-API may not be the sole approach available for the industry – the IETF has a separate activity – the successful tests and the broad involvement of organisations such as the ONF and MEF make a strong case for T-API 2.0 as the approach for operators as they seek to automate their networks.

“When it comes to the orchestrator tying into the transport network, we do believe T-API will be one of the main approaches for these APIs,“ says Sadler.

SK Telecom said participating in the interop demonstrations enabled it to test and verify, at a global level, APIs that the operators and equipment manufacturers have been working on. And from a business perspective, the demonstration work confirmed to SK Telecom the potential of the ‘global network-as-a-service’ concept.

Editor note: Added input from SK Telecom on September 1st. 

OIF INTEROPERABILITY TEST VALIDATES TRANSPORT APPLICATION PROGRAMMING INTERFACE (T-API) 2.0 MARKET-READINESS – RESULTS PUBLISHED IN NEW WHITE PAPER

August 7, 2018  Leah Wilkinson

Successful collaborative demo identified multiple success points and areas where additional work is needed to enhance performance – white paper to provide deep dive and outline specifics

Fremont, Calif.—August 7, 2018 – Detailed results from the OIF’s (Optical Internetworking Forum) 2018 Software-Defined Networking (SDN) Transport Application Programming Interface (T-API) multi-vendor interoperability demonstration showcasing new dynamic behavior use cases and deployment scenarios are available in a white paper published today. To request a copy, please go here.

Demo results were initially announced at a public read-out at NGON in Nice, France, and at two invitation-only events earlier this month at CenturyLink and China Telecom. An additional read-out was held last week during MEF’s Annual Meeting in Nashville, Tenn.

Following a six-week testing period, the OIF released its findings through liaisons to industry bodies.  Among the findings are the following (additional details on the testing and results can be found in the white paper):

  • Open Networking Foundation (ONF) T-API 2.0 specifications have addressed the main issues identified in the OIF’s 2016 testing and provide a basis for real-time orchestration of on-demand connectivity setup, control and monitoring across diverse multi-layer, multi-vendor, multi-domain carrier networks
  • Additional scaling and performance enhancements will need to be addressed as T-API is deployed in real networks, such as refinements to the model, greater detail in error codes to improve debugging properties, and potential implementation options such as a separate server for notifications of network events
  • The API allows for some variability in the use of topology abstraction depending on business requirements and technology; documentation of supplementary examples for topology abstraction will help application and orchestration software developers.

“Standardized and open SDN APIs reduce complexity in intra and inter-domain operations, allowing us to provide more diverse services to our customers in less time,” said Park Jin-hyo, EVP of ICT R&D Center at SK Telecom. “After successfully completing the test trial, SK Telecom will keep engaging in 5G transport network and service development by opening APIs and transforming the current infrastructure into Network-as-a-Service (NaaS) Platform.”

The multi-vendor demo led by four network operator labs included lab-deployed and cloud-deployed systems testing new dynamic behavior use cases and deployment scenarios. The demo also incorporated service provisioning scenarios at the LSO Presto reference point in the MEF LSO architecture, using the MEF NRP Interface Profile Specification (MEF 60), which defines extensions to T-API in support of Carrier Ethernet services.

Participating network operators were CenturyLink, China Telecom, SK Telecom and Telefónica and vendors included ADVA, Coriant, Infinera, NEC/Netcracker, Nokia and SM Optics. Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) was a participating academic institution and TELUS Communications participated as a consulting network operator.

Additional information and an infographic can be found at http://www.oiforum.com/meetings-and-events/2018-oif-sdn-t-api-demo/

2018 OIF SDN Transport API Interoperability Demonstration

Committed to accelerating the commercialization of transport SDN worldwide, the Optical Internetworking Forum (OIF), in collaboration with MEF, will bring new dynamic behavior use cases and deployment scenarios into network operator labs around the world to test multi-vendor interoperability of the industry leading T-API 2.0 northbound interface (NBI) from the Open Networking Foundation (ONF). The 2018 Software-Defined Networking (SDN) Transport Application Programming Interface (T-API) interoperability demonstration builds on the OIF’s 2016 interoperability test and demonstration which addressed multi-layer and multi-domain environments as well as on the 2014 demo which prototyped the use of Northbound APIs and helped advance transport SDN standardization. For an infographic of the demo, click here.

About the OIF

The OIF facilitates the development and deployment of interoperable networking solutions and services. Members collaborate to drive Implementation Agreements (IAs) and interoperability demonstrations to accelerate and maximize market adoption of advanced internetworking technologies. OIF work applies to optical and electrical interconnects, optical component and network processing technologies, and to network control and operations including software defined networks and network function virtualization. The OIF actively supports and extends the work of national and international standards bodies. Launched in 1998, the OIF is the only industry group uniting representatives from across the spectrum of networking, including many of the world’s leading service providers, system vendors, component manufacturers, software and testing vendors. Information on the OIF can be found at http://www.oiforum.com

 

PR Contact:

 

Leah Wilkinson

Wilkinson + Associates for the OIF

Email: leah@wilkinson.associates

Office: +1-703-907-0010