melohn@SUN.COM.UUCP (09/27/87)
Technically speaking, DECservers do not speak DECnet, they use a DEC propriatary protocol called LAT. This is an ethernet protocol which coexists with any other Ethernet protocol (like TCP/IP) without any problems.
dolson@ADA20.ISI.EDU.UUCP (09/28/87)
> From: melohn@Sun.COM (Bill Melohn) > Technically speaking, DECservers do not speak DECnet, they use a DEC > propriatary protocol called LAT. This is an ethernet protocol which > coexists with any other Ethernet protocol (like TCP/IP) without any > problems. Mostly right, thats during normal operations. However, during software downline loading from a VAX or PDP (or other?) host, and during the infrequent software crash dump UPline load, they do speak DECnet. Also, they support remote console facility which I guess is also DECnet...(thats NCP> CONNECT CONSOLE, check it out, nice for the times when you have to forceably logout a locked-up port and the terminal server in question is a long stroll away down the building!) Point is, 'technically speaking' the beasties do speak both LAT and DECnet, sometimes at the same time. Doug ------- -------
melohn@SUN.COM (Bill Melohn) (09/29/87)
Not true. Downline loading, upline dumping, and the remote console utility are handled by MOP, the Maintenance Operations Protocol, yet another Digital propriatary protocol that is NOT included under the publically available DECnet suite. True, to provide a mapping between LAT server names and their ethernet addresses they use the DECnet node database, but this is purely an implementation convienence (since their is no DNA equivalant of ARP). The point I was making is that DECnet is a publically specified interface for talking to DEC machines; however it does NOT include terminal servers, VAX clusters, and many other protocols which Digital considers propritary. I'm tired of explaining to customers why we can't support DEC terminal servers, "since they run DECnet" (which we can and do support under SunOS).
jsloan@wright.UUCP (09/29/87)
in article <8709270622.AA01122@sluggo.sun.com>, melohn@SUN.COM (Bill Melohn) says: > > Technically speaking, DECservers do not speak DECnet, they use a DEC > propriatary protocol called LAT. This is an ethernet protocol which > coexists with any other Ethernet protocol (like TCP/IP) without any > problems. True, LAT terminal servers are nice with LAT-capable machines (like VMS or Ultrix) but just about useless with any other vendors equipment, which is why we're going to TCP/IP terminal servers. Anyway, I think the issue here is whether the TCP/IP code and the DECnet code running on the same machine can coexist on the same ethernet controller, which is a very sticky question. The DECnet/Ultrix implementations seems to work fine. We use DECnet to talk to the VMS machines, TCP/IP (and NFS) to talk to the UNIX machines and our terminal servers, and LAT to talk to the few LAT boxes in other departments. I remember reading, I think, that other commercial products, like TWG's TCP/IP for VMS, would do the same. But I would read the fine print very carefully. I do know that there were a variety of changes to the networking code in Ultrix to support DECnet. I seem to recall that the lowest level TCP/IP layer was boosted up above an sort of generic ethernet packet server that controlled the interface board, and handed out appropriate ethernet packets to the TCP/IP or DECnet code. -- John Sloan CSNET: jsloan@CS.Wright.EDU UUCP: ...!cbosgd!wright!jsloan Computer Science Department, Wright State University, Dayton OH, 45435 +1 513 873 2491 belong(opinions,jsloan). belong(opinions,_):-!,fail. The only thing that depreciates faster than a computer is fresh fruit.
howard@COS.COM (Howard C. Berkowitz) (10/01/87)
In article <8709290741.AA02129@sluggo.sun.com>, melohn@SUN.COM (Bill Melohn) writes: > Not true. Downline loading, upline dumping, and the remote console > utility are handled by MOP, the Maintenance Operations Protocol, yet > another Digital propriatary protocol that is NOT included under the > publically available DECnet suite. MOP is fairly thoroughly documented in the DDCMP specification manual, part of publicly available Digital Network Architecture documentation. Use of MOP by DECnet software, however, deals more with VMS design than the protocols. Using the DDCMP manual, however, I was, in a previous job, able to design a dump/reload handler using MOP (which, for other reasons, we did not use). -- -- howard(Howard C. Berkowitz) @cos.com {uunet, decuac, sun!sundc, hadron, hqda-ai}!cos!howard (703) 883-2812 [ofc] (703) 998-5017 [home] DISCLAIMER: I explicitly identify COS official positions.
dolson@ADA20.ISI.EDU (Douglas M. Olson) (10/05/87)
> From: melohn@Sun.COM (Bill Melohn) > ... MOP, the Maintenance Operations Protocol, yet > another Digital propriatary protocol that is NOT included under the > publically available DECnet suite. "MOP is a subset of DDCMP..." (p 4-14 of the VAX/VMS Networking Manual) "DDCMP was designed in 1974 specifically for the Digital Network Architecture." (p 28 of pamphlet "Digital's Networks: An Architecture with a Future") So we are in agreement that LAT-speaking DECservers speak MOP, but we disagree on whether MOP is part of DNA or not. Fine. > From: melohn@Sun.COM (Bill Melohn) > The point I was making is that DECnet is a publically specified > interface for talking to DEC machines; however it does NOT include > terminal servers, VAX clusters, and many other protocols which Digital > considers propritary. I'm tired of explaining to customers why we > can't support DEC terminal servers, "since they run DECnet" (which we > can and do support under SunOS). Point taken. Doug -------
sandrock@uxc.cso.uiuc.edu (10/06/87)
I have an old DEC manual in front of me called: "Maintenance Oper-
ation Protocol (MOP), Functional Specification Version 2.0, March 1978".
It says: "To order additional copies of this document, contact the
Software Distribution Center, Digital Equipment Corp., Maynard, MA
01754". It also shows: "Order No. AA-D602A-TC".
Hope this is of some help!
Mark Sandrock, (sandrock@uiucuxc.UUCP)tedcrane@TCGOULD.TN.CORNELL.EDU (Ted Crane) (10/08/87)
In article <159@medivax.UUCP> chinson@medivax.UUCP (Chinson Yi) writes: >we have some DECserver 100 accessing it. We are trying to >install a TCP/IP product on it to communicate with our Ultrix >machine and I am wondering if the DECnet and TCP/IP will coexist >on the same machine sharing a DEQNA. We will be getting There've been a few replies to this. One mentioned putting DECnet up on the Ultrix machine. This is, in some ways, a limited solution but, *for what it does*, it works very well. Of course, it isn't free... -ted -- - ted crane, alias (tc) tedcrane@tcgould.tn.cornell.edu BITNET: tedcrane@CRNLTHRY {decvax!ucbvax}!tcgould.tn.cornell.edu!tedcrane DECnet: GOPHER::THC (607) 273-8768
pete@NCSC.ARPA (Fernandez) (02/18/89)
Fellow SIG Members,
I don't know exactly what would satisfy the following,
but I,m looking for a thing which can smooth the turbulent waters between
TCP/IPers and DECNETters; something that uses the tcp/ip in the appropriate
levels and uses the plusses of decnet in the higher levels. I know it's
a tall order, particularly since decnet is predicated upon DDCMP.
Thanx in advance
Pete Fernandez, pete@ncsc.arpaadelman@TGV.COM (Kenneth Adelman) (02/18/89)
I don't know exactly what would satisfy the following, but I,m > looking for a thing which can smooth the turbulent waters between > TCP/IPers and DECNETters; something that uses the tcp/ip in the > appropriate levels and uses the plusses of decnet in the higher > levels. I know it's a tall order, particularly since decnet is > predicated upon DDCMP. Ah, DECnet isn't stuck on DDCMP. As part of our VMS TCP product, MultiNet, we provide the ability to run DECnet lines and circuits over an arbitrary IP network (and the inverse). You can make a point-to-point DECnet circuit across the Internet, or any other place where you have IP connectivity. One copy of MultiNet would be required on each site of the link, and of course any other DECnet-only machines could route through the link. We attach DECnet at the lowest level of the protocol stack and encapsulate the DECnet datagrams into UDP datagrams for transmission. When they arrive at the other site, we pass them up to DECnet. For more information about MultiNet, please contact me offline... Kenneth Adelman TGV, Incorporated
CERF@A.ISI.EDU (02/19/89)
Pete, how about running higher level DECNET stuff above TCP so we can use ordinary IP gateways to tie everything together? Rather like Marshal Rose's ISODE suggestion in which higher level OSI protocols are supported above the TCP layer. Vint Cerf
german@UXH.CSO.UIUC.EDU (Gregory German) (02/19/89)
We are running a DECNET to TCP/IP gateway on a DECserver 3500.
This is a DEC software product running under Ultrix. TCP/IP users
can login on DECNET machines and DECNET users can login to TCP/IP
machines. Filetransfer is possible as well.
On a different level our campus backbone routes both TCP/IP and DECNET
traffic. We are using Proteon gateways between building networks and
the backbone is a collection of 10 and 80 megabit/sec Proteon Token
Rings. The two protocols do not interact, but they do co-exist.
Greg German (german@sonne.CSO.UIUC.EDU) (217-333-8293)
US Mail: Univ of Illinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801
Office: 129 Digital Computer Lab., Network Design Officekwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (02/22/89)
In article <8902172114.AA06098@ncsc.ARPA> pete@NCSC.ARPA (Fernandez) writes: > >Fellow SIG Members, > I don't know exactly what would satisfy the following, >but I,m looking for a thing which can smooth the turbulent waters between >TCP/IPers and DECNETters; something that uses the tcp/ip in the appropriate >levels and uses the plusses of decnet in the higher levels. Oh, what you want is "DECNet-over-TCP/IP", better known as DECNOT. This is similar to the concept of plugging ISO application layer protocols on top of TCP/IP, like CMOT, which is CMIP-over-TCP/IP. I was thinking of publishing the specs for DECNOT around the first of April. [note date] I was thinking this might take some of the wind out of DEC's sails when they come out with "ISO-compliant" DECNet Phase V. I like the acronym, DECNOT. Practically speaking, we should call it DECNEVER. The converse stack, "TCP/IP-over-DECNet", known as TIPDEC, is not nearly as feasible as DECNOT. IF all you want is "TCP/IP-over-DDCMP", that's no problem, just order TCPoMP, from Wollamagung software. Kent England, Boston University Disclaimer: None of the above should be taken seriously. It's all a personal whimsy of the author's. Seriously, the desired mongrel stack you seek is unfeasible and you should look for an application layer gateway, like DECNet-on-Ultrix, or run dual stacks on your DEC nodes, like you can with the Wollengong software. You aren't going to see anyone gluing lower layer TCP and DECNet together in any fashion. If you really want to see some fun with application gateways, look for the "transport-gateways" for gluing TCP/IP applications onto ISO applications. That should be fun to watch.