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 20742hedrick@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?> ------------------------------------------------------------------------------