dolson@ADA20.ISI.EDU (Douglas M. Olson) (07/18/86)
Preface: This one got longer than I had expected. I'd planned a
brief query to INFO-VAX for suggestions: but what this missive is
REALLY about is a newcomer to the DDN community trying to bring a new
installation aboard the net. It is long. I need some help. If this
sort of thing isn't your bag, recommend you skip it!
---------
From the outside looking in, I'm having a hard time figuring out
what I'm supposed to obtain (hardware and software) to make my
VAXCluster able to communicate on the DDN using VAX-based
instantiations of TELNET, FTP, and (especially important) SMTP. We
have just registered our connection requirement through the normal
MAJCOM and ASPO channels. They in turn will get our requirement to
DCA who will eventually service us with (we are told informally) a
56KB connection. I'm assuming that this connection will be a
conditioned circuit from the nearest node, probably over at AFWL on
the other side of Kirtland AFB. I'm also aware that the DCA may elect
to install a node here in our facility.
I'm being quite free with terms that I don't fully understand. For
instance, 'node'. I'm assuming this is (with current technology and
given the state of the net) the same thing as a C-30. Which runs some
node-control software (versions of which I understand are being
upgraded to allow older '1822' implementations to communicate with
newer 'x.25' { Basic | Standard } implementations...more terms I don't
fully understand). I have policy guidance indicating in typical DoD
doublespeak that I Shalt Not Plan to use an 1822 interface, as if I
could figure out what I wanted.
ACC glossies picked up at DEXPO indicate that the IF-11/HDH "operates
in HDH (1822-J) Packet Mode" and "the supported link level protocol
is HDLC/LAPB"....does that mean its on the verboten list for being
1822 or is it ok for me to buy?
As you can see, from what I can tell of the state of the net world, is
that things are in flux. What I can't tell is whether the flux
affects the decisions I ought to make right now. Due to the fact that
we are completely without the flavor of money that lets us make
capital expenditures when we need to, we rely TOTALLY on fallout funds
to make such purchases. That is, our only budget is Operations and
Maintenance; upgrades depend on our being ready to use other peoples
unspent money during a very brief window in August and September. If
I don't purchase interfaces next month, then DCA may show up with my
connection in May next year and we won't be able to buy the interfaces
then, and use the connection, until October!
I paint that bleak funding picture to explain WHY I need to answer the
interfaces question NOW.
Hm; actually, what I want is to use some smart box on the same
ethernet that services my VAXCluster. This box needs to support up to
100 simultaneous users who have opened connections from TACs around
the country. That '100' is usage projected within 3 years; initially,
I can probably get by supporting 50-60 simultaneous. Once into the
Cluster, on any machine, a user should be able to use FTP and SMTP to
exchange with the rest of the internet, presumably transparently using
the same connection route...diagrammed here:
VAXCluster---(ethernet)----[Smart Box]===(56KB)===C30....
The reasons I want to do it this way is to avoid either 1) buying a
separate interface for every single node on the Cluster or 2) buying
one interface for one VAX and then burying that VAX serving i/o to the
rest of the cluster... is it a ridiculous concept? Are these
ridiculous fears?
Given that 'what I want' probably doesn't exist; given that I fully
expect to have mangled at least one of these concepts and I HOPE you
can understand anyway; given that what I'm trying to do is comply with
directives to move all long-haul data communication requirements onto
the DDN, and my users are scattered from San Diego to West Palm Beach
to Boston to Seattle; I have several pleas to make.
Simple ones up front:
-anybody else already done this? how? are you using x.25 or 1822
interfaces (or is that even a valid question?)
-anybody so inclined, straighten out whichever concepts I mangled;
-if I belong in another forum, please point; I've been looking for months.
More involved issues:
Other approaches:
We have 3 Ethernet Terminal Servers (each w/32 ports) on the ether
now. They support dial-in modems and a few local hardwires. Is there
a device which provides a sort of reverse TAC facility? I believe it
may be a device I have heard called a PAD (for Packet Assembler/
Disassembler). If I had numerous terminal ports coming in off the C30
via such a device I could connect each port to the Ethernet Terminal
Servers over which we have software configuration control. This
solves my WORST problem of bringing my remote users in. I could
probably then accomodate putting a single interface for FTP and SMTP
and outgoing TELNET onto one VAX in the Cluster. Can anyone address
whether or not my understanding of a 'PAD' (or whatever its called) is
realistic? Is this a reasonable model?
Here are three DEC part numbers for "commercial" (vice educational)
TCP/IP networking packages; I understand DEC offers these products
through a licensing arrangement with The Wollongong Group.
QAX74-CM VAX IP/TCP VMS (supports DEUNA and DMR-11 interfaces)
QAXA9-CM VAX IP/TCP DDN (supports DEUNA and ACC's IF-11/HDH)
QAXX1-C3 IP/TCP MicroVMS (supports DEQNA)
(Just to save anyone the hassle of trying to find
the "educational" part numbers, here they are:
QAX75-CM VAX IP/TCP VMS and QAXX2-C3 IP/TCP MicroVMS...)
Are these the best VMS products available? Will any of them support
the [Smart Box] prayer I outlined above? Could a MicroVAX II with the
QAXX1-C3 possibly be the Smart Box? Could it support 50-100 users, or
would I need three (or 'n', tell me your guess at n) of them? If I
HAD three of them, how many can be supported by a single C30? If,
above, when I asked if my description of a [Smart Box] was a
ridiculous concept, you said to yourself, 'yes, ridiculous; he should
just use the blotzo' whats your blotzo?
I appreciate your patience. I've been digging since February when
Bob Tinker from the David Taylor Naval Ship R&D Center asked about
ethernet-DDN gateways. As of late April, he privately expressed
interest in new technology under development, upon which a product
announcement was expected late this year. I don't know if I can wait;
I hope you can tell from the tone of this that I have several degrees
of uncertainty about our approach. We're ignorant and need help.
From the real-(ignorant)-world of real requirements for day-to-day
long-haul data-communications, I'm sayin that we're mighty short on
solid information. Comments on the above gratefully appreciated.
Lt Doug Olson, USAF
Air Force Contract Management Division
Future Information Systems Program Manager
-------AFDDN.TCP-IP@GUNTER-ADAM.ARPA (08/14/86)
Oops! I meant this to go out the first time. Anybody know a good typing
instructor.
---------------
Date: 13 Aug 1986 23:22:07 CDT
Subject: Re: VAX IP/TCP
From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA
To: Douglas M. Olson <dolson@ADA20.ISI.EDU>
cc: AFDDN.TCP-IP@GUNTER-ADAM.ARPA
In-Reply-To: (Message from "Douglas M. Olson <dolson@ADA20.ISI.EDU>" of 18 Jul 1986 13:13:22 PDT)
Doug,
The real solution to support the large number of users you talked about
would be to support TCP/IP on your ethernet and use multiple IP gateways.
PAD is a generic term for the function of turning certain data streams
into X.25 packets for transmission through a packet network, and then
turning the packets back into the data stream on the other side of the
network. The purpose is to make the network transparent to the devices
generating the data streams. The primary use for PADs is to support
synchronous terminals across packet nets. This nutshell description doesn't
cover every aspect of PADs; its just info. The bottom line is PADs are not the
solution you need.
I recently sent you a note on the uVAX configuration you were considering.
Again, the bottom line of all I said was that I don't think a uVAX can handle
the simultaneous traffic you suggest. I would probably take two to handle
60 connections and even then I think that might be pushing it since every user
will be Telneting into the uVAX and then DecNetting out to their real host in
the Cluster. FTP users will have to transfer files onto the uVAX, then get
them across the ethernet. The same will probably be true of electronic mail
using SMTP; unless there's a package for the uVAX that will forward mail
through the ethernet. If anybody out there in TCP/IP land knows of software
to make the uVAX a cleaner interface, please let me know.
I have assumed that you are running DECNET in your Cluster. I think you
should consider using TCP/IP and use gateways into the Milnet. However,
I've heard it mentioned that some folks out at JPL are working on what
has been termed a DDN/Decnet gateway. I assume such a device would translate
between the ARM protocols and Decnet and would be transparent. Again, does
anybody else have more info?
Darrel Beach
-------
-------