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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Sun, 5 Nov 2006 15:23:29 -0500

I think this also needs to be something we discuss this week. 

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt
--> Sent: Tuesday, October 31, 2006 10:25 AM
--> To: Radia Perlman
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> 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
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->