[rbridge] New shim header proposal---without F-tag field
Radia Perlman
Radia.Perlman at sun.com
Mon Oct 30 18:49:52 PST 2006
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
More information about the rbridge
mailing list