This group is locked. No changes can be made to the group while it is locked.
Date 1 - 3 of 3
[controller-dev] Openflow Protocol Library
Baohua Yang <yangbaohua@...>
toggle quoted message Show quoted text
I suggest to take care of handling different of versions, providing enough flexibility for user selection.
Seems the of protocol is growing to another complicated stack...
Also, the pipeline part, not clear will affect the latency too much.
btw, there's some typo on page 6: "genaretion" :)
On Tue, Aug 6, 2013 at 2:28 AM, <michal.polkorab@...> wrote:
we have received some reactions / suggestions to our OpenFlow Protocol Library Architecture introduction. From these, we have formulated common questions that we would like to respond to.
Q: What OpenFlow protocol versions will the library support ?
A: The library is designed to support OpenFlow 1.3 right now. However, there are components called OF Version Detector and OF Codec. OF Version Detector detects the version of a wire-protocol from the OpenFlow frame and after the detection the Version Detector chooses the right OpenFlow Codec to process the information. By doing so we can achieve that other versions will be supported too. Another benefit of this approach is that we can use the same port.
Q: What about connection termination ? In case of OF 1.3 the connection is terminated within the library and in case of OF 1.0 the connection is terminated in OF plugin.
A: It is possible to build the wrapper around OpenFlow 1.0 and use it as another Openflow Codec. This way we can terminate the connection within the library.
Q: How big will be the impact of pipeline on the latency ?
A: Pipeline is mentioned as logical division of code, so that reusable components would not be tightly coupled. If we want to support TLS connections, we need to implement this mechanism.
Christopher Price <christopher.price@...>
Thanks for providing some opinions on the obvious questions.
I do think we need to dig a little more into the best architecture for the
solution. Not a discussion on the code itself, but how the code fit's
I don't believe the connections should terminate in the library as we want
the library to be a modular component of the solution. I can envision
that the plugin should provide a way to feed the library with packets and
have the library provide an interpretation of those. If another project
or deployer wishes to deploy the ODL controller with a "OF-like" library,
or an alternative OF-Library, and swap out the standard one this should be
manageable without the need to re-write the plugin.
Modularity of the software does not dictate in which repository the
software exists in. I am concerned with the alignment of architecture and
dependancies existing between the SW components in order to create an
easily extensible solution.
We should sketch out the plugin/library components as they will exist and
then discuss the modularity of software that will realize it. I feel that
we have not yet concluded that part of the discussion.
On 8/6/13 1:02 PM, "michal.polkorab@..."
|1 - 3 of 3|