|
|
ARCHIVE: TCP-IP Distribution List - Archives (1987)
DOCUMENT: TCP-IP Distribution List for December 1987 (271 messages, 139513 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1987/12.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Tue, 01 Dec 87 08:22:25 -0500 From: haverty@CCV.BBN.COM To: TCP-IP@SRI-NIC.ARPA Subject: Re: MRC: NFS over ARPANET
Mark -- you might want to describe the BOJ/JOB machinery that was the underpinning for MLDEV et al; we didn't just have NFS over the Arpanet, we had a general network I/O and RPC facility, which was the infrastructure for creation of things like the MLDEV NFS and a variety of other strange things. Jack (I'd describe it but I don't trust my memory for the details)
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Dec-87 08:07:13 EST From: jsloan@wright.UUCP To: comp.protocols.tcp-ip Subject: Ethers, Copper, Fiber, Microwaves, Etc.
Some time ago I helped write an RFP for a 10 Mb/sec ethernet-to-ethernet link via microwave (thanks, Kent England at BU for the info!). We have since contracted with the vendor and installation should be completed around Christmas. In the process there has been some mutual education between the microwave group and the networking group on campus. There are now incredibly cheap (a few thousand $s) microwave systems, with dishes that you could put in a briefcase, that could conceivably be pushed to 10 Mb/sec over very short distances. How long will it be before it will be cheaper to run networks between adjacent buildings on a campus or research park etc. using these tiny microwave systems instead of running copper or fiber? I suspect the major cost would be the ether bridges on either end that may be necessary (and maybe not), but it could also be that you would want packet filtering with bridges even if you used copper or fiber. I remember reading about lasers doing similar things. Also an interesting thought. Our RBOC bid a optical fiber link. Although their ethernet-to-ethernet product (if its not vaporware) was not available by our deadline, this too is an interesting idea, not for short distances (a solution which has been around for a while) but for long distances, like over five miles or more. Managing a geographically dispersed ethernet would be challenging, but the functionality is appealing. Anyone have any concrete ideas on any of this? Those little microwave dishes are looking better and better. -- John Sloan Wright State University Research Center jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 ...!cbosgd!wright!jsloan (513) 259-1384 (513) 873-2491 Logic Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Dec-87 09:00:13 EST From: haverty@CCV.BBN.COM To: comp.protocols.tcp-ip Subject: Re: MRC: NFS over ARPANET
Mark -- you might want to describe the BOJ/JOB machinery that was the underpinning for MLDEV et al; we didn't just have NFS over the Arpanet, we had a general network I/O and RPC facility, which was the infrastructure for creation of things like the MLDEV NFS and a variety of other strange things. Jack (I'd describe it but I don't trust my memory for the details)
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Dec-87 13:29:21 EST From: slevy@UMN-REI-UC.ARPA (Stuart Levy) To: comp.protocols.tcp-ip Subject: Re: Fwd: NFS over arpanet?
One problem we've had in NFSing between disparate machines is with naming them. The mount request passes the originating machine -name- rather than having the server use gethostbyaddr(). It's important to check that "hostname" on the client yields a name known to the server and vice versa. That's probably not the whole problem but can cause things to break. A guy from Proteon, Mick Scully (mcs@proteon.com) recently visited here and mentioned that he had mounted NFS filesystems at Berkeley across ARPAnet.
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 1 Dec 87 09:05:59 GMT From: howellg@idec.stc.co.uk (Gareth Howell) To: rec.ham-radio.packet,comp.protocols.tcp-ip Subject: NEEDED: KISS for TNC220
I have a Pacomm TNC220 on which I want to run KISS and thence the KA9Q tcp/ip package. Unfortunately I don't have a KISS for the TNC. Can anybody help. I would prefer the co-resident bootstrap with a downloaded KISS module if possible. ta Gareth ==== -- Gareth Howell <howellg@idec.stc.co.uk> G6KVK @ IO91VX ICL NS PNBC, England, SG1 1YB Tel:+44 (0)438 738294 howellg%idec%ukc@mcvax.uucp, mcvax!ukc!idec!howellg@uunet.uu.net G6KVK @ G4SPV (uk packet 144.650MHz)
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Dec-87 11:14:22 EST From: NIC@SRI-NIC.ARPA (DDN Reference) To: comp.protocols.tcp-ip Subject: ARPANET UPGRADE SCHEDULE
A meeting will be held on Thursday, December 3, to furthur discuss the new ARPANET End-to-End protocol (PSN 7.0). Due to necessary software patches, 2 test period options are being considered: 1) Testing of the new End-to-End on two week-ends, December 5th and 6th, and December 12th and 13th for a total of 4 days. 2) Testing of the new End-to-End beginning December 5th running through December 13th, for a total of 9 days. Hosts experiencing problems during this test period are asked to call the ARPANET Monitoring Center at (617) 873-3571/3070 or (800) 492-4992. -------
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Dec-87 11:34:00 EST From: YBMCU@CUNYVM.CUNY.EDU (Ben Yalow) To: comp.protocols.tcp-ip Subject: BITNET-Internet gateway changes
As has been announced in a number of places, the Internet <-> BITNET gateway at WISCVM (WISCVM.WISC.EDU) is going away. The final date for using that gateway is Dec 15, 1987. BITNET has been working with the Internet administration to provide a set of multiple regional gateways between the two networks. Until that time when a suitable technical solution is developed, an interim solution has been put in place, effective immediately. From the BITNET side, mail should be sent to SMTP@INTERBIT. The node is currently in the tables distributed by BITNIC, and now points towards CUNYVM. At a later date, this will point to the appropriate regional gateway. The distributed DOMAIN NAMES file is being updated to point at SMTP@INTERBIT instead of SMTP@WISCVM. The updated file will be distributed as the normal distribution on Monday, Dec 7. All sites, especially those other than end nodes, should ensure that the latest tables are installed. For those on the Internet side, the first of the gateways is at CUNYVM.CUNY.EDU (CUNYVM on the BITNET side). Any mail formerly sent to user%node.BITNET@WISCVM.WISC.EDU should now be sent to user%node.BITNET@CUNYVM.CUNY.EDU. This is an interim solution until the full set of gateways is in place. At that time, notice will be sent out giving details of the new gateways. Those users on other networks who use WISCVM as a gateway to BITNET need to modify their mailer tables appropriately. The code running in the gateway is fully compatible with the code currently running at the WISCVM gateway. Any mail which worked at the WISCVM gateway will work with the CUNYVM gateway. If any problems are experienced, you may direct any discussion to POSTMASTER@CUNYVM.CUNY.EDU. Note: The node CUNYVM.CUNY.EDU on the Internet is the same as CUNYVM.BITNET. This node now has a direct connection to the Internet. Ben Yalow Director of Systems & Programming City University of New York/University Computer Center BITNET: YBMCU@CUNYVM Internet: YBMCU@CUNYVM.CUNY.EDU
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Wed, 02 Dec 87 11:34:00 EST From: Ben Yalow <YBMCU@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: BITNET-Internet gateway changes
As has been announced in a number of places, the Internet <-> BITNET gateway at WISCVM (WISCVM.WISC.EDU) is going away. The final date for using that gateway is Dec 15, 1987. BITNET has been working with the Internet administration to provide a set of multiple regional gateways between the two networks. Until that time when a suitable technical solution is developed, an interim solution has been put in place, effective immediately. From the BITNET side, mail should be sent to SMTP@INTERBIT. The node is currently in the tables distributed by BITNIC, and now points towards CUNYVM. At a later date, this will point to the appropriate regional gateway. The distributed DOMAIN NAMES file is being updated to point at SMTP@INTERBIT instead of SMTP@WISCVM. The updated file will be distributed as the normal distribution on Monday, Dec 7. All sites, especially those other than end nodes, should ensure that the latest tables are installed. For those on the Internet side, the first of the gateways is at CUNYVM.CUNY.EDU (CUNYVM on the BITNET side). Any mail formerly sent to user%node.BITNET@WISCVM.WISC.EDU should now be sent to user%node.BITNET@CUNYVM.CUNY.EDU. This is an interim solution until the full set of gateways is in place. At that time, notice will be sent out giving details of the new gateways. Those users on other networks who use WISCVM as a gateway to BITNET need to modify their mailer tables appropriately. The code running in the gateway is fully compatible with the code currently running at the WISCVM gateway. Any mail which worked at the WISCVM gateway will work with the CUNYVM gateway. If any problems are experienced, you may direct any discussion to POSTMASTER@CUNYVM.CUNY.EDU. Note: The node CUNYVM.CUNY.EDU on the Internet is the same as CUNYVM.BITNET. This node now has a direct connection to the Internet. Ben Yalow Director of Systems & Programming City University of New York/University Computer Center BITNET: YBMCU@CUNYVM Internet: YBMCU@CUNYVM.CUNY.EDU
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Dec-87 11:35:00 EST From: rrv@uxc.cso.uiuc.edu To: comp.protocols.tcp-ip Subject: Re: Connexions - Magazine (defunct ??)
ConneXions Advanced Computing Environments 21370 Vai Avenue Cupertino, CA 95014, USA phone 408/996-2042
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Dec-87 14:52:40 EST From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) To: comp.protocols.tcp-ip Subject: Re: Ethers, Copper, Fiber, Microwaves, Etc.
In article <203@wright.EDU> jsloan@wright.EDU (John Sloan) writes:
>
>There are now incredibly cheap (a few thousand $s) microwave systems,
>with dishes that you could put in a briefcase, that could conceivably
>be pushed to 10 Mb/sec over very short distances.
Now this is something new to me. If you can put them in a
briefcase they must be around 100GHz. That would probably limit the
range to a mile or so. The problem with infrared laser technology is
the atmospheric attenuation of smog, fog, and rain. Sounds like this
new ultra-high freq microwave fills the gap between low freq uwave and
infrared.
>
>Our RBOC bid a optical fiber link. Although their ethernet-to-ethernet
>product (if its not vaporware) was not available by our deadline, this
>too is an interesting idea, not for short distances (a solution which
>has been around for a while) but for long distances, like over five
>miles or more. Managing a geographically dispersed ethernet would be
>challenging, but the functionality is appealing.
I like fiber. I can't wait to see what happens to FDDI as it
develops. Fiber optic FDDI will be robust, high speed, and simpler
than broadband. I think the ring circumference is around 23 km which
will cover a lot of campuses. Speed is 100/200 Mbps. Of course,
Pronet-80 is here now and works much the same way FDDI will.
I won't repeat the arguments regarding routers versus bridges
or introduce a new argument about slow routers versus smart/fast
bridges, but I definitely favor routers if we can get some new
hardware architectures that will run thousands of packets per second
in a multi-protocol environment. Multibus and Interlan Enet cards
won't cut it with FDDI and embryonic ISO protocols. Fiber optic token
ring is my preference over a fiber optic monolithic Ethernet. You
should be excited about managing a geographically dispersed internet,
but appalled at the thought of managing a geographically dispersed
(large) Ethernet.--
-------------------------------------------------------------------
Kent W. England | Boston University
Network & Systems Engineering Group | Information Technology
kwe@bu-it.bu.edu internet | 111 Cummington Street
itkwe@bostonu BITnet | Boston, MA 02215
harvard!bu-cs!kwe UUCP | (617) 353-2780
-------------------------------------------------------------------
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Dec-87 17:49:21 EST From: rob@PRESTO.IG.COM (Rob Liebschutz) To: comp.protocols.tcp-ip Subject: Re: NFS over arpanet?
While casually playing around during a recent visit to Rutgers, I was able to sucessfully mount and access an NFS file system over the Arpanet (cross-country). Things were a bit slow and I experienced timeouts, but it did work (and that was back when the performance of our Arpanet connection was quite bad). I didn't even bother to specify anything other than the default NFS mount parameters. I was waiting to see if the operator at Rutgers would come running into the systems office complaining about messages on the console "NFS server presto.ig.com not responding" what should I do :-). Rob
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Thu, 3-Dec-87 00:21:31 EST From: henry@utzoo.UUCP.UUCP To: comp.protocols.tcp-ip Subject: Re: Networks & vendor upgrades/fixes
> For example, one could simply demand, as with all warrantees, that
> software will not be maintained if monkeyed with...
I dimly recall a software vendor who would sell you source *or* support
but not both. They had the right idea.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Thu, 3-Dec-87 11:04:33 EST From: AD@BROWNVM.BITNET.UUCP To: comp.protocols.tcp-ip Subject: Re: Connexions - Magazine (defunct ??)
Subscription information for Connexions:
conneXions
21370 Vai Avenue
Cupertino, CA 95014
US/Canada $360/12 issues/year
University $240/ " / "
They accept POs, MC, and VISA.
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Thu, 03 Dec 87 11:04:33 EST From: Arif Diwan <AD%BROWNVM.BITNET@WISCVM.WISC.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Re: Connexions - Magazine (defunct ??)
Subscription information for Connexions:
conneXions
21370 Vai Avenue
Cupertino, CA 95014
US/Canada $360/12 issues/year
University $240/ " / "
They accept POs, MC, and VISA.
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Thu, 3-Dec-87 18:08:51 EST From: jerry@oliveb.UUCP To: comp.unix.wizards,comp.protocols.tcp-ip Subject: Re: Can I print on a terminal server port
A while back I posted a request for information on printing using a telnet terminal server from a 4.3bsd host. Here is the prommised summary of responses. Several people pointed out that one can run telnet<filename to send a file to a printer connected to a terminal server port. (All of this assumes that the terminal server will allow you to configure a port as a host and assign an IP address to it.) It was also pointed out that it is possible to modify telnet and turn it into a filter program for the lpd spooler. Many responses stated that the Encore Annex terminal servers provide support for the Berkeley lpd protocol as well as providing a centronics parallel port. It does require modification to the lpd software though. Cisco also supplies a "filter" to allow printing on one of its terminal servers. Finally, some people are working on making the changes in lpd to support this. (Roy Marantz at Rutgers.) This seems the correct sollution as it does not lock one into a particular brand of server. Apparently there are problems with implementing this. One mentioned was the terminal server flushing the buffered portion of the data when the connection is closed. The edited responses follow: -- From: eshop%saturn.UCSC.EDU@ucscc.UCSC.EDU (Jim Warner) Bridge Communications application note #12 contains a printer server program that looks like it would do what you want. The program is intended to be run on a 4.2BSD machine. If you send me a US mail address, I will send you a paper copy. This is coming up soon for us, too. I will probably hand it to a secretary to see how well they can type in c-code. jim warner -- From: unisoft!suntea!carl@ucbvax.Berkeley.EDU (Carl Smith) We do this with our cisco ASM terminal servers. It's trivial to take telnet and hack it a bit to act as a filter to a port on a terminal server. Carl -- From: sun!tundra!dave%rosevax.Rosemount.COM (Dave Marquardt) I've been able to print to terminals attached to Bridge TCP/IP terminal servers. I've also managed to integrate this into the 4.3 BSD lpr spooling system, in a primitive sort of way. Dave -- From: Scott Brim <swb@tcgould.tn.cornell.edu> Encore terminal servers come with instructions on how to set this up. -- From: jsalmi@eta.eta.com (John Salmi) a couple of us hacked out a tcp print server to enable us to print from our sun network on a big imagen connected to a very large apollo ring. lemme know if you want the code. it's really quite simple :-) -- From: ames!uw-beaver!ssc-vax!jeff (Jeffrey Jongeward) We do this to 2 LW+'s from VMS & 4.3BSD, talking telnet to a bridge box in listen mode. This gives us connectivity w/o having to rely on any one host which seemed like a good thing at the time tho' if I were doing it again, I'd just make VMS talk to lpd and hardwire the LW+'s to one of the 4.3 systems. Works quite well, s/w is home grown. - jeff jongeward @ boeing aerospace -- From: Milo S. Medin (NASA ARC Code ED) <medin@orion.arpa> Encore Corp's Annex terminal server lets you do just this. In fact, they include a Centronics parallel port too, in case you like parallel printers better. They have tons of other features, and I just can't praise them enough. And people who know me will tell you I rarely give that complement. They understand the UCB lpd protocol as well. All very good stuff. We've tried many terminal servers here, and the Annex is by far the best. -- From: William Westfield <BILLW@MATHOM.CISCO.COM> cisco Systems terminal servers fully support the use of terminal ports in the reverse direction (eg host establishes a connection to a specific terminal port of the server). Various types of connections are supported (eg telnet, telnet binary, and 8 bit stream), along with rotary groups (get the first free port in a group) and miscellaneous other options. In fact, we use such an arangement internally at cisco to allow spooling from our tops20 and unix systems to an apple laserwriter. We will supply source code for a unix filter that sends data over a TCP connection, that can be used to build full-fledged spoolers, or in a simpler configuration for smaller networks. At least one of our competitiors also supports using a terminal server in ths manner, though of course not as well :-) Give us a call at (415)-326-1941 if you would like more information. Bill Westfield cisco Systems. -- From: jas@monk.proteon.com (John A. Shriver) The Encore TIU (which we also sell as the Proteon TIU) has support for this. It requires some changes to the lpd software on the UNIX system. The box even has a Centronics printer port, or you can use an async port. -- From: ron@topaz.rutgers.edu (Ron Natalie) Roy Marantz here at Rutgers is working on this for lpd. The printcap has a terminal server name/ TCP port number entry for these printers. There is currently still some bug that prevents this from working. -- From: hplabs!hpda!uunet!unido!iaoobel!woerz (Dieter Woerz) We had several terminal servers for test here. (CS/100 from Bridge Communicatios, Spider Ports from Spider systems, Micom/Interlan Terminalservers and an ANNEX box from Encore). Encore gives you all you want in this direction. Their software is host based and they have included a patch for the line printer spooler (at least for 4.2BSD) to use either the parallel port or one of the seriell ports as a printer port driven from the printer spooler. You have to add two fields in the printcap file, apply the patch, recompile and then it works. Spider systems has a small program in their documentation to print onto a specified port. This doesn't use the Berkeley spooler, but perhaps you could use it as an output-filter out for the line printer daemon. The other servers don't provide such a feature (or I didn't notice it). Hope this helps -- From: ames!harvard!talcott!encore!xenna!loverso (John Robert LoVerso) I'm one of the software engineers who works on development of the Encore Annex Terminal Server. Not only do we currently support both parallel and serial printers, but we've got some new things cooking for the next release that will make it possible to run either a bi-directional serial printer or even a host's getty on an Annex serial port! The Annexes currently available contain 1 parallel printer port and 16 serial ports. Current printer support (for all BSD-compatible hosts) is by means of either small modifications to the Berkeley Printer Spooler, or by a program we distribute called "aprint", both of which are included in source form on our distribution tape. The Annex operational image (the software you boot onto the Annex - its loaded from any BSD host on the network) contains a modified LPD server. The mods to the Berkeley spooler support a small extension to the printcap file that allows an annex & port to be specified as the hardware device. This is used just like an "lp=/dev/xxx" entry had been specified. If you don't have source for lpd, then you can just use our "aprint" program, which talks to the Annex LPD daemon and prints (not spools) a file. An example of how aprint could be used as a printcap "of=" filter is included in the administrators manual. John Robert LoVerso Encore Computer Corp encore!loverso, loverso@multimax.arpa 617-450-0600 x2638 -- From: Andy Linton <asjl@cheviot.ncl.ac.uk> We are currently doing what you want using Encore Annexes attached to an Encore Multimax. Special case you might say but the same thing can be done from a Vax or whatever. Robert Claeson <seismo!enea!pvab!robert> has written some code to do it. He says that Encore will possibly make it available with the next release of the Annex UX software. I include it for your info. The Annex is a nice box and cheap! andy [Contact Andy for the code. JA] -- From: ll-xn!budd@bu-it.bu.edu What kind of terminal server? Encore UMAX lpd can drive printers attatched to Annex printer and terminal ports. They also distribute diffs for you to modify your lpd. Phil Budne Boston University --
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Fri, 4-Dec-87 00:35:57 EST From: mikep@ism780c.UUCP (Michael A. Petonic) To: comp.protocols.tcp-ip Subject: TCP/IP Software Raves Wanted
Hey, I'm new in the terrain, so go easy on me. I need help determining
what would be the best product for TCP/IP and mail software to
run on a VAX and a MicroVAX (VMS 4.4). I'm trying to help
a friend make an informed decision, so I don't know all the
specifics. He doesn't have access to the net, so....
I'd appreciate and references, suggestions, flames or any other
general comments on TCP/IP products that you have run into.
He's looking into something called MultiNet Plus (and is there
a MultiNet?). In any case, any comments on this product would
be appreciated, also.
Please reply to the net or to me via mail. I'm sure there
are other's out there who would like this sort of info, also.
I'll summarize any info that I get.
TNX 1.0e06
-MikeP
--------------------
Michael A. Petonic (213) 453-8649 x3247
INTERATIVE Systems Corporation "My opinions in no way influences
2401 Colorado Blvd. the price of tea in China."
Santa Monica, CA. 90404
{sdcrdcf|attunix|microsoft|sfmin}!ism780c!mikep
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Fri, 4-Dec-87 10:08:38 EST From: scott@scirtp.UUCP To: comp.protocols.tcp-ip,comp.dcom.lans,comp.std.internat Subject: Inter-Domain Addressing Standards
I'd appreciate pointers to material concerning address protocols
for inter-network communication.
Thanks very much !
--
Scott Crenshaw {akgua,decvax}!mcnc!rti-sel!scirtp!scott
SCI Systems , Inc. Research Triangle Park, NC
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Fri, 4-Dec-87 13:24:52 EST From: scott@scirtp.UUCP To: comp.std.internat,comp.protocols.tcp-ip Subject: ISDN Specs Wanted
From where can I obtain CCITT publications related to
ISDN ? Addresses and phone numbers are appreciated.
Thanks very much.
--
Scott Crenshaw {akgua,decvax}!mcnc!rti-sel!scirtp!scott
SCI Systems , Inc. Research Triangle Park, NC
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Fri, 4-Dec-87 14:54:03 EST From: wjc@LL-VLSI.ARPA (Bill Chiarchiaro) To: comp.protocols.tcp-ip Subject: IP options under 4.? BSD
Does anyone know how to set and get IP options (LSRR, SSRR, RR) on outgoing and incoming datagrams under any version of 4 BSD? I would be especially interested in ways of doing this under Sun's releases of 4.2 BSD. Thanks, Bill
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Sat, 5-Dec-87 23:17:14 EST From: cyrus@hi.UUCP (Tait Cyrus) To: comp.protocols.tcp-ip Subject: best version of UN*X
The University of New Mexico will shortly be attached to the Internet
via NSFnet. What versions of UN*X are best when it comes to networking?
I have heard that Ultrix 2.2 is VERY bad when it comes to handling the
Internet protocols (routing protocols for example) correctly and that
it won't handle them correctly until around release 2.4. I have heard
that BSD 4.3 DOES handle the Internet protocols correctly. Since one
of the reasons that we are even considering Ultrix is because of NFS,
Mt. Zinu (sp?) BSD 4.3 would be another viable choice. Our CS department
is going with Mt. Zinu and REALLY like the support that they are getting
are REALLY like the op sys.
What I am looking for are some 'responses' from you good folks
out there (is it getting too thick? :-) that I can use in convincing
the administrative types here which release to go to. Which op sys's
are best, which have problems, which don't, etc.....
Oh, the machines in questions are microvax II's (currently running
BSD 4.3). We also have a lot of SUN's running SUNos 3.4, Bridge
Inc. Terminal servers, and DEC LAN 100 bridges isolating us (the
ECE department) from the rest of the UNM backbone.
I hope my question is clear enough, though any answers don't necessarly
have to be clear (I can translate, I hope, for the admin types).
Thanks in advance.
--
@__________@ W. Tait Cyrus (505) 277-0806
/| /| University of New Mexico
/ | / | Dept of EECE - Hypercube Project
@__|_______@ | Albuquerque, New Mexico 87131
| | | |
| | hc | | e-mail:
| @.......|..@ cyrus@hc.dspo.gov
| / | /
@/_________@/
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Sun, 6-Dec-87 21:27:00 EST From: W8SDZ@SIMTEL20.ARPA (Keith Petersen) To: comp.protocols.tcp-ip Subject: Latest KA9Q TCP/IP for MSDOS now available from SIMTEL20
The latest version of KA9Q's TCP/IP for MSDOS is now available via
standard anonymous FTP from SIMTEL20...
Filename Type Bytes CRC
Directory PD1:<MSDOS.KA9Q-TCPIP>
NELSON.ARC.1 BINARY 7385 1825H
NET_BM.ARC.2 BINARY 23171 48BBH
NET_DES.ARC.2 BINARY 18721 E18CH
NET_DOC.ARC.2 BINARY 104826 B348H
NET_EXE.ARC.2 BINARY 104944 244DH
NET_READ.ME.2 ASCII 3381 9A51H
NET_SRC.ARC.2 BINARY 233582 16A4H
PXX107.ARC.1 BINARY 46952 3F49H
TNC_ASH.ARC.2 BINARY 53998 9927H
TNC_LDR.ARC.2 BINARY 15790 0D43H
TNC_TNC1.ARC.2 BINARY 33058 1B49H
TNC_TNC2.ARC.2 BINARY 47427 D326H
[Here is the NET_READ.ME file]
Welcome to the KA9Q Internet Package!
(Updated 25 November 1987 by KA9Q)
This file reflects the changes made up to version 870829.16. The major
new feature since 870829.0 is the addition of full-blown support for
AX.25 Level 2. It may be used to acknowledge IP datagrams on a
hop-by-hop basis and also to communicate with conventional (i.e.,
non-TCP) AX.25 stations from the keyboard.
A number of the commands relating to specific protocols (e.g., AX.25,
TCP, IP, UDP) have been restructured in a hierarchical fashion. For
example, the "digipeat" and "mycall" commands have been made subcommands
under the "ax25" main command. See useguide.doc for details. NOTE: you
will have to change your autoexec.net with this release!
In addition to commands added to support the new AX.25 functions,
several utility commands have been added for your convenience. "dir"
lists directories on the console without leaving net, "cd" (alias "pwd")
prints and changes the current working directory, and "shell" (alias
"!") allows you to suspent net.exe temporarily to run other commands
(note that this freezes any network activity in progress). The "record"
command allows you to record your Telnet and AX.25 sessions in a file,
and "upload" allows you to send files as though they were typed at the
keyboard.
Lots of little bug fixes and enhancements have been made. TCP round trip
timing when sending into large windows has been fixed.
The .ARC files that make up the distribution are compressed archives that
were created with version 3.5 of the PKXARC archive program. They may
not be compatible with the ARC program produced by System Enhancement
Associates, because the PKARC program knows more compression methods than
ARC. For your benefit, a self-extracting archive PKX35A35.EXE has been
provided. Run it to extract a program that can be used to extract the
archives.
The distribution is structured based on the directory structure used to
create the software:
NET_BM.ARC .\BM - sources to Bdale's Mailer, and Gerard's Gateway
NET_DES.ARC .\DES - an implementation of DES (Data Encryption Standard)
for possible use in validating logins, etc.
NET_DOC.ARC .\DOC - all of the doc files
NET_EXE.ARC .\EXE - executable programs and config files
NET_SRC.ARC .\SRC - sources to NET.EXE
NELSON.ARC .\SRC - alternative assembler source files for net.exe
not dependent on Aztec macros. Contributed by Russ
Nelson (nelson@clutx.clarkson.edu).
TNC_ASH.ARC .\TNC\ASH - KISS for the VADCG and ASHBY boards (AJ9X)
TNC_LDR.ARC .\TNC\LDR - N4HY's KISS downloader in Turbo Pascal
TNC_TNC1.ARC .\TNC\TNC1 - KISS for the TAPR TNC-1 and clones (WB6ECE)
TNC_TNC2.ARC .\TNC\TNC2 - KISS for the TAPR TNC-2 and clones (K3MC)
Whatever you do, *PLEASE* don't unpack all of the .ARC files in one directory,
as there are duplicate names all over the place... Makefiles, README files,
etc.
After unpacking, look for a README file in each archive. Read this first,
before you do *anything* else. Some are just informative, some are very
important.
Finally, we're constantly striving to improve this software, and the
distribution as a whole. Comments may be forwarded to Bdale Garbee, N3EUA.
Several of the Doc files include info on how to reach me...
Above all, HAVE FUN!
73
Bdale, N3EUA
Phil, KA9Q
-----
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Sun, 6-Dec-87 22:50:13 EST From: roy@phri.UUCP (Roy Smith) To: comp.protocols.appletalk,comp.protocols.tcp-ip Subject: Using Kinetics boxes an an etherbridge
A couple of weeks ago, I asked what people thought about my idea of
rolling my own bargain-basement etherbridge by putting two Kinetics KFPS-2's
back-to-back on opposite ends of a LADC (4-wire leased) circuit, with Farallon
PhoneNet drivers. Thanks to the following people for responding:
husc6!sob (Scott Bradner)
ucscc.UCSC.EDU!haynes (Jim Haynes)
bu-it.bu.edu!ccjap (John Papadopoulos)
bu-cs!bu-it.bu.edu!kwe (???)
reed!goetz (Norman Goetz)
I said that the PhoneNet could drive up to 4000 feet of twisted-pair
cable, and that I hoped that our 2000-foot line-of-sight circuit would be
withing that limit as-the-cable-snakes. Several people pointed out that phone
lines run radially from the CO, with an LADC circuit consisting of two pairs
(one from here to the CO, the other from there to the CO) patched together,
and thus my 4000-foot hope was unrealistic. Perhaps, but I suspect that the
people who suggested that have never been to Manhattan. CO's are every few
blocks around here. I'm still hoping I'll make the 4000-foot limit, but I'm
not holding my breath.
Anyway, with much random editing, some of the more interesting
comments.
----------------
From: allegra!likewise!uunet!ucscc.UCSC.EDU!haynes (Jim Haynes)
Well, a guy here has been trying it for months and it still hasn't worked. I
guess he doesn't have 'appropriate software' to download. The problem, as I
understand it, is that the Kinetics software isn't prepared to cope with
having two Kinetics boxes on the same Appletalk line.
----------------
From: cmcl2!harvard!husc6!bu-cs!bu-it.bu.edu!kwe
It's crazy enough that it just might work! It's a novel idea.
I like your inventiveness.
I'm not sure you want to risk the investment on the Kboxes,
since I would guess that the Appletalk link will not work. If you
have the need for the Kboxes anyway, I would recommend trying the
set-up you suggest.
You can run anything you want on a LADC, but the telco will
only guarantee (and it's a weak guarantee) service up to 9600 baud.
19.2k is usually worth a try, 38k is very iffy, and 56k is not going to
cut it. 230k is way out there.
You can get a good idea of how long your circuit is by knowing
where your Central Office is physically located. If it's two miles
away, you have a four mile LADC (20k ft). All local circuits
originate in a CO, that's the definition of a CO. There is no
patching on the pole. Chances are slim you will get a 4k ft circuit.
But I like the idea anyway.
----------------
From: cmcl2!rutgers!mimsy.umd.edu!uunet!tektronix!reed!goetz (Norman Goetz)
I think the Farralon hardware would work fine this way. [...]
Unfortunately I don't think this will work. The hardware connections
are fine but the Kinetics boxes are neither routers nor half-repeaters
which is the role you are asking them to play. I've heard it described
that the K-boxes are not true IP gateways but more remote front ends
for devices on AppleTalk.
Have you looked into twisted-pair Ethernet as a link?
----------------
In addition, I had a conversation with Bill Russell (russell@nyu.edu)
who pointed out that even if the LADC could support AppleTalk over whatever
length the circuit turns out to be, and if the boxes could be taught to be
proper level-2 IP bridges, there is the problem of speed. We were talking
about Ungermann-Bass etherbridges, which would cost about $16k for a pair,
running 56 kbps over the LADC. Why so much, I asked, when it's obvious you
can put together a reasonable stab at the same end result for about a quarter
the price, and at five times the serial line speed? Bill's answer was that
the limiting factor was not line speed, but CPU cycles. The U-B bridge can
pass hundreds of packets per second. A kbox, with a poor little 6809 (?)
processor in it, couldn't hope to keep up with a fraction of that traffic, not
to mention the minimal amount of ram available (i.e. minimal routing tables,
minimal packet buffering, etc).
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Dec-87 08:21:45 EST From: mckenzie@LABS-N.BBN.COM.UUCP To: comp.protocols.tcp-ip Subject: Re: ISDN Specs Wanted
I suggest that you contact Omnicom, Inc. 501 Church Street Suite 304 Vienna, VA 22180 phone: 703/281-1135 fax: 703/281-1505 telex: 279678 OMNI UR Tell them you want ISDN info and ask what they have. The currently-official version is contained in the CCITT "Red Book", Volume III, Fascile III.5. This was adopted in 1984. There are undoubtedly also newer versions which are expected to be adopted in 1988, but I don't know what is available. However, the Omnicom people are quite likely to know. By the way, Omnicon is required by CCITT to charge the "official" price for "official" documents - they are likely to seem expensive. Regards, Alex McKenzie
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Mon, 7 Dec 87 8:21:45 EST From: Alex McKenzie <mckenzie@LABS-N.BBN.COM> To: Scott Crenshaw <rti!scirtp!scott@MCNC.ORG> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: ISDN Specs Wanted
I suggest that you contact Omnicom, Inc. 501 Church Street Suite 304 Vienna, VA 22180 phone: 703/281-1135 fax: 703/281-1505 telex: 279678 OMNI UR Tell them you want ISDN info and ask what they have. The currently-official version is contained in the CCITT "Red Book", Volume III, Fascile III.5. This was adopted in 1984. There are undoubtedly also newer versions which are expected to be adopted in 1988, but I don't know what is available. However, the Omnicom people are quite likely to know. By the way, Omnicon is required by CCITT to charge the "official" price for "official" documents - they are likely to seem expensive. Regards, Alex McKenzie
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Dec-87 12:25:14 EST From: root@sbcs.UUCP To: comp.protocols.tcp-ip Subject: bsd4.3 network (IP/TCP) code
I've heard recently that the networking code for IP/TCP from bsd4.3 Unix has been placed into the public domain. The only ftp'able sources I have seen so far is a port of 4.3 TCP for Suns, though. Are the sources PD? If so, where may I ftp (or otherwise obtain) them from? Advance thanks, Rick Spanbauer SUNY/Stony Brook
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Dec-87 23:24:57 EST From: roy@phri.UUCP (Roy Smith) To: comp.protocols.appletalk,comp.protocols.tcp-ip Subject: Re: Using Kinetics boxes an an etherbridge
In article <3057@phri.UUCP> roy@phri.UUCP I wrote:
> The U-B bridge can pass hundreds of packets per second. A kbox, with a
> poor little 6809 (?) processor in it, couldn't hope to keep up with a
> fraction of that traffic.
Two corrections to add. First, I got a note from kinetics!swan
(Michael J. Swan), who is Director of Software Products. Michael says:
[...] no, that type of setup wouldn't work because our
gateway is not a true IP router (I assume you were routing IP
style packets). The KFPS code routes according to what's
commonly refered to as Mac/IP routing which implements a subset
of IP-style routing. Also, to dispell some other misinformation
you received, the KFPS uses a 68008 processor, not a 6809.
Also, from glancing at my newly-arrived Ungermann-Bass product
literature, I see that my estimate of "hundreds of packets per second" was
low by about an order of magnitude.
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 8 Dec 87 02:45:43 GMT From: gore@nucsrl.UUCP (Jacob Gore) To: comp.protocols.tcp-ip Subject: How to set up lpd with CMU IP/ACP
(Is there a better place than this newsgroup (or mailing list) to discuss the
CMU implementation of TCP/IP for VMS?)
I am trying to install the lpd server and symbiont that was distributed with
CMU's IP/ACP(V6.2) (TCP/IP for VAX/VMS), but I can find no instructions on how
to do it, and my intuition didn't get me far. Could somebody who has done it
give me some instructions (or at least hints)?
Thanks,
Jacob Gore gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept. {gargoyle,ihnp4,chinet}!nucsrl!gore
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Dec-87 07:45:50 EST From: daveb@geac.UUCP To: comp.protocols.tcp-ip Subject: Re: Networks & vendor upgrades/fixes
In article <8712040041.AA00504@ucbvax.Berkeley.EDU> henry@utzoo.UUCP.UUCP writes:
>I dimly recall a software vendor who would sell you source *or* support
>but not both. They had the right idea.
Two vendors (not necessarily of network code) which have this policy
are Honeywell (now -Bull) and the University of Waterloo SDG.
--dave
--
David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb
Geac Computers International Inc., | Computer Science loses its
350 Steelcase Road,Markham, Ontario, | memory (if not its mind)
CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Dec-87 11:20:42 EST From: NIC@SRI-NIC.ARPA (DDN Reference) To: comp.protocols.tcp-ip Subject: ARPANET UPGRADE SCHEDULE
Testing of the new ARPANET End-to-End Protocol resumed on Saturday, December 5th and will continue running through Sunday, December 13th. Most problems have been fixed and/or identified. Those problems that have been identified are awaiting software patches. Hosts experiencing problems during this test period are asked to call the ARPANET Monitoring Center at (617) 873-3571/3070 or (800) 492-4992. -------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Dec-87 17:02:42 EST From: lazear@gateway.mitre.ORG To: comp.protocols.tcp-ip Subject: Protocols in Ada
I am trying to gather information on companies that are using Ada to implement communication protocols. Please send me any leads or rumors about such endeavors, implementation experiences, performance issues, etc. I will summarize back to the net if there is interest. Walt (Lazear@gateway.mitre.org)
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Dec-87 19:40:35 EST From: david@elroy.Jpl.Nasa.Gov (David Robinson) To: comp.protocols.tcp-ip Subject: IP protocol on a chip(s)
I frequently hear that TCP/IP is too slow of a protocol. I have seen
good ethernet boards on a Sun push packets as fast as 5Mbps and claims
of Crays pushing > 10Mbps on hyperchannels.
The throughput on most machines appears to be the speed that the
CPU can process the packets, whether the CPU is the main CPU or
an on board CPU.
To increase TCP/IP performance has anyone looked into making an IP
protocol chip or chipset? Would this be practical to do given
the complexity of IP? IP on a chip would also be interesting from
a routing point of view.
Any comments on the idea and potential problems that I may not
have thought of?
--
David Robinson elroy!david@csvax.caltech.edu ARPA
david@elroy.jpl.nasa.gov ARPA
{cit-vax,ames}!elroy!david UUCP
Disclaimer: No one listens to me anyway!
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 8 Dec 87 15:41:24 GMT From: cel@MITRE-BEDFORD.ARPA To: comp.protocols.tcp-ip Subject: NETMAN meeting at TCP/IP Interoperability Conference
Members of the IETF Network Management committee met at the TCP/IP
Interoperability Conference in Washington on Dec. 1. The following decisions
were made to progress the development of network management for TCP/IP.
PROTOCOL
O Develop an RFC for using CMIP/RO on TCP/UDP transport.
(Presentation and Session layers will not be used.)
O Clarify the Management Services document and document the
differences between its services and those provided by HEMS.
O Provide the above documents to the HEMS developers.
O Reexamine the use of CMIP/RO or HEMS at the end of February 1988.
TCP/IP Management Information
O Review the HEMS RFC and ANSI X3S3 on transport/network layer
management information.
O Work with HEMS developers to create separate RFCs for TCP and IP
layers.
802.2, 802.3, 802.4, and X.25 Management Information
O Using as input MAP/TOP and IEEE network management documents,
develop RFCs for each layer.
Structure of Management Information
O Using as input ISO, HEMS, MAP/TOP and IEEE documents develop an RFC
defining the structure of management information.
We welcome assistance in developing these RFCs -- especially those
related to specification of management information and its structure. People
wishing to participate may contact:
Lee LaBarre
The MITRE Corp.
Burlington Road
Bedford, MA 01730
(617) 271 8507
cel@mitre-bedford.arpa
Again, we welcome your assistance in this endeavor.
Lee LaBarre
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 8 Dec 87 20:32:00 GMT From: holt@inco.UUCP (Mark Holt) To: comp.protocols.tcp-ip Subject: KA9Q TCP/IP
I'm not sure if you are the person I should be sending this to, but I figure you can lead me in the right direction. We have the KA9Q TCP/IP package here and have had great success with using it to talk to our Sun. What I thought you might be interested in is the fact that I ported the software to our VAX 11/780 running VMS 4.2. We have a DEUNA interface to the Ethernet and so far have managed to do file transfers among all three machines (Sun, VAX, PC) and Telnet from the VAX to the Sun. I only made changes that were necessary (ie., I/O to the Ethernet, file I/O, etc.) and so far it seems to work OK. Thank you for making such a valuable product available to the public! Sincerely,
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 9 Dec 1987 0915-EST From: hsw@TYCHO.ARPA (Howard Weiss) To: david at elroy.jpl.nasa.gov Cc: tcp-ip at sri-nic.arpa Subject: re: IP protocol on a chip(s)
There was a TCP/IP 40-pin chip implementation built back in 1983 by
a company called Quanta Microtique. I actually still have the
data sheets on the chip (called the QM10 - Advanced Communications
Controller). Steve Holmgren developed the chip and ran the company -
he now runs CMC in Santa Barbara, Ca.
The "General Description" of the chip (from the QM-10 literature) says:
"The QM10 is an LSI circuit designed to support virtual connection and
packet functions previoulsy found in larger digital communications
processors. A 40-pin, dual inline form factor makes integration into
existing hardware straightforward."
The "Device Characteristics" were listed as:
* DoD Standard TCP connection protocol firmware.
* DoD Standard IP packet protocol firmware.
* Single Connection per device.
* IP address filtering for ganged device configurations.
* Flexible shared memory user interface.
* Configurable network interfaces.
- Onboard UART configuration.
- Outborrad USART configuration.
- Outboard shared memory network interface.
* Single +5 volt power supply
* 12mW stand-by power for connection state retention.
* Standard 40-pin package.
Howard Weiss
-------
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 9 Dec 87 06:31:12 GMT From: beach.cis.ufl.edu!esj@bikini.cis.ufl.edu (Eric S. Johnson) To: tcp-ip@sri-nic.arpa Subject: Re: ARPANET UPGRADE SCHEDULE
Forgive me if this question is obvious, but Im not very knowledgable about routeing issues. During the recent ARPANET testing (12-5 to 12-13) I have noticed strange behavior in the internet. We are a SURANET/NSF net site here and during the testing, I find I am not able to connect to many hosts that are within LAN's that are gatewayed on to the ARPANET proper. Yet I am able to make connections with hosts actually on the ARPANET. For example, some mail has been sitting in our mailq here waiting to be delivered to violet.berkeley.edu. No connection can be made to that machine, but a connection can be made to ucbvax.berkeley.edu and ucbarpa.berkeley.edu. I know violet is up becuase a finger @violet.berkeley.edu@ucbarpa.berkeley.edu happily lists the users. This is only one example; many other sites that are gatewayed via a 10.*.*.* are not reachable directly, but via finger @host@arpahost I am able to confirm that the host is up and running. It seems to me (and my armchair tests) that some routeing information is getting lost somewhere. Everything was fine, and I none of these problems, before last saturday (12-5). Also, I have no problem reaching other NSFnet sites. Would someone care to fill me in on the details. Is this problem seen from only our LAN here? Have others noted this kind of problem? Is it limited to NSFnet or SURAnet? Thanks for any enlightenment. -- In Real Life: UUCP: ...ihnp4!codas!ufcsv!beach.cis.ufl.edu!esj Eric S. Johnson II Internet: esj@beach.cis.ufl.edu University of Florida "Your species is always dying and suffering" -Q
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 9 Dec 87 06:31:12 GMT From: beach.cis.ufl.edu!esj%bikini.cis.ufl.edu%CRNLVAX2.BITNET@CUNYVM.CUNY.EDU (Eric S. Johnso, n) To: tcp-ip@sri-nic.arpa Subject: Re: ARPANET UPGRADE SCHEDULE
I noticed what may be the same problem. For a period of at least days at the end of November, I could FTP to SRI-NIC.ARPA at its 10.0.0.51 address, but not at its 26.0.0.73 address (I got "Network Unreachable"). I just tried it and both address are working now. Mark Bodenstein (mab%cornellc.bitnet@cunyvm.cuny.edu) Cornell University ----------------------------Original message---------------------------- ... During the recent ARPANET testing (12-5 to 12-13) I have noticed strange behavior in the internet. We are a SURANET/NSF net site here and during the testing, I find I am not able to connect to many hosts that are within LAN's that are gatewayed on to the ARPANET proper. Yet I am able to make connections with hosts actually on the ARPANET. ...
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 9 Dec 87 13:10:38 GMT From: fair@ucbarpa.Berkeley.EDU (Erik E. Fair) To: comp.protocols.tcp-ip Subject: Re: IP protocol on a chip(s)
In the referenced article, david@elroy.Jpl.Nasa.Gov (David Robinson) writes:
>To increase TCP/IP performance has anyone looked into making an IP
>protocol chip or chipset?
Greg Chesson of Silicon Graphics in Mountain View, CA has been
looking into this. He gave a paper at the Summer 1987 USENIX
Conference in Phoenix, entitled "Protocol Engine Design." The paper
starts on page 209 in the proceedings from that conference, which
are available from the USENIX Association. His design goal was to
produce a chipset capable of keeping up with FDDI data rate
(100Mbit/sec) by doing protocol processing in a packet-time.
The technology he described was reported sold by Silicon Graphics
two months ago to a company called "Protocol Engines, Inc." in
Santa Barbara, CA. Greg Chesson's reply to an inquiry I made about
the sale was as follows:
-------------------------------------------------------------------------------
Date: 23 Oct 87 22:47:56 GMT
From: sgi!greg@ucbvax.berkeley.edu (Greg Chesson)
Organization: Silicon Graphics Inc, Mountain View, CA
Subject: Re: Greg Chesson's Protocol Engine technology sold by SGI
Message-Id: <7237@sgi.SGI.COM>
References: <21255@ucbvax.BERKELEY.EDU>
to: Erik Fair, Dave Farber, and others:
The newspaper article quoted in this news group created some undeserved
speculation and masked the enthusiastic and public spirited support
that SGI has for the project and the concept. SGI has given over
protocol engine technology to Protocol Engines Inc for nominal
reimbursement of costs. It was not a significant financial
transaction. SGI engineers and people at other companies continue to
work on the project.
Protocol engine details - protocol, state machines, software emulation
- will be placed in the public domain as has been stated before. PEI
is modeled after other multi-company consortia such as the group that
standardized the SCSI bus. It is a corporate shell intended to achieve
the following:
1) provide a neutral repository for P-engine technology
2) fund chip fabrication
3) focus on standards activities
4) provide multiple sources for chips
5) push the technology beyond 100 Mbit/sec
Item (1) helps preserve the open nature of the design and to ensure
that there exists an organization dedicated to P-engine technology.
Item (2) should be obvious, since prototype production is more than I
can accomplish as an internal skunkworks. Item (4) means that PEI is
working with semiconductor houses to make P-engines become standard
products. The other items should be self-explanatory.
Greg Chesson Silicon Graphics 2011 Stierlin Road Mountain View,
Ca, 94043 (415)962-3496 {sun,pyramid,adobe,allegra,decwrl}!sgi!greg
-------------------------------------------------------------------------------
If you (or anyone else) knows about other efforts in this general
direction, I would appreciate hearing about it.
Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 9 Dec 87 13:15:19 GMT From: sra@MITRE-BEDFORD.ARPA (Stan Ames) To: comp.protocols.tcp-ip Subject: Re: IP protocol on a chip(s)
As part of an IR&D project MITRE developed several experimental chips to see if performance improvements could be obtained several chips were developed for the TP4 protocol. The most useful was an ip checksum chip. For more information you can call Jerry Freedman at 617-271-6248 Stan Ames
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 9 Dec 87 13:42:15 GMT From: heath@ncrcae.Columbia.NCR.COM (Robert Heath) To: comp.std.internat,comp.protocols.tcp-ip Subject: Re: ISDN Specs Wanted
Scott, For CCITT documents, including the Series I, which describes ISDN, you can contact: OMNICOM, Inc. 501 Church St., N.E. Suite 304 Vienna, VA 22180 (703) 281-1135
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 9 Dec 87 14:15:00 GMT From: hsw@TYCHO.ARPA (Howard Weiss) To: comp.protocols.tcp-ip Subject: re: IP protocol on a chip(s)
There was a TCP/IP 40-pin chip implementation built back in 1983 by
a company called Quanta Microtique. I actually still have the
data sheets on the chip (called the QM10 - Advanced Communications
Controller). Steve Holmgren developed the chip and ran the company -
he now runs CMC in Santa Barbara, Ca.
The "General Description" of the chip (from the QM-10 literature) says:
"The QM10 is an LSI circuit designed to support virtual connection and
packet functions previoulsy found in larger digital communications
processors. A 40-pin, dual inline form factor makes integration into
existing hardware straightforward."
The "Device Characteristics" were listed as:
* DoD Standard TCP connection protocol firmware.
* DoD Standard IP packet protocol firmware.
* Single Connection per device.
* IP address filtering for ganged device configurations.
* Flexible shared memory user interface.
* Configurable network interfaces.
- Onboard UART configuration.
- Outborrad USART configuration.
- Outboard shared memory network interface.
* Single +5 volt power supply
* 12mW stand-by power for connection state retention.
* Standard 40-pin package.
Howard Weiss
-------
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 9 Dec 87 18:02:02 GMT From: zeeff@b-tech.UUCP (Jon Zeeff) To: comp.protocols.tcp-ip Subject: Re: Latest KA9Q TCP/IP for MSDOS now available from SIMTEL20
Is this the version that includes support for running as a single task under Unix? If not, what is the status of that version (I heard is was almost done months ago). --Jon -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 9 Dec 87 18:42:39 GMT From: evan@ndcheg.UUCP (Evan Bauman) To: comp.protocols.appletalk,comp.protocols.tcp-ip,comp.sys.mac Subject: software to use with Kinetics box
We just got our first Kinetics FastPath box to bridge our appletalk net to our ethernet. I was wondering if anyone had any suggestions for software that we could use with it. We already have NCSA telnet and we are expecting our copy of K-Spool from Kinetics anyday now. Someone else has ordered UNIX Tops. Our configuration: 10 Sun 3's, a few Convergent SYS V boxes, 2 appletalk nets with a total of about 30 nodes, various modems, imagewriters, and laserwriters. A few PC's with appletalk cards will be added soon. Thanks in advance. Evan Bauman Univ. of Notre Dame ..!iuvax!ndcheg!evan
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Wed, 09 Dec 87 16:18:40 IST From: Hank Nussbacher <HANK%TAUNIVM.BITNET@WISCVM.WISC.EDU> To: tcp-ip@sri-nic.ARPA Subject: Routers vs. Bridges
I know this has been covered once before but I am preparing a paper on the benefits of routers over bridges and bridges over routers. Specifically, there are routers today that handle multiple protocols (cisco and proteon to name two) and there are bridges that are starting to handle alternate routing and allow the construction of a closed network loop. What I would like to receive (please reply directly to me and not to the list) are examples and explanations of what a router can do at level 3 that a bridge just cannot handle. And why is it so important to be able to do it. When I have finished creating my document I will post it to the this list. If you have any articles or papers you would like to send to me on the subject, please send them to: Henry Nussbacher Computer Center Tel Aviv University Ramat Aviv Israel Thanks, Hank
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 9 Dec 87 20:05:21 GMT From: michaud@irisa.UUCP (Michaud Franck INSA BN205) To: comp.protocols.tcp-ip Subject: virtual circuit
I'd like to have a good definition of : - virtual circuit. If you have a good definition, send me a mail. thanck you. franck
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 9 Dec 87 22:22:58 GMT From: percy@amdcad.AMD.COM (Percy Irani) To: comp.protocols.tcp-ip Subject: Vitalink Bridges..
We have a Vitalink sales guy trying to sell Vitalink Bridges to our Company. We primarily have TCP/IP hosts on the net. We also have some DECNET hosts. What is attractive to some people (Sigh!) is that the Vitalink's will be able to do protocol independant connections. I guess we can beat the Vitalinks iff there is a router that does both IP and DECNET. IS THERE ONE AVAILABLE LIKE THAT TODAY???? ------------------------------------------ Also, the Vitalink sales and tech support (I beleive the sales guy talked to them) do **NOT** understand the problem of "Ethernet Meltdown". Has *anyone*, yes anyone, encountered this problem using bridges? Also, to be specific, has anyone, encountered this problem using Vitalink boxes? (DEC sells Vitalinks too!!). (Come on some one from DEC can shed light on that!!). Besides, our friends do not understand the advantages of alternat routing (routed type), support of triangles in a net instead of spanning trees....... Sigh! -- Ignorance is bliss but can be embarassing at times!
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 9 Dec 87 22:33:36 GMT From: don@SRI-LEWIS.ARPA (Donald Holman) To: comp.protocols.tcp-ip Subject: Why wait for the rabid bite of a problem withou a solution?
To those that listen with appologies to those that don't: I left the TCP/IP conference (Monterey East) with a few items that appeared to be without solution in the near future. I query the mailing list in an effort to solicit for ideas from the collective body on each of these areas. One or all of these will be of interest to my efforts in the near future, thus why wait for the rabid bite of a problem without solution. Probably be inundated with flaming broadcast storms over these questions, but here goes. PLEASE; IF YOUR RESPONSE IS NOT ENTIRELY APPLICABLE TO THE TCP/IP MAILING LIST RESPOND DIRECTLY TO ME. Glossary of terms and acronyms: --------------------- Standard - an accepted degree or level of excellence. TIA - That Is All. 1) SLIP LINK ESTABLISHMENT, there is no standard link establishment procedure/protocol for SLIP which presents problems when attempting to utilize SLIP in a dialup or various other modes. There are additional problems which are related to address mapping for the user of a SLIP port, which incidently may cause problems with security. Is anyone working on a solution to this, or is there an existing solution may have the pleasing aroma of a standard? 2) SECURITY, various vendors of IP routers touted the ability to discriminate for/against packets based on the security field found in the IP portion of a datagram header. The present problem with this is that there is no provision in any of the ARPA/DDN upper layer protocols for setting this security bit (or is there?). How does one determine to set the bit since SMTP, FTP etc. does not provide the mechanics for passing this security information to the network layer? 3) ROUTING METRICS. Most gateway routing decisions are determined by hop count or minimum path. This is not always the best approach since the minimum path may not be the best path. Example: who cares if the packet traverses 5 hops to get to the destination if the 5 hop path is more economical/better than the 2 hop path. Is there a published method that is better than min_hop? 4) LEASED LINES FOR DDN. The DDN may not be able to afford all of the dedicated leased lines which are to be in service over the next several years. Is there an alternative to leased lines? Perhaps something that utilizes dial-up in conjunction with a machine-machine (read uucp-uucp) transfer of queued information. This could reduce the need for high-cost leased lines in selected cases. TIA, Don
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 9 Dec 87 22:42:29 GMT From: castillo.osbunorth@XEROX.COM To: comp.protocols.tcp-ip Subject: smtp on Unix (sun) machines
According to the BNF's on RFCs 822 & 821 in its reference to qstrings (quoted
text on user names of the form user@host), you can have any of the 128 ASCII
chars (except for CR, LF, ", \, unless preceded by \) on the user name as long
as it is enclosed between double quotes (") chars.
I found that on the Sun implementation, even after modifying one of the Mailer
Flags (removed 's) in the sendmail.cf, so that the mailer passes the strings
without removing the quotes, it still manages to find the Spaces
procedes to separate the user name.
Esentially I'm interesting in passing along user names of the form "xx:xx
xx:xx".
Are there any known workarounds or modifications to the sendmail.cf on Sun
machines, or for that matter in the any of the BSD Unix machines?
thanks for you suggestions
** julio
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 00:01:25 GMT From: PULLEN@VAX.DARPA.MIL (Mark Pullen) To: comp.protocols.tcp-ip Subject: Re: IP protocol on a chip(s)
David, Michael Foster and Yechaim Yemini and Columbia University are working on VLSI implementations of protocols. Mark Pullen DARPA Program Manager Advanced Networking -------
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 00:40:35 GMT From: len@SPAM.ISTC.SRI.COM (Len Schlegel) To: comp.protocols.tcp-ip Subject: POP2, etc.
I am interesting in finding out about POP versions other than that specified in RFC937. I also would like to know who funded the development of the protocol. Also, any references to other distributed mail access work and who funded it would be appreciated (aside from RFC984 on pcmail). Thanks in advance. Len Schlegel (len@spam.istc.sri.com)
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 1987 07:52:15 CST From: Link Verstegen@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA Cc: LINK@GUNTER-ADAM.ARPA, lan-EPS@GUNTER-ADAM.ARPA, afddn.beACH@GUNTER-ADAM.ARPA Subject: LAN Presentation and Security Packages
Gentlemen, The Standard Systems Center (AFCC) is preparing an Air Force wide acquisition of LAN Presentation Software (ULANA Compatible) and PC (8088, 80286, and 80386) Security Hardware/Software. The Equipment Performance Specification is available for FTP on the Gunter-Adam. The account name is LAN-EPS and the password is the same. Comments may be addressed to LAN-EPS@GUNTER-ADAM.ARPA. If you have comments that you do not wish to share with other vendors, address them to LINK@GUNTER-ADAM.ARPA. Remember, this is an informal medium, and the Standard Systems Center will NOT be held accountable for the disposition of the comments received. This is provided as a courtesy to the vendor community and provides them a chance to point out any glaring errs we may have made. /| /| ===================/ |=================/ |=================== Link N. Verstegen Link@Gunter-ADAM.ARPA Computer Systems/Network Engineer HQ SSC/PRS (205)279-5151 Gunter AFS, AL 36114-6343 AV 446-5151 -------
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 Dec 87 14:24:47 -0500 From: Craig Partridge <craig@NNSC.NSF.NET> To: holman@sri-lewis.ARPA Cc: tcp-ip@sri-nic.ARPA Subject: re: Why wait....
Sounds like we didn't get the word out at Monterey East. I believe that all the problems you list are currently being worked on by various task forces. Craig
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 Dec 87 14:39:24 -0500 From: Craig Partridge <craig@NNSC.NSF.NET> To: tcp-ip@sri-nic.ARPA Subject: Current State of Network Management
I got a couple of inquiries today from people who mis-interpreted Lee's
note to suggest that all network management activities are being
coordinated through him. That's not what the note was intended to
say.
Regretfully, network management work is still a multi-headed beast.
Here's a short Who's Who:
NETMAN (Network Management) Working Group of the IETF. Chaired
by Lee LaBarre. As Lee's note indicated, they are working on
fashioning their own network management proposal, based in part
on work done by the HEMS group. Contact Lee (cel@mitre-bedford.arpa)
for information.
GWMON (Gateway Management) Working Group of the IETF. Chaired
by me, and the source of the High-Level Entity Management System
(HEMS) proposal, documented in RFC1021-1024 and recently implemented.
Operates the GWMON mailing list, which is the mailing list for
all general interest announcements/correspondence on network
management. Mail to gwmon-request@sh.cs.net to join.
SGMP (Simple Gateway Monitoring Protocol). Affiliated with the
IETF but not a working group (for odd historical reasons).
Documented in RFC 1028 (which I believe has not yet been released).
Several test implementations exist. I believe most SGMP announcements
appear on GWMON, although there is a separate mailing list for
SGMP implementors.
There are also activities attempted to build applications or protocols
that work at a higher level that these protocols (which primarily address
the problem of data extraction). These activities include:
The Network Computing Forum (NCF) is trying to develop higher level
management applications/protocols. This is being led by Terry
Hardgraves (pardon any mis-spelling, his business card is in
my briefcase at home) of the Software Productivity Consortium.
ANM (Automated Network Management), a project at BBN Laboratories
which uses a distributed database system and AI tools to effect
network management. Contact Jil Westcott, jwestcott@bbn.com, for
more information.
An IETF working group led by Jeff Case (one of the SGMP authors).
case@utkcs2.cs.utk.edu
I hope this all helps.
Craig
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 06:39:55 GMT From: HANK@TAUNIVM.BITNET (Hank Nussbacher) To: comp.protocols.tcp-ip Subject: Routers vs. Bridges
I know this has been covered once before but I am preparing a paper on the benefits of routers over bridges and bridges over routers. Specifically, there are routers today that handle multiple protocols (cisco and proteon to name two) and there are bridges that are starting to handle alternate routing and allow the construction of a closed network loop. What I would like to receive (please reply directly to me and not to the list) are examples and explanations of what a router can do at level 3 that a bridge just cannot handle. And why is it so important to be able to do it. When I have finished creating my document I will post it to the this list. If you have any articles or papers you would like to send to me on the subject, please send them to: Henry Nussbacher Computer Center Tel Aviv University Ramat Aviv Israel Thanks, Hank
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 Dec 87 12:46:37 EST From: Ross Callon <rcallon@PARK-STREET.BBN.COM> To: don@SRI-LEWIS.ARPA Cc: tcp-ip@SRI-NIC.ARPA, rcallon@PARK-STREET.BBN.COM Subject: re: rabid bite of problems
Don; In response to part (3) of your message: The BBN Butterfly gateways do NOT use a simple hop count for routing decisions, for essentially the reason that you gave. Instead we use a cost which is administratively set as a function of the network characteristics. Each gateway-to-gateway link may in principle be given a different cost. For example, the cost (over the Arpanet) between gateways at BBN and MIT could be administratively set to be different than the cost between gateways at BBN and ISI. In practice, we tend to assign a single cost for all links over a single network. As an example, we currently use a single fixed cost for links over the Arpanet, which is greater than the cost which we use for links over LANs. The routes calculated by the Butterfly SPF algorithm minimize the sum of these costs, and do reflect differences in network characteristics. A link up/down algorithm is used to determine whether each gateway-to-gateway link is operating successfully, but as long as the link is up its metric is stable. We have been having good success with operational use of this algorithm since it was installed about a year and a half ago. The IS to IS routing proposal which is being progressed in ANSI X3S3.3 (and is being taken to the next ISO network layer meeting in Guernsey) also uses administratively set costs. Here again a link up/down protocol is used to determine whether a link is operational. You asked if there is a "published" method which is better than hop count. We are intending to publish a description of our SPF, but haven't done so yet. The ANSI proposal is semi-available. The most recent version was passed out at the last X3S3.3 meeting, and should be mailed out to the X3S3.3 mailing list soon. Ross
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Thu, 10-Dec-87 14:15:45 EST From: oattes@gpu.utcs.toronto.edu (Lee Oattes) To: comp.protocols.tcp-ip Subject: micro-vax with more than one ether-net board?
I am interested in knowing whether any one out there has had experience
in connecting more than two ethernet boards to a micro-vax (Q-bus)
running Ultrix 2.0. The application is to use such micro-vaxen as
gateways between many ether(sub)nets (ie. more than two!). As it is
now, we can only use each micro-vax as the gateway between two ether
networks and it would definitely be nice to have more capability to
handle more ether networks without having to purchase more micro
vaxes! The standard deqna boards have switches for only two csr
addresses, though the device driver will allow more than two. Is there
any trick to get around this? It seems a little silly to allow only two
deqna boards (?).
An alternative would be to install another type of ethernet board with
its own driver. Does any one know of any such products? We have considered
the Interlan NI2010 board, but Interlan only supports device drivers for
the multibus. Has anyone developed an Ultrix device driver for the Q-bus
for this board?
Any suggestions would be welcome.
--
Lee Oattes, University of Toronto Computing Services, CTS.
UUCP - {ihnp4!decwrl!utai!, uunet!utai!, allegra!utai! } utgpu!oattes
BITNET - oattes@utorgpu.bitnet
INTERNET - oattes@gpu.utcs.toronto.edu
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 Dec 87 16:52:05 EST From: Bob Dixon <TS0400%OHSTVMA.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Re: Vitalink Bridges..
We are using Proteon routers with tcp/ip and decnet today, and very
successfully.
Bob Dixon
Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 13:52:15 GMT From: Link.Verstegen@GUNTER-ADAM.ARPA To: comp.protocols.tcp-ip Subject: LAN Presentation and Security Packages
Gentlemen, The Standard Systems Center (AFCC) is preparing an Air Force wide acquisition of LAN Presentation Software (ULANA Compatible) and PC (8088, 80286, and 80386) Security Hardware/Software. The Equipment Performance Specification is available for FTP on the Gunter-Adam. The account name is LAN-EPS and the password is the same. Comments may be addressed to LAN-EPS@GUNTER-ADAM.ARPA. If you have comments that you do not wish to share with other vendors, address them to LINK@GUNTER-ADAM.ARPA. Remember, this is an informal medium, and the Standard Systems Center will NOT be held accountable for the disposition of the comments received. This is provided as a courtesy to the vendor community and provides them a chance to point out any glaring errs we may have made. /| /| ===================/ |=================/ |=================== Link N. Verstegen Link@Gunter-ADAM.ARPA Computer Systems/Network Engineer HQ SSC/PRS (205)279-5151 Gunter AFS, AL 36114-6343 AV 446-5151 -------
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 15:55:36 GMT From: radia@XX.LCS.MIT.EDU (Radia Perlman) To: comp.protocols.tcp-ip Subject: Re: Routers vs. Bridges
The January, 1988 issue of IEEE Network magazine has multiple articles on bridges vs routers. I wrote one of them. The main problem with the "bridge vs router" issue is defining what a bridge vs a router is. You could define an entire network architecture and declare that to be your data link layer, and claim then that the box that forwards packets is a "bridge" because it operates at the "data link layer". My contention, though, is that a Data Link layer header only has in it information to deal with one hop -- one pair of addresses, (source and destination), no route, no hop count, etc. Since the Network Layer handles multiple hops, if a header is defined with two pairs of addresses (ultimate source, ultimate destination plus immediate source and immediate destination), hop counts, routes, etc, then I claim it's a Network Layer protocol. For instance, I claim the DEC bridge is clearly a bridge (although it allows store and forward) because as far as the end stations are concerned, they are dealing only with a Data Link protocols -- the header they see fits my description of a Data Link header. The "source routing bridge", on the other hand, I'd claim is clearly a router and not a bridge, because it requires end stations to discover and place a route in the header. You may want to wait until the January IEEE Network comes out for many different viewpoints on this issue. If you'd like to study the issue independently, I'd suggest starting with a rigorous definition of "routers" and "bridges" that clearly places a box in one category or another, before trying to argue the merits of each kind of box. Radia -------
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 16:22:18 GMT From: dennist@tektronix.TEK.COM (Dennis Thomas) To: comp.protocols.tcp-ip,comp.dcom.lans,comp.sys.dec Subject: AT&T ISN
I am interested in contacting or receiving input from any one that has experience in using AT&T's ISN product in a networking environment. The environment to be considered is a single communications link, connected by 2 ISN's concentrating Ethernet (TCP/IP, DECNET, LAT), IBM 3274, IBM 3270 and DECNET synchronous traffic. Some of the concerns relate to the effect of file transfer rates for TCP/IP and DECNET when the other traffic is active. Since the ISN moves data in small packets (180bits) with an 8.64 Mb transmit and receive bus, it would seem that large TCP/IP or DECNET packets (file transfer) would suffer at the expense of terminal activity. Thank you in advance for your input. Dennis Thomas Tektronix, Inc. dennist@tektronix.TEK.COM (503) 627-5030
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 17:40:07 GMT From: rdhobby@ucdavis.edu (Russ Hobby) To: comp.protocols.tcp-ip Subject: SLIP discussion at the Interoperability Conference
Here is what happened at the TCP/IP Interoperability Conference with
regards to SLIP.
The BOF session was too large to get any protocol standards work done,
but the group provided input as to what needs to be covered by the the
standard and some of the potential uses for SLIP connections. There
seemed to be two types of usage for the new standard SLIP protocol. One
is the connection of isolated computers that do not have access to a
LAN. PCs would be a big proportion of the computers in this category,
but certainly any type of computer can use the capability.
The other use of SLIP connections is for temporary network links. The
idea is to advertise a route to another location all the time, but to
dialup and establish the connection to that location only when there is
traffic. The first packet will be delayed while the connection is being
made, but there after traffic would flow smoothly. After a certain
period of no traffic the connection would be dropped, thus saving on
communications costs.
The evening after the BOF session, a smaller group of us got together
and got some productive work done towards the writing of an RFC for a
SLIP type protocol. Here is an overview of what was decided (at least
what I can decipher from my notes).
1) The RFC will cover both connection and line protocols
2) Connection specifications will cover negotiation of items such
as network addresses, authentication, line speed, compression
used, and probably other items.
3) The line protocol will contain one byte in the header to
indicate the protocol in the packet. This allows the use of line
control packets for maintaining the serial link, as well as
allowing other protocols in addition to IP and the line control
to use the connection.
Much more detail was discussed, but I don't want to bore you with it
now. It was thought that an RFC draft could be done and an
implementation to test it in a couple of months.
UC Davis will be implementing the new standard by modifying our current
work. So some of you may want to wait for the standard version rather
than using what we have available now. But then if you have an immediate
need, out old version will be there. Since the standard version will be
more than experimental software, it will more complete and better
documented.
Russell Hobby
Data Communications Manager
U. C. Davis
Computing Services BITNET: RDHOBBY@UCDAVIS
Davis Ca 95616 UUCP: ...!ucbvax!ucdavis!rdhobby
(916) 752-0236 INTERNET: rdhobby@ucdavis.edu
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 17:42:18 GMT From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Routers vs. Bridges
Here is one way you might decide if a given box is a bridge or an IP gateway (aka router): see if it forwards a local network broadcast packet. A bridge "must" forward broadcasts, while a gateway "must never" forward one. Another test: see if the IP network number changes when the packet is forwarded. A bridge must not change anything in the IP header, while a gateway "must" change the IP destination address. These two tests give some clues about the advantages of gateways over bridges. Bob Braden
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 17:46:37 GMT From: rcallon@PARK-STREET.BBN.COM (Ross Callon) To: comp.protocols.tcp-ip Subject: re: rabid bite of problems
Don; In response to part (3) of your message: The BBN Butterfly gateways do NOT use a simple hop count for routing decisions, for essentially the reason that you gave. Instead we use a cost which is administratively set as a function of the network characteristics. Each gateway-to-gateway link may in principle be given a different cost. For example, the cost (over the Arpanet) between gateways at BBN and MIT could be administratively set to be different than the cost between gateways at BBN and ISI. In practice, we tend to assign a single cost for all links over a single network. As an example, we currently use a single fixed cost for links over the Arpanet, which is greater than the cost which we use for links over LANs. The routes calculated by the Butterfly SPF algorithm minimize the sum of these costs, and do reflect differences in network characteristics. A link up/down algorithm is used to determine whether each gateway-to-gateway link is operating successfully, but as long as the link is up its metric is stable. We have been having good success with operational use of this algorithm since it was installed about a year and a half ago. The IS to IS routing proposal which is being progressed in ANSI X3S3.3 (and is being taken to the next ISO network layer meeting in Guernsey) also uses administratively set costs. Here again a link up/down protocol is used to determine whether a link is operational. You asked if there is a "published" method which is better than hop count. We are intending to publish a description of our SPF, but haven't done so yet. The ANSI proposal is semi-available. The most recent version was passed out at the last X3S3.3 meeting, and should be mailed out to the X3S3.3 mailing list soon. Ross
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 17:54:28 GMT From: percy@amdcad.AMD.COM (Percy Irani) To: comp.protocols.tcp-ip Subject: Proteon Routers..
This may be dumb, but my efforts to get the Proteon (the
router company :-) ) number for a sales guy has lead to
a futile chase. Can anyone tell me the number of
Proteon. Leads will also be appreciated. If this helps,
Im in the 408 area code.
Lets not clutter the net with responses. Send me mail
directely.
Thanks in advance.
-Percy Irani
percy@amdcad.amd.com
{decwrl,ihnp4,gatech,sun,ucbvax}!amdcad!percy
--
Ignorance is bliss but can be embarassing at times!
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 18:10:03 GMT From: dab@ALLSPICE.LCS.MIT.EDU To: comp.protocols.tcp-ip Subject: Re: Ethers, Copper, Fiber, Microwaves, Etc.
> Now this is something new to me. If you can put them in a >briefcase they must be around 100GHz. That would probably limit the >range to a mile or so. The problem with infrared laser technology is >the atmospheric attenuation of smog, fog, and rain. Sounds like this >new ultra-high freq microwave fills the gap between low freq uwave and >infrared. In the ham radio community for several years there have been devices called Gunnplexers available (I don't know if that's a brand name or a generic name) which are a 10 GHz microwave system for about $200. When they first showed up there were several articles in ham radio magazines descibing how to send video through them, so 10 Mb/sec is probably not too far out of line. Except for maybe the feedhorn (or the dish itself) it would easily fit into a briefcase. The range is limited but I think to line of sight rather than 1 mile. Dave Bridgham
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 18:55:14 GMT From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) To: comp.protocols.tcp-ip Subject: Re: Vitalink Bridges..
Yes, we've encountered meltdowns and broadcast storms across bridges. Watch for Chuck Hedrick and Len Bosack's article on such network phenomena in an upcoming IEEE Network Magazine. We do run IP and DECNET through our CISCO routers. I don't know if CISCO has made it a product yet (although it is likely that they will). Also Proteon, I believe, has already marketed the product. Noel's code has always been aimed at multiple protocol support (originally IP/CHAOS). As a slight bit of humor, when hooking up my sun, I managed to crash every VMS machine at Rutgers (including two in NEWARK that were 20 miles away) because all the VMS machines (being primarily DECNET speakers) were on the data link repeated parts of the Rutgers net. -Ron
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 19:41:19 GMT From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Routers vs. Bridges (CORRECTION)
As Bill Westfield immediately pointed out to me (SIX MINUTES later!), my brain was disengaged when I sent a message earlier. Sorry. Here is what I meant to say: ___________________________________________________ Here is one way you might decide if a given box is a bridge or an IP gateway (aka router): see if it forwards a local network broadcast packet. A bridge "must" forward broadcasts, while a gateway "must never" forward one. Another test: see if the destination local network address changes when the packet is forwarded. These two tests give some clues about the advantages of gateways over bridges. Bob Braden ----- End Forwarded Message -----
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 20:44:31 GMT From: haas%gr@CS.UTAH.EDU (Walt Haas) To: comp.protocols.tcp-ip Subject: Re: Vitalink Bridges..
In article <19509@amdcad.AMD.COM>, percy@amdcad.AMD.COM (Percy Irani) writes: > > We have a Vitalink sales guy trying to sell Vitalink Bridges to our > Company. We primarily have TCP/IP hosts on the net. We also have > some DECNET hosts. > > What is attractive to some people (Sigh!) is that the Vitalink's will > be able to do protocol independant connections. I guess we can beat > the Vitalinks iff there is a router that does both IP and DECNET. > > IS THERE ONE AVAILABLE LIKE THAT TODAY???? > ------------------------------------------ There are at least two, cisco and Proteon. However the real advantage of level two bridges like the Vitalink is that they let you also run ISO, XNS, Ethertalk, Novell and what have you with no further modification. Given the dynamic state of protocols today this is a big advantage. For example, the low level protocols of DECnet will change drastically next year. Proteon and cisco may or may not keep up, but a level two bridge won't even notice. Cheers -- Walt Haas arpa: haas@cs.utah.edu uucp: ...utah-cs!haas
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 21:35:25 GMT From: ruffwork@orstcs.CS.ORST.EDU (Ritchey Ruff) To: comp.protocols.tcp-ip Subject: Re: ARPANET UPGRADE SCHEDULE
We are having the same problem here - before the new protocall went
into testing orstcs.cs.orst.edu and uwchem.acs.washington.edu could
talk directly to each other, now they can't (it's actually intermitent
but I have not been keeping that close a track of when the new
protocall is in/out). I can do a
finger @uwchem.acs.washington.edu@washington.edu
now and see uwchem, but directly to uwchem, which use to work ALL
the time, works less and less (and has not worked for the last week
that I know of).
Is this a problem with the new protocall ???
--ritchey ruff ruffwork@cs.orst.edu -or-
"It's against my programming ruffwork%oregon-state@relay.cs.net -or-
to impersonate a deity" --C3PO { hp-pcd | tektronix }!orstcs!ruffwork
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 21:52:05 GMT From: TS0400@OHSTVMA.BITNET (Bob Dixon) To: comp.protocols.tcp-ip Subject: Re: Vitalink Bridges..
We are using Proteon routers with tcp/ip and decnet today, and very
successfully.
Bob Dixon
Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 10 Dec 87 22:52:07 GMT From: leiner@riacs.EDU To: comp.protocols.tcp-ip Subject: Re: Vitalink Bridges..
Proteon makes a gateway that can deal with both Decnet and IP (so they tell me). NASA is exploring their use in the NASA Science Internet. Barry
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 11 Dec 87 00:51:01 GMT From: craig@NNSC.NSF.NET (Craig Partridge) To: comp.protocols.tcp-ip Subject: re: Why wait....
Sounds like we didn't get the word out at Monterey East. I believe that all the problems you list are currently being worked on by various task forces. Craig
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 11 Dec 87 01:50:09 GMT From: craig@NNSC.NSF.NET (Craig Partridge) To: comp.protocols.tcp-ip Subject: Current State of Network Management
I got a couple of inquiries today from people who mis-interpreted Lee's
note to suggest that all network management activities are being
coordinated through him. That's not what the note was intended to
say.
Regretfully, network management work is still a multi-headed beast.
Here's a short Who's Who:
NETMAN (Network Management) Working Group of the IETF. Chaired
by Lee LaBarre. As Lee's note indicated, they are working on
fashioning their own network management proposal, based in part
on work done by the HEMS group. Contact Lee (cel@mitre-bedford.arpa)
for information.
GWMON (Gateway Management) Working Group of the IETF. Chaired
by me, and the source of the High-Level Entity Management System
(HEMS) proposal, documented in RFC1021-1024 and recently implemented.
Operates the GWMON mailing list, which is the mailing list for
all general interest announcements/correspondence on network
management. Mail to gwmon-request@sh.cs.net to join.
SGMP (Simple Gateway Monitoring Protocol). Affiliated with the
IETF but not a working group (for odd historical reasons).
Documented in RFC 1028 (which I believe has not yet been released).
Several test implementations exist. I believe most SGMP announcements
appear on GWMON, although there is a separate mailing list for
SGMP implementors.
There are also activities attempted to build applications or protocols
that work at a higher level that these protocols (which primarily address
the problem of data extraction). These activities include:
The Network Computing Forum (NCF) is trying to develop higher level
management applications/protocols. This is being led by Terry
Hardgraves (pardon any mis-spelling, his business card is in
my briefcase at home) of the Software Productivity Consortium.
ANM (Automated Network Management), a project at BBN Laboratories
which uses a distributed database system and AI tools to effect
network management. Contact Jil Westcott, jwestcott@bbn.com, for
more information.
An IETF working group led by Jeff Case (one of the SGMP authors).
case@utkcs2.cs.utk.edu
I hope this all helps.
Craig
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: 11 Dec 87 04:46:12 GMT From: RCONN@SIMTEL20.ARPA (Rick Conn) To: comp.protocols.tcp-ip Subject: Re: Protocols in Ada
The software submitted to the Ada Software Repository on communications protocols written in Ada (namely, TCP/IP) was written by E_Systems, Inc. Details are contained in the PROlogues files in PD2:<ADA.DDN> and in PD2:<ADA.WIS-TOOLS> Rick Conn -------
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 11 Dec 87 08:08:30 GMT From: hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: Routers vs. Bridges
>Another test: see if the IP network number changes when the packet is >forwarded. A bridge must not change anything in the IP header, while a >gateway "must" change the IP destination address. One hopes the IP network number doesn't change when a gateway forwards a packet. The only thing that would normally change is TTL. The problem with trying to define these things is that there are hybrid beasts, e.g. bridges that allow the user to specify filtering using boolean operations on arbitrary bytes in the header. One could (and indeed probably should) set up such a bridge so it did not pass IP broadcasts. There seems to be a continuum possible. I have evidence that as time goes on, we're going to see a lot more points in that continuum. E.g. boxes that act as true gateways for IP packets and bridges for everything else, and bridges whose routing is as complex as an IP router, but applied to the MAC address instead of the IP address. I'd say that to qualify as an IP gateway by modern standards you need to process correctly most of the fields in the IP header, including decrementing the TTL, doing type of service routing, implementing source quench, source routing, record route, etc., and doing fragmentation. The claim that a bridge is all you need is equivalent to the following claims: - that everything in the IP header other than source and destination is unnecessary. - that it makes sense to build routing on top of an address with no internal structure. (That is, the MAC addresses have no pattern to them. IP gateways normally have to figure out a route to each network that they can reach. A bridge has to keep track of distinct MAC addresses. The thought of a gateway that knows every address in the Internet is absurd. So in effect the bridge's knowledge may be just a cache. But then you need a way to find a route initially. There are many such schemes, but they all run into trouble for very big networks.) - that ICMP functions, e.g. unreachable, and source quench, are unnecessary. (I don't mention redirects, because they obviously are unnecessary in a system using bridges.) In short, that the IP network layer is unnecessary. In my opinion, you can survive without a full network layer in a small, homogeneous system. So I have no problem with using LANbridges to connect a few Ethernets (though I wouldn't do it myself). But if the network layer is unnecessary, how come every protocol has one, and attempts to do routing at the MAC layer end up reinventing them (e.g. the IBM MAC-level source routing, and other ISO MAC-level network functions)? Again, I have no doubt that there are uses for LANbridges and similar gadgets. But at some point you have to draw the line, and start using the facilities that the protocol designers have supplied for you. The question is where that line is. One has a suspicion that when you start having a network of bridges running a full-scale routing protocol, there's a good chance you've crossed the line. On the other hand, there may be cases where for various practical reasons, such a product would actually be useful.
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 11 Dec 87 08:23:21 GMT From: slevy@UMN-REI-UC.ARPA (Stuart Levy) To: comp.protocols.tcp-ip Subject: Determining gateway buffer capacity
Some recent messages on this list described efforts to define a scheme for
hosts to find a network path's maximum preferred message size, e.g. the
largest datagram which could be sent without some gateway fragmenting it.
Has anyone considered having gateways give advice to hosts on how -much- data
they should send, either in terms of total amount of outstanding data
(which TCPs could use to limit windows) or data flow rate (which, say,
NETBLTs could use to set rate parameters)?
This seems like a natural function to piggyback onto a max-message-size
probe. It suffers from some of the same limitations, that there may be
multiple paths with different behavior.
A gateway giving buffering advice would have to make some assumption about
what fraction of its capacity (or its links' capacity) should be available
to a given session. It might make a static decision ("I expect to have <= 10
active connections passing through me at once, so I advise everybody to use
no more than 1/10th of my capacity") or a dynamic one ("Things are getting
too crowded, so I'll tell everyone to send no more than 1000 bytes per second").
If implemented as an IP option it could be hung on Source Quenches to give
some crude quantitative information. Capacity assumptions could be wrong,
but at least they would prevent hosts with 32K TCP windows from swamping
gateways with 20K of buffer space.
Is anything along these lines being discussed? (Or has it already been
discussed and abandoned?)
Stuart Levy, Minnesota Supercomputer Center
slevy@uc.msc.umn.edu, (612) 626-0211
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 11 Dec 87 10:25:23 GMT From: jgh@root.co.uk (Jeremy G Harris) To: comp.protocols.tcp-ip Subject: Subnetting questions
A whole bunch of questions:
Does anybody run multiple subnets on a single Ethernet?
If so, do you use subnet broadcasts or net broadcasts?
Do you find it worthwhile to use ethernet multicast for
subnet broadcasts? How do you assign the multicast addresses?
For what purposes do you still use net broadcast?
Should redirects be provided by an inter-subnet gateway,
when both subnets are on the same Ethernet?
What are the semantics of 'ICMP redirect to net' in a subnettted environment?
Does anybody run multiple classes of subnet on a single net?
Does the mechanism proposed in rfc950 ( ICMP broadcasts to
discover the subnet mask ) still work? Do you use it?
Thanks for your time
Jeremy
--
Jeremy Harris jgh@root.co.uk
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 11 Dec 87 13:14:07 GMT From: bill@trotter.usma.edu (Bill Gunshannon) To: comp.protocols.tcp-ip Subject: Re: Latest KA9Q TCP/IP for MSDOS now available from SIMTEL20
In article <4063@b-tech.UUCP>, zeeff@b-tech.UUCP (Jon Zeeff) writes:
> Is this the version that includes support for running as a single task under
> Unix? If not, what is the status of that version (I heard is was almost
> done months ago).
>
The latest word on the next release of KA9Q's TCP/IP is to look for it
in your Christmas stocking.
As there appears to be a lot of interest any more I will post a message
as soon as it becomes available if noone beats me to it. I check on it
just about every day. The UNIX support is supposed to be for SYS V but
I will be converting that over to Version 7 and probbly XENIX (SYS III)
as soon as I lay my hands on it as those are what I run.
bill gunshannon
UUCP: {philabs}\ US SNAIL: Martin Marietta Data Systems
{phri } >!trotter.usma.edu!bill USMA, Bldg 600, Room 26
{sunybcs}/ West Point, NY 10996
RADIO: KB3YV PHONE: WORK (914)446-7747
AX.25: KB3YV @ K3RLI PHONE: HOME (914)565-5256
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 11 Dec 87 13:24:00 GMT From: holt@inco.UUCP (Mark Holt) To: comp.protocols.tcp-ip Subject: KA9Q TCP/IP on VMS 4.2
[In answer to Mark Eggers' questions] > Could you send me more information ?? Yes. > What language, C. > how much CPU does it use (on average), I haven't checked into this yet. We're running under VMS 4.2 and it run as one *big* task. CPU cycles aren't a big deal, memory might be on some systems. > can you run DECnet at the > same time ? Yes, DECnet, ARP, and IP each have unique Ethernet protocol types. > > More importantly, can you either give me a list of mods or > make the code available ? Eventually, I plan to send the changes to Bdale Garbee at winfree.n3eua.ampr. I still have some work to do, though. > We are just starting out with our campus TCP/IP network, and > the Ultrix - DECnet gateway running on a microVAX has some > problems with ACCESS/MVS running on an IBM 3033. Running > your code on the VAXes would sure make life simpler. As noted above, we're using VMS, and my changes to the KA9Q package were *very* VMS specific, so I'm not sure we can help. > Thanks > for any information, You are welcome. > > Mark Eggers, Network Communications Analyst > Computing Center, University of Notre Dame /*--------------------------------------------------------------* * Mark L Holt * * McDonnell Douglas - Inco, Inc. 800-DOT-INCO * * ...!seismo!sundc!hadron!inco!holt * * "If you ain't the lead dog, the scenery never changes" * * DISCLAIMER: The opinions expressed are my own and in no way * * reflect the views of McDonnell Douglas or its subsidiaries. * *--------------------------------------------------------------*/
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 11 Dec 87 15:06:24 GMT From: radia@XX.LCS.MIT.EDU (Radia Perlman) To: comp.protocols.tcp-ip Subject: Re: Routers vs. Bridges (CORRECTION)
Just a clarification -- bridges don't HAVE to forward multicasts (broadcasts)
in order to be a bridge. The Vitalink and DEC bridges have the capability
to manually set certain multicast addresses as "don't forward". This
is very important for various reasons. The default is "forward", but
some finite number (large enough for all practical purposes, I claim)
of multicast addresses can be manually configured to be localized, i.e.
not forwarded by the bridge.
Once people agree on what a bridge vs a router is, I'd summarize the
tradeoffs as:
1) bridges don't require a standard layer 3 (win for bridges unless
suddenly layer 3 standards crystallized and universalized)
2) routers can do much fancier stuff because of the extra layer
of header and explicit cooperation from the stations, like
utilizing better routes, or utilizing hierarchical addresses
3) even if layer 3 standards crystallized, a mixture of bridges and
routers might be desirable because it gives an extra level
of hierarchy "for free". In other words, it might be efficient
to clump LANs into big LANs, and then the layer 3 protocol
doesn't have to trouble itself with the inner topology of
the bridged extended LANs.
Radia
-------
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 11 Dec 87 15:59:23 GMT From: hoffmann@BITSY.MIT.EDU (Ron M. Hoffmann) To: comp.protocols.tcp-ip Subject: multiple DEQNAs in microvaxen
The DEQNA manual goes as far as to state that more than one in a Microvax-II could exceed the FCC specified RF emission levels. -Ron
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: 11 Dec 87 19:01:09 GMT From: paulf@umunhum.STANFORD.EDU To: comp.protocols.tcp-ip Subject: Re: Ethers, Copper, Fiber, Microwaves, Etc.
In article <8712101810.AA00864@PTT.LCS.MIT.EDU> dab@ALLSPICE.LCS.MIT.EDU writes: > In the ham radio community for several years there have been >devices called Gunnplexers available (I don't know if that's a brand >name or a generic name) which are a 10 GHz microwave system for about >$200. When they first showed up there were several articles in ham >radio magazines descibing how to send video through them, so 10 Mb/sec >is probably not too far out of line. Except for maybe the feedhorn >(or the dish itself) it would easily fit into a briefcase. The range >is limited but I think to line of sight rather than 1 mile. > Dave Bridgham The biggest problem with using GunnPlexers (TM) for digital communications is their lack of linearity. GunnPlexers have both phase and amplitude distortion, and have some real temperature - frequency dependence problems. Despite this, by using FSK or MSK combined with some equalization, one can make an incredibly cheap digital link. We're currently working on a modem that uses temperature stabilized GunnPlexers, and MSK with some simple adaptive equalization, to be used by the 230.4kbps AppleTalk protocol. Look for the article in the March '88 issue of _MacWorld_. -=Paul Flaherty, N9FZX | "The only thing that we've learned from Computer Systems Laboratory |history is that we havn't learned anything Stanford University |from history..." Domain: paulf@shasta.Stanford.EDU| -- William Jennings Bryant
-----------[000081][ne