Hello,

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.

Michal Polkorab

Hi Michal,

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
together.

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.

/ Chris




On 8/6/13 1:02 PM, "michal.polkorab@..."
<michal.polkorab@...> wrote:

Hello,

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.

Michal Polkorab
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev