This group is locked. No changes can be made to the group while it is locked.
Re: [openflowplugin-dev] [controller-dev] Openflow Protocol Library
Anil Vishnoi
Hi,
In the current architecture one of the main responsibility of southbound protocol plugin is to handle connections with network devices. Other responsibilities of the protocol plugin ( discovery/inventory service, data packet service, stats collection, SAL abstraction to protocol message conversion etc) are kind of dependent on the connection handling service. In the proposed design of protocol library, I think pipeline processing and concept of facade is interesting and possibly required components from the perspective that we will have multiple version of openflow spec (without backward compatibility) or multiple implementation of protocol library.
IMHO component 1 to 5 & 7 of the pipeline processing (slide 13), can be part of the southbound protocol plugin. Component 1 to 5 can help in building comprehensive connection handling service that can support existing openflow 1.0 & 1.3 protocols connection mechanism, as well as future enhancement in this area. Component 6 (OF 1.3 CoDec) can be a static library on the similar line of current openflowj, or based on Yang as proposed in the design. Component 7 (Facade) can be extended to support both the OF 1.0 & 1.3 CoDec ( or may be its a redundant component). In that way I think it will require minimal changes in the existing architecture and will satisfy the requirement of proposed design.
From the slide decks I didn't actually get very strong rationale or use case for implementing this mechanism in the protocol library compared to the southbound protocol plugin, until and unless I am missing something in this context. These opinions are based on my understanding of the existing ODL architecture and interpretation of the slide decks (which may be wrong :) ), so please feel free to correct me or +1/-1.
Thanks
Anil Vishnoi
On Wed, Aug 7, 2013 at 9:24 AM, Christopher Price <christopher.price@...> wrote:
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
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
Thanks
Anil