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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 31 Oct 2006 14:03:38 -0500

Why do you need/want a multicast bit?

If we're going to have both RBridge IDs in the SHIM, we don't
need to consume a bit for multicast/unicast discrimination...

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Tuesday, October 31, 2006 1:06 PM
--> To: Dinesh G Dutt
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] New shim header proposal---without 
--> F-tag field
--> 
--> No. I just forgot that bit.
--> 
--> So, we need
--> a) ingress RBridge
--> b) egress RBridge
--> (where both above fields are the same size)
--> c) TTL (6 bits ought to be enough)
--> d) multicast flag (just a single bit)
--> 
--> Anything else?
--> 
--> Radia
--> 
--> 
--> 
--> Dinesh G Dutt wrote:
--> 
--> > 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
--> >>
--> >>   
--> >
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 31 Oct 2006 13:48:40 -0800

Re: Eric Gray asked: Why a multicast bit:

I'm not sure we do need it, now that you mention it. Let's
work through the cases.

There is a field in the shim indicating what we've been calling "egress 
RBridge".  Let's say
the value of that field is "X".
An RBridge has to know whether
to forward via unicast to X, or to forward
along the bidirectional tree rooted at X.

The ingress RBridge will fill in the field as:
a) the nickname of the egress RBridge, if the destination is unicast and 
the location is known
b) the nickname of the root of the selected tree (usually itself) in the 
case of multicast
c) some reserved value (probably "0") in the case of unicast where the 
destination is unknown. (I'm
assuming nobody wants to multipath *these* types of packets to select a 
different tree than the
one rooted at the ingress RBridge).

With a multicast bit, that would determine in. But suppose there wasn't 
a multicast bit?

If the destination address in the original frame is multicast, then 
forward along the bidirectional tree rooted at X.

Otherwise, if "X"=0, then forward along the tree rooted at "ingress 
RBridge". Otherwise, forward
unicast towards X.

And if an RBridge R in the middle was ambitious, and knew where D was, 
it could replace "0"
with the egress RBridge.

Ordinarily I don't like seeing multiple ways of specifying something in 
a header, because then
you have to say what happens if they disagree. But if having the 
multicast bit makes forwarding
much simpler (since RBridges wouldn't have to look inside at the 
original frame), then maybe
people would prefer it.

So technically, I think ERic is right and it's not needed. But does it 
make things a lot more convenient?

Radia