[rbridge] Ambiguity with IS-IS messages on PPP

[Radia Perlman]

(Note: I like descriptive subject lines, so I'm changing the subject 
line for the thread to discuss
James Carlson's latest noticing of a problem in the spec).

He mentioned that currently the way to tell the difference between an 
IS-IS message and an encapsulated
TRILL message is that the outer destination MAC address is 
"All-IS-IS-RBridges" for IS-IS messages, and
"All-RBridges" for encapsulated data, and ESADI. But on PPP, there is no 
"outer destination MAC addres". So,
how can we differentiate them?

Here are the possibilities that were floated around:

a) get two protocol types for TRILL for PPP (it's frowned on to "waste" 
these)

b) use the top bit after the PPP header, which would be the version 
field if there were
a TRILL header there, which fortuitously today happens to be 0 for 
TRILL-encapsulated, and 1 for
IS-IS. (kind of kludgy, and uses a bit of the already small version 
number field)

c) insert a "sub-protocol type" field after the PPP header, either a 
byte, or more if
people want the header byte-or word aligned. Currently it would only 
have two
values (IS-IS, or encapsulated)

d) always encapsulate with a TRILL header, and differentiate based on 
the "inner"
MAC destination address

************
I think I prefer suggestion c).

Here's James Carlson's original post:

James Carlson writes:

> >   - Given both this problem and the subtle MTU issues, reconsider the
> >     "unencapsulated" decision, and put IS-IS frames after a TRILL
> >     header that includes a flag indicating whether the payload is
> >     IS-IS or data.
>   

I know, bad form to follow up my own posting, and I should have
included this in my original message, but I could live with either the
original Inner.MacDA test (needed for both IS-IS and ESADI) to
distinguish these frames or with a discrete flag in the header.  The
latter would chew up a precious bit, but would be far easier to
implement in hardware and embedded systems (much easier than looking
for a giant Ethernet address later in the message at a potentially
*variable* offset due to options).

That latter sort of header would look like this on Ethernet:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               All-IS-IS-RBridges MAC Destination              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     MAC Destination (cont)    |       Source MAC Address      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Source MAC Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        TRILL Ethertype        | V |R|C|M|Op-Length| Hop Count |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Egress RBridge Nickname     |  Ingress RBridge Nickname     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  TRILL Options ...
      +-+-+-+-+-+-+-+-+-...
      |   IDRP = 83   |   Length ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

and this on PPP:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   ADDR = FF   |   CTRL = 03   |       TRILL Protocol ID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | V |R|C|M|Op-Length| Hop Count |   Egress RBridge Nickname     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Ingress RBridge Nickname     |  TRILL Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
      |   IDRP = 83   |   Length ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

Where the big change is the addition of the "C" (command/data) flag:

  If C == 0, then the header specifies TRILL data, and contains an
  Ethernet MAC header with VLAN tag after the TRILL Options (if any).

  If C == 1, then:

	M must be 0
	Op-Length is zero because no options are yet defined
	Hop Count must be 0
	Egress and Ingress RBridge Nicknames are 0 on transmit
	The IS-IS packet (starting with IDRP) begins after the
	(non-existent) options field.

A form like this guarantees that the key information required to
distinguish control from data is always at fixed offsets in the
packet, which is necessary for hardware design, simple embedded
systems, and some kinds of packet filtering mechanisms.

-- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun 
Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS 
UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 
_______________________________________________ rbridge mailing list 
rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge