Ask is moving to Stack Overflow and Serverfault.com! Please use the "opendaylight" tag on either of these sites. This site is now in Read-Only mode

Revision history [back]

1) If i am getting your question correct, by "creating new openflow plugin" if you mean to make a copy the existing code and then modify it to add your extension, then i would say that's unnecessary. If you use 'git' for managing the code, you can create your own local branch and modify the code. Following URL can give you some direction

https://wiki.opendaylight.org/view/GITCheatSheet

2) openflowplugin project has dependency on "openflowjava" library, and it usage it for connection handling and for decoding/encoding of the openflow protocol messages.

/controller/opendaylight/protocol_plugins/openflow/ -- this directory contains AD-SAL based openflowplugin code and /controller/third-party/openflowj/ directory contains the encoding / decoding library code. Both of these source code are part of the AD-SAL based stack of the controller. So to give a clear view, we have two parallel stack a) AD-SAL based -- and above mentioned directory contains its openflowplugin and openflowjava (encoding/decoding) library. This stack only support openflow 1.0. b) MD-SAL based -- Openflowplugin project (repo : openflowplugin.git) is MD-SAL based openflow plugin that supports openflow 1.0 and openflow 1.3 both. Openflowjava project (repo : openflowjava.git) is MD-SAL based encoder/decoder library and it supports for openflow protocol as well. In the hydrogen release, to start MD-SAL based stack you have to use -of13 option while starting the controller.

3) Yes, its AD-SAL.

1) If i am getting your question correct, by "creating new openflow plugin" if you mean to make a copy the existing code and then modify it to add your extension, then i would say that's unnecessary. If you use 'git' for managing the code, you can create your own local branch and modify the code. Following URL can give you some direction

https://wiki.opendaylight.org/view/GITCheatSheet

2) openflowplugin project has dependency on "openflowjava" library, and it usage it for connection handling and for decoding/encoding of the openflow protocol messages.

/controller/opendaylight/protocol_plugins/openflow/ -- this directory contains AD-SAL based openflowplugin code and /controller/third-party/openflowj/ directory contains the encoding / decoding library code. Both of these source code are part of the AD-SAL based stack of the controller. So to give a clear view, we have two parallel stack

a) AD-SAL based -- and above mentioned directory contains its openflowplugin and openflowjava (encoding/decoding) library. This stack only support openflow 1.0. 1.0.

b) MD-SAL based -- Openflowplugin project (repo : openflowplugin.git) is MD-SAL based openflow plugin that supports openflow 1.0 and openflow 1.3 both. Openflowjava project (repo : openflowjava.git) is MD-SAL based encoder/decoder library and it supports for openflow protocol as well. In the hydrogen release, to start MD-SAL based stack you have to use -of13 option while starting the controller.

3) Yes, its AD-SAL.