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

[Silvano Gai]

I propose that we replace Figure 3 in
http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-00.txt

with:

0xxxxxxxxxxxxxxx	Unicast
100rrrffffffffff	Unicast floooding
101rrrffffffffff	Registered multicast
110rrrffffffffff	Non-registered multicast
111rrrffffffffff	VLAN Broadcast

Where:
xxxxxxxxxxxxxxx is the RBridge ID
ffffffffff is the FTAG
r is reserved

-- Silvano



> -----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 7: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