[Bridge] RSTP-Linux Bridge (2.6 Kernel) query

[voxner <voxner.dev@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]

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 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.

[-- Attachment #2: Type: text/html, Size: 2148 bytes --]