Software Defined Network week 3（二）

Commercial-Grade Controllers: ODL

The OpenDaylight Consortium has heavy industry involvement and backing. It’s focussed on providing an open frame work for building on various SDN and network function virtualization innovations that are being developed across the industry. The OpenDaylight controller is not limited to open flow innovations.

It supports many different south bound API’s.

And perhaps no controller better illustrates the concept that SDN is much, much broader than just OpenFlow.

Here’s an illustration of the OpenDaylight controller release called Hydrogen. At the very bottom of the architecture, we have OpenFlow enabled switches. Open v switches, or software switches. Maybe additional other virtual and physical devices and other data plan elements. It’s important to note that these need be open flow switches. In fact, when you look at the south bound interfaces, that the open daylight controller supports, open flow is just one south bound interface that it aims to support. It also supports many other Southbound interfaces including Netcomf and OVSCP, as well as more conventional network management and configuration protocols. In between the Southbound interface and the controller platform itself, OpenDaylight provides what’s called a service abstraction layer.

Which abstracts the southbound interfaces from the modules that are provided by the controller platform. This abstraction layer, or cell, is the main difference between OpenDaylight and more open-flow centric controller platforms. The controller platform implements various basic services on top of the cell.

And on top of the controller itself one can use the OpenDaylight REST API’s to write more complex network applications for orchestration and network services.
The OpenDaylight ecosystem has many moving parts. The controller’s written in Java.
Java was chosen as an enterprise-grade, cross-platform compatible language. OpenDaylight uses Maven as a build system, and we’ll see that in action during the demonstration. It also uses OSGI to allow the controller to dynamically load bundles, automatically register dependencies and services. And to exchange information across bundles.
We’ll look at an example of how OSGI allows dynamic loading of bundles in the demonstration of the Mac learning switch. OpenDaylight provides Java interfaces for event listening, specification and various patterns.

In the example that we’ll look at, a packet will arrive. At a particular switch will be sent to the appropriate plugin that’s managing the switch at the control log. The plugin will parse the packet and generate an event for the service abstraction layer. The service abstraction layer dispatches the packet to modules that are listening for data packet events using the iListenDataPacket interface. These modules, such as an ARP Handler or a MAC Learning Switch, handle the packet and send the packet out through the iDataPacketService. SAL then dispatches the packet to the modules that are listening for data packets. And the controller will also send OpenFlow messages to the appropriate switches such as flow modification directives.

换到ubuntu用户下就success了
In the end is the Maven command that compiles the code based on the pam.xml file in that directory. Maven resolves dependencies between pathogens. And the code that we’re using here depends on the open daylight controller package. So, Maven will download the pre-compiled .jar files from opendaylight.org, resolve dependencies, and so on.


重启了，目前比较顺利
额，我是Be版本？

跟Nick的不一样啊
跟着Nick走不下去了，回到官方教程，反正以后都要安装，期间发现它common parent 大概装好了能更好叭


我把common/parent目录下的pom.xml改成

不对啊，目录错了，命令的输出不一样了，是clean和-nsu的区别？
mvn install -nsu -rf :learning-switch-impl

再次运行了mvn clean install，发现pox.xml多了一个？
https://blog.csdn.net/chuodun0399/article/details/100765672 java jdk1.8.0_231肯定是配好了的，source ~/.bashrc javac和java -version验证完都没事了 然后可以继续向下执行了
之后又遇到了netconf那个问题，按照网上的方案这次也顺利解决了（见博客OpenDayLight）

换成root试试了

The OpenDaylight controller has three essential types of code constructs.

One for handling packet in messages or packet arrivals.

Another for parsing themselves as they arrive at the controller, and a third for sending control messages to switches. You can see in these code snippets that there are several similarities between Beacon and OpenDaylight. While the code itself here look similar, you should by now be noticing that the above three types of functions are common to all controller platforms.