> -----Original Message----- > From: openflow-discuss-boun...@lists.stanford.edu > [mailto:openflow-discuss-boun...@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 > <chenyangseam...@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@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
