Cloud Platform for Networking: OpenDayLight - Revision history

Unknown user at 01:21, 29 December 2021

2021-12-29T01:21:38Z

← Older revision		Revision as of 01:21, 29 December 2021
Line 5:		Line 5:
	The control platform includes the basic network services and some additional services installed as a plugin, which increases the flexibility of OpenDaylight. Of course, it is stable, but it is not as stable as Open Network Operating System (ONOS) which is a distributed strategy.		The control platform includes the basic network services and some additional services installed as a plugin, which increases the flexibility of OpenDaylight. Of course, it is stable, but it is not as stable as Open Network Operating System (ONOS) which is a distributed strategy.

	The southbound supports various protocols through the plugins, including		The southbound supports various protocols through the plugins, including OpenFlow, Border Gateway Protocol Link-State (BGP-LS), etc. These modules are dynamically mounted to the service abstraction layer (SAL) for the upper service that the call from the upper layer packaged as a suitable protocol format for the underlying network devices. However, one of the southbound protocol named OpFlex [9] is questionable, which is considered by some to be a wrong abstraction and expose the details of the device to the application, which means that it involves less abstraction and more complexity. It can be seen that the southbound of OpenDaylight does not completely abstract the underlying devices to be processed by the controller platform.
	OpenFlow, Border Gateway Protocol Link-State (BGP-LS), etc. These modules
	are dynamically mounted to the service abstraction layer (SAL) for the upper
	service that the call from the upper layer packaged as a suitable protocol format
	for the underlying network devices. However, one of the southbound protocol

	~~named OpFlex~~ [9] ~~is questionable, which is considered by some to be a wrong~~		==Pranala Menarik==
	~~abstraction and expose the details of the device to the application, which means~~
	~~that it involves less abstraction and more complexity. It can be seen that the~~		* [[Cloud]]
	~~southbound of OpenDaylight does not completely abstract the underlying devices~~		* [[Cloud Computing]]
	~~to be processed by the controller platform.~~		* [[Cloud-Based Networking]]
			* [[Cloud Platform for Networking]]

Unknown user: Created page with "OpenDaylight 9 is a community-driven open source framework to promote the innovation and implementation of SDN. Faced SDN, the right tools are essential to manage the infrastr..."

2021-12-29T01:20:23Z

Created page with "OpenDaylight 9 is a community-driven open source framework to promote the innovation and implementation of SDN. Faced SDN, the right tools are essential to manage the infrastr..."

New page

OpenDaylight 9 is a community-driven open source framework to promote the innovation and implementation of SDN. Faced SDN, the right tools are essential to manage the infrastructure, which is the expertise of OpenDaylight. OpenDaylight has a modular, pluggable, and extremely flexible controller including a collection of modules can quickly complete the network tasks, which enable it to be deployed on any Java-enabled platform [5].

In Fig. 3.6, it illustrates that the architecture of the latest OpenDaylight consisting of four layers. OpenDaylight provides the applications with the opened northbound API and supports Open Services Gateway initiative (OSGi) framework and bi-directional REST API. Specifically, the OSGi framework is provided to the applications running in the same address with the controller, while the REST API is provided to the applications running in the different address.

The control platform includes the basic network services and some additional services installed as a plugin, which increases the flexibility of OpenDaylight. Of course, it is stable, but it is not as stable as Open Network Operating System (ONOS) which is a distributed strategy.

The southbound supports various protocols through the plugins, including
OpenFlow, Border Gateway Protocol Link-State (BGP-LS), etc. These modules
are dynamically mounted to the service abstraction layer (SAL) for the upper
service that the call from the upper layer packaged as a suitable protocol format
for the underlying network devices. However, one of the southbound protocol

named OpFlex [9] is questionable, which is considered by some to be a wrong
abstraction and expose the details of the device to the application, which means
that it involves less abstraction and more complexity. It can be seen that the
southbound of OpenDaylight does not completely abstract the underlying devices
to be processed by the controller platform.