[rbridge] Ingress Rbridge address and BCN
Larry Kreeger (kreeger)
kreeger at cisco.com
Fri Oct 27 14:05:27 PDT 2006
I think you bring up a good point, that there are multiple scenarios
that we need to analyze. Please allow me to try to make sure I
understand what you wrote. In the figure below, we have two end
stations A and C connected via 802.1au capable 802.1q bridges (B) and
In this scenario, B2 is providing transit for traffic from RB1 and RB2.
Assume traffic is flowing from A to C.
Caitlin Bestler wrote on Friday, October 27, 2006 9:53 AM:
> My analasys is that an 802.1au-capable RBridge could send a BCN in
> three different ways:
> 1) RBridge encapsulated to the original source c/o its
> source RBridge, which it already knew. The egress RBRidge
> would typically have this information.
In my network above, I think you are referring to when B3 detects
congestion and generates a BCN back towards RB2. True?
> 2) non-RBridge encapsulated is sent to the outer source,
> which is the *prior* rbridge and not necessarily the
> source rbridge, and we specify that 802.1au-capable
> RBridges act as proxies for BCNs received that are
> not RBridge encapsulated.
In my network above, I think you are referring to when B2 detects
congestion and generates a BCN back towards RB1. True?
> 3) RBridge encapsulated to the original source, but with
> an unknown destination RBridge.
In my network above, I think you are referring to when RB2 detects
congestion and generates a BCN back towards B2. True? As I mentioned
earlier, I believe the amount of BCN traffic could be non-trivial, so I
am not comfortable with flooding BCN to all RBridges in this case.
> I believe that #2 is required anyway, to deal with 802.1au bridges
> that are not RBridges.
> It is also worht pointing out that unless there are *four* RBridges
> in the "rbridge path" that the immediate prior rbridge to any core
> rbridge *will* be the source rbridge.
In a more interesting network (not the straight line I drew), the tree
sourced at the RBridge that is the congestion point may not always have
a branch that goes out the port that the original frame came in on (if
that link has a high cost). So, I think the originating RBridge may
need to send the BCN on all branches of its tree to ensure it will reach
the source RBridge.
> I believe these three options provide adequate solutions to this
> problem without requiring the addition of the source rbridge to the
> frame. But it does suggest that the header format should be designed
> so that it stacks efficiently with 802.1a headers.
> Standardizing the 802.1au proxy role is also important because
> otherwise you would have Rate Limited Frame wrappers around RBridge
> encapsulation. I believe it is far better to ensure that the BCN is
> forwarded to the original source so that RBridge encapsulates the
> Rate Limited Frame.
> rbridge mailing list
> rbridge at postel.org
More information about the rbridge