[rbridge] Ingress Rbridge address and BCN

[Larry Kreeger (kreeger)]

Hi Caitlin,

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
RBridges (RB).

A--RB1--B2--RB2--B3--C

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
> http://mailman.postel.org/mailman/listinfo/rbridge