Conference 7.286::fddi

    Basically, the Ethernet header is translated into an 802.2 SNAP SAP
    FDDI header.  If this reaches an FDDI adapter, it's back translated
    into an Ethernet looking header (for the VMS case) so that the
    application on the FDDI node thinks it's doing Ethernet.  The reverse
    is true for FDDI to Ethernet.  That is, the application (in the VMS
    case) will thinks it's sending an Ethernet frame.  The VMS driver will
    actually build a translated FDDI 802.2 SNAP SAP header and put the
    frame on the FDDI ring.  If the frame hits a 10-100 bridge and needs
    to be moved to the Ethernet, it's translated back into an Ethernet
    frame (as long as it's size is okay; except for IP) and placed on
    the Ethernet.  For IP, if the frame is too large, it's segmented.
    
    So...  applications should be able to run on FDDI adapters just as
    they run on Ethernet.  The VMS drivers will handle all the translation
    for Ethernet frames.  The interfaces to the FDDI drivers is the same
    as the Ethernet drivers.  There have been a few additional features
    added; but they should be of no concern to all Ethernet applications.
    The existing MBS parameter (maximum buffer size) which can be read
    by an Ethernet/FDDI application will return a different value for
    FDDI.  If an application uses this parameter to know how many bytes
    it can send, it may have a problem getting full size frames sent
    to an Ethernet node.
    
    So the main problem (on VMS) is knowing whether or not the receiving
    node (from an FDDI node) can be reached with a full size frame.  There
    may be a solution to this.  If so, it will be documented.  If
    applications use Ethernet-sized frames, then this is not a problem.
    
    As far as DECnet, LAT, LAVC, etc go; most are planning to make use of
    the full size frames if they are able to do so.  And that is their
    biggest problem because the interface (for VMS) to the FDDI driver
    is the same as the interface to the Ethernet drivers.  So the
    applications don't have much to do at this time.  Of course, network
    management in the Phase V timeframe will be a lot of additional work
    because it doesn't look anything like Ethernet.

If you were looking for the translation specifics, here is a capsule
description:

The data portion (including length and pad if it's a "Padded Ethernet"
protocol such as phase 4 DECnet) goes into the data portion of an 802.2
SNAP frame.  The protocol type is converted into a protocol ID by
prefixing 3 bytes of zero.

In the other direction, the bridge looks for SNAP frames with 3 bytes of
zero at the start of the protocol ID.  (In other words, it looks for
AA-AA-03-00-00-00 immediately following the source address.)  If it
finds that, it takes the next 2 bytes and makes those the Ethernet
protocol type.  Then it takes the data and puts that into the Ethernet
packet data.  Finally, if the result is too short, it pads it with nulls.

All this is in conformance with RFC 1042.

	paul

I probably should have thought of it about four years ago...before suggesting
to Postel that the way out of the bind caused by ISO not providing a second
SAP for ARP was to use SNAP with a protocol ID with 0 in the vendor field...

This leads to the annomolous case of an IP node on an 802.3 LAN sending packets
in 802.2 LLC SNAP format to a node on another LAN which receives it in Ethernet
format.  It gets even stranger if there are two paths, one via a 10/10 bridge
and the other via a 10/100-FDDI-10/100 bridge.  As long as the FDDI path is
operational, packets sent in 802.2 format will be recieved in Ethernet formats
but if it is taken out of service, the packets will now arrive in 802.2 format.

I guess this will resolve the unspecified part of RFC 1042:

	"The use of IEEE 802.1 compatible Transparent Bridges to allow
	interoperability across different networks is not fully describe
	pending completion of that standard."

Perhaps someone will forward Paul's note to Jon Postel so that he revise
RFC 1042?

(Don't get me wrong; I whole heartedly endorse the method described by Dave
and Paul for handling the migration and interoperability issues with Ethernet.
I just wish that I had thought of it and beleived that DEC might actually
implement this idea.)

Oh, so that's where it came from.  You correctly described an interesting
case, but it is NOT a problem provided that hosts conform to RFC 1122,
"Host Requirements".  That RFC requires anyone who uses 802.3 packet
format to accept Ethernet packets as well.  That RFC is what convinced
us that the translation approach I described is valid, and the anomaly
you mentioned is a non-problem.

I assume Postel is well aware of all this, though I agree it would be
nice to see RFC 1042 cleaned up in a few spots.

Incidentally, a corrolary to all this is that there is actually no benefit
whatsoever to using 802.3 (rather than Ethernet) IP packets on CSMA/CD
LANs.  It's extra software for no purpose.  The same could be said for
other protocols; unfortunately for a number of them the plan to migrate
to 802.3 format occurred before translating bridges were thought of.

	paul

    What is an RFC and how could I get a look at RFC 1042 ?
    
    Steve

    An RFC is a "Request for Comment", but it's also the name give to
    essentially anything distributed via the Internat Activities Board, the
    sanctioning body for TCP/IP.  RFCs include protocol specs, requirements
    documents, essays on related topics, and even occasional poetry and
    satire (especially around April).  Most are in plaintext, though some
    are in PostSCript or both.
    
    We keep them on line at trix::"~rfc/rfc####.txt", where #### is replaced
    by the 3 or 4 digit number.  This is Ultrix so case counts. 
    Get "rfc-index.txt" first.

In case at sometime in the future there are access problems to trix::,
another way of getting RFCs is to send mail (ULTRIX or VMSmail) -

To: DECWRL::"service @nic.ddn.mil"
Subj: rfc nnnn

where nnnn is the number of the rfc, ie "rfc 1042".  By the magic of NAS,
your RFC will appear in your mail within a few hours.

[Remember this is UNIX you are sending a request to, so observe the lower-case
convention used above.]