Did you get the ONOS architecture analysis ？

Fancy Wang 1207 2021

ONOS is an SDN controller promoted by On.Lab, dedicated to providing Carrier-Grade's SDN basic platform. OnLab is an SDN open source organization initiated by Stanford. Since the establishment of On.Lab, ONOS has developed very rapidly. Compared with OpenStack and OpenDayLight's half-year version, ONOS's first bird, Avocet, was born in December 2014. This bird evolves every 3 months and has reached the second generation of MagPie. Compared with OpenDaylight's extensive application scenarios, ONOS focuses on the field of operators. From the perspective of success and failure, there are many top large operators in the world. Some universities and scientific research institutions with network infrastructure are also listed among them.

Because ONOS is more specific in its direction, it is also different from ODL in project-driven approach. ODL uses applications to drive use cases, while ONOS uses use cases to drive applications. There are often multiple applications under one use case for support. There are many use cases listed on the Wiki of ONOS. Some of the main ones are as follows: CORD (End Office Cloudization), SONA (Data Center Network Virtualization), Packet Optical Convergence (IP + Optical Coordination), IP RAN (Access Network) , SDN-IP (SDN and traditional IP domain intercommunication), VPLS (L2VPN), Seamless MPLS (end-to-end MPLS), Carrier Ethernet (Carrier Ethernet), PCE+ (PCEP-based path optimization), RR+ (BGP-based Traffic scheduling).

It can be seen that ONOS does do a lot of things around operators, but most of the use cases are still in the prototype design stage, and there are not many that can actually be put into commercial use or even PoC. There are only a few data centers, which will be introduced one by one later in this chapter. In this section, let’s take a look at the architecture of ONOS first.

7.1.1 Layered Architecture

The main body of ONOS is developed in Java. Like ODL, ONOS also uses Karaf. Users can dynamically load or unload various modules of ONOS according to their needs. ONOS has always maintained a layered structure in its architectural design. The middle layer is responsible for adapting between the application and the southbound protocol to shield the differences in the southbound protocol. This is similar to the AD-SAL architecture used in the early versions of ODL. of.

The architecture of ONOS, as shown in Figure 7-1, is divided into three layers: App, Core, and Providers+Protocls from top to bottom. The App layer is some applications integrated by ONOS. It opens up interfaces to external applications and administrators of the controller through RESTful API, GUI and CLI, and calls down the interfaces provided by the Core layer to implement the logic of network applications. The Core layer is responsible for collecting the status of the underlying network, interacting with the App layer to execute the logic of the network application, adapting to the Providers, and operating the network equipment through the Protocols. The horizontal direction will use the cluster mechanism to perform status among multiple ONOS instances. Synchronization or information exchange. The Protocols layer is the implementation of various southbound protocols, which are adapted to the Core layer through Providers, and manage or control network devices down.

Figure 7-1 Layered architecture of ONOS

App consumes the interface provided by Core to implement different network application logic. Pay attention to the difference between these apps and

External applications of the controller, external applications can only use RESTful API to call the API provided by these apps for secondary development, and cannot directly call the internal interface provided by the Core.

Core isolates the App from the Protocols. It abstracts the different network resources in the southbound protocol into general network resources, so that App developers do not need to care about the interface characteristics of the underlying network, which reduces the difficulty of App development, especially When there are multiple manufacturers or heterogeneous types of equipment in the underlying network. The current resource abstraction of the Core layer is shown in Figure 7-2. The red part is the Core network resources, and the gray part is the common platform resources in ONOS.

Figure 7-2 The ONOS Core layer's abstraction of resources

These different resources correspond to different Subsystems in ONOS. The term Subsystem is more common in the Linux field and refers to the implementation set of a certain type of function (such as process management, memory management, etc.). For a network OS such as ONOS, Subsystem can be understood as being carried out around a certain type of Core resource The vertical implementation of Device Subsystem, for example, includes the definition of Device resources in the Core, and all apps that consume the Core Device interface, and Providers that adapt to the Core Device model. Multiple ONOS instances will use the Subsystem as the unit to synchronize state or exchange information through the Store mechanism to achieve cluster collaboration.

Protocols are the implementation of southbound protocols. Because different southbound protocols have different ways of abstracting the network, they need to be adapted through Providers when connecting to the Core. In addition, because the resources described by different southbound protocols are also different, the adaptation needs to be carried out for different subsystems. The subsystems that can be adapted to some major southbound protocols are shown in Table 7-1. Show.

Table 7-1 Subsystems that can be adapted to some major southbound protocols in ONOS

Asterfusion Data Technologies is committed to providing enterprise users with services including technical consultation and one-stop deployment, and helping enterprise users enjoy the technological dividends brought by the Internet, open source, and open networks.