fddi encapsulation woes

jqj@rt-jqj.stanford.edu Thu, 31 May 1990 17:33 UTC

Received: from merit.edu by NRI.NRI.Reston.VA.US id aa10260; 31 May 90 13:33 EDT
Received: Thu, 31 May 90 12:32:39 EST from rt-jqj.Stanford.EDU by merit.edu (5.59/1.6)
Received: from LOCALHOST by rt-jqj.Stanford.EDU (5.61/inc-1.0) id AA19953; Thu, 31 May 90 10:32:33 -0700
Message-Id: <9005311732.AA19953@rt-jqj.Stanford.EDU>
To: fddi@merit.edu, jqj@rt-jqj.stanford.edu
Subject: fddi encapsulation woes
Date: Thu, 31 May 90 10:32:26 -0700
From: jqj@rt-jqj.stanford.edu
Status: O

I'm not on the FDDI list, so please CC me directly in any responses to this
query.

I'm confused by the IP encapsulation standard proposed in RFC1103 and in
the March draft (or maybe by the relationship between IEEE 802 and ANSI
XT3T9.5 committees).  Perhaps someone can clarify for me.

The March draft states that an IP datagram on FDDI looks like:

    MAC header | 802.2 LLC | 802.2 SNAP | IP datagram ...02

Where, 802.2 LLC is DSAP,SSAP,Control, and, presumably, the MAC header is
FC,DA,SA.  Notice that there is no length field there.

Several vendors have proposed that IEEE 802.x traffic (e.g. OSI) on FDDI
be carried as:

    MAC header | length | 802.x packet ...

mirroring the 802.3 "SA,DA,length,LLC, ..." bytes from the coax onto the
fiber.  If this becomes the standard method for carrying 802.x traffic on
FDDI, then it implies that an alternative IP encapsulation (mandated by
RFC1042) to the one suggested by RFC1103 and successors would be:

    MAC header | 16-bit length | 802.2 LLC | 802.2 SNAP | IP datagram

and that there would be 2 competing encapsulations for IP on FDDI, just as
there are 2 competing encapsulations for IP on Ethernet/802.3 media.

Of course, there is no standard yet here, since ANSI != IEEE.  However,
this seems to be a genuine problem with the proposed IP standard, and
somebody should put together an addendum allowing both encapsulations, with
appropriate advice on which one is more important.  Ugly.

The issue is driven primarily by the desire for transparent bridging between
Ethernet+802.3 and FDDI.  I gather that the transparent bridge vendors want
to have a mostly-invertible mapping so they can be sure that traffic
Ethernet => FDDI => Ethernet ends up with packets in the same format as
they were initially generated.  The standard for Ethernet => FDDI seems to
be to do RFC1103-style encapsulation of the Ethernet packet, which is great
for IP/Ethernet.  But what about IP/802.3 or AppletalkII/802.3 or whatever?

I guess it's possible that the standard way to carry 802.x traffic on FDDI
will be RFC1103-style (i.e. without the length field).  If so, how is a
transparent FDDI=>Ethernet bridge supposed to distinguish between packets
that were originally Ethernet and those that were originally 802.3?

JQ Johnson                              voice: 415-723-3078
Manager, Special Projects               Internet: jqj@jessica.stanford.edu
Networking and Communications Systems
Pine Hall Rm 125-A 
Stanford University
Stanford, CA 94305-4122