Hi Sudeep,
Sorry if I didn't understand exactly what you meant.
If you have a mixed environment of both OF switches and traditional
switches as in your example you're trying to create loops between
OpenFlow island (cluster) and traditional switches.
Currently I'm using Floodlight and this is not allowed
(http://www.openflowhub.org/display/floodlightcontroller/Supported+Topologies).
I know that there should be a version of OpenDayLight already supporting
these kind of topologies (search "Supports OF island connections with
loops?" on http://vlkan.com/blog/post/2013/07/31/openflow-controllers/).
You can find more informations about ODL on http://wiki.opendaylight.org.
Everything I mentioned above is about the so called Forwarding module.
With the LearningSwitch module (that emulates a common layer2 switch on
the controller) things are different.
By OF specifications (I'm talking about OF spec 1.0) OF switches should
export an STP bit and controllers should receive it and use it for STP
purposes. This unfortunatelly almost never happens. Thus, using the
LearningSwitch module with common OF switches you can't have loops in
your topology.
For this reason we created the GreenMST module (github.com/LucaPrete).
After each topology change (for example due to a failure) the module
creates through the Kruskal algorithm a tree from the looped topology
and it sends a port_mod message to the switches, blocking (or
activating) the port outside (or inside) the just calculated tree. Thus,
all broadcast messege can't go through the closed ports and broadcast
storms never happen.
Hope everything is clear, as well if I think our module can't do
anything to solve your problem.
Cheers,
Luca
Il 28/08/2013 07:06, Sudeep Singh ha scritto:
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
<mailto:openflow-discuss-requ...@lists.stanford.edu>> wrote:
Send openflow-discuss mailing list submissions to
openflow-discuss@lists.stanford.edu
<mailto: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
<mailto:openflow-discuss-requ...@lists.stanford.edu>
You can reach the person managing the list at
openflow-discuss-ow...@lists.stanford.edu
<mailto: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 <mailto:luca.pr...@garr.it>>
To: openflow-disc...@mailman.stanford.edu
<mailto:openflow-disc...@mailman.stanford.edu>
Subject: Re: [openflow-discuss] Fwd: IEEE 802.1Q MSTP support in
OpenFlow Controller
Message-ID: <521c6106.6090...@garr.it
<mailto: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
<http://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
<mailto: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
<mailto: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
_______________________________________________
openflow-discuss mailing list
openflow-discuss@lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
