[rbridge] New fields in shim header?
Radia.Perlman at sun.com
Wed Oct 11 14:46:43 PDT 2006
Silvano Gai has posted an interest draft suggesting new fields for the
The draft is at:
If new fields are added, we'll have to give up on the MPLS-like
encoding, and the shim header
would be slightly larger, so we should consider each of these fields and
see whether people think
the functionality they give warrants the extra space in the shim header.
I think it might be best to start a thread about each field separately.
But I'll summarize here.
The current shim header contains:
a) RBridge nickname, which is either egress or ingress RBridge depending
on whether it is
directed unicast or not. This fits in MPLS's 20-bit Label field with one
bit indicating whether
the RBridge nickname is the ingress (multicast) or egress (directed
The proposed extra fields for the shim header are:
a) have BOTH ingress and egress RBridge nicknames, and shrink the
nicknames down to 16 bits.
The reason for this is that in the case of directed unicast policy (such
as source address filtering)
can be applied to ingress as well as egress RBridge).
b) F-Tag: I think of this as a metric identifier, proposed length
10-bits. This enables setting multiple
costs for each link, and calculating paths and trees differently for
different types of traffic
c) egress LID ("local identifier"). This is for the convenience of the
egress RBridge---for example, it could
be the port onto which the (decapsulated) frame should be forwarded. It
saves the egress RBridge
from looking up the destination address in the original frame (since the
ingress RBridge already
had to do that work). The ingress RBridge knew the LID to put in because
the egress RBridge had
announced (my nickname, LID) for that destination. The ingress RBridge
does not interpret the LID---just
sticks it into the shim header.
d) ingress LID The only reason I think to have an ingress
LID is in case at some point in the future learning of (destination MAC
address corresponds to
egress RBridge, LID) is done based on looking at data packets.
Otherwise, this would be learned
from link state advertisements, and only one LID (egress LID) would be
in the shim.
Anyway---the format of the shim is something we really should decide on
and attempt to never change
in the future. I don't have strong opinions. What do other people think?
If you care about any of these fields (pro or con) start a thread with
subject line, e.g., "F-tag in shim header".
Or maybe I'll do it. Or for now, reply to this note with opinions about
any of the fields.
More information about the rbridge