Re: OpenFlow version hell

[Haris Rotsos <cr409@xxxxxxxxxxxx>]

Hi all,

This is a mail I send a while ago to Nirav Dave and Andrew W. Moore in order toÂsummariseÂthe differences between the versions of the OpenFlow protocol. It might come in handy in this discussion.Â

"So far I have used only the 1.0 specification in my projects and the 1.1 specifications, although they are assumed as the current default, there is no adoption for them yet. Just toÂorganiseÂthings, I will group changes based on functionality:

1) Tables and switch state:

In the 1.1 specifications there are two main changes on the processing packet pipeline. Firstly, there is a new table type which is calledÂgroup tableÂand by using an identifier, it can group together multiple flow definitions. Additionally, the lookup process changes and instead of a parallel search in all flow tables it now looks up flows among tables in a pipeline fashion. AssumeÂnÂtables exist in the switch, then the packet will be matched against table 0Âinittially. If a match is found then the actions are appliedÂonÂthe packet, and a new lookup is performed on to the next table of the switch etc. As a result a matchingÂflowÂon table 1 may change the operation applied from the matchÂofÂthe 1st table etc. For the group table, my understanding is that they try to create a hack in the processing stack that allows 2 things: Firstly, process special packets like multicast packets in a homogenous way, without having to go through the pipeline and, secondly, reduce space to store actions by accumulatingÂthenÂin the group table.Â

2)ÂmatchingÂtuple:Â

IntroduceÂbitmaskÂmatches on theÂmacÂaddress of a packet.Â

Introduce a metadata field in the tuple that can store partial results during the processing of a packet. The basic idea is that the metadata field can store control defined state and allow to propagate state between the tables in the processing pipeline.ÂThis way you can create state machines between the various processing tables.Â

The matching process can now extract alsoÂmpls,Â802.3 andÂsctpÂpacket headers.Â

3) Packet processing:

As I already mentioned, the packet processing occurs now in a pipeline fashion. Additionally, during the processing of a packet, a list of actions is Âassigned to the packet. This list contains the transient list ofÂoperationÂthat will be applied at the endÂonÂthe packet. Each table can add actions in the list or invalidate previous one.Â

A number of new actions are introduced that allow to handleÂmplsÂtags,ÂecnÂhandling and copy or decrementÂttlÂfield (AlthoughÂttlÂis not exposed in the matchingÂtupple).Â

I think this summarizes the differences in the protocol. It appears that the protocol has been mildly bloated and as a result I am not aware of anyÂhwimplementation so far. "

By the way, I was wondering if I could take a lookÂinÂtheÂbluespecÂcode of the switch you presented last week in SRI. I am asking mainly because I would like to see a bit howÂbluespecÂcode looks like.Â

hopeÂmy answer helped you a bit. If you have any further question feel free to contact me.Â

On 1 May 2013 09:11, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

Thanks for this summary, Prashanth. ÂI looked around for 1.3 implementations,
and came up with just this switch:
https://github.com/CPqD/ofsoftswitch13

This does convince me that having continuing to develop the controller and
switch library would very useful, since we could use it to mix-and-match
different deployment scenarios, but also understand the performance impact
of different data structures for use within the switch itself...

-anil

On 30 Apr 2013, at 18:21, Prashanth Mundkur <pmundkur.ocaml@xxxxxxxxx> wrote:

>
> As mentioned on today's Mirage call, here are some pointers to
> OpenFlow versioning issues.
>
> https://github.com/horms/openvswitch/blob/master/OPENFLOW-1.1%2B#L38
>
> This document underplays the issues, especially for OpenFlow 1.1.
> There are major changes in the semantics for flow matching.
>
> - Wildcards vs. exact matching
>
> https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.0.0.pdf
> OF 1.0, Section 3.4:
>
> ÂPackets are matched against flow entries based on prioritization. An
> Âentry that specifies an exact match (i.e., it has no wildcards) is
> Âalways the highest priority. ÂAll wildcard entries have a priority
> Âassociated with them. Higher priority entries must match before
> Âlower priority ones.
>
> https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.1.pdf
> OF 1.3.1, Section 5.3:
>
> The packet is matched against the table and only the highest priority
> flow entry that matches the packet must be selected.
>
> (The language is a little more ambiguous in OF 1.1, but the intent is
> clarified in 1.3.1 above.
>
> https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.1.0.pdf
> Section OF 1.1, Section 4.4:
>
> Â The switch should apply the instruction set and update the
> Â associated counters of only the highest-priority flow entry
> Â matching the packet.
> )
>
> - VLAN tag matching
>
> Summarized here:
>
> https://github.com/horms/openvswitch/blob/master/DESIGN#L155
>
> --prashanth
>

--
Charalampos Rotsos
PhD student
The University of Cambridge
Computer Laboratory
William Gates Building
JJ Thomson Avenue
Cambridge
CB3 0FD

Phone: +44-(0) 1223 767032
Email: cr409@xxxxxxxxxxxx