[rbridge] TTL only - was RE: New fields in shim header?
touch at ISI.EDU
Thu Oct 12 06:31:16 PDT 2006
Silvano Gai wrote:
> Are you advocating a model in which TRILL add an Ethernet shim header
> containing the TTL only? No RBridge addresses/nicknames?
Not necessarily, but it's clear that only TTL is *required*, and
everything else ought to have a very strong reason for inclusion.
> IMO, without a level of addressing at the RBridge level the forwarding
> is not flexible and scalable.
It would be useful to explain. In particular:
- how do rbridge addresses/nicknames enable flexibility vs. either VLAN
tags or the outer ethernet addresses?
- how does the lack of such tags affect scalability, *especially* given
that the solution is not intended to scale beyond that of current
ethernet deployments (we've discussed this before, and that was the WG
- which nodes would this affect?
- why is it important to carry decapsulation forwarding information in
the packet? (e.g., for the new proposal)
> -- Silvano
> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Joe Touch
> Sent: Wednesday, October 11, 2006 9:46 PM
> To: Radia Perlman
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] New fields in shim header?
> Radia Perlman wrote:
>> Silvano Gai has posted an interest draft suggesting new fields for the
>> shim header.
>> 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
>> see whether people think
>> the functionality they give warrants the extra space in the shim
>> I think it might be best to start a thread about each field
>> But I'll summarize here.
>> The current shim header contains:
>> a) RBridge nickname, which is either egress or ingress RBridge
>> on whether it is
>> directed unicast or not. This fits in MPLS's 20-bit Label field with
>> bit indicating whether
>> the RBridge nickname is the ingress (multicast) or egress (directed
>> 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.
>> 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
>> 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.
>> saves the egress RBridge
>> from looking up the destination address in the original frame (since
>> ingress RBridge already
>> had to do that work). The ingress RBridge knew the LID to put in
>> 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
>> 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
>> and attempt to never change
>> in the future. I don't have strong opinions. What do other people
>> 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
>> any of the fields.
>> rbridge mailing list
>> rbridge at postel.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061012/ac192c7d/signature.bin
More information about the rbridge