AppleTalk broadcast addr on FDDI

Robert_Jeckell@3mail.3com.com Mon, 19 April 1993 22:14 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27447; 19 Apr 93 18:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27443; 19 Apr 93 18:14 EDT
Received: from cayman.cayman.com by CNRI.Reston.VA.US id aa11003; 19 Apr 93 18:14 EDT
Received: by cayman.Cayman.COM (4.1/SMI-4.0) id AA21928; Mon, 19 Apr 93 17:06:13 EDT
Return-Path: <Robert_Jeckell@3mail.3com.com>
Received: from gatekeeper.3Com.COM by cayman.Cayman.COM (4.1/SMI-4.0) id AA21924; Mon, 19 Apr 93 17:06:10 EDT
Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA29747 (5.65c/IDA-1.4.4-910725 for <apple-ip@cayman.com>); Mon, 19 Apr 1993 14:05:55 -0700
Received: by gw.3Com.COM id AA17691 (5.65c/IDA-1.4.4); Mon, 19 Apr 1993 14:05:52 -0700
Date: Mon, 19 Apr 1993 12:16:00 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Robert_Jeckell@3mail.3com.com
Subject: AppleTalk broadcast addr on FDDI
To: raj@doelztc.timeplex.com
Cc: apple-ip@cayman.com, Robert_Jeckell@3mail.3com.com
Message-Id: <930419.140706@3Mail.3Com.COM>
In-Reply-To: Message from {raj@doelztc.timeplex.com}:ug... of 4-19-93

    Date: Mon, 19 Apr 93 10:20:11 PDT
    From: raj@doelztc.timeplex.com (Raj Bhagwat)

    Hi all,

    Could someone please tell me what is the AppleTalk broadcast address on 
    FDDI. Is it 0x090007ffffff or 0xffffffffffff? I thought it was the former 
    one but I saw the FDDITalk that came with the Impulse Technologies' FDDI 
    cards use 0xffffffffffff for AppleTalk broadcast.

    Thanks in advance.

    Raj.

    Note: I had posted this query to info-appletalk list but got only one 
    response and it did not quite answer my question.


We have assumed it is 0x090007ffffff as Apple has specified.

Below is the text of the only document I know of that Apple has produced 
describing FDDITalk.  I'm not sure if a newer version is available.  I haven't 
heard anything in a long time.

It's funny you should ask at this time.  We implemented to the Apple spec, but 
I have just recently heard rumors that some third parties (as you have 
described) don't comply and that there may be some problems out in the real 
world.  I have asked Apple (Garry Hornbuckle), for any information they have, 
but I haven't heard back yet.  If I do, I will share the information.

Unfortunately we didn't go out and buy every FDDI adapter available for our 
tests.  We used Network Peripheral's adapters on Novell servers when we did our 
tests last year.  I believe we also did some testing with cisco boxes.  We 
didn't have any reason to question Apple's document.

This may be a case of early implementations that cropped up in lieu of a 
published standard from Apple.  But you would think that implementations would 
have caught up with the Apple spec.  It's been out for 2 years.  

By the way, I looked around up on AppleLink this morning and didn't find the 
FDDITalk document.  I also looked around on both ftp.apple.com.  Anyone at 
Apple know where it is located these days?

Has anyone else come across problems?  Any comments?

/bob

-----------------------------------------------------------------
Date: Thu, 27 Feb 1992 08:54:41 -0800
To: apple-ip@apple.com, mm@hobbit.gandalf.ca
From: veizades@apple.com
Subject: Re: fdditalk
-----------------------------------------------------------------
The following is the text of the document FDDITalk that is found on
AppleLink.

I hope it helps those who need it.

John...

--------------------------------------------------------------

FDDITalk: Preliminary Proposal
Apple Computer, Inc.
March 8, 1991

This document represents a proposed definition for how AppleTalk protocols
should be implemented on FDDI (that is, for "FDDITalk").  This proposal
should be considered as highly preliminary and subject to change.  Apple
will be publishing an official definition of FDDITalk at some point in the
near future.

The proposed definition of FDDITalk is simple and easy to state: FDDITalk
is precisely the same as EtherTalk Phase 2.  Although this is a slight
oversimplification, it is true from an overall point of view.  To be more
accurate, FDDITalk packet formats, at the 802.2 level, are precisely the
same as those used by EtherTalk.  Specifically, AppleTalk data packets and
AppleTalk Address Resolution Protocol (AARP) packets on FDDI have exactly
the same format as those on Ethernet (802.3) when looked at from the LLC
level (MAC headers will of course be different).

FDDITalk packets, like EtherTalk packets, are encapsulated in SNAP headers.
 AppleTalk data packets use SNAP type $080007809B.  AARP packets use SNAP
type $00000080F3.  The AppleTalk broadcast address used by FDDITalk is the
same as that used by EtherTalk, $090007FFFFFF.  The zone multicast
addresses are also the same, $090007000000 through $0900070000FC.  Finally,
the AARP hardware type used by FDDITalk is the same as that used by
EtherTalk, one (1).

At this time, it has not been decided whether AARP timeouts on FDDITalk
will remain the same as those on EtherTalk or not.  The issue of AARP
timeouts on FDDI is currently under investigation.

It is important to note that the actual AppleTalk data (i.e. the DDP
packet) is encapsulated in the FDDITalk packet (that is in the SNAP frame)
in the same way as it is encapsulated in EtherTalk packets.  This means
that the maximum size packets used by AppleTalk on FDDI is in the 600 byte
range (600 bytes plus SNAP, LLC and MAC headers).  The FDDI data link,
however, provides the ability to transmit multiple back-to-back packets on
one token, up to the limit placed by the "token hold timer" (a
MAC-layer-settable parameter).  Through judicious use of this feature, it
should be possible to achievement end-to-end AppleTalk throughput on FDDI
roughly equivalent to that which could be achieved through use of much
larger packets.

FDDITalk is being defined to be the same as EtherTalk due to the emergence
of FDDI-to-Ethernet "transparent" bridges.  These bridges make possible
communication between Ethernet (802.3) and FDDI, at the data link level. 
Although communication at this level may or may not be desirable (routing
is often be a better approach), this communication may be necessary in some
environments. Specifically, environments which already have FDDI-Ethernet
bridges installed may desire communication between AppleTalk nodes on both
media without requiring the installation of a router.