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.

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M01/58/41/wKioL1Ss-m7A7XtSAALWJG7HHLM553.jpg "style=" float: none; "title=" 1.jpg "alt=" Wkiol1ss-m7a7xtsaalwjg7hhlm553.jpg "/>

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 onos > A server failure can be done quickly in case of failure recovery. and the network operator can add the server without interruption, and easily expand the control plane processing ability. onos Examples work together to form a single platform that is viewed by other networks and applications. Applications and network devices do not need to know is and a single onos instance interaction or multiple onos instance interaction. This feature implements the onos onos capacity. Is the characteristic performance of the distributed core platform.

publish/subscribe High-speed messages in the model, onos An instance can quickly notify other instances of update information. onos Internally designed recovery protocol to handle updates lost as a result of an instance failure. onos Managing the operational state of an instance using multiple mechanisms , and each mechanism corresponds to a state type of one by one. Typical examples are application intent, topology database, and flow table, each with a unique scale, read /

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

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M02/58/41/wKioL1Ss-3uQ3-4CAAKOD77SZ0c079.jpg "title=" 3.jpg " alt= "Wkiol1ss-3uq3-4caakod77sz0c079.jpg"/>

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

    southward abstraction layers are composed of network components such as switches, hosts, or links. onos onos Control 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.

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M00/58/41/wKioL1Ss-6Pi3TyHAAEodhG0nNI850.jpg "title=" 4.png " alt= "Wkiol1ss-6pi3tyhaaeodhg0nni850.jpg"/>

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.

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M01/58/44/wKiom1Ss-xGhx_CYAAEKD5HNPZA047.jpg "title=" 5.png " alt= "Wkiom1ss-xghx_cyaaekd5hnpza047.jpg"/>

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 to this article interested, can participate in following interact in close proximity to the author.

(1) Micro-Blog ( http://weibo.com/sdnlab/ )

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M02/58/41/wKioL1Ss_DSh9RGAAACRj-P-jzw902.jpg "title=" Weibo. png "alt=" Wkiol1ss_dsh9rgaaacrj-p-jzw902.jpg "/>

(2) ( account No. :sdnlab)

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/58/41/wKioL1Ss_eKz6lDGAACT9kgFKuI106.jpg "title=". png " alt= "Wkiol1ss_ekz6ldgaact9kgfkui106.jpg"/>

(3) QQ Group

SD N Research Group (214146842)

Opendaylight Research Group (194240432)

Onos White Paper Medium Onos architecture