1. Topics
  2. [openflowplugin-dev] [controller-dev] Openflow Protocol Library

[openflowplugin-dev] [controller-dev] Openflow Protocol Library

Anil Vishnoi
 

Hi,

I agree with the point made by Chris. 

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
Michal Polkorab
 

Hello,

i would like to summarize our thoughts behind OF Protocol Library architecture and react to given suggestions.


In the current architecture one of the main responsibility of southbound
protocol plugin is to handle connections with network devices.
I agree. But it is not defined how southbound protocol plugin has to implement this functionality - if it must be implemented directly or if the plugin can use other component (or library) to achieve this.


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.
With right API design connection handling could be exposed to the plugin and the plugin could still control things like acceptance on session, capability negotiation and other funcionalities. However, base pieces of this functionality could be in library.


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.
The location of code and functionality in OF protocol library vs. southbound plugin does not prevent creating comprehensive solution, but this functionality is not southbound protocol plugin specific. With right API design, the plugin could use or customize it to its specific needs.


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.
By implementing this architecture model in the protocol library it allows library to be used also outside of the controller without the need to extract logic from the southbound protocol plugin.



Michal Polkorab
1 - 2 of 2