Introduction to SDN Controller

1. Introduction to SDN and controller

SDN (Software Defined Network) is a new network innovation architecture proposed by the Clean-Slate research group of Stanford University in the United States. It is a way to implement network virtualization. Its core technology is to separate the control plane from the data plane of network devices to achieve flexible control of network traffic and make the network smarter. SDN attempts to get rid of the network's dependence on hardware devices and realize network management, configuration, and upgrade functions through direct programming.

Fig1. Typical SDN architecture diagram

The SDN controller is the representative of the SDN control plane and the brain of SDN. As the core component of the SDN architecture, the SDN controller manages the policies and traffic of the entire network in a centralized manner. The SDN controller can significantly improve the utilization of network resources, shorten the service launch cycle, and greatly improve operation and maintenance efficiency. At the same time, the SDN controller can provide a unified security policy and provide top-down security protection for the network.

2. Development History of SDN Controllers

SDN controllers have gone through several development stages from the early NOX controllers to today's enterprise-level controllers. Their functions have gradually become more complete and powerful. According to their development routes, they can be divided into: open source routes represented by ODL and ONOS, and commercial controller routes represented by Orion.

➢ First-generation controller: NOX is the first OpenFlow controller, which uses the OpenFlow protocol for control. It was developed by Nicira Networks and released as open source in 2008. As the earliest controller, NOX provides a good example for subsequent controllers. However, since it is written in C++, the development cost of SDN applications is high, and it gradually loses its advantage in the controller competition. Its subsequent version was changed to Python development, named POX, but POX has certain defects in architecture and performance, and is gradually replaced by emerging controllers.

➢ Universal SDN control platform: As equipment manufacturers join the competition in the SDN controller market, higher requirements are put forward for SDN controllers. OpenDaylight, an open source SDN controller jointly developed by multiple equipment manufacturers rather than dominated by operators, came into being. ODL supports multiple southbound protocols, not limited to OpenFlow, Netconf, OVSDB, etc. The birth of ODL means that SDN has entered a new era. Controllers have evolved from supporting only a single protocol to supporting multiple southbound protocols. During this period, the deployment form of controllers has also changed from single application to distributed platform deployment.

After several years of development, competition among SDN controllers has become increasingly fierce. With the strong support of equipment manufacturers, the ODL community is in a leading position in open source controllers. Targeting the operator market, ONOS, which also uses the OSGI architecture, has gained a considerable market share with better performance. At the same time, a variety of closed-source frameworks are also competing with each other. In 2013, the ONIX controller launched by Google increased the broadband utilization rate to nearly 100%.

➢ Cloud-native SDN controller: As more and more businesses move to the cloud, especially with the development of large-scale data centers, the requirements for controllers are getting higher and higher. SDN controllers are increasingly integrated with cloud management platforms. SDN controllers are developing in a smarter and more convenient direction by combining AI technology, intent-based networks, and other content. Open source platforms such as ODL and ONOS are gradually focusing on intelligent operation and maintenance. Google's new generation controller Orion fully applies microservice architecture and coordination concepts, adopts large-scale distributed deployment solutions, and realizes the control and management of large-scale production networks.

3. Introduction to mainstream controllers

The controllers currently active in the open source community include: OpenDayLight, ONOS, Ryu, POX, etc. The closed source controllers are represented by Orion, HP's VAN, Cisco's DNA Center, etc.

Each controller has its own characteristics and advantages. Here we will introduce the relevant technologies and functions of several mainstream controllers:

3.1 ODL Controller

The OpenDayLight (ODL) controller is an open source SDN controller managed and maintained by the Linux Foundation. It was launched in 2013. It adopts a community-driven development model, and the main contributors are major equipment manufacturers, such as Huawei and ZTE. It aims to provide a universal, programmable SDN controller. It can support a variety of hardware and software platforms to achieve flexible and scalable network management and control.

3.1.1 Architecture Solution

ODL is developed using the OSGi framework, and the southbound protocol is abstractly modeled and managed through the MD-SAL model architecture, achieving decoupling from devices and protocols, and supporting a variety of southbound transmission protocols. The core plug-in in the controller provides functions such as data storage, configuration management, network traffic management, service quality management, network monitoring and debugging, and provides docking with third-party applications through northbound protocols such as RESTful API, providing device data support for third-party services.

The figure below shows a typical ODL architecture design:

picture

Image source: OpenDayLight official website

3.1.2 Core Concepts

