[rbridge] New fields in shim header?

[Joe Touch]

Radia Perlman wrote:
> Silvano Gai has posted an interest draft suggesting new fields for the 
> shim header.
> The draft is at:
> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-00.txt
> 
> 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 
> unicast).
> 
> b) TTL
> 
> c) priority

Of these, only the TTL seems absolutely required; that includes the ones
below. Keeping the shim minimal seems important (to reduce MTU impact,
in particular). If further IP functionality is required - e.g., diffserv
code point-like f-tags, or source-routes-like LIDs - then perhaps we
shouldn't be doing this at the link layer, IMO.

Joe

> ****************
> 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.
> 
> Thanks,
> 
> Radia
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061011/7e6e6c98/signature.bin