[rbridge] How is an IS-IS packet differentiated from layer 3 IS-IS, and TRILL-encapsulated data packets?

[Eastlake III Donald-LDE008]

OK.

Well, based on the email with this subject, the working group seems
pretty happy with the solution where both TRILL encapsulated data and
TRILL IS-IS frames are indicated by the TRILL Ethertype and header with
one of the current two reserved bits used to distinguish these cases.

But, to allow for the possibility of learning end nodes via IS-IS, I
think we need to provide for a per VLAN TRILL IS-IS message. The
proposal seems to be that, if a Q-tag is present, then it is per VLAN,
otherwise it is a core TRILL IS-IS message.

So a per VLAN multicast TRILL IS-IS message would look like

Outer.DA - 6 bytes (All-Rbridges)
Outer.SA - 6 bytes (this hop SA)
TRILL-Ethertype - 2 bytes (tbd)
TRILL Header - 6 bytes (with "control message" and multi-destination
bits on)
Inner.DA - 6 bytes (All-Rbridges)
Inner.SA - 6 bytes (original SA)
Q-Ethertype - 2 bytes
Q-tag value - 2 bytes
Length - 2 bytes
IS-IS DSAP - 1 byte (0xFE)
IS-IS SSAP - 1 byte (0xFE)
CTL - 1 byte (0x03)
IS-IS payload - variable

A core TRILL IS-IS message would be the same but without the inner
Q-tag. (Also, for a core IS-IS message, the inner and outer SA would
always be the same.)

If the IS-IS message was unicast core, the outer and inner DA addresses
would be the unicast destination, there would be no inner Q-tag, and the
multi-destination bit would be off.

If the IS-IS message was unicast per VLAN, the outer DA would the "this
hop" DA, the inner DA would be the original DA, the Q-tab would be
present, and the multi-destination bit would be off.

In the TRILL header, for the per VLAN case, the Hop Count seems
meaningful. But the ingress and egress RBridge nicknames are not used
and, in fact, you need to send IS-IS Hellos before nicknames may have
been established. Basically, the TRILL data frame needs six addresses,
one pair each for the end stations, the ingress/egress Rbridges, and the
per hop Rbridges. But IS-IS control messages are only ever from one
Rbridge to another, so they only need four addresses in the per VLAN
case (and really only two addresses in the core case since they go only
one hop).

So it seems to me that the alternatives are to either
	(1) Leave the nickname fields unset or set to zero on
transmission and ignored on receipt or
	(2) Maybe add one of the reserved bits to the Version field and
re-name it "Variation" or something and have the 6 byte "Data" variation
as currently specified and the "IS-IS" variation which is just 2 bytes
because it does not have the nickname fields.

Thanks,
Donald

-----Original Message-----
From: Silvano Gai [mailto:sgai at nuovasystems.com] 
Sent: Wednesday, May 30, 2007 2:25 PM
To: Erik Nordmark
Cc: Radia Perlman; Eastlake III Donald-LDE008; Rbridge at postel.org
Subject: RE: [rbridge] How is an IS-IS packet differentiated from layer
3 IS-IS, and TRILL-encapsulated data packets?

Erik,

You are correct, I oversimplified the explanation, but the conclusion
still holds

-- Silvano

> -----Original Message-----
> From: Erik Nordmark [mailto:erik.nordmark at sun.com]
> Sent: Wednesday, May 30, 2007 11:02 AM
> To: Silvano Gai
> Cc: Radia Perlman; Eastlake III Donald-LDE008; Rbridge at postel.org
> Subject: Re: [rbridge] How is an IS-IS packet differentiated from
layer 3
> IS-IS, and TRILL-encapsulated data packets?
> 
> Silvano Gai wrote:
> 
> > The advantage of using a reserved bit is that the frame with
Ethertype =
> TRILL already go through DR blocked ports. The non-TRILL IS-IS frames
will
> have Ethertype = ISIS and will be dropped by DR blocked ports.
> 
> I don't know if this matters, but AFAIK (and after checking RFC 1142),
> there is no Ethertype for IS-IS. Instead IS-IS uses a 802.3 header
(i.e.
> a length field instead of an Ethertype field) followed by 3 bytes of
LLC
> header with the SAP 0xFE. Thus the 3 bytes after the length field is
03
> FE FE.
> 
>     Erik
>