5G: SDN IP/MPLS Backbone
Over the past few years all the telecommunications industry actors, including vendors, network service providers, standardization bodies (e.g., IETF, GSMA), and industry fora (e.g., ONF, OIF, OpenConfig, TMForum) have been working toward the habilitation of automatic network control and programmability. Many efforts have been made to make software defined networking (SDN) a reality, hence a large number of architectural frameworks have been proposed. It’s now time to define a common strategy to reduce and select the most suitable standards to unify disparate SDN solutions.
A worldwide, top-ranked network operators group—formed by Telefonica, Vodafone, MTN, Telia Company, DeutscheTelekom, and Orange—has joined efforts to collaborate on open transport SDN within the Telecom Infra Project’s Open Optical and Packet Transport (OOPT) project group. They’ll be leading a new workstream called MUST (Mandatory Use case requirements for SDN for Transport). This white paper presents its common architectural view, the use casebased methodology, and the selection of the most relevant standard interfaces to be implemented by the industry.
The target reference architecture for the transport SDN controllers is hierarchical, with specific domain controllers per technological domain (IP/MPLS, microwave, optical) and a hierarchical controller to provide real-time control of multi-layer and multi-domain transport network resources. The operation support systems (OSS)—including service orchestration and service and resource inventory—will be consuming a set of APIs exposed by the controllers to handle the data and configurations toward end users and enabling service fulfillment.
Based on common use cases defined by the operators, the set of standard SDN interfaces are selected and detailed to produce a common industry specification. The presented SDN architecture enables other systems in charge of planning, inventory, NFV orchestration, service orchestration, performance, or fault management to retrieve information and program the network with well-known, vendor-agnostic interfaces. The SDN controllers will enable resource configuration. The resource abstraction level exposed in the northbound interface (NBI) will depend on the use case definition and the technology considered.
Over the past few years all the telecommunications industry actors, including vendors, network service providers, standardization bodies (e.g., IETF, GSMA), and industry fora (e.g., ONF, OIF, OpenConfig, TMForum) have been working toward the habilitation of automatic network control and programmability. Many efforts have been made to make software defined networking (SDN) a reality, hence a large number of architectural frameworks have been proposed. It’s now time to define a common strategy to reduce and select the most suitable standards to unify disparate SDN solutions.
A worldwide, top-ranked network operators group—formed by Telefonica, Vodafone, MTN, Telia Company, DeutscheTelekom, and Orange—has joined efforts to collaborate on open transport SDN within the Telecom Infra Project’s Open Optical and Packet Transport (OOPT) project group. They’ll be leading a new workstream called MUST (Mandatory Use case requirements for SDN for Transport). This white paper presents its common architectural view, the use casebased methodology, and the selection of the most relevant standard interfaces to be implemented by the industry.
The target reference architecture for the transport SDN controllers is hierarchical, with specific domain controllers per technological domain (IP/MPLS, microwave, optical) and a hierarchical controller to provide real-time control of multi-layer and multi-domain transport network resources. The operation support systems (OSS)—including service orchestration and service and resource inventory—will be consuming a set of APIs exposed by the controllers to handle the data and configurations toward end users and enabling service fulfillment.
Based on common use cases defined by the operators, the set of standard SDN interfaces are selected and detailed to produce a common industry specification. The presented SDN architecture enables other systems in charge of planning, inventory, NFV orchestration, service orchestration, performance, or fault management to retrieve information and program the network with well-known, vendor-agnostic interfaces. The SDN controllers will enable resource configuration. The resource abstraction level exposed in the northbound interface (NBI) will depend on the use case definition and the technology considered.
Implementing a complete standard specification is a time-consuming process. To accelerate adoption, the operators have compiled the needs of multiple operations, engineering, and planning teams, and have selected the most relevant common use cases. Based on this, technical requirements are prepared and shared with the vendors. These specifications will be incorporated as part of future RFQ processes, which will facilitate a gradual implementation of the defined standards according to a given use case prioritization plan.
To achieve the open programmable transport networks goal, operators will require solution suppliers (both hardware and software—including network operating system and controller software) to include the selected standard interfaces in their commercial product releases, reducing the need for ad hoc development during solution deployment phase.
The operators signing this whitepaper encourage others to join and contribute toward defining and accelerating standardization and implementation of the required SDN interfaces and use cases needed for our transport networks.
This document summarizes the open transport SDN strategy with respect to the SDN, together with objectives and activities roadmap needed to accomplish the goal of a full automated IP/optical transport network. This document will not cover technical details associated with SDN [SDN1] and assumes the reader is familiar with the basic concepts.
Over the last few years operators have worked hard on network simplification, aiming to reduce complexity, maintenance needs, and operational burden, while simultaneously producing economic efficiencies within the respective areas. One step ahead, SDN aims to fulfill the same goals by advocating the need to separate the data plane (by transforming network switches to simple packet forwarding devices) from the control plane (by putting a centralized software component, also known as SDN controller, in control of entire network behavior).
It’s not foreseen that a complete separation or decoupling of the control plane is required to benefit from the high survivability of networks against failures, disaster recovery, et al. The more practical approach is to enhance network programmability through a hybrid, hierarchical SDN architecture, in which management and control functionalities are split between devices and a set of controllers.
By way of definition, service is always considered as the E2E service consumed by an end user and involves several domains and corresponding resources. Management of such services is achieved at the OSS/service orchestration layer. By contrast, the transport connectivity service refers to resources handled by the transport domain (IP/MPLS, optical, microwave), and can be considered as a part of the overall service.
The main goals of the SDN approach are:
• Agile Network Programmability – Enabling full network automation and reducing time-to-market of service introduction. This is achieved through a dynamic use caseoriented strategy and by standardizing network interfaces.
• Network Abstraction – Introducing the adequate level of abstraction at each layer of the architecture (network elements, domain controllers, hierarchical controller), simplifying the development of the OSSes and orchestrators. The first level is moving from a vendor-specific view of networks and devices to a technological one—agnostic from who is implementing the network function. The second level refers to specific use cases, where some device-level behavior is automatically inferred by the SDN control mechanisms. This facilitates interactions among components and therefore overall network automation.
• Open Transport Networks – Enabling deployment of open network devices at any transport layer (IP, optical, MW) as suppliers implement the same configuration interface. Controller interfaces will be based on generic functions, not on vendorspecific implementations, thereby reducing the vendor lock-in associated with closed management platforms that were to be used with their own devices.
• Network Intelligence – Enabling traffic engineering (TE) and automated service provisioning between layers and vendor technologies.