• Model-driven: ODL's model-driven approach means that the configuration and status information of network devices is represented as a YANG data model, which uniformly describes the properties, configuration, and status information of network devices, and defines a set of standard RESTful APIs based on the YANG model for communication between controllers and devices. ODL implements multi-protocol support, plug-in, and programmability through the YANG model.
• OSGi: ODL is based on the OSGi framework for functional development, which naturally supports modular design, allowing users to easily add and delete functions. At the same time, the Karaf framework provides a good operating base, which can easily achieve high availability of business and reduce the difficulty of development.
• Yang: A lightweight data modeling language. The YANG model defines the hierarchical structure of data. ODL uses YANG to define network configuration, which can easily distinguish between configuration and status and has strong scalability. With the promotion of standardization, YANG is gradually becoming the mainstream data description specification in the industry. Standard organizations, manufacturers, operators, and OTTs have defined their own YANG models.

3.1.3 Typical modules

• AAA: AAA stands for Authentication, Authorization and Accounting, which provides authentication, certification and accounting functions for the controller. This module is used to control access to resources, enforce resource usage policies, and audit and count resource usage, providing effective network management and basic security architecture for the controller.
• BGPCEP: This module is a typical application module, mainly composed of BGP plug-in and PCEP plug-in. BGP plug-in provides users with the implementation of BGP protocol and the implementation of services based on BGP protocol. PCEP is a path calculation communication protocol used for communication between PCC and PCE in the context of MPLS and GMPLS label switching paths. The PCEP plug-in provides all the basic service units required to build a PCE-based controller. In addition, it also provides LSP management functions for Active Stateful PCE, which is the cornerstone of most SDN solutions that support PCE.

The following figure shows the PCE-based path calculation architecture:

Image source: OpenDayLight official website

• Controller: The controller module is a Java-based model-driven controller that uses YANG as the modeling language for various aspects of the system and application, providing a basic platform for other OpenDaylight applications. It relies on modules such as MD-SAL, Netconf, and RestConf.
• MD-SAL: Model Driven Service Adaptation Layer (MD-SAL) is an extensible middleware component inspired by message buses that provides messaging and data storage capabilities based on data and interface models defined by application developers (i.e. user-defined models). This module defines common layers, concepts, data model building blocks, and messaging patterns, and provides infrastructure/framework for applications and inter-application communication.
• Netconf module: NETCONF itself is an XML-based transport protocol used to configure and monitor devices in the network. The Netconf module in ODL supports the NETCONF protocol as a northbound server and southbound plug-in, and also provides a set of tools for simulating NETCONF devices and client testing.

3.2 ONOS Controller

ONOS is the first open source SDN network operating system, mainly for service providers and enterprise backbone networks. The ONOS community brings together well-known service providers (such as AT&T, NTT Communications), high-standard network suppliers (such as Ciena, Ericsson, Fujitsu, Huawei, Intel, NEC), network operators (such as Internet2, CNIT, CREATE-NET), and other partners (such as SRI, Infoblox), and has received strong support from ONF.

3.2.1 Architecture Solution

ODL is a typical distributed architecture system, which can be divided from top to bottom into: APP layer, northbound interface API, distributed core layer, and southbound interface layer. Among them, the distributed core platform ensures that the controller can operate with high reliability, easy scalability and high stability. The northbound interface abstraction provides important support for the graphical interface and more friendly management and configuration services. The pluggable southbound interface abstraction layer enables the ONOS controller to support OpenFlow devices and traditional devices. The abstraction of the southbound interface shields the differences between the underlying devices and protocols, and can support the management and control of multiple devices at the same time. Its architecture diagram is as follows:

Image source: ONOS official website

3.2.2 Core Concepts

SDN operating system: An operating system needs to have the following basic characteristics:

(1) User resource management;

(2) User isolation;

(3) Abstract management of services and resources;

(4) User security mechanism;

(5) Efficient use of services.

ONOS has the basic functions of an operating system, so it is not just an SDN controller, but an SDN operating system.

• Software modularity: ONOS can provide developers and service providers with faster and more convenient development, debugging, maintenance and upgrade services, just like a software operating system. ONOS itself is composed of a series of functional modules, each of which is composed of one or more components, providing a specific service to the outside world. This SOA-based framework also supports the full life cycle management of components and supports dynamic loading and unloading of components.
• Unified network model: ONOS abstracts a unified network resource and network element model, laying the foundation for interoperability of third-party SDN applications, allowing operators to perform flexible business collaboration and low-cost business innovation.

3.2.3 Typical components

• REST API: Provides an open northbound abstract interface to facilitate operators and users to develop applications and plug-ins based on ONOS.
• Functional components: ONOS provides a unified network resource and network element model, which is more conducive to operators' business development. The unified component and model structure is shown in the following figure:

[Quoted from the ONOS components and services section in feiskyer]

Image source gitbook-SDN Guide

• Cluster: ONOS cluster communication supports two algorithms, Gossip and Raft. Cluster provides good partition fault tolerance and elastic expansion mechanism. Cluster can ensure that node failure has no impact on the business. When an ONOS node goes down, other nodes will take over the control of the node over the network element. When the node is restored, the loadbalance command is used to restore the node's control over the network element and achieve load balancing for the overall control. ONOS shields the responsible distributed mechanism and only exposes the business interface to the outside, making application development simpler. The cluster mechanism is as follows:

[Quote from the ONOS cluster principle section in feiskyer]

Image source gitbook-SDN Guide

3.3 Orion Distributed Controller

The Orion controller is a second-generation controller independently developed by Google. Google published a paper on Orion at the 2021 NSDI conference, which detailed the design principles, overall architecture, and application of Orion in the network. When the paper was published, Orion had been running stably in the existing network for four years. Compared with Google's first-generation controller Onix, Orion has the following features:

(1) Completely independent development.

(2) Microservice architecture and distributed programs have higher stability.

(3) Based on agile development, faster iteration speed.

3.3.1 Architecture Solution

Orion is a typical microservice application. Its working mode is based on the reconciliation mode. From the fundamental design principle, the principles of Orion and Kubernetes are almost the same.

The overall framework is as follows:

Image source: Orion: Google's Software-Defined Networking Control Plane

From an architectural perspective, the top layer is various specific network applications, such as the Routing Engine responsible for intra-domain route calculation.

The core layer in the middle implements the common functions of the controller, including the NIB database, configuration module, topology module, and flow management module. Each module in the middle layer is a microservice application.

The lower layer is the OpenFlow protocol stack. All routers controlled by Orion only have the OpenFlow protocol stack and no traditional protocol stack. Traditional protocols are all completed on the controller, which can be said to have completely realized SDN.

3.3.2 Core Concepts

• Intent-driven: Orion is designed for large-scale production networks. In large-scale production networks, macro intentions are far more stable and less prone to errors than tedious processes, so intent-based has become an inevitable choice. Orion itself is designed as a controller that translates and refines intents. The controller will eventually convert the manager's intent into Openflow primitives that can be recognized by the device. The Intent chain reaction diagram is as follows:

Image source: Orion: Google's Software-Defined Networking Control Plane

• Distributed controller: Traditional controllers are mostly centralized controllers, where controller units are managed by a center and multiple sub-centers, while Orion adopts logical centralization. The paper mentions: The controller is a logically centralized controller. In order to achieve high performance, the controller needs to have a memory-based state representation and use an appropriate consistency level between loosely coordinated microservice SDN applications [Quoted from the first chapter of "Orion: Google's Software-Defined Networking Control Plane"].

3.3.3 Typical Design

• Microservice framework: Orion has completely gotten rid of the centralized control constraints of traditional controllers. It is designed with an architecture similar to K8S, abstracting network services into independent services, which facilitates business development, deployment, and maintenance. In the era of cloud computing, the design concept based on microservice architecture is more in line with the implementation and deployment of business.
  
  The microservice framework is an important development direction for SDN controllers in the future. The SDN controller developed by China Mobile's Smart Home Operation Center divides network services based on the microservice architecture and uses a coordination mechanism to achieve efficient service configuration and scheduling.
• Chain reaction of intent and ground truth : As shown in the intent network above, intent comes from multiple sources. Through the coordination of controllers at each level, the configuration is finally converted into machine primitives. In the intent network, the ultimate starting point is human intent.

As written in the paper: "Intentbased networks specify management or design changes by describing the new intended end-state of the network (the "what") rather than prescribing the sequence of modifications to bring the network to that end-state (the "how") [citing the description of the principles of intent networks in 3.1 of the paper "Orion: Google's Software-Defined Networking Control Plane"]".

4. Summary

Through the above brief introduction, we have learned about the development history and direction of controllers, which provides a good reference and example for our self-developed controllers.

At present, China Mobile's Smart Home Operation Center has accumulated certain technical experience in the field of self-developed controllers, especially self-developed controllers for SDWAN. The open source controller based on ODL has been trial-commercialized in some of the company's businesses and has achieved good results. China Mobile's Smart Home Operation Center is evolving its self-developed controllers into microservice-based distributed controllers. In the future, controllers based on microservice architecture will provide support for the development of the mobile network cloud era with faster iteration speed, more stable performance, and higher service efficiency.