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

Revision history [back]

click to hide/show revision 1
initial version

Hi, protocol_plugins/openflow is of type (osgi) bundle and supports OF-1.0. thirdparty/openflowj is translation library for this plugin and is passed to osgi as embedded dependency of plugin.

Support for OF-1.0 and OF-1.3 is provided by OFPlugin in separate repository ( with help od OFJava ( Repository suffix: openflowplugin.git and openflowjava.git

Version is decided during version negotiation step of handshake. OFJava's main purpose is to decode/encode between wire protocol and OFJava-API models. Those models are following messages of OFP-Spec. In OFPlugin those models (containig OF-messages) are translated to general MD-SAL models. Those are supposed to be protocol and version agnostic.

In case of "old" sal (AD-SAL) there is probably no extensibility support scheduled right now. In case if "new" sal (MD-SAL) you do not need to change MD-SAL because it is routing models which are described by yang files. So you can introduce an augmentation to existing model and you have your data packed and transported by MD-SAL without recompiling it.

Current vision of extensibility support looks like this: - OFJava provides API through which vendor/thirdParty/other codec can be registered and used by processing of those special messages. (this strategy presumes that existing OFJava-API models would be augmented in order to include special data) - OFPlugin extensibility feature is in progress. There will be applied probably similar strategy as by OFJava.

Bypassing sal is a bad idea. But there are bundles assisting when using plugins (e.g. NSF - network services functions). This can be bypassed if you know, what you are doing (and are prepared to reflect all API changes of corresponding plugin).

Regards, Michal