[rbridge] New shim header proposal---without F-tag field

[Dinesh G Dutt]

I hit "send" too soon. We talked about an additional bit in the header 
to identify a multicast frame. Did you see no need for that ?

Dinesh
Radia Perlman wrote:
> After talking to Silvano and Dinesh to get them to explain to me why
> the use of F-tag didn't multiply the number of trees that RBridges
> needed to compute by the number of F-tag values, they were able to
> explain to me why they wanted the F-tag. Here is a proposal to
> get the functionality they want without the use of F-tag.
>
> ***********************
>
> Motivation for F-tag
>
> They want to be able to do multipathing on multicast. We can already
> do multipathing on unicast by having an RBridge keep multiple equal
> cost (or near equal cost) paths to destination D, and split traffic
> however it wants. But if we have a single tree for all multicast
> with ingress RBridge R1, then all multicast traffic has to use
> the same links. The original proposal was to use F-tag as a selector
> for a tree. But the modified proposal is to use the "egress RBridge"
> field, which wasn't all that useful for multicast, as a "tree selector".
>
> ******************************
>
> So the proposal is:
>
> In the shim header will only be:
> 1) 16-bit ingress RBridge
> 2) 16-bit egress RBridge
> 3) TTL
>
>
> How these fields will be used in order to do multipathing:
>
> a) RBridges calculate a single tree for each ingress RBridge
>
> b) For unicast, an RBridge can calculate multiple equal-cost
> paths to the destination (or near-equal cost), and split traffic. That 
> is how
> we'd get multipathing for unicast. If S7 has two ways to get to 
> destination D,
> it can send some of its traffic one way, some of it the other. This is 
> solely
> S7's choice and doesn't need to be coordinated with any other switches.
>
> c) For multicast, we can provide multipathing by letting the ingress RBridge
> choose the distribution tree.
> The tree used will be indicated by the "egress RBridge"
> field. So, if S3 receives a multicast packet from an endnode, it puts
> "S3" as "ingress RBridge", but selects a tree by whatever means it
> wants, and puts, say, "S1" into "egress RBridge". That way the packet
> will be forwarded based on the tree calculated using S1 as the root.
>
> With this proposal, we get multipathing for multicast without configuration.
> The same space used for RBridge nicknames can be used for choosing the
> tree for multicast packets. The number of trees to be calculated does
> not change---it is still per ingress RBridge.
>
> Radia
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan