Ask Your Question

I would like to extend OF1.3, where should I start.

asked 2014-06-18 10:04:01 -0700

anonymous user


Hi, all,

Our group plans to extend the OF1.3 library to support additional functions and would you please point out which folder shall I start with?

Currently, we found two related libraries: (1) At thirdparty/openflowj which seems to support OF1.0 only. (2) under protocol_plugins/openflow/.

We decide to choose the second one since it seems to support OF1.3. But I have three questions. (1) How this plugin decides whether to choose OF1.0 or OF1.3? Are both protocols written in that library? Where can I find the OF1.3 part. (2) If I extend OF1.3, shall I extend the SAL as well? (3) Can this plugin become standalone and directly communicate with applications, i.e. bypass SAL?

edit retag flag offensive close merge delete

2 answers

Sort by ยป oldest newest most voted

answered 2014-07-07 07:59:02 -0700

michal.rehak gravatar image

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 ( Plugin:Main) 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

edit flag offensive delete publish link more


hi,Michal; could you tell me the detail method to add a match and a action ?

wangruxun ( 2015-04-10 06:46:18 -0700 )edit

answered 2014-07-01 03:38:24 -0700

Robert Varga gravatar image
  1. The openflowplugin has in-band protocol detection, e.g. it will decide whether to use 1.0 or 1.3 based on the message it receives from the switch. The relevant code is spread across three projects:

    • the semantic model is in the controller project, opendaylight/md-sal/models/model-flow-*
    • the low-level parsing/serialization forms the openflowjava project
    • the plugin itself (e.g. controller/openflowjava integration) forms the openflowplugin project
  2. Extending the models, which can be done internally or externally (via augments), automatically extends MD-SAL, so your job is done there. On the AD-SAL side, I guess you'd have to add new abstractions and create the appropriate MD-SAL/AD-SAL compatiblity translation.

  3. The way the code is structured means that you can use talk directly to openflowjava, which is a pure library

edit flag offensive delete publish link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

[hide preview]

Question Tools



Asked: 2014-06-18 10:04:01 -0700

Seen: 241 times

Last updated: Jul 07 '14