| Table of Contents | ||
|---|---|---|
|
...
OpenFlow Plugin:Backlog:Overload Protection and Event Dampening
Overload Protection
Rationale and Usecase Scenarios
Typically on OpenFlow interface, there is likelihood of heavy packet-ins spikes due to scenarios like links going down, switches going down (thereby, potentially invalidating the pre-computed path-based flow rules) etc. Combining this with ongoing traffic across the topology the spike of packet-in rate punted towards controller could be very high and steep.
...
There are multiple means of realizing overload-protection
Solution Approaches
Some options which could be considered are (there could be other options, but following ones are relatively simpler)
...
Option 2: monitor the resource loading - CPU utilization, memory etc and based on a higher and lower watermarks, sense the load. Action part could be to drop packet-ins when load is between lower and higher thresholds
Event Dampening
Rationale and Usecase Scenarios
This has more to do with the events which occur very frequently due to instability in switch/network layer. For example, flapping of switch links is one such case.
If multiple applications start reacting to the link-up down events at a very high rate, the possibility of system becoming unstable is very high. So, selective Openflow (or any events from southbound interfaces) must be dampened before escalating the same to the applications layer.
Solution Approaches
One solution approach is discussed here (this example explains the edge-device-side implementation - but, in principle, this can also be useful on controller) - http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/s_ipevdp.html
...
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
...
- Since this part is in a bigger context hence please follow up with PoC For Single Model Layer
OpenFlow Plugin:Split connection layer
...
OpenFlow Plugin:Bundles extension support
- Please head over to Bundles extension support documentation.
OpenFlow Plugin:Implementation For Single Model Layer
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.
...