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

[Silvano Gai]

Eric,
I was just replying to Dinesh about where to put the bit that says if
the frame is a multicast.

The proposal is put it into the table.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Tuesday, October 31, 2006 8:37 AM
> To: Silvano Gai
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] New shim header proposal---without F-tag field
> 
> Silvano,
> 
> 	You do not need to send a message to the mailing list
> to do this, as this is not currently a WG document and you
> are one of its authors.
> 
> 	If you're asking if the draft would be more acceptable
> if this change were made, then that is what you should say.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: rbridge-bounces at postel.org
> --> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
> --> Sent: Tuesday, October 31, 2006 11:02 AM
> --> To: Dinesh G Dutt; Radia Perlman
> --> Cc: rbridge at postel.org
> --> Subject: Re: [rbridge] New shim header proposal---without
> --> F-tag field
> -->
> -->
> --> 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
> -->
> --> _______________________________________________
> --> rbridge mailing list
> --> rbridge at postel.org
> --> http://mailman.postel.org/mailman/listinfo/rbridge
> -->