Thanks Luca. Is this implementation takes care of interop with traditional switch MSTP? As my main concern was loop formation with traditional switch. For example: consider a triangle topology with one OF switch and two traditional switch or two OF switch and one traditional switch. Here OF switches does not form loop by itself but with traditional switch, there is loop, because tradition switch will not received BPDU from OF switches (or from controller on behalf of OF switches) and this will make traditional switch to open its interfaces connected with OF switches.
I think, we need OpenFlow spec support to extend data structure and controller's API framework to allow traditional control plane protocols in controller (centralized environment) for OF switches that does not have their own control plane and entirely depend on controller. -Sudeep On Wed, Aug 28, 2013 at 12:30 AM, < openflow-discuss-requ...@lists.stanford.edu> wrote: > Send openflow-discuss mailing list submissions to > openflow-discuss@lists.stanford.edu > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > or, via email, send a message with subject or body 'help' to > openflow-discuss-requ...@lists.stanford.edu > > You can reach the person managing the list at > openflow-discuss-ow...@lists.stanford.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openflow-discuss digest..." > > > Today's Topics: > > 1. Re: Fwd: IEEE 802.1Q MSTP support in OpenFlow Controller > (Luca Prete) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 27 Aug 2013 10:19:18 +0200 > From: Luca Prete <luca.pr...@garr.it> > To: openflow-disc...@mailman.stanford.edu > Subject: Re: [openflow-discuss] Fwd: IEEE 802.1Q MSTP support in > OpenFlow Controller > Message-ID: <521c6106.6090...@garr.it> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > Hi, > > In the past Consortium GARR has developed a module for using looped > topologies using the Floodlight Learning Switch module, as well with > switches not supporting the STP protocol. > > The module build a tree from the looped topology using the Kruskal > algorithm. > > GreenMST module code and documentation at www.github.com/LucaPrete > GreenMST article > > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6385045 > > Hope it will help! > > Cheers, > > Luca > > Il 11/08/2013 11:55, Sudeep Singh ha scritto: > > Hi, > > > > There had been some discussion on MSTP support in OpenFlow Spec. But I > > don't see yet any MSTP support extension in Spec. > > > > Even, if some non-standard STP evolves for OF controller. but it still > > has serious issue with interop with legacy switches. > > For example: Traditional switch will form loop with OF Switch if > > standard STP is not running in OF Switches. And If STPs are to be run > > on OF Switches instead of controller, then we are loosing the > > centralize control advantages of OF Switches. > > > > Is there any thought of extending MSTP support in OpenFlow controller? > > > > I mean running control protocol in controller environment (not > > necessarily tightly coupled with controller) to get interop with > > traditional switches. > > > > Loop Overview: > > ---------------------- > > Traffic flow is decided by controller and it is the flood message > > (broadcast, multicast and unknown unicast messages) that causes loop > > in OpenFlow Switch (assuming basic Learning switch implemented by > > controller). > > > > Solution: > > ------------- > > Now, once message hits controller, (after checking ingress port state) > > default flood should change to forward data on forwarding ports of the > > frame Vlan (classified Vlan of the frame). > > And, for bidirectional traffic, once Macs are learnt for both > > direction install a flow. therefore, flow will be installed only on > > forwarding ports dynamically. > > > > - This should be done by controller not devices, OF switch > > port should remain unblocked for all Vlan. > > - This will give benefit to allow static flow creation even > > on blocked Vlan ports. > > > > > > Running MSTP in centralized environment: > > ------------------------------------------------------------- > > > > Controller and Control Protocol need not be tightly coupled. Consider, > > MSTP as separate module interacting with controller to - gets > > switchId, SwitchMac, Ports capability from controller and sets port > > state in controller. > > This control plane module can get their own CLI and Management plane, > > just like traditional switch. > > > > > > Static Flow: > > ------------------ > > Static Flow provision need not consult [Vlan, Port] state to provision > > flow. This will allow specific traffic to be provisioned by admin even > > on blocked ports. Since nothing is actually blocked in OF Switches, > > static flow will work, even on STP blocked ports. > > > > Advantage: > > ----------------- > > 1) Interop with legacy swiches. > > 2) Utilization of blocked link for static flows. > > > > Disadvantage: > > --------------------- > > > > 1) Packet received on blocked port will still hit controller, instead > > of getting dropped in OF Switch itself. (But this also can be fixed) > > I can propose following MSTP extension in OpenFlow spec: > > > > 1) - Table for Vlan to Instance mapping > > - [Instance, Port] PortState > > 2) Static Flow need not consult these table install flows. > > > > > > This model is a step to allow other control protocol to make there > > way in centralized environment of OF Network and at the same time > > interop with exisitng devices. > > > > If there is already some work in progress on this, please ignore this > > mail. > > > > Regards > > Sudeep > > > > > > > > _______________________________________________ > > openflow-discuss mailing list > > openflow-discuss@lists.stanford.edu > > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.stanford.edu/pipermail/openflow-discuss/attachments/20130827/1623712f/attachment-0001.html > > > > ------------------------------ > > _______________________________________________ > openflow-discuss mailing list > openflow-discuss@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > > End of openflow-discuss Digest, Vol 58, Issue 10 > ************************************************ >
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
