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

[Silvano Gai]

Radia,

Thank you for improving our proposal,
Of course, I am in favor

-- Silvano

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Radia Perlman
> Sent: Monday, October 30, 2006 6:50 PM
> To: rbridge at postel.org
> Subject: [rbridge] New shim header proposal---without F-tag field
> 
> 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