Deliverables, White Papers & Tech Reports

The purpose of this document is to define the technical requirements for an open and disaggregated aggregation router (DAR) solution that operators can deploy in their backhaul transport networks. It describes the required hardware and proposes non-mutually exclusive software packages to support additional services or functionalities.

The purpose of this document is to describe the technical requirements and recommendations for a Distributed Disaggregated Backbone Router P-Router and Internet Gateway (DDBR P & IGW) solution. It defines the shift from monolithic chassis-based IP backbone architecture to a disaggregated Spine & Leaf architecture and describes the technical aspects required to support P-Router and Internet Gateway use cases in IP core/backbone networks.

The purpose of this document is to define the detailed technical requirements for a Distributed Disaggregated Backbone Router (DDBR) P-Router and Internet Gateway solution. It provides the technical detail needed to support the transition from monolithic chassis-based IP backbone architecture to a disaggregated Spine & Leaf architecture, with a specific focus on P-Router and Internet Gateway use cases in IP core/backbone networks.

The purpose of this document is to define the technical requirements for a Distributed Disaggregated Backbone Router Provider Edge (DDBR-PE) solution. It describes the hardware required to support DDBR-PE deployments in current and future networks and proposes non-mutually exclusive software packages to support additional backbone services or functionalities.

The purpose of this document is to define the detailed technical requirements for a Distributed Disaggregated Backbone Router Provider Edge (DDBR-PE) solution. It provides the technical detail needed to support DDBR-PE deployments in current and future networks, with a specific focus on the hardware and software capabilities required to enable Provider Edge backbone services and related functionalities.

The purpose of this document is to define the technical requirements, as specified by the TIP MUST subgroup, for the Northbound Interface (NBI) exposed by an IP SDN Controller. The document focuses on the NBI requirements for IP Domain Controllers, including support for an IP Domain Path Computation Element.

The purpose of this document is to define the technical requirements for the Southbound Interface (SBI) between an IP SDN Controller and IP routers. It describes the SDN interface requirements to be exposed by IP/MPLS Network Elements, which are managed through the Southbound Interface of the IP SDN Controller.

The purpose of this document is to define the detailed technical requirements for the Southbound Interface (SBI) between an IP SDN Controller and IP routers. It provides the technical detail required for IP/MPLS Network Elements to expose an SDN interface that enables management through the Southbound Interface of the IP SDN Controller.

The purpose of this document is to define the technical requirements for the Southbound Interface (SBI) between an Optical SDN Controller and Open Terminals. It describes the Optical SDN Controller SBI requirements for Open Terminals as defined within the Open Optical Packet Transport (OOPT) working group.

The purpose of this document is to define the detailed technical requirements for the Southbound Interface (SBI) between an Optical SDN Controller and Open Terminals. It provides the technical detail required to support Open Terminal management through the Optical SDN Controller SBI, as defined within the Open Optical Packet Transport (OOPT) working group.

The purpose of this document is to define the detailed requirements and vendor response framework for Optical/O-OLS SDN Controller NBI solutions, including TAPI-based APIs, model support, notification and streaming behavior, alarm and TCA handling, and performance/scalability criteria aligned to the MUST Optical SDN Controller NBI TRD.

The purpose of this document is to define the detailed technical requirements for the Northbound Interface (NBI) of an Optical SDN Controller. It provides the technical detail required to support standardized control and management interfaces between network systems operating over WDM/OTN networks, including activation, configuration, service provisioning, path computation, fault management, and monitoring.

The purpose of this document is to define the technical requirements and recommendations for the Northbound Interface (NBI) of an Optical SDN Controller. It describes the standard use of the NBI to support control and management interfaces between network systems operating over WDM/OTN networks, including activation, configuration, service provisioning, path computation, fault management, and monitoring.

The purpose of this document is to define the technical requirements for MUST Optical SDN Controller Northbound Interface (NBI) v2.1. It covers the base requirements for an Optical SDN Controller NBI solution based on Transport API (TAPI) version 2.5.x, reflecting the transition from TAPI 2.1.3+ to TAPI 2.5.0+, which is not backward compatible. This version also addresses new management and control capabilities enabled by recent TAPI versions, including TAPI Streaming and Fault Management.

The purpose of this document is to define the use cases and technical requirements for a Wireless Backhaul SDN Domain Controller and associated network equipment. It addresses the need to move beyond vendor-specific Network Management Systems (NMS) and proprietary interfaces, which often require manual and static operations, configuration, and maintenance. The document focuses on reducing complexity for higher-level applications and OSS systems, particularly in microwave (MW) networks, where the number and technical complexity of proprietary interfaces can become difficult to manage at scale.

TIP Greenlight addresses these issues by the application of common and standards-based technologies:

This first release of TIP Greenlight focuses on the initial deployment of network elements with disaggregated hardware (e.g. a router or a transponder) and software components (“disaggregated devices”)

Future iterations of TIP Greenlight will build upon the flexible and extensible mechanisms contained in this document to deliver additional use cases.

IPoDWDM-capable routers’ coherent pluggable integration and management.

This Use Cases Definition document extends the current MANTRA Whitepaper: IPoWDM convergent SDN architecture – Motivation, technical definition & challenges with an extended description of the target applicability scenarios and use cases targeted by the TIP OOPT MANTRA operators subgroup.

The purpose of describing the optical planning use cases is to provide a base for reviewing how the function of online optical planning should be incorporated into the TIP MUST Open Transport SDN Architecture. The scope of the optical planning is to plan the properties of Open-Optical Networks O-ON with its O-OLS (Open-Optical Line System) and connected O-OLI (Open Optical Line Interfaces). To prepare a proposal for implementation of the use case functionality, all necessary topics of relevance should be reviewed. In section 4, input is given for consideration on a solution, however this is not a complete description but the first set of important topics shared by the operators. Any other topics of relevance have to be identified during the continuing work.

Performance data streaming in the network plays a vital part for many applications like monitoring, network management, closed loop automation, and much more. This is getting complex when it comes to optical transport network, where streaming of performance data from multiple domains is required to manage the end to end optical service.

Therefore, a systematic approach is required for telemetry data streaming from optical domain controllers to facilitate its utilization to northbound applications. The ONF TAPI v2.5 is proposed with a telemetry streaming improvements and recommended respective YANG models and protocols to effectively support streaming of performance data from multiple domains.

A worldwide top-ranked Network Operators group, formed by Telefonica, Vodafone, MTN, Telia Company,Deutsche Telekom and Orange, have joined efforts to collaborate on Open Transport SDN within the Telecom Infra Project Open Optical and Packet Transport (OOPT) project group. These operators will be leading a new workstream called MUST (MUST: Mandatory Use case requirements for SDN for Transport). This White Paper presents the common architectural view, the use case-based methodology and the selection of the most relevant standard interfaces to be implemented by the industry.

The purpose of this document is to summarize the CANDI Experimental Demonstration, including a series of packet and optical proofs of concept conducted by the CANDI work group. It captures key lessons learned from the trials and identifies issues and technology requirements needed to validate agreed use cases and assess the feasibility of operator use cases.

In this paper, we explain and outline the accomplishments and goals of the Open Optical & Packet Transport (OOPT) project group within Telecom Infra Project. This group defines open technologies, architectures and interfaces in Optical and IP Networking.

In this whitepaper, we explore the opportunities, use cases, and challenges of IP/Optical convergence through IP-over-WDM capable routers and we highlight the main objectives of the MANTRA Operator’s signing this whitepaper.

This Use Cases Definition document extends the current MANTRA Whitepaper: IPoWDM convergent SDN architecture – Motivation, technical definition & challenges [1] with an extended description of the target applicability scenarios and use cases targeted by the TIP OOPT MANTRA operators subgroup.

This paper provides the TIP OOPT MUST target architecture for Disaggregated Open Optical Networks. We describe the meaning of “Open”, the functions associated with the use cases and the degree of “Disaggregation” of the monolithic transport optical system.


The main sections of this white paper will discuss Open-Optical Terminals (O-OT), focusing on Open-Optical Line Interfaces (O-OLI), Open-Optical Line Systems (O-OLS), Open-Planning and Impairment Validation (O-PaIV) and the management guidelines via SDN and APIs.