Hi all,
I am fairly new to Bridging, and I have been trying to understand the Bridge-RSTP communication. I have an RSTP implementation running in user-space and I would like to use the existing Linux bridge data-structures (like net_bridge, net_bridge_port used in Linux 2.6) so that I have a Linux-Bridge/RSTP setup. For this I need to introduce some sort of communication mechanism (maybe IOCTL calls) to alter these data-structures by my RSTP.
My idea is to disable STP (thus making sure that routines like br_configuration_update() are not called) and then use a communication mechanism to alter bridge/bridge-port states(stored in net_bridge) of kernel from my RSTP.
From my analysis, I found the following instances of communication
Bridge -> RSTP Communication
1. An RSTP BPDU (control) packet is received (like the routine br_stp_rcv in existing linux)
2. When a bridge is added or removed
3. When a port in a bridge is added or removed
RSTP -> Bridge Communication
1.Setting a Bridge-Port state
2.Setting Bridge-Ports pirority
3.Getting number of ports.
4.Command to send a BPDU packet
etc .......
I would like to know if I am on the right track. To summarize I "disable" all those STP routines, introduce a bunch of routines that set bridge/ports based on communication received from the RSTP running in user-space.
I am fairly new to Bridging, and I have been trying to understand the Bridge-RSTP communication. I have an RSTP implementation running in user-space and I would like to use the existing Linux bridge data-structures (like net_bridge, net_bridge_port used in Linux 2.6) so that I have a Linux-Bridge/RSTP setup. For this I need to introduce some sort of communication mechanism (maybe IOCTL calls) to alter these data-structures by my RSTP.
My idea is to disable STP (thus making sure that routines like br_configuration_update() are not called) and then use a communication mechanism to alter bridge/bridge-port states(stored in net_bridge) of kernel from my RSTP.
From my analysis, I found the following instances of communication
Bridge -> RSTP Communication
1. An RSTP BPDU (control) packet is received (like the routine br_stp_rcv in existing linux)
2. When a bridge is added or removed
3. When a port in a bridge is added or removed
RSTP -> Bridge Communication
1.Setting a Bridge-Port state
2.Setting Bridge-Ports pirority
3.Getting number of ports.
4.Command to send a BPDU packet
etc .......
I would like to know if I am on the right track. To summarize I "disable" all those STP routines, introduce a bunch of routines that set bridge/ports based on communication received from the RSTP running in user-space.
I have looked at the differences between STP and RSTP but I am unsure as to how this will play out in my solution. Should I go for another strategy? Is there any similar work out there that does this? I would really appreciate any input/pointers in this matter.
Thanks,
Vox
P.S. To get an insight into this problem I took a cursory look at another RSTP implementation called RSTPLib (http://rstplib.sourceforge.net) but it uses daemons, sysfs & crucially it is not "integrated" into the kernel. I am also unclear if it's purely on a simulation tool. Also its code seems no longer under development.
Thanks,
Vox
P.S. To get an insight into this problem I took a cursory look at another RSTP implementation called RSTPLib (http://rstplib.sourceforge.net) but it uses daemons, sysfs & crucially it is not "integrated" into the kernel. I am also unclear if it's purely on a simulation tool. Also its code seems no longer under development.
_______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
