Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!hayes
From: hayes@Apple.COM (Jim Hayes)
Newsgroups: comp.protocols.appletalk
Subject: Re: Phase 1 vs. Phase 2
Message-ID: <48379@apple.Apple.COM>
Date: 23 Jan 91 07:31:54 GMT
References: <1991Jan17.205340.11378@pbs.org> <48241@apple.Apple.COM> <29515@usc>
Organization: Apple Computer Inc., ECO Networking Group
Lines: 78

frankc@skat.usc.edu (Frank Callaham III) writes in article <29515@usc>:
>
>I know the "benefits" of Phase II, the problem I have, is that the
>Cisco Routers cannot currently route EtherTalk Phase II packets over
>a FDDI backbone.(This is according to my net admin.  He says that
>apple did something "wrong/strange" with the E-Talk2 packets)
>
>My point is...  It would not be all that difficult to port the phase 1
>code to the new card.
>

cisco does *route* Phase II over FDDI.  It's in software release
8.2 that started shipping around Christmas.  We currently route Phase
II on our FDDI backbone using cisco hardware.

---As for bridging Phase II onto/over FDDI:

You cannot easily BRIDGE Phase II over FDDI...  That's our fault not the
bridge vendor's.

SHORT STORY:
	In a particular type of AppleTalk phase II packet, we use a 
	non-standard vendor code (all zeroes) that most bridge 
	manufacturers interpret as meaning "no special format, so use 
	standard 802.3 packets on the other end" which means the 
	packets come out at the other end with the wrong format.

LONG STORY:  

When the powers that be created AppleTalk phase II, they decided to use
the IEEE 802.2 packet format with EtherTalk which would be consistent
with the packet format for TokenTalk as well.   (IEEE is an
"engineering professionals" organization that likes to make standards.)

The 802.2 packet contains something called a SAP (Service Access Point)
which is designed to help differentiate between different IEEE
protocols.  Since AppleTalk is not an IEEE protocol, it uses as special
SAP code ($AA [hex]) that the IEEE set aside for non-standard
protocols.

To distinguish all the various non-standard protocols, the IEEE created
something inside the $AA packet called the SNAP (Sub-Network Access
Protocol) that identifies the non-standard protocol and the vendor that
created it.

What we did wrong (and not just wrong, really *wrong*) was mess up the
SNAP header that identifies Phase II.  Turns out that for regular Phase
II packets we do the right thing.  We correctly shove our company code
($080007) into the packet and everything works just fine.  For the
other type of Phase II packet, the ARP (address resolution protocol) we
incorrectly shove in a company code of $000000 which most bridge
vendors take to mean "I have no special packet format".  Well, 802.2 is
a special packet format.   When the packet gets to the other end of the
network, it shoves it back onto the Ethernet as a regular old 802.*3*
packet which looks exactly like a Phase I AARP packet.  Needless to
say, the Phase II nodes ignore it.

This $000000 vendor code also causes problems for hosts on FDDI that speak
AppleTalk Phase II.

CONCLUSION:

Bridge manufacturers should agree on a way to correctly recognize this
packet and reconstitute it on the other end.  You can tell a Phase I
AARP from a Phase II AARP by looking inside the packet.  The network
number will always be zero in Phase I, and always non-zero in phase
II.  

I don't think there is an easy way to "fix" the Phase II spec. in this
regard.  Doing so would probably break more implementations than 
would benefit from its use.


-- 
Jim Hayes, Network Manager (I manage the hardware, not the network group)
Engineering Network Services, Apple Computer Inc.

Inet: hayes@apple.com		 UUCP: {amdcad|decwrl|ames}!apple!hayes