[net.dcom] TCP/IP and XNS compatibility ?

dave@ecrcvax.UUCP (David Morton) (10/08/85)

Expires:
References:
Sender:
Reply-To: dave@ecrcvax.UUCP (David Morton)
Followup-To:
Distribution:
Organization: European Computer-Industry Research Centre, Munchen, W. Germany
Keywords:


[ hungary lion ]

Apologies if this request is downright naive.
As you all have probably heard XNS will be supported under 4.3.
We are currently running a VAX/785 and we have a number of TCP/IP
connections to other in-house machines.

My question to all you dcoms types is can we integrate those fancy
Xerox systems (which i believe support only XNS) into our current
environment and still remain transparent over the network. I've
heard a rumor that the Xerox systems (Dandelion etc.) only support
the original Ethernet spec. which differs slightly in the preamble
format( I think). These are, of course, two seperate problems.

Anybody have any experience integrating these systems into a 4.2/3
environment ?

Many thanks for your time and effort in advance.
-- 

Dave Morton
Tel. (49) 89 - 92699 - 139

CSNET: dave%ecrcvax.uucp@germany.csnet
UUCP: decvax!mcvax!unido!ecrcvax!dave

chris@umcp-cs.UUCP (Chris Torek) (10/08/85)

> ... can we integrate those fancy Xerox systems ... into our current
> environment and still remain transparent over the network.

Depends on what you mean by `remain transparent'.  To log on to
the Xerox print server in the CSD mail room, I have to type `gaptelnet
marylandps1' rather than `rlogin ...'.  But it works just fine.
Everything is compatible at the Ethernet level.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu

mark@tove.UUCP (Mark Weiser) (10/08/85)

Maryland, Cornell, and Berkeley all have Dandelions, Vaxes, Suns,
etc. on the same ethernet cable talking mixtures of XNS and TCP/IP
betwixt themselves.  All works well.  The business about the 
Dandelion's using a slightly different ethernet spec makes a (hardware
only) difference with which tranceivers will work with which ethernet
boards, but has nothing to do with the levels of protocol above
raw etherpackets.

(Well, is there is the funny business of TCP/IP using the XNS type
field as a length field, but this is gotten around by XNS reserving
all types which are valid TCP/IP lengths).
	-mark
-- 
Spoken: Mark Weiser 	ARPA:	mark@maryland	Phone: +1-301-454-7817
CSNet:	mark@umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!mark
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742

hedrick@topaz.RUTGERS.EDU (Charles Hedrick) (10/09/85)

We have Dandelions talking to other systems on the Ethernet, so there
does not seem to be a compatibility problem at the Ethernet level.  We
are using Interlisp on the Dandelions, and it supposts TCP/IP, PUP,
and XNS.  We use PUP with our 4.2 systems (using Stanford's PUP
implementation, which Xerox distributes) and TCP/IP with other
systems.  If you are using the XDE or office system instead of
Interlisp, I think your only choice is XNS.  In that case, talk to
Xerox about XNS for your VAX.  I don't recall the exact state of that,
but they may have it. Someone else will have to comment on whether 4.3
XNS will suffice to support your Dandelions.  It is common for
non-Xerox "XNS" implementations to include only the lower levels, and
not Courier and the file server protocols.  I don't know hether 4.3
has this problem or not.  If so, it may be less use that you would
hope.
In that case, talk to Xerox about XNS software for

robert@cheviot.uucp (Robert Stroud) (10/10/85)

In article <340@tove.UUCP> mark@tove.UUCP (Mark Weiser) writes:
>Maryland, Cornell, and Berkeley all have Dandelions, Vaxes, Suns,
>etc. on the same ethernet cable talking mixtures of XNS and TCP/IP
>betwixt themselves.  All works well.  The business about the 
>Dandelion's using a slightly different ethernet spec makes a (hardware
>only) difference with which tranceivers will work with which ethernet
>boards, but has nothing to do with the levels of protocol above
>raw etherpackets.

OK so far...

>
>(Well, is there is the funny business of TCP/IP using the XNS type
>field as a length field, but this is gotten around by XNS reserving
>all types which are valid TCP/IP lengths).
>	-mark
>-- 

Oh dear! If this is true, things are worse than I thought!! But I think
Mark is getting confused with the IEEE 802 world here. Let me explain
my understanding of the situation:

XNS, TCP/IP and other protocol families (DECNET?) are media independent.
However, they need some kind of medium to transport their packets between
machines, and clearly if two machines can't agree a common medium, they
can't communicate, even if they both have TCP/IP implementations (or whatever).

What we are concerned with here is the mechanism used by a media-specific
protocol (e.g. Ethernet) to encapsulate higher level protocols, and whether
this mechanism is sufficient to guarantee that the protocols will be kept
distinct.

The original Xerox Ethernet spec has the concept of a Type field. Each
protocol which uses the Ethernet is supposed to have been allocated
a globally unique Type value, and the Ethernet driver should keep
packets with different Type fields distinct. The XNS version of IP
uses a type field of 0x600 and the DoD version of IP uses 0x800.

The more recent Ethernet 2 spec, also produced by Xerox, uses the
same Type field mechanism and transmits the same bytes with the same
meaning over the network. The differences concern hardware interfaces.

Unfortunately, the IEEE 802 standards for LAN's are subtly different.
The encapsulation mechanism (802.2) is defined in a media independent
fashion, and there are a series of media specific standards - 802.3
is the one for Ethernet. 802.3 has no encapsulation mechanism because
it is only designed to carry one protocol - 802.2. The Type field in
the Xerox Ethernet spec is replaced by a Length field in 802.3.

Although this difference should mean that Xerox Ethernets and 802 Ethernets
are completely incompatible - distinct media - of course, in practice they
have a great deal in common. However, in order for 802 packets to safely co-exist
with Xerox packets on the same physical Ethernet, we need the equivalent of
the Type field used to distinguish the XNS packets from the TCP/IP packets.
Fortunately, if we arrange that no valid Xerox Type field can be a valid
802 Length field and vice-versa, we can achieve this. In practice this means
that the values 0x000-0x5ff are reserved by Xerox as Type fields for 802, 
whilst 802 implementations ignore packets with a Length field of 0x600 and above.

This is what I think Mark means - substitute "Xerox" for "XNS" and "802"
for "TCP/IP" in what he writes above. But if I'm wrong, please tell me!

It should be clear from what I have said that there is nothing to stop you 
using 802 rather than Xerox as the medium for XNS or TCP/IP, but don't expect an
802 TCP/IP implementation to be able to talk to a Xerox TCP/IP implementation.
All the 4.2 BSD Ethernet drivers happen to use Xerox to encapsulate the IP
packets, but they could just as easily use 802.2!

Disclaimer: I'm not expressing any opinion about the relative merits of Xerox
	    vs 802 - I'm just saying they're different! Comments which are
	    more informative than "802 is brain-damaged" would be appreciated.

Robert Stroud,
Computing Laboratory,
University of Newcsatle upon Tyne.

ARPA robert%cheviot.newcastle@ucl-cs.ARPA
UUCP ...!ukc!cheviot!robert
JANET robert@newcastle.cheviot

mark@tove.UUCP (Mark Weiser) (10/11/85)

> Someone else will have to comment on whether 4.3
> XNS will suffice to support your Dandelions.  It is common for
> non-Xerox "XNS" implementations to include only the lower levels, and
> not Courier and the file server protocols.  I don't know hether 4.3
> has this problem or not.  If so, it may be less use that you would

4.3's XNS will have Courier and many of the other higher level protocols.
It will not initially have filer server, but will have file client, GAP
server and client, print client, and other stuff.  All this nice higher
level stuff courtesy of Cornell.  Works fine with Dandelions running
the office environment.
	-mark
-- 
Spoken: Mark Weiser 	ARPA:	mark@maryland	Phone: +1-301-454-7817
CSNet:	mark@umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!mark
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742

pete@ecrcvax.UUCP (Pete Delaney) (10/17/85)

In article <tove.340> mark@tove.UUCP (Mark Weiser) writes:
   >Maryland, Cornell, and Berkeley all have Dandelions, Vaxes, Suns,
   >etc. on the same ethernet cable talking mixtures of XNS and TCP/IP
   >betwixt themselves.  All works well.  The business about the 
   >Dandelion's using a slightly different ethernet spec makes a (hardware
   >only) difference with which tranceivers will work with which ethernet
   >boards, but has nothing to do with the levels of protocol above
   >raw etherpackets.
I've heard from Bull that type1 and type2 tranceivers are compatible on the
cable but that type1 controllers can not be used with type 2 tranceivers;
perhaps because the new tranceivers sink more current.  Today I heard they
are not conpatible on the cable.  Any other optiions?
   >
   >(Well, is there is the funny business of TCP/IP using the XNS type
   >field as a length field, but this is gotten around by XNS reserving
   >all types which are valid TCP/IP lengths).
Are you sure it's not the other way around.  The ISO link headers have a length
field where TCP/IP has a type field.   



-- 

--------------------------------------------
Pete Delaney - Rocky Mnt. Unix Consultant	Phone: (49) 89 92699-139
European Computer-Industry Research Center 	UUCP: mcvax!unido!ecrcvax!pete
ArabellaStrasse 17 				UUCP Domain: pete@ecrcvax.UUCP
D-8000 Muenchen 81, West Germany 		X25: (262)-45890040262
CSNET:pete%ecrcvax.UUCP@Germany.CSNET		     Login: <to be provided?>
------------------------------------------------------------------------------