Re: Does FlowVisor support OpenFlow1.1?
> -----Original Message-----
> From: openflow-discuss-bounces <at> lists.stanford.edu
> [mailto:openflow-discuss-bounces <at> lists.stanford.edu] On
> Behalf Of Rob Sherwood
> Sent: Wednesday, July 04, 2012 4:00 AM
> To: chenyangseamoon
> Cc: openflow-discuss讨论组
> Subject: Re: [openflow-discuss] Does FlowVisor support OpenFlow1.1?
>
> On Tue, Jul 3, 2012 at 6:07 PM, chenyangseamoon
> <chenyangseamoon <at> 163.com> wrote:
> > Hi,
> > Does FlowVisor support OpenFlow1.1 version? If not,
> which part do I
> > have to modified to support the OpenFlow1.1 protocol?
> > I used the OpenFlow soft switch1.1 which was developed
> by Erricsson
> > of11softswitch.
>
> FlowVisor does not yet support OF1.1 (or beyond). To update
> FlowVisor to OF1.1 would be a pretty substantial change, but
> minimally you would have to rewrite a lot of openflowj, which
> the floodlight project is looking to do also (it's shared
> code between flowvisor and floodlight).
>
> Hope this helps,
>
> - Rob
> .
FWIW, I think you should first figure out how FlowVisor should work with
OF 1.1 (or beyond).
Having multiple tables raises some issues. Controllers can now use a chain
of flow entries (in subsequent tables) to inspect, modify and forward packets.
Throughout this chain of flows the protocol stack of the packet can change
substantially, even to the point, where it "temporarily" falls outside the
assigned flow space.
For example, think of a slice that handles all MPLS traffic, but nothing else.
If you want to inspect the IP payload of an incoming MPLS packet, you need to
first pop the MPLS label, then inspect the IPv4 header, then push the label back.
Here, in the second flow you are actually matching on IP packets, which is not
part of your slice.
As OpenFlow does not provide transaction semantics, those chains of flows will be
installed as independent flow entries. So FlowVisor will have to enforce the flow
space on each entry independently, messing up pretty much everything.
The only solution I can think of at the moment is that FlowVisor keeps track of
all installed flows (both the original and the rewritten/enforced forms). Then,
Whenever a controller installs a new flow entry, the FlowVisor executes some sort
of packet-flow analysis on all the original flows, compares it to the rewritten
ones, and if it finds that an enforced version can be relieved, it also sends
down a flow-mod to modify it back to the original (or a less enforced) version.
This will only cause temporary packet mishandling, which you might live with, or not.
The group table probably also raises similar issues in relation with the multiple
tables. Also, in group tables FlowVisor will have to implement a group ID mapping
to avoid group id collisions between controllers.
So indeed, this is a pretty substantial change, if you want it to behave correctly.
Regards,
Zoltan.
_______________________________________________
openflow-discuss mailing list
openflow-discuss <at> lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
RSS Feed