...
Receiving messages with/without Single Layer Serialization
OpenDaylight OpenFlow Plugin:Southbound Manager
Southbound Manager
- Provides simpler API for applications to use OFPlugin RPC
- Facilities include Flow provisioning, Group provisioning, Flow <-> group dependency chaining and Group <-> group dependency chaining
Single Layer
OpenDaylight OpenFlow Plugin:Avoid Translations
The main goal is to improve performance in Openflow-plugin (OFP) in order to get better times on installing flows on devices. Main idea is to use flows in form as in Openflow-java (OFJ) and avoid using translators to spare time in heavy load.
Openflowplugin
OFP now is working as layer between generic type of flow format and standard openflow specification. This kind of design is highly modular and downstream project are able to use generic type of flows which are translated into device form. Any device can by provided with own translator and therefore able to work without any change on front-end.
Openflowjava
OFJ is able to convert flow specified by openflow specification. This kind of flow is OFJ able to send into device as byte representation message to the device.
Boron and previous version of OFP
Here you can see the basic architecture of processing all models in OFP.
As you can see there is a long way from creating a ODL overall known flow model to device bytes representation of flow. Therefore can possibly be a performance issue on heavy load.
WARNING: All proposal changes in this document will make change on actual project design and in two layer approach. With this changes will lowest model accessible to upper layer or OFJ basic architecture will be drastically changed.
First change proposal
First change proposal to avoid first flow translation is use direct usage of flows model as defined in openflow specification.
NOTE: This should have impact on all downstream projects in this solution they need to rewrite all models.
Second change proposal
Second change proposal to avoid using translator is in making changes in OFJ instead of changing actually the model using. This approach is better in aspect not to change the actual models. Using same models has no impact to downstream projects.
NOTE: Need to cooperate with OFJ committers and project leader.
OpenFlow Plugin:Backlog:Statistics collection performance improvements
...
The main goal is to improve performance in Openflow-plugin (OFP) in order to get better times on installing flows on devices. Main idea is to use flows in form as in Openflow-java (OFJ) and avoid using translators to spare time in heavy load.
Openflowplugin
OFP now is working as layer between generic type of flow format and standard openflow specification. This kind of design is highly modular and downstream project are able to use generic type of flows which are translated into device form. Any device can by provided with own translator and therefore able to work without any change on front-end.
Openflowjava
OFJ is able to convert flow specified by openflow specification. This kind of flow is OFJ able to send into device as byte representation message to the device.
Boron and previous version of OFP
Here you can see the basic architecture of processing all models in OFP.
...
WARNING: All proposal changes in this document will make change on actual project design and in two layer approach. With this changes will lowest model accessible to upper layer or OFJ basic architecture will be drastically changed.
First change proposal
First change proposal to avoid first flow translation is use direct usage of flows model as defined in openflow specification.
NOTE: This should have impact on all downstream projects in this solution they need to rewrite all models.
Second change proposal
Second change proposal to avoid using translator is in making changes in OFJ instead of changing actually the model using. This approach is better in aspect not to change the actual models. Using same models has no impact to downstream projects.
...