5G networks require a significant increase in the number of cell sites as compared to their predecessors to support an enormous increase in the number of connected devices, from mobile phones to multitudes of IoT sensors. In addition, routing services are required in those locations to support the heterogeneous requirements in latency and bandwidth for the different types of 5G applications, from latency-sensitive URLLC applications to bandwidth-hungry eMBB applications. Both requirements translate into an increase by one to two orders of magnitude in the number of routers needed in 5G access networks. Traditional mechanisms for network operation and management, many of them still manual and operating at the device level, simply do not scale to manage the volume of routers and devices in an effective and efficient manner. There is a clear realization within the operator community that a different approach is needed.
A new approach based on automatic network control and programmability is being pushed by many relevant members of the operator community within the Telecom Infra Project (TIP) umbrella. The proposed Open Transport Strategy describes a Software-Defined Networking (SDN) architecture within the framework of open and disaggregated networking that includes separation of the data plane and control plane, with data plane running in white boxes and control plane running as a NOS in the device or as microservices in the cloud. This architecture proposes that all network elements present in the access network at the wireless (e.g., radio units), optical (e.g., concentrators) and IP domains (e.g., routers) expose a common management interface through their North Bound Interface (NBI). This approach has a number of advantages:
- It enables managing network elements per network domain instead of per vendor, irrespective of the vendor.
- It enables management by a single, centralized entity (at least a single per domain entity), known as the SDN Controller.
- It enables replacing a network element from one vendor with another network element from another vendor in a seamless manner.
This is a significant departure from the current situation, where each network element vendor may expose its own proprietary NBI, and network elements are managed on a per “vendor domain” basis. This leads to complexity and vendor lock-in for operators. Those inefficiencies and limitations are eliminated with the common NBI across all network elements in the same domain (IP, wireless, optical), and a single SDN controller per domain, as proposed in the Open Transport SDN architecture. Similarly, this architecture also proposes an analogous interface between the SDN controllers and the OSS systems. Instead of OSS systems having to interact with proprietary NBIs from NMS vendors (or even directly with proprietary NBIs from device vendors), OSS interact with a single NBI from the SDN controllers.
NETCONF/YANG is the technology selected to support a common, per domain network element NBI across all vendors. NETCONF enables open transport using standard technologies such as XML, and YANG models enable open, vendor-agnostic descriptions of the functionalities that network elements support, using a common data description language (YANG). This approach enables replacing one network element from one vendor with another network element from another vendor in a transparent way, because both network elements support the same functionality by adhering to the required YANG models, and expose them in the same way through a standard NBI based on NETCONF/YANG.
YANG model standardization is currently happening at IETF and OpenConfig organizations, with OpenConfig more focused on individual network element functionality, and IETF taking a more holistic approach and including not only YANG models for network elements, but also service level models that are requested by OSS systems and require configuration across multiple individual network elements (note that IETF and OpenConfig YANG models are not compatible with each other, something that poses some interoperability risks that need to be managed by operators).
The approach outlined in the Open Transport SDN architecture crucially opens the door for network control automation, because OSS systems can interact through open standards and a single NBI interface with SDN Controllers to request services’ configuration such as L2VPN or L3VPN services, and the SDN controllers can in turn implement and manage those services by communicating with all network elements involved, also using open standards and a NETCONF/YANG-based NBI interface.
This approach is a step forward towards automatic network control via programmability. If the NBI interface of network elements also include support for gathering topology information (e.g., via standard BGP-LS and LLDP protocols), event information (e.g., via YANG Push), and support for traffic engineering (e.g., via standard PCEP protocol), the SDN controller can use all this information as input to PCE. Performance management and fault management algorithms that would automatically determine the actions required to maintain services up and running. For example, this may mean draining a faulty link and redirecting traffic to another path to ensure the levels of service required are maintained. When these actions are automatically communicated to network elements to be implemented, an automated closed-loop mechanism is effectively in place, which is the last component needed to essentially enable the ultimate goal of automatic network control via programmability: the advent of true self-driving networks.