Onos White Paper Medium Onos architecture

Editor's note: This series is divided into three articles on the ONOS White Paper, and then theONOS white paper, which is translated in part 5 of the white Paper ONOS structure, if there is any improper, please correct me.

5.ONOS Architecture

ONOS from the outset from the point of view of the service provider architecture design. It has basic performance such as high availability, scalability, and good performance, as well as a strong North interface abstraction Layer and a south interface.

The Onos has the following core functions:

A distributed core platform that delivers high scalability, high availability, and high performance for carrier-class SDN control plane features. ONOS 's ability to operate in a clustered manner makes the SDN control platform and service provider network similar to Web -style flexibility.

The north-to-interface abstraction Layer /apis, decoupling network and application from the development of control, management, and configuration services. This abstraction layer is also one of the factors that have similar web -style flexibility to the SDN control platform and service provider network .

The /apisis a south-to-the-interface abstraction layer that controls OpenFlow devices and traditional devicesthrough a plug-in South interface protocol . The south-to-interface abstraction layer isolates the core functions of ONOS and the underlying devices, shielding the differences between the underlying devices and protocols. The South interface is the key to migrating from traditional equipment to OpenFlow white card equipment.

Software modularity enables ONOS to be developed, debugged, maintained, and upgraded by community developers and providers like software systems.

5.1 Distributed Core

ONOS can be deployed as a service on a server cluster, running the same ONOS software on each server , because symmetric deployment is an important design consideration that can be ONOS Failure recovery can occur quickly in the event of a server failure. and the network operator can add the server without interruption, and easily expand the control plane processing ability. ONOS instances work together to form a single platform that is viewed by other networks and applications. Applications and network devices do not need to know whether to interact with a single ONOS instance or with multiple ONOS instances. This feature enables scalability of the ONOS to seamlessly expand the ONOS capacity. Is the characteristic performance of the distributed core platform.

Distributed core provides services such as communication, state management, leader selection, etc. between instances. In fact, multiple instances are represented as a logical entity. By using high-speed messages in the Publish/subscribe model,ONOS instances can quickly notify other instances of update information. ONOS Internal Design recovery protocol to handle updates lost as a result of an instance failure. ONOS uses several mechanisms to manage the operational state of an instance, and each mechanism corresponds to the state type one by one. Typical examples are application intent, topological databases, and flow tables, each with a unique scale, read / write pattern, and persistence requirements. A leader select a service to ensure that the switch has only one primary instance. At the same time, messaging, state management, and leadership selection mechanisms ensure high throughput, low latency, and high availability of the cluster.

What does that mean? For a device, there is only one primary ONOS instance, and if the primary instance fails, then another instance is connected, without recreating the new instance and re-synchronizing the flow table. For an application, you can continuously get a view of the network through the Network Graphics abstraction layer. In addition, instance failures and data plane failures are transparent to the application, which can greatly simplify application development and error handling.

From a business perspective,ONOS provides a highly available environment where applications can effectively avoid network-related downtime. Furthermore, service providers can easily expand the control plane capacity as the network grows, without generating network outages. Through the same mechanism, network operators can implement zero-update software according to the steps of offline, update and on-line.

In a word, the distributed core is the key to the ONOS architecture feature, which makes the SDN control plane meet the carrier-level requirements.

5.2 North to abstract layer

There are two powerful northern abstraction layers in the Onos architecture: Intent Framework and global Network view. The intent framework masks the complexity of the service's operation, allowing applications to request services to the network without needing to know the specifics of the service's operation, which means that network operators and application developers can do advanced programming. They can easily make intentions: a policy statement or a connection requirement.

Examples of intent frameworks:

To establish a connection between host A and B

Establish a bandwidth- z Optical channel between the switch Y and z

Prevent host A from communicating with B

The intent framework handles all application requests, determines which applications can be met, resolves conflicts between applications, executes managers ' policies, provides requests for network programming, and delivers the requested service to the application.

One intent translates to multiple goals. For example, an intent to connect 2 hosts translates into 2 destinations, each providing a flow in one direction. Compiling the target of intent conversion to the network device, the whole process is carried out according to the policy specified by the network operation and maintenance personnel. To some extent, this method can solve the conflict between intentions.

The Global Network View provides a network view of the application, including host, switch, and network-related state parameters such as utilization. The application can program The network view via APIs, an API that provides a network view of the application as a network diagram. The following work can be done based on a network diagram:

Create a simple app that calculates the shortest path when the app gets a global view of the network.

Maximize network utilization by monitoring the network view and programmatically changing the path to adjust the load (traffic engineering).

Directs traffic from a network that is being upgraded or is quarantined by a virus.

Specifically, the north-to-interface abstraction Layer and APIs Isolate the application from the network details. It is also possible to isolate applications and other applications that need to understand network events such as link outages. Instead, isolate the network operating system from the application, and the network operating system can manage requests from multiple, competing applications. From a business perspective, the speed of application development is increased, allowing the network to change and ensure that the application does not become a machine.

5.3 South-to-interface abstraction Layer

The southward abstraction layer is made up of network components, such as switches, hosts, or links. ONOS the south-to-the-abstraction layer represents each network component as a common-format object. With this abstraction layer, the distributed core can maintain the state of the network components without needing to know the specifics of the underlying device. In short, the distributed core can realize the south-to-interface protocol and the device without perception. This network component abstraction layer allows the addition of new devices and protocols to support extensions in pluggable form, which the plug-in maps (or translates) generic network components to describe or manipulate devices, and vice versa. Therefore, the southbound interface ensures that ONOS controls multiple different devices, even if they use different protocols (OpenFlow,netconf , etc.).

The hierarchical structure of the south-facing interface is shown in 3 , the lowest layer is the network device,ONOS through the protocol and the device connection, the protocol details are blocked by the network component plug-in or adapter. In fact, the core of the southbound interface is to maintain network component objects (devices, hosts, links) without knowing the specifics of the protocol and the network components. With the adaptation layer API, the distributed core can be aligned with the network Component Object state, and the adaptation layer API isolates the distributed core from protocol details and network components.

The main advantages of the southward abstraction layer include:

Managing different devices with different protocols does not affect the distributed core.

The scalability is strong and new devices and protocols can be added to the system.

Easily move from legacy devices to White-card devices that support OpenFlow.

5.4 Software modularity

Software modularity is a major feature of ONOS, and software-based forms can be easily added, changed and maintained. the ONOS team has put a lot of effort into modularity, making it easy for developers to operate the software quickly and easily.

What is modularity? Splits the software into several components and the interaction between the components. As shown below, The main architecture of ONOS is a layered architecture around distributed cores. So, from a macro structure, the north-to-South interface API separates the application, the distributed core, and the adaptation layer from each other, and can add new applications and protocol adapters independently.

In the same way, from the concrete details, the sub-structure inside the distributed core can also embody the modularization feature, and the existence value of the distributed core is to constrain the scale of all subsystems and ensure the scalability of the module. In addition, connecting interfaces of different modules is critical, allowing modules to be independent of other modules. This makes it possible to continuously update the algorithms and data structures without affecting the overall system or application.

Obviously, theONOS attaches great importance to the interface, because the interface can promote the separation of the module business and responsibility, as far as possible to make the interaction between subsystems more natural and simple. This feature is key to ensuring software stability updates. For example, try to provide a level of abstraction to the South API , avoid passing deviations from different protocols to the upper layer, and harden the distributed core rather than the adaptation layer to create network model objects.

the tree structure of the ONOS source code is not only to follow but to strengthen these structural principles. Properly control the size of the module and maintain proper dependencies between the modules to form a non-cyclic structure diagram, which is interconnected between modules through API modules, as shown in.

The benefits of software modularity are summarized in the following points:

Ensure the integrity and consistency of the architecture

Simplifies test structures and allows for more integration testing

Reduce the negative impact of changes in a part of the system, thus reducing maintenance difficulty

Components with scalable and customizable features

To circumvent the cycle-dependent situation

This article comes from Sdnlab , you can click this Read the original . If you are interested in this article, you can participate in the following interactive ways to communicate with the author in close range.

If you are interested in this article, you can participate in the following interactive ways to communicate with the author in close range.

Weibo (http://weibo.com/sdnlab/)

( account No.:Sdnlab)

QQ Group

SDN Research Group (214146842)

Opendaylight Research Group (194240432)

Onos White Paper Medium Onos architecture