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
_______________________________________________
openflow-discuss mailing list
openflow-discuss@lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
