----MESSAGE-BEGIN---- <1987120100022500> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Tue 1 Dec 87 05:29:54-PST To: TCP-IP@SRI-NIC.ARPA Subject: Re: MRC: NFS over ARPANET In-reply-to: Your message of Mon, 30 Nov 87 23:14:55 -0800. <12354925894.6.MRC@PANDA.COM> Date: Tue, 01 Dec 87 08:22:25 -0500 From: haverty@CCV.BBN.COM 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [203@wright.EDU] <1987120103071300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jsloan@wright.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Ethers, Copper, Fiber, Microwaves, Etc. Message-ID: <203@wright.EDU> Date: Tue, 1-Dec-87 08:07:13 EST Article-I.D.: wright.203 Posted: Tue Dec 1 08:07:13 1987 Date-Received: Fri, 4-Dec-87 05:38:35 EST References: <3044@phri.UUCP> Organization: Wright State University, Dayton OH, 45435 Lines: 35 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712011359.AA18677@ucbvax.Berkeley.EDU] <1987120104001300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: haverty@CCV.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: MRC: NFS over ARPANET Message-ID: <8712011359.AA18677@ucbvax.Berkeley.EDU> Date: Tue, 1-Dec-87 09:00:13 EST Article-I.D.: ucbvax.8712011359.AA18677 Posted: Tue Dec 1 09:00:13 1987 Date-Received: Fri, 4-Dec-87 05:43:53 EST References: <12354925894.6.MRC@PANDA.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712011829.AA19633@uc.msc.umn.edu] <1987120108292100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: slevy@UMN-REI-UC.ARPA (Stuart Levy) Newsgroups: comp.protocols.tcp-ip Subject: Re: Fwd: NFS over arpanet? Message-ID: <8712011829.AA19633@uc.msc.umn.edu> Date: Tue, 1-Dec-87 13:29:21 EST Article-I.D.: uc.8712011829.AA19633 Posted: Tue Dec 1 13:29:21 1987 Date-Received: Fri, 4-Dec-87 21:58:31 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [869@idec.stc.co.uk] <1987120109055900> From: howellg@idec.stc.co.uk (Gareth Howell) Newsgroups: rec.ham-radio.packet,comp.protocols.tcp-ip Subject: NEEDED: KISS for TNC220 Message-ID: <869@idec.stc.co.uk> Date: 1 Dec 87 09:05:59 GMT Organization: ICL Network Systems, Stevenage, Herts. UK Lines: 12 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 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12355286242.14.NIC@SRI-NIC.ARPA] <1987120206142200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NIC@SRI-NIC.ARPA (DDN Reference) Newsgroups: comp.protocols.tcp-ip Subject: ARPANET UPGRADE SCHEDULE Message-ID: <12355286242.14.NIC@SRI-NIC.ARPA> Date: Wed, 2-Dec-87 11:14:22 EST Article-I.D.: SRI-NIC.12355286242.14.NIC Posted: Wed Dec 2 11:14:22 1987 Date-Received: Sat, 5-Dec-87 15:55:09 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712022019.AA25644@ucbvax.Berkeley.EDU] <1987120206340000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: YBMCU@CUNYVM.CUNY.EDU (Ben Yalow) Newsgroups: comp.protocols.tcp-ip Subject: BITNET-Internet gateway changes Message-ID: <8712022019.AA25644@ucbvax.Berkeley.EDU> Date: Wed, 2-Dec-87 11:34:00 EST Article-I.D.: ucbvax.8712022019.AA25644 Posted: Wed Dec 2 11:34:00 1987 Date-Received: Sat, 5-Dec-87 17:37:56 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 45 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987120206340001> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Wed 2 Dec 87 08:34:07-PST Received: from CUNYVM.BITNET by CUNYVM.CUNY.EDU ; Wed, 02 Dec 87 11:34:02 EST Received: by CUNYVM (Mailer X1.25) id 8804; Wed, 02 Dec 87 11:34:01 EST Date: Wed, 02 Dec 87 11:34:00 EST From: Ben Yalow Subject: BITNET-Internet gateway changes To: TCP-IP@SRI-NIC.ARPA 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [171500009@uxc.cso.uiuc.edu] <1987120206350000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rrv@uxc.cso.uiuc.edu Newsgroups: comp.protocols.tcp-ip Subject: Re: Connexions - Magazine (defunct ??) Message-ID: <171500009@uxc.cso.uiuc.edu> Date: Wed, 2-Dec-87 11:35:00 EST Article-I.D.: uxc.171500009 Posted: Wed Dec 2 11:35:00 1987 Date-Received: Sun, 6-Dec-87 23:44:41 EST References: <418@trlluna.trl.oz> Lines: 7 Nf-ID: #R:trlluna.trl.oz:418:uxc.cso.uiuc.edu:171500009:000:105 Nf-From: uxc.cso.uiuc.edu!rrv Dec 2 10:35:00 1987 ConneXions Advanced Computing Environments 21370 Vai Avenue Cupertino, CA 95014, USA phone 408/996-2042 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [16836@bu-cs.BU.EDU] <1987120209524000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethers, Copper, Fiber, Microwaves, Etc. Message-ID: <16836@bu-cs.BU.EDU> Date: Wed, 2-Dec-87 14:52:40 EST Article-I.D.: bu-cs.16836 Posted: Wed Dec 2 14:52:40 1987 Date-Received: Sat, 5-Dec-87 15:54:25 EST References: <3044@phri.UUCP> <203@wright.EDU> Reply-To: kwe@bu-it.bu.edu (Kent England) Organization: Boston Univ. Information Tech. Dept. Lines: 44 Summary: I like fiber 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 ------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712022249.AA17111@presto.ig.com] <1987120212492100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rob@PRESTO.IG.COM (Rob Liebschutz) Newsgroups: comp.protocols.tcp-ip Subject: Re: NFS over arpanet? Message-ID: <8712022249.AA17111@presto.ig.com> Date: Wed, 2-Dec-87 17:49:21 EST Article-I.D.: presto.8712022249.AA17111 Posted: Wed Dec 2 17:49:21 1987 Date-Received: Sun, 6-Dec-87 08:39:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712040041.AA00504@ucbvax.Berkeley.EDU] <1987120219213100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: henry@utzoo.UUCP.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Networks & vendor upgrades/fixes Message-ID: <8712040041.AA00504@ucbvax.Berkeley.EDU> Date: Thu, 3-Dec-87 00:21:31 EST Article-I.D.: ucbvax.8712040041.AA00504 Posted: Thu Dec 3 00:21:31 1987 Date-Received: Mon, 7-Dec-87 07:25:33 EST References: <8711222104.AA11940@etn-wlv.EATON.COM> <8711222136.AA25270@bu-cs.BU.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 > 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712032028.AA24808@ucbvax.Berkeley.EDU] <1987120306043300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AD@BROWNVM.BITNET.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Connexions - Magazine (defunct ??) Message-ID: <8712032028.AA24808@ucbvax.Berkeley.EDU> Date: Thu, 3-Dec-87 11:04:33 EST Article-I.D.: ucbvax.8712032028.AA24808 Posted: Thu Dec 3 11:04:33 1987 Date-Received: Sun, 6-Dec-87 17:23:55 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987120306043301> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Thu 3 Dec 87 08:09:50-PST Received: from BROWNVM.Brown.BITNet by WISCVM.WISC.EDU ; Thu, 03 Dec 87 10:10:15 CDT Received: by BROWNVM (Mailer X1.25) id 7390; Thu, 03 Dec 87 11:09:10 EST Date: Thu, 03 Dec 87 11:04:33 EST From: Arif Diwan Subject: Re: Connexions - Magazine (defunct ??) To: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message of 30 Nov 87 05:40:03 GMT from 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10105@oliveb.UUCP] <1987120313085100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jerry@oliveb.UUCP Newsgroups: comp.unix.wizards,comp.protocols.tcp-ip Subject: Re: Can I print on a terminal server port Message-ID: <10105@oliveb.UUCP> Date: Thu, 3-Dec-87 18:08:51 EST Article-I.D.: oliveb.10105 Posted: Thu Dec 3 18:08:51 1987 Date-Received: Sun, 6-Dec-87 21:02:26 EST References: <8215@oliveb.UUCP> Organization: Olivetti ATC; Cupertino, Ca Lines: 193 Keywords: print server telnet Summary: Only hacks are currently available. 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 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) 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 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 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 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 -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8130@ism780c.UUCP] <1987120319355700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mikep@ism780c.UUCP (Michael A. Petonic) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP Software Raves Wanted Message-ID: <8130@ism780c.UUCP> Date: Fri, 4-Dec-87 00:35:57 EST Article-I.D.: ism780c.8130 Posted: Fri Dec 4 00:35:57 1987 Date-Received: Thu, 10-Dec-87 22:36:09 EST Reply-To: mikep@ism780c.UUCP (Michael A. Petonic) Organization: Interactive Systems Corp., Santa Monica CA Lines: 26 Summary: Need info 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1106@scirtp.UUCP] <1987120405083800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: scott@scirtp.UUCP Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans,comp.std.internat Subject: Inter-Domain Addressing Standards Message-ID: <1106@scirtp.UUCP> Date: Fri, 4-Dec-87 10:08:38 EST Article-I.D.: scirtp.1106 Posted: Fri Dec 4 10:08:38 1987 Date-Received: Wed, 9-Dec-87 20:08:51 EST Organization: SCI Systems, Research Triangle Park, NC Lines: 8 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1107@scirtp.UUCP] <1987120408245200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: scott@scirtp.UUCP Newsgroups: comp.std.internat,comp.protocols.tcp-ip Subject: ISDN Specs Wanted Message-ID: <1107@scirtp.UUCP> Date: Fri, 4-Dec-87 13:24:52 EST Article-I.D.: scirtp.1107 Posted: Fri Dec 4 13:24:52 1987 Date-Received: Thu, 10-Dec-87 03:45:26 EST Organization: SCI Systems, Research Triangle Park, NC Lines: 8 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712041954.AA28307@ll-vlsi.arpa] <1987120409540300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: wjc@LL-VLSI.ARPA (Bill Chiarchiaro) Newsgroups: comp.protocols.tcp-ip Subject: IP options under 4.? BSD Message-ID: <8712041954.AA28307@ll-vlsi.arpa> Date: Fri, 4-Dec-87 14:54:03 EST Article-I.D.: ll-vlsi.8712041954.AA28307 Posted: Fri Dec 4 14:54:03 1987 Date-Received: Thu, 10-Dec-87 04:29:23 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [21277@hi.UUCP] <1987120518171400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cyrus@hi.UUCP (Tait Cyrus) Newsgroups: comp.protocols.tcp-ip Subject: best version of UN*X Message-ID: <21277@hi.UUCP> Date: Sat, 5-Dec-87 23:17:14 EST Article-I.D.: hi.21277 Posted: Sat Dec 5 23:17:14 1987 Date-Received: Sat, 12-Dec-87 03:50:01 EST Organization: U. of New Mexico, Albuquerque Lines: 38 Keywords: 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 | / | / @/_________@/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [KPETERSEN.12356446456.BABYL@SIMTEL20.ARPA] <1987120616270000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: W8SDZ@SIMTEL20.ARPA (Keith Petersen) Newsgroups: comp.protocols.tcp-ip Subject: Latest KA9Q TCP/IP for MSDOS now available from SIMTEL20 Message-ID: Date: Sun, 6-Dec-87 21:27:00 EST Article-I.D.: SIMTEL20.KPETERSEN.12356446456.BABYL Posted: Sun Dec 6 21:27:00 1987 Date-Received: Sat, 12-Dec-87 04:01:54 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 98 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: 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3057@phri.UUCP] <1987120617501300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: roy@phri.UUCP (Roy Smith) Newsgroups: comp.protocols.appletalk,comp.protocols.tcp-ip Subject: Using Kinetics boxes an an etherbridge Message-ID: <3057@phri.UUCP> Date: Sun, 6-Dec-87 22:50:13 EST Article-I.D.: phri.3057 Posted: Sun Dec 6 22:50:13 1987 Date-Received: Sat, 12-Dec-87 04:27:00 EST Organization: Public Health Research Institute, NYC, NY Lines: 84 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712071405.AA21382@ucbvax.Berkeley.EDU] <1987120703214500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckenzie@LABS-N.BBN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: ISDN Specs Wanted Message-ID: <8712071405.AA21382@ucbvax.Berkeley.EDU> Date: Mon, 7-Dec-87 08:21:45 EST Article-I.D.: ucbvax.8712071405.AA21382 Posted: Mon Dec 7 08:21:45 1987 Date-Received: Sat, 12-Dec-87 10:31:44 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987120703214501> Received: from LABS-N.BBN.COM by SRI-NIC.ARPA with TCP; Mon 7 Dec 87 05:31:03-PST Date: Mon, 7 Dec 87 8:21:45 EST From: Alex McKenzie To: Scott Crenshaw 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [878@sbcs.sunysb.edu] <1987120707251400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: root@sbcs.UUCP Newsgroups: comp.protocols.tcp-ip Subject: bsd4.3 network (IP/TCP) code Message-ID: <878@sbcs.sunysb.edu> Date: Mon, 7-Dec-87 12:25:14 EST Article-I.D.: sbcs.878 Posted: Mon Dec 7 12:25:14 1987 Date-Received: Sun, 13-Dec-87 15:30:56 EST Organization: State University of New York at Stony Brook Lines: 9 Keywords: Question: is code public domain? 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3059@phri.UUCP] <1987120718245700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: roy@phri.UUCP (Roy Smith) Newsgroups: comp.protocols.appletalk,comp.protocols.tcp-ip Subject: Re: Using Kinetics boxes an an etherbridge Message-ID: <3059@phri.UUCP> Date: Mon, 7-Dec-87 23:24:57 EST Article-I.D.: phri.3059 Posted: Mon Dec 7 23:24:57 1987 Date-Received: Sun, 13-Dec-87 08:34:08 EST References: <3057@phri.UUCP> Reply-To: roy@phri.UUCP (Roy Smith) Organization: Public Health Research Inst. (NY, NY) Lines: 23 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7080002@nucsrl.UUCP] <1987120802454300> From: gore@nucsrl.UUCP (Jacob Gore) Newsgroups: comp.protocols.tcp-ip Subject: How to set up lpd with CMU IP/ACP Message-ID: <7080002@nucsrl.UUCP> Date: 8 Dec 87 02:45:43 GMT Organization: Northwestern U, Evanston IL, USA Lines: 12 (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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1947@geac.UUCP] <1987120802455000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: daveb@geac.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Networks & vendor upgrades/fixes Message-ID: <1947@geac.UUCP> Date: Tue, 8-Dec-87 07:45:50 EST Article-I.D.: geac.1947 Posted: Tue Dec 8 07:45:50 1987 Date-Received: Sun, 13-Dec-87 02:20:07 EST References: <8711222104.AA11940@etn-wlv.EATON.COM> <8711222136.AA25270@bu-cs.BU.EDU> <8712040041.AA00504@ucbvax.Berkeley.EDU> Reply-To: daveb@geac.UUCP (David Collier-Brown) Organization: The little blue rock next to that twinkly star. Lines: 12 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12356860258.15.NIC@SRI-NIC.ARPA] <1987120806204200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NIC@SRI-NIC.ARPA (DDN Reference) Newsgroups: comp.protocols.tcp-ip Subject: ARPANET UPGRADE SCHEDULE Message-ID: <12356860258.15.NIC@SRI-NIC.ARPA> Date: Tue, 8-Dec-87 11:20:42 EST Article-I.D.: SRI-NIC.12356860258.15.NIC Posted: Tue Dec 8 11:20:42 1987 Date-Received: Sun, 13-Dec-87 15:10:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712082202.AA26595@saturn.mitre.org] <1987120812024200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lazear@gateway.mitre.ORG Newsgroups: comp.protocols.tcp-ip Subject: Protocols in Ada Message-ID: <8712082202.AA26595@saturn.mitre.org> Date: Tue, 8-Dec-87 17:02:42 EST Article-I.D.: saturn.8712082202.AA26595 Posted: Tue Dec 8 17:02:42 1987 Date-Received: Sun, 13-Dec-87 15:50:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4994@elroy.Jpl.Nasa.Gov] <1987120814403500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: david@elroy.Jpl.Nasa.Gov (David Robinson) Newsgroups: comp.protocols.tcp-ip Subject: IP protocol on a chip(s) Message-ID: <4994@elroy.Jpl.Nasa.Gov> Date: Tue, 8-Dec-87 19:40:35 EST Article-I.D.: elroy.4994 Posted: Tue Dec 8 19:40:35 1987 Date-Received: Sun, 13-Dec-87 15:39:52 EST Organization: Image Analysis Systems Grp, JPL Lines: 22 Keywords: Faster IP? 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! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712081541.AA13038@mitre-bedford.ARPA] <1987120815412400> From: cel@MITRE-BEDFORD.ARPA Newsgroups: comp.protocols.tcp-ip Subject: NETMAN meeting at TCP/IP Interoperability Conference Message-ID: <8712081541.AA13038@mitre-bedford.ARPA> Date: 8 Dec 87 15:41:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 50 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [KPETERSEN.12356979656.BABYL@SIMTEL20.ARPA] <1987120820320000> From: holt@inco.UUCP (Mark Holt) Newsgroups: comp.protocols.tcp-ip Subject: KA9Q TCP/IP Message-ID: Date: 8 Dec 87 20:32:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 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, ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987120904150000> Received: from TYCHO.ARPA by SRI-NIC.ARPA with TCP; Wed 9 Dec 87 06:31:17-PST Date: 9 Dec 1987 0915-EST Subject: re: IP protocol on a chip(s) From: hsw@TYCHO.ARPA (Howard Weiss) To: david at elroy.jpl.nasa.gov cc: tcp-ip at sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987120906311200> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu 10 Dec 87 09:08:48-PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA16871; Thu, 10 Dec 87 08:47:20 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Dec 87 06:31:12 GMT From: beach.cis.ufl.edu!esj@bikini.cis.ufl.edu (Eric S. Johnson) Organization: UF CIS Department Subject: Re: ARPANET UPGRADE SCHEDULE Message-Id: <9630@ufcsv.cis.ufl.EDU> References: <12356860258.15.NIC@SRI-NIC.ARPA> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987120906311201> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Thu 10 Dec 87 19:45:22-PST Received: from CORNELLC.BITNET by CUNYVM.CUNY.EDU ; Thu, 10 Dec 87 22:45:28 EST Received: by CORNELLC (Mailer X1.25) id 7470; Thu, 10 Dec 87 22:44:58 EST Resent-Date: Thu, 10 Dec 87 22:36:21 EST Resent-From: Mark Bodenstein Resent-Subject: Re: ARPANET UPGRADE SCHEDULE Resent-To: TCP-IP@SRI-NIC.ARPA Received: from devvax by vax2.ccs.cornell.edu (5.51/4.30) id AA13191; Sat, 2 Jan 88 00:37:00 EST Received: by devvax.TN.CORNELL.EDU (5.54/1.3-Cornell-Theory-Center) id AA05425; Thu, 10 Dec 87 19:59:38 EST Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu 10 Dec 87 09:0 8:48-PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA16871; Thu, 10 Dec 87 08:47:20 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) 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) Organization: UF CIS Department Subject: Re: ARPANET UPGRADE SCHEDULE Message-Id: <9630@ufcsv.cis.ufl.EDU> References: <12356860258.15.NIC@SRI-NIC.ARPA> Sender: tcp-ip-request%sri-nic.arpa%CRNLVAX2.BITNET@CUNYVM.CUNY.EDU To: tcp-ip@sri-nic.arpa 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. ... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22118@ucbvax.BERKELEY.EDU] <1987120913103800> From: fair@ucbarpa.Berkeley.EDU (Erik E. Fair) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP protocol on a chip(s) Message-ID: <22118@ucbvax.BERKELEY.EDU> Date: 9 Dec 87 13:10:38 GMT References: <4994@elroy.Jpl.Nasa.Gov> Sender: usenet@ucbvax.BERKELEY.EDU Organization: Nebula Consultants of San Francisco Lines: 68 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712091315.AA28675@mitre-bedford.ARPA] <1987120913151900> From: sra@MITRE-BEDFORD.ARPA (Stan Ames) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP protocol on a chip(s) Message-ID: <8712091315.AA28675@mitre-bedford.ARPA> Date: 9 Dec 87 13:15:19 GMT References: <4994@elroy.Jpl.Nasa.Gov> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2862@ncrcae.Columbia.NCR.COM] <1987120913421500> From: heath@ncrcae.Columbia.NCR.COM (Robert Heath) Newsgroups: comp.std.internat,comp.protocols.tcp-ip Subject: Re: ISDN Specs Wanted Message-ID: <2862@ncrcae.Columbia.NCR.COM> Date: 9 Dec 87 13:42:15 GMT References: <1107@scirtp.UUCP> Reply-To: heath@ncrcae.UUCP (Robert Heath) Distribution: na Organization: NCR Corp., Engineering & Manufacturing - Columbia, SC Lines: 9 Keywords: ISDN 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712092310.AA28631@ucbvax.Berkeley.EDU] <1987120914150000> From: hsw@TYCHO.ARPA (Howard Weiss) Newsgroups: comp.protocols.tcp-ip Subject: re: IP protocol on a chip(s) Message-ID: <8712092310.AA28631@ucbvax.Berkeley.EDU> Date: 9 Dec 87 14:15:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 30 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4063@b-tech.UUCP] <1987120918020200> From: zeeff@b-tech.UUCP (Jon Zeeff) Newsgroups: comp.protocols.tcp-ip Subject: Re: Latest KA9Q TCP/IP for MSDOS now available from SIMTEL20 Message-ID: <4063@b-tech.UUCP> Date: 9 Dec 87 18:02:02 GMT References: Reply-To: zeeff@b-tech.UUCP (Jon Zeeff) Organization: Branch Technology Ann Arbor, MI Lines: 9 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [340@ndcheg.UUCP] <1987120918423900> From: evan@ndcheg.UUCP (Evan Bauman) Newsgroups: comp.protocols.appletalk,comp.protocols.tcp-ip,comp.sys.mac Subject: software to use with Kinetics box Message-ID: <340@ndcheg.UUCP> Date: 9 Dec 87 18:42:39 GMT Organization: Univ. of Notre Dame Lines: 18 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987120919484000> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Wed 9 Dec 87 12:27:13-PST Received: from VM1.TAU.AC.IL by WISCVM.WISC.EDU ; Wed, 09 Dec 87 14:27:18 CDT Received: by TAUNIVM (Mailer X1.24) id 5456; Wed, 09 Dec 87 16:24:03 IST Date: Wed, 09 Dec 87 16:18:40 IST From: Hank Nussbacher Subject: Routers vs. Bridges To: tcp-ip@sri-nic.ARPA Reply-To: Hank Nussbacher 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [202@irisa.UUCP] <1987120920052100> From: michaud@irisa.UUCP (Michaud Franck INSA BN205) Newsgroups: comp.protocols.tcp-ip Subject: virtual circuit Message-ID: <202@irisa.UUCP> Date: 9 Dec 87 20:05:21 GMT Organization: IRISA, Rennes (Fr) Lines: 7 Keywords: tcp, socket I'd like to have a good definition of : - virtual circuit. If you have a good definition, send me a mail. thanck you. franck ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19509@amdcad.AMD.COM] <1987120922225800> From: percy@amdcad.AMD.COM (Percy Irani) Newsgroups: comp.protocols.tcp-ip Subject: Vitalink Bridges.. Message-ID: <19509@amdcad.AMD.COM> Date: 9 Dec 87 22:22:58 GMT Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca. Lines: 29 Keywords: Bridge, TCP/IP, Vitalink 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! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712092233.AA28045@hoquiam] <1987120922333600> From: don@SRI-LEWIS.ARPA (Donald Holman) Newsgroups: comp.protocols.tcp-ip Subject: Why wait for the rabid bite of a problem withou a solution? Message-ID: <8712092233.AA28045@hoquiam> Date: 9 Dec 87 22:33:36 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 52 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [871209-150341-2766@Xerox] <1987120922422900> From: castillo.osbunorth@XEROX.COM Newsgroups: comp.protocols.tcp-ip Subject: smtp on Unix (sun) machines Message-ID: <871209-150341-2766@Xerox> Date: 9 Dec 87 22:42:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: castillo.osbunorth@Xerox.COM Distribution: world Organization: The ARPA Internet Lines: 20 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [566092885.0.PULLEN@VAX.DARPA.MIL] <1987121000012500> From: PULLEN@VAX.DARPA.MIL (Mark Pullen) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP protocol on a chip(s) Message-ID: <566092885.0.PULLEN@VAX.DARPA.MIL> Date: 10 Dec 87 00:01:25 GMT References: <4994@elroy.Jpl.Nasa.Gov> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 David, Michael Foster and Yechaim Yemini and Columbia University are working on VLSI implementations of protocols. Mark Pullen DARPA Program Manager Advanced Networking ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712100040.AA04558@apptek6] <1987121000403500> From: len@SPAM.ISTC.SRI.COM (Len Schlegel) Newsgroups: comp.protocols.tcp-ip Subject: POP2, etc. Message-ID: <8712100040.AA04558@apptek6> Date: 10 Dec 87 00:40:35 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121001521500> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Thu 10 Dec 87 05:52:39-PST Date: 10 Dec 1987 07:52:15 CST Sender: LINK@GUNTER-ADAM.ARPA Subject: LAN Presentation and Security Packages 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 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121006044700> Received: from NNSC.NSF.NET by SRI-NIC.ARPA with TCP; Thu 10 Dec 87 11:30:34-PST To: holman@sri-lewis.ARPA cc: tcp-ip@sri-nic.ARPA Subject: re: Why wait.... Date: Thu, 10 Dec 87 14:24:47 -0500 From: Craig Partridge 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121006192400> Received: from NNSC.NSF.NET by SRI-NIC.ARPA with TCP; Thu 10 Dec 87 11:40:53-PST To: tcp-ip@sri-nic.ARPA Subject: Current State of Network Management Date: Thu, 10 Dec 87 14:39:24 -0500 From: Craig Partridge 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712100552.AA06745@ucbvax.Berkeley.EDU] <1987121006395500> From: HANK@TAUNIVM.BITNET (Hank Nussbacher) Newsgroups: comp.protocols.tcp-ip Subject: Routers vs. Bridges Message-ID: <8712100552.AA06745@ucbvax.Berkeley.EDU> Date: 10 Dec 87 06:39:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Hank Nussbacher Organization: The ARPA Internet Lines: 25 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121007463700> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Thu 10 Dec 87 13:51:34-PST Date: Thu, 10 Dec 87 12:46:37 EST From: Ross Callon 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1987Dec10.141545.23407@gpu.utcs.toronto.edu] <1987121009154500> Checksum: 53794 From: oattes@gpu.utcs.toronto.edu (Lee Oattes) Date: Thu, 10-Dec-87 14:15:45 EST Message-ID: <1987Dec10.141545.23407@gpu.utcs.toronto.edu> Organization: University of Toronto Computing Services Newsgroups: 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121011520500> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Thu 10 Dec 87 15:24:12-PST Received: from OHSTVMA.BITNET by CUNYVM.CUNY.EDU ; Thu, 10 Dec 87 18:08:13 EST Received: by OHSTVMA (Mailer X1.23b) id 1673; Thu, 10 Dec 87 16:53:22 EST Date: Thu, 10 Dec 87 16:52:05 EST From: Bob Dixon Subject: Re: Vitalink Bridges.. To: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message of 9 Dec 87 22:22:58 GMT from We are using Proteon routers with tcp/ip and decnet today, and very successfully. Bob Dixon Ohio State University Acknowledge-To: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712101503.AA15185@ucbvax.Berkeley.EDU] <1987121013521500> From: Link.Verstegen@GUNTER-ADAM.ARPA Newsgroups: comp.protocols.tcp-ip Subject: LAN Presentation and Security Packages Message-ID: <8712101503.AA15185@ucbvax.Berkeley.EDU> Date: 10 Dec 87 13:52:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12357379979.12.RADIA@XX.LCS.MIT.EDU] <1987121015553600> From: radia@XX.LCS.MIT.EDU (Radia Perlman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Routers vs. Bridges Message-ID: <12357379979.12.RADIA@XX.LCS.MIT.EDU> Date: 10 Dec 87 15:55:36 GMT References: Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12494@tektronix.TEK.COM] <1987121016221800> From: dennist@tektronix.TEK.COM (Dennis Thomas) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans,comp.sys.dec Subject: AT&T ISN Keywords: ATT,ISN Message-ID: <12494@tektronix.TEK.COM> Date: 10 Dec 87 16:22:18 GMT Reply-To: dennist@tektronix.TEK.COM (Dennis Thomas) Followup-To: dennist@tektronix.TEK.COM (Dennis Thomas) Organization: Tektronix, Inc., Beaverton, OR. Lines: 19 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [702@ucdavis.ucdavis.edu] <1987121017400700> From: rdhobby@ucdavis.edu (Russ Hobby) Newsgroups: comp.protocols.tcp-ip Subject: SLIP discussion at the Interoperability Conference Message-ID: <702@ucdavis.ucdavis.edu> Date: 10 Dec 87 17:40:07 GMT Sender: uucp@ucdavis.ucdavis.edu Reply-To: rdhobby@ucdavis.edu (Russ Hobby) Organization: University of California, Davis Lines: 52 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712101742.AA23362@braden.isi.edu] <1987121017421800> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Routers vs. Bridges Message-ID: <8712101742.AA23362@braden.isi.edu> Date: 10 Dec 87 17:42:18 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712110826.AA05986@ucbvax.Berkeley.EDU] <1987121017463700> From: rcallon@PARK-STREET.BBN.COM (Ross Callon) Newsgroups: comp.protocols.tcp-ip Subject: re: rabid bite of problems Message-ID: <8712110826.AA05986@ucbvax.Berkeley.EDU> Date: 10 Dec 87 17:46:37 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 30 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19521@amdcad.AMD.COM] <1987121017542800> From: percy@amdcad.AMD.COM (Percy Irani) Newsgroups: comp.protocols.tcp-ip Subject: Proteon Routers.. Keywords: Proteon, routers, TCP/IP, DECNET Message-ID: <19521@amdcad.AMD.COM> Date: 10 Dec 87 17:54:28 GMT Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca. Lines: 17 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! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712101810.AA00864@PTT.LCS.MIT.EDU] <1987121018100300> From: dab@ALLSPICE.LCS.MIT.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethers, Copper, Fiber, Microwaves, Etc. Message-ID: <8712101810.AA00864@PTT.LCS.MIT.EDU> Date: 10 Dec 87 18:10:03 GMT References: <16836@bu-cs.BU.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 > 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712101855.AA07448@topaz.rutgers.edu] <1987121018551400> From: ron@TOPAZ.RUTGERS.EDU (Ron Natalie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Vitalink Bridges.. Message-ID: <8712101855.AA07448@topaz.rutgers.edu> Date: 10 Dec 87 18:55:14 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712101941.AA23821@braden.isi.edu] <1987121019411900> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Routers vs. Bridges (CORRECTION) Message-ID: <8712101941.AA23821@braden.isi.edu> Date: 10 Dec 87 19:41:19 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 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 ----- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712102044.AA05561@gr.utah.edu] <1987121020443100> From: haas%gr@CS.UTAH.EDU (Walt Haas) Newsgroups: comp.protocols.tcp-ip Subject: Re: Vitalink Bridges.. Message-ID: <8712102044.AA05561@gr.utah.edu> Date: 10 Dec 87 20:44:31 GMT References: <19509@amdcad.AMD.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Keywords: Bridge, TCP/IP, Vitalink 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1461@orstcs.CS.ORST.EDU] <1987121021352500> From: ruffwork@orstcs.CS.ORST.EDU (Ritchey Ruff) Newsgroups: comp.protocols.tcp-ip Subject: Re: ARPANET UPGRADE SCHEDULE Summary: can't reach what we could before Message-ID: <1461@orstcs.CS.ORST.EDU> Date: 10 Dec 87 21:35:25 GMT References: <12356860258.15.NIC@SRI-NIC.ARPA> <9630@ufcsv.cis.ufl.EDU> Reply-To: ruffwork@orstcs.CS.ORST.EDU.UUCP (Ritchey Ruff) Organization: Oregon State University - CS - Corvallis, Oregon Lines: 15 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712110937.AA06638@ucbvax.Berkeley.EDU] <1987121021520500> From: TS0400@OHSTVMA.BITNET (Bob Dixon) Newsgroups: comp.protocols.tcp-ip Subject: Re: Vitalink Bridges.. Message-ID: <8712110937.AA06638@ucbvax.Berkeley.EDU> Date: 10 Dec 87 21:52:05 GMT References: Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 We are using Proteon routers with tcp/ip and decnet today, and very successfully. Bob Dixon Ohio State University Acknowledge-To: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712101638.AA19498@phun.riacs.edu] <1987121022520700> From: leiner@riacs.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Vitalink Bridges.. Message-ID: <8712101638.AA19498@phun.riacs.edu> Date: 10 Dec 87 22:52:07 GMT References: <19509@amdcad.AMD.COM> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712110033.AA27520@ucbvax.Berkeley.EDU] <1987121100510100> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: re: Why wait.... Message-ID: <8712110033.AA27520@ucbvax.Berkeley.EDU> Date: 11 Dec 87 00:51:01 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712110148.AA29321@ucbvax.Berkeley.EDU] <1987121101500900> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: Current State of Network Management Message-ID: <8712110148.AA29321@ucbvax.Berkeley.EDU> Date: 11 Dec 87 01:50:09 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 49 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12357520262.18.RCONN@SIMTEL20] <1987121104461200> From: RCONN@SIMTEL20.ARPA (Rick Conn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Protocols in Ada Message-ID: <12357520262.18.RCONN@SIMTEL20> Date: 11 Dec 87 04:46:12 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 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: and in PD2: Rick Conn ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712110808.AA18036@athos.rutgers.edu] <1987121108083000> From: hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Routers vs. Bridges Message-ID: <8712110808.AA18036@athos.rutgers.edu> Date: 11 Dec 87 08:08:30 GMT References: <8712101742.AA23362@braden.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 57 >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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712110823.AA05126@uc.msc.umn.edu] <1987121108232100> From: slevy@UMN-REI-UC.ARPA (Stuart Levy) Newsgroups: comp.protocols.tcp-ip Subject: Determining gateway buffer capacity Message-ID: <8712110823.AA05126@uc.msc.umn.edu> Date: 11 Dec 87 08:23:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 29 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [498@root44.co.uk] <1987121110252300> From: jgh@root.co.uk (Jeremy G Harris) Newsgroups: comp.protocols.tcp-ip Subject: Subnetting questions Message-ID: <498@root44.co.uk> Date: 11 Dec 87 10:25:23 GMT Organization: Root Computers Ltd., London, England Lines: 27 Keywords: subnet ethernet 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1146@trotter.usma.edu] <1987121113140700> From: bill@trotter.usma.edu (Bill Gunshannon) Newsgroups: comp.protocols.tcp-ip Subject: Re: Latest KA9Q TCP/IP for MSDOS now available from SIMTEL20 Message-ID: <1146@trotter.usma.edu> Date: 11 Dec 87 13:14:07 GMT References: <4063@b-tech.UUCP> Organization: US Military Academy, West Point, NY Lines: 22 Summary: Not Yet 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [KPETERSEN.12357721733.BABYL@SIMTEL20.ARPA] <1987121113240000> From: holt@inco.UUCP (Mark Holt) Newsgroups: comp.protocols.tcp-ip Subject: KA9Q TCP/IP on VMS 4.2 Message-ID: Date: 11 Dec 87 13:24:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 46 [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. * *--------------------------------------------------------------*/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12357633164.33.RADIA@XX.LCS.MIT.EDU] <1987121115062400> From: radia@XX.LCS.MIT.EDU (Radia Perlman) Newsgroups: comp.protocols.tcp-ip Subject: Re: Routers vs. Bridges (CORRECTION) Message-ID: <12357633164.33.RADIA@XX.LCS.MIT.EDU> Date: 11 Dec 87 15:06:24 GMT References: <8712101941.AA23821@braden.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712111559.AA03343@BITSY.MIT.EDU] <1987121115592300> From: hoffmann@BITSY.MIT.EDU (Ron M. Hoffmann) Newsgroups: comp.protocols.tcp-ip Subject: multiple DEQNAs in microvaxen Message-ID: <8712111559.AA03343@BITSY.MIT.EDU> Date: 11 Dec 87 15:59:23 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [120@umunhum.STANFORD.EDU] <1987121119010900> From: paulf@umunhum.STANFORD.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethers, Copper, Fiber, Microwaves, Etc. Message-ID: <120@umunhum.STANFORD.EDU> Date: 11 Dec 87 19:01:09 GMT References: <16836@bu-cs.BU.EDU> <8712101810.AA00864@PTT.LCS.MIT.EDU> Reply-To: paulf@umunhum.UUCP (Paul Flaherty) Organization: The Three Packeteers Lines: 29 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712111138.aa17290@Huey.UDEL.EDU] <1987121119252900> From: mminnich@UDEL.EDU (Mike Minnich) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP discussion at the Interoperability Conference Message-ID: <8712111138.aa17290@Huey.UDEL.EDU> Date: 11 Dec 87 19:25:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Isn't there a problem with dynamically changing the kernel's routing table (via a slattach/sldetach mechanism) while user level routing agents such as egpup, routed, or gated are running? This has typically not been a problem for hardwired SLIP connections, since the slip interfaces can be configured before routing agents start up, and are left alone thereafter. One solution would be to home all dial-in connections on another host that would presumably use static routing, but that requires the "host" to function as a "gateway", which is something I would like to minimize. mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2480@dcatla.UUCP] <1987121122135900> From: dnwcv@dcatla.UUCP (William C. VerSteeg) Newsgroups: comp.protocols.tcp-ip Subject: More than one IP (sub)network on one ethernet cable Message-ID: <2480@dcatla.UUCP> Date: 11 Dec 87 22:13:59 GMT Reply-To: dnwcv@dcatla.UUCP (William C. VerSteeg) Distribution: world Organization: DCA Inc., Alpharetta, GA Lines: 28 I have bumped into a distressing situation dealing with getting a generic host to communicate with other host with different IP network numbers on the same network. Let's assume that the following scenario for demonstration purposes. Through the process of adding link-level (hardware) bridges, I have had the unenviable situation of having more than one internet network appear on what appears to be one ethernet cable. I want to telnet from my PC to a SUN. They have different IP network numbers. The PC will not generate a packet to this host in the absence of gateway information. The only way I can think of to make this work is to have the PC route to a gateway, which sends an ICMP redirect back to the PC. This leads me to my questions. What can be done to make the PC (or any other device for that matter) directly access differring IP networks that are directly connected to its local ethernet? This situation runs against "normal" IP addressing schemes. But does it violate any specific rules? Are there implementations that handle this situation gracefully? Bill VerSteeg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712112246.AA12554@monk.proteon.com] <1987121122465800> From: mcs@MONK.PROTEON.COM (Mick Scully) Newsgroups: comp.protocols.tcp-ip Subject: Proteon Routers.. Message-ID: <8712112246.AA12554@monk.proteon.com> Date: 11 Dec 87 22:46:58 GMT References: <19521@amdcad.AMD.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Hello, We have sales, service, and system people in your neighborhood. The regional manager is: Dave Buchanan Proteon Inc. 5201 Great American Pkwy Santa Clara, CA (408)562-6100 Thanx. Mick Scully (mcs@proteon.com) Product Marketing Manager 2 Technology Drive Westborough, Mass. 617-898-2800 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6977@apple.UUCP] <1987121200093300> From: berner@apple.UUCP (William Berner) Newsgroups: comp.protocols.appletalk,comp.protocols.tcp-ip Subject: Re: Using Kinetics boxes an an etherbridge Message-ID: <6977@apple.UUCP> Date: 12 Dec 87 00:09:33 GMT References: <3057@phri.UUCP> Reply-To: berner@apple.UUCP (William Berner) Organization: Apple Computer Inc., Cupertino, USA Lines: 8 Roy smith posted a couple of message about using 2 Kinetics boxxes as an Ethernet bridge. However, if you're just looking for an Ethernet bridge, then Retix sells one called the RetixGate 2255, that's priced at less than $2000. You can find out more by calling Retix at 800/255-2333 Bill Berner Apple Computer, Inc. Desktop Communications Marketing ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712120403.AA18224@ACC-SB-UNIX.ARPA] <1987121204032900> From: chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) Newsgroups: comp.protocols.tcp-ip Subject: Re: Vitalink Bridges.. Message-ID: <8712120403.AA18224@ACC-SB-UNIX.ARPA> Date: 12 Dec 87 04:03:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 In response to Percy Irani and his obvious disgust for MAC-level bridges I would just like to emphasize(as I do to potential Customers when I talk to them) that bridges are not THE solution for every problem. But they certainly DO have their uses and to deny that is a blatant system adminstration power play. I would like to believe that an approach different from Percy's is not "ignorant" but just that, different! Not all network managers want to open each day with a careful scrutinization of the routing tables(how shall we route traffic TODAY?). Many just want to plug it in and forget it(at least at the LAN level. Bridging to the great, big world is another issue entirely...). Many customers must feel this way because ACC and others are selling LOTS of MAC-level bridges. I think most people would agree the BROUTER question may not be resolved for quite a while. It's all clear as mud to me... Chris VandenBerg Applications Engineer Advanced Computer Communications (chris@acc-sb-unix.arpa) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [298359.871212.PAP4@AI.AI.MIT.EDU] <1987121205594400> From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") Newsgroups: comp.protocols.tcp-ip Subject: Re: IP protocol on a chip(s) Message-ID: <298359.871212.PAP4@AI.AI.MIT.EDU> Date: 12 Dec 87 05:59:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 I think that an ip-on-a-chip would have to be micro-coded (not because of complexity, it could certainly fit in random logic), because bugs would certainly be found. Also, certain parameters (such as fragmenting/reassembly philosophy) might need to be tailored to the environment (i.e. an ethernet enviroment device should not generate back to back fragments, but should space or scatter them over time). Ideas? -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [298390.871212.PAP4@AI.AI.MIT.EDU] <1987121207251500> From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") Newsgroups: comp.protocols.tcp-ip Subject: Re: beginners guide to ... ? Message-ID: <298390.871212.PAP4@AI.AI.MIT.EDU> Date: 12 Dec 87 07:25:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 (plug, plug, plug) Doug Comer ("Xinu", et al) is writing a book about Internetworking, pretty much outside of the context of an operating system, though he does talk briefly about 4.3BSD (sockets and utilites). The book is fairly exhaustive, and seems to be a timely replacement for the Tanenbaum book (is it still being printed with NCP references?). What I saw seemed as well written as his previous publications. I just hope it makes it to print before it starts to get out of date... It happens so quickly these days. (Doug: hope I didn't let the cat out of the bag) -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1045@infinet.UUCP] <1987121218554500> From: rhorn@infinet.UUCP (Rob Horn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethers, Copper, Fiber, Microwaves, Etc. Message-ID: <1045@infinet.UUCP> Date: 12 Dec 87 18:55:45 GMT References: <16836@bu-cs.BU.EDU> <8712101810.AA00864@PTT.LCS.MIT.EDU> Reply-To: rhorn@infinet.UUCP (Rob Horn) Organization: Infinet, Inc. North Andover, MA Lines: 30 I think that these systems are operating in the 23 GHz band. The frequencies between 21.2 and 23.6 GHz are set aside for commercial short-haul communications. This band has 2.4 GHz available, which is a whole lot. The equipment also tends to be relatively cheap, typically under $50K. The antennas that I have seen have been 2-3 foot diameter, giving antenna beam widths of a few degrees. This is more suitcase size than briefcase size. The wider beam width and small antenna make these easy to install. The reliable range at 23 GHz is at most a few miles. The attenuation in air is not too bad, but fog and rain cause significant problems. You have to expect dropouts during heavy rains. The greater the distance, the more you need to worry about these things. Short-haul microwave is a good complement to fiber optic and copper wiring. The installation cost is much lower than physical cable, provided you have line of site between the two ends. FCC licensing is required but usually easy to get. The frequency band is huge, not too heavily used (yet), and the attenuation is such that you can ignore sites that are many miles away. You have to put up with dropouts during heavy rains, so for applications that must work during bad weather they are a bad choice. (Dropouts act like a very overloaded gateway. Traffic can still pass occasionally but lots of packets get lost.) -- Rob Horn UUCP: ...harvard!adelie!infinet!rhorn Snail: Infinet, 40 High St., North Andover, MA (Note: harvard!infinet path is in maps but not working yet) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712122103.AA22653@okeeffe.Berkeley.EDU] <1987121221034500> From: karels@OKEEFFE.BERKELEY.EDU (Mike Karels) Newsgroups: comp.protocols.tcp-ip Subject: Re: micro-vax with more than one ether-net board? Message-ID: <8712122103.AA22653@okeeffe.Berkeley.EDU> Date: 12 Dec 87 21:03:45 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 We are using a Microvax II with 5 ethernet interfaces and a DMV-11 56 kbaud serial interface as a gateway. It's running 4.3BSD, not Ultrix. (I would strongly recommend the use of 4.3; Ultrix IP code is based on the 4.3 alpha release from July 1985, and the IP forwarding and option handling and ICMP received a lot of work after that time.) Our configuration includes two DEQNA ethernet interfaces and three Excelan interfaces; we're obviously using the "world box" BA123 cabinet, as the BA23 doesn't have nearly enough power for all of this. Use of more than two DEQNA's would require modification of the board, and is clearly not worth considering. (I suspect that the limitation is due to the FCC radiation limits already mentioned.) In addition to the Excelan and DEQNA interfaces, 4.3 includes drivers for Interlan NI1010 and NP100 UNIBUS interfaces; at least the latter has a compatible Q-bus interface. (I doubt that there are Q-bus controllers that are compatible with the 3Com or DEUNA/DELUA UNIBUS interfaces, although we have drivers for those, too.) Our Microvax gateway has been very reliable; it recently went down when a hardware tech was rearranging cables after 126 days up. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [745@gvgpsa.UUCP] <1987121308010900> From: davew@gvgpsa.UUCP (David C. White) Newsgroups: comp.protocols.tcp-ip Subject: Re: Vitalink Bridges.. Message-ID: <745@gvgpsa.UUCP> Date: 13 Dec 87 08:01:09 GMT References: <8712110937.AA06638@ucbvax.Berkeley.EDU> Reply-To: davew@gvgpsa.UUCP (David C. White) Organization: Grass Valley Group, Inc., Grass Valley, CA Lines: 16 In article <8712110937.AA06638@ucbvax.Berkeley.EDU> TS0400@OHSTVMA.BITNET (Bob Dixon) writes: >We are using Proteon routers with tcp/ip and decnet today, and very >successfully. We are using the Vitalink T1 type bridges, because we have several sites scattered around the Grass Valley/Nevada City area, and we are using TCP/IP, DECnet, XNS, 3Com, and some strange TCP/IP stuff occasionally output by our Cadnetix workstations and everthing passes transparently through the Vitalinks with no problems. We also have a DEC Lanbridge stuck in between two of of networks and it seems to be able to pass all of the above protocols also. -- =================================================================== Dave White Grass Valley Group, Inc. P.O. Box 1114 Grass Valley, CA 95945 UUCP: ...!tektronix!gvgpsa!davew PHONE: +1 916 478 3052 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1969@geac.UUCP] <1987121413332100> From: daveb@geac.UUCP (David Collier-Brown) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP protocol on a chip(s) Summary: Its been done for other protocols... Keywords: Faster IP? MNP chip Message-ID: <1969@geac.UUCP> Date: 14 Dec 87 13:33:21 GMT Article-I.D.: geac.1969 Posted: Mon Dec 14 08:33:21 1987 References: <4994@elroy.Jpl.Nasa.Gov> Reply-To: daveb@geac.UUCP (David Collier-Brown) Organization: The little blue rock next to that twinkly star. Lines: 45 In article <4994@elroy.Jpl.Nasa.Gov> david@elroy.Jpl.Nasa.Gov (David Robinson) writes: > >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. >... >To increase TCP/IP performance has anyone looked into making an IP >protocol chip or chipset? I don't know about IP, but several protocols have been put into modem controllers. One I know of in some detail is MNP, an combined sync/async facility with Network, Host-host and Applications layers (ie, it fits the ARM). It explicitly does **not** consider routing or network management, as it is restricted to running on a circuit-switched line. Another is the telebit "UUCP emulation" facility in their high-speed modems. >... 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. Neither of the above runs on an unprogrammable chip: even the chip-level MNP being developed by two people on this net has a z80 as part of the silicon. If one restricts the chipset to doing what it is good at and passing the administrivia off to a large host to do what **it** is good at, you have a viable project. Deciding exactly what to put on the chip is a design/marketing (ie $) issue. > >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 I think its a **good** idea. I also think it can be done "inexpensively". --dave (It's almost an old idea...) c-b -- 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121416424100> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Tue 15 Dec 87 06:39:51-PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA09564; Tue, 15 Dec 87 06:20:26 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Dec 87 16:42:41 GMT From: tektronix!dennist@ucbvax.Berkeley.EDU (Dennis Thomas) Organization: Tektronix, Inc., Beaverton, OR. Subject: AT&T ISN Message-Id: <12512@tektronix.TEK.COM> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712141737.AA16593@monk.proteon.com] <1987121417371000> From: mac@MONK.PROTEON.COM (Michael A. Curtis) Newsgroups: comp.protocols.tcp-ip Subject: Proteon Routers.. Message-ID: <8712141737.AA16593@monk.proteon.com> Date: 14 Dec 87 17:37:10 GMT References: <19521@amdcad.AMD.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Percy, If you would like to get in touch a Proteon salesman, try 408-562-6100. You may want to talk to Bruce Harrison or Michael Tezak. If you would like to talk to the Regional Manager, his name is Dave Buchanan. The reason you didn't get a response is twofold: 1) I was out of town. 2) We typically don't respond to general messages on the internet as we feel this is a conversation between users. I guess that's because we are somewhat of a conventional company and still make a lot of use of the phone. BTW, the Proteon home office number is 617-898-2800. Best regards, Michael A. Curtis Proteon, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712141813.AA00187@hoquiam] <1987121418131700> From: don@SRI-LEWIS.ARPA (Donald Holman) Newsgroups: comp.protocols.tcp-ip Subject: Final comments, Rabid Bite. Message-ID: <8712141813.AA00187@hoquiam> Date: 14 Dec 87 18:13:17 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 173 To the collective body: I recently sent a note out requesting information on a few (4) items of interest which appeared to lack a clear standard solution. These were SLIP Link establishment, setting the security bit in the IP header, routing metric determination and DDN Leased lines. Below is a summary of the several comments I received pertaining to all but DDN Leased lines. 1) SLIP LINK ESTABLISHMENT Comment summary: --------------------- From: Charles Hedrick alias hedrick@athos.rutgers.edu - About routing. Most protocols allow the system administrator to set the link cost. Even RIP now allows this. The algorithm is still the same as min hop, but you can in effect simulate a certain line counting as more than one hop. This lets you take into account cost, line speed, or whatever. DECnet has been doing this for years, as have various similar protocols. From: Bill Graves alias Graves@mathcom.cisco.com - cisco Systems has developed a SLIP server which performs negotiation for IP addresses. This server is presently in alpha test and is being prepared for shipping as a standard feature of their terminal servers. From: James B. VanBokkelen alias JBVB@AI.AI.MIT.EDU - there was interest expressed in a Birds Ofa Feather session hospitality suite in just this issue. This BOF consisted of considerable discussion of what to do next, and there were some basic agreements reached regarding direction and basic structure. There is a new mailing list being formed to discuss /evolve/resolve serial lines and dialup IP. From: Russ Hoby alias ccruss@deneb.ucdavis.edu - The BOF was too large to get any protocol work done, however various input was received with regard to potential uses of SLIP. One use is the connection of isolated computers without access to a LAN. The second is SLIP in support of temporary network links. Some work was done toward and RFC, this is what was covered: 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. From: Michael A. Patton alias map@GAAK.LCS.MIT.EDU - There was an extensive session at the "High Speed SLIP" demonstration at which an upgraded SLIP was designed. I believe that Drew Perkins (ddp+@Andrew.CMU.EDU) is going to write up an RFC for it. MY COMMENTS (for what they are worth): I missed the BOF session, and thus am not well read-in on what specifically has been proposed or what was considered for the RFC. Can I get more information on what was discussed? I am interested in the IP address validation & data compression techniques and the general content of the RFC. I would appreciate anything that is passed in my direction pertaining to SLIP. 2) SETTING THE IP SECURITY OPTION Comment summary: --------------------- From: Bill Graves alias Graves@mathcom.cisco.com - This is probably a key management issues and should be referred to the appropriate government agency as they are the only ones able to authorize the setting of this bit. From: Michael A. Patton alias map@GAAK.LCS.MIT.EDU - The problem is that if you let the application set it arbitrarily, then it doesn't offer security (everybody just turns it on), it needs to be connected with some security mechanism in the hosts, and you have to trust the security of ALL the hosts. From: John A. Shriver alias jas@monk.proteon.com - Our security features (in the p4200) do NOT depend on the IP security option. They depend on origins and destinations. You specify two masks, two results, and a sense. The source and destination are and-ed with the appropriate mask (a 32-bit integer). This is then compared to the results. If both results match, the packet is (or is not) forwarded as per the sense. This appeared to be as all-encompassingly flexible as we could imagine without being lethal to performance. MY COMMENTS (for what they are worth): Since there will be a real security requirement sooner than most would like, this is something that should be resolved ASAP. I agree that there are some real headaches when one begins to consider security. I tend to believe that the upper layer protocols MUST have the mechanics for passing this information to the network layer (anyone done this?). I realize the implications of adding this to the the upper layers, but if the IP security bit is the way to go the setting of the bit has to be supported. I agree that as soon as this is supported that every hacker and their brother will be TRYING to use this as a way of breaking into a secure system. It seems to me that this bit (in the IP header) is not really for security but is to assist in the routing and or discrimination of the datagram. The only real security might be network isolation via some form of encryption. 3) ROUTING METRICS. Comment summary: --------------------- From: Bill Graves alias Graves@mathcom.cisco.com - Routing metrics are an exceedingly complex set of issues and cannot be effectively addressed in this message. From: Paul F. Tsuchiya alias tsuchiya@gateway.mitre.org - The techniques for routing with something more sophisticated than hop-count are well known. ARPANET uses a delay calculation which many people, including myself, believe is over-kill in the sense that the filtering required on the delay measurements to avoid oscillations wipes out most of the benefit gained. The current IS-IS (gateway to gateway) routing proposal in ISO uses a static value that can mean anything the system administrator wants. It usually is related to the bandwidth of the link. The IS-IS protocol uses this value in its update messages if the link is up, or declares it down otherwise. Finally, BBN has done a fair amount of work in the area of multiple metrics (Type of Service routing). From: Michael A. Patton alias map@GAAK.LCS.MIT.EDU - cisco systems uses a much more elaborate scheme (I believe it's a five dimensional metric, and hop count isn't one of them). From: Ross Callon alias rcallon@PARK-STREET.BBN.COM - 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. The IS to IS routing proposal being developed by the X3S3.3 folks also uses administratively set costs. BBN is intending to publish a description of their SPF, while there is a semi available version of the ANSI proposal. From: John A. Shriver alias jas@monk.proteon.com - DECnet uses cost as a metric of goodness. They also keep a hop count, but this exists SOLELY to implement the count-to-infinity speedup on the routing loops that form in broadcast routing protocols when a node goes away. The same logic exists in the ANSI IS-IS proposal to ISO, which is essentially DECnet Phase V. MY COMMENTS (for what they are worth): It seems to me that (simply stated) if the best route can be determined the best route should be used. I don't argue with the complexity of determining the best route. I am minimally aware of the five determining factors which cisco Systems uses in route selection (from what I know of this five factor method it seems sound, it would be nice if it had broader support thru the community). I guess that the best of all worlds would be nice, what about a standard? To be capable of garnishing the route determination with a mix of all information available would be the best way to go as long as looping is avoided and the overhead of doing so is not a burden. It would seem to me that 6 or 7 of the items mentioned below would be good input for route selection, but then again I have not considered this for long and may be in left field. MINIMUM_HOP BANDWIDTH MINIMUM_DELAY MINIMUM_MTU FRAGMENTATION_REQUIRED RELIABILITY ADMINISTRATIVE DISTANCE I will looking forward to any published information on routing algorithms (hope it becomes available to the general public soon). Thanks for the time spent on responses! The thoughts and comments within, unless specified, are my own. TIA, Don ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712150202.AA06187@bacchus.dec.com] <1987121502025800> From: mogul@DECWRL.DEC.COM (Jeffrey Mogul) Newsgroups: comp.protocols.tcp-ip Subject: Re: Determining gateway buffer capacity Message-ID: <8712150202.AA06187@bacchus.dec.com> Date: 15 Dec 87 02:02:58 GMT References: <8712110823.AA05126@uc.msc.umn.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: DEC Western Research Lines: 58 In article <8712110823.AA05126@uc.msc.umn.edu> Stuart Levy writes: 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. Yet another one of the points Chris Kent and I covered in our paper "Fragmentation Considered Harmful", presented at SIGCOMM '87. (Proceedings should be available, as an issue of CCR, in early 1988; Chris and I have also produced a slightly revised version that will be available as a DECWRL Technical Report at about the same time.) In our paper, we proposed two different ways (use of IP options, or use of a separate ``Probe'' protocol) to gather the following information about a path (as opposed to a single gateway, which would be an interesting thing as well, but probably not quite as useful. Probing the path periodically should resolve most multipath problems): Minimum MTU Minimum bandwidth Maximum delay (intrinsic, not queueing) Maximum (gateway) queue length Maximum error rate Hop count This kind of info would let a protocol implementation control such things as datagram size, rate of packet injection, rate of total data injection, use of forward error correction, perhaps better RTT estimates, etc. I think this is a good idea, but realize that it might not be feasible to retrofit the existing Internet, or enough of it to make a difference. At some point, the proposal in our paper should be turned into a couple of RFCs. Anyone who would rather write an RFC than wait for us to do it, please go ahead! -Jeff P.S.: someone recently complained that probes don't work because paths are asymmetric. Our proposals, as well as those made by others, are ``round-trip'' rather than one way; if the probes follow the same route that the useful packets follow, asymmetry is not a problem. If the path were known to be symmetric, the information would be available 1/2 RTT sooner, but the kinds of things we want to probe for are not meant to vary that rapidly. (Reported queue lengths might have to be smoothed before using them in a congestion-control method.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712150435.AA20059@tcgould.TN.CORNELL.EDU] <1987121504352000> From: alison@TCGOULD.TN.CORNELL.EDU (Alison Brown) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP protocol on a chip(s) Message-ID: <8712150435.AA20059@tcgould.TN.CORNELL.EDU> Date: 15 Dec 87 04:35:20 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Chesson is indeed working on a protocol engine, but the protocol to be put into the chip is in no way IP (DoD IP as in TCP/IP), at least as I understand what they are doing. The high speeds they want to attain require a lighter weight protocol than anything defined as a standard today, from what I can gather..... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [299714.871215.PAP4@AI.AI.MIT.EDU] <1987121506312700> From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") Newsgroups: comp.protocols.tcp-ip Subject: Re: Determining gateway buffer capacity Message-ID: <299714.871215.PAP4@AI.AI.MIT.EDU> Date: 15 Dec 87 06:31:27 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 [ Probing gateways for MTU and transmission characteristics ] I think this is a good idea, but realize that it might not be feasible to retrofit the existing Internet, or enough of it to make a difference. -Jeff Certainly some of the regional networks might be interested in experimenting with it to measure effects. A lot of the Internet is still growing -- it would be less trouble to build it into the new networks... And me, I love to tinker. -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [299725.871215.PAP4@AI.AI.MIT.EDU] <1987121506521100> From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") Newsgroups: comp.protocols.tcp-ip Subject: Re: beginners guide to ... ? Message-ID: <299725.871215.PAP4@AI.AI.MIT.EDU> Date: 15 Dec 87 06:52:11 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 My apologies for being ambiguous -- apparently I left some people in doubt. The new Comer book is unrelated to the Xinu series... -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712141019.aa12180@Dewey.UDEL.EDU] <1987121507260800> From: parulkar@UDEL.EDU (Gurudatta Parulkar) Newsgroups: comp.protocols.tcp-ip Subject: Re: beginners guide to ... ? Message-ID: <8712141019.aa12180@Dewey.UDEL.EDU> Date: 15 Dec 87 07:26:08 GMT References: <298390.871212.PAP4@AI.AI.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 (plug, plug, plug) > > Doug Comer ("Xinu", et al) is writing a book about Internetworking, > pretty much outside of the context of an operating system, though he > does talk briefly about 4.3BSD (sockets and utilites). The book > is fairly exhaustive, and seems to be a timely replacement for > the Tanenbaum book (is it still being printed with NCP references?). I believe Tanenbaum's book's Second edition is also coming out very soon. Of course, it wouldn't have as much on ARPA internet as Comer's book. (As per the local Prentice Hall Representative) -guru parulkar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712150730.AA19137@sccgate.scc.com] <1987121507305200> From: oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) Newsgroups: comp.protocols.tcp-ip Subject: Suspected problem with new end-to-end Message-ID: <8712150730.AA19137@sccgate.scc.com> Date: 15 Dec 87 07:30:52 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 69 We've observed a problem with our gateway's interaction with the Arpanet and we believe that the problem might be associated with the end-to-end upgrade since it was not observed prior to the current end-to-end testing period. We realize that the end-to-end testing was scheduled to end on Dec. 13 and that all of our tests were made on Dec. 14 but something is not as it used to be and the new end-to-end is our best guess as to the cause. Regardless of the culprit, the problem exists and can be repeatably demonstrated. The problem arises when certain net 10 hosts establish connections to our gateway which require that a new X.25 virtual circuit be established. The connection is made, an X.25 virtual circuit is established, one (1) packet is received and the connection hangs. When the circuit is timed out due to inactivity, it is immediately reestablished and another packet is received. Any outbound traffic from our gateway that uses that virtual circuit will free it up and traffic will commence flowing from the remote node. In our tests we used one (1) ICMP echo-request to free the hang-ups. Our gateway (SCCGATE-GW.SCC.COM) is a Sun-3 running Sun's 3.4 OS and Sun's DDN X.25 software. We are connected to port 11 on PSN 20. Sun supplied a virtual circuit monitor as part of their DDN package which we used in our tests. This monitor displays all of the X.25 circuits between our Sun and the PSN. The display consists of the locally assigned circuit number (which indicates whether the circuit was initiated locally or remotely), the current state of the circuit, the number of packets sent, the number of packets received, and the IP address of the net 10 destination. An X.25 line monitor would be a better tool but we do not have access to one. In order to reproduce the problem, we send traffic to destinations via routes that differ from the remote system's idea of the route to us. For instance, when we Telnet to the Milnet address of SRI-NIC.ARPA, the return traffic comes from their Arpanet interface. The following table summarizes our test results to date: Destination Name and Address | Outbound VC | Inbound VC | Hangs? --------------------------------+---------------+---------------+------ twg.arpa 26.5.0.73 | 10.7.0.20 | 10.4.0.51 | Yes sri-nic.arpa 26.0.0.73 | 10.7.0.20 | 10.0.0.51 | Yes dugway-mil-tac. 26.0.0.120 | 10.7.0.20 | 10.5.0.5 | Yes sac-milnet-gw.a 26.0.0.105 | 10.7.0.20 | 10.2.0.80 | Yes arpa-milnet-gw. 26.0.0.106 | 10.7.0.20 | 10.2.0.28 | Yes milnet-gw.isi.e 26.0.0.103 | 10.7.0.20 | 10.2.0.22 | Yes enet1-gw.bbn.co 8.5.0.18 | 10.4.0.82 | 10.2.0.5 | Yes egp-gate.mitre. 128.29.31.2 | 10.1.0.111 | 10.5.0.111 | Yes gateway.mitre.o 128.29.31.10 | 10.5.0.111 | 10.1.0.111 | Yes violet.berkeley 128.32.136.22 | 10.2.0.78 | 10.0.0.78 | Yes bikini.cis.ufl. 128.277.2.1 | 10.8.0.20 | 10.9.0.20 | No bikini.cis.ufl. 128.277.2.1 | 10.1.0.17 | 10.9.0.20 | No terp.umd.edu 128.8.10.90 | 10.8.0.20 | 10.1.0.17 | No trantor.umd.edu 128.8.10.14 | 10.1.0.17 | 10.8.0.20 | No In case our explanation was not too clear, I'll describe a test scenario. After insuring that a VC to 10.4.0.51 did not exist, we would ping twg.arpa. We would receive 1 echo-reply and the newly created VC to 10.4.0.51 would show 1 packet received. The outbound counter on the VC to 10.7.0.20 would steadily increment as the ping program continued. If we simply sat and watched, eventually the VC to 10.4.0.51 would time out and be removed. A new VC to 10.4.0.51 would be created immediately thereafter and we would then receive another echo-reply from twg.arpa. This new VC would also show 1 packet received. If we sent as little as 1 echo-request to 10.4.0.51, the flood-gates would open and traffic would flow normally. We believe that this problem could explain some of the recent comments about network troubles in tcp-ip. For instance, Eric Johnson's mail delivery problems to violet.berkeley.edu from hosts in cis.ufl.edu. I wish we could explain the cause of the problem instead of just describing symptoms but that's all our current resources allow. Bob & Mike Bob Enger enger@bluto.scc.com Mike O'Connor oconnor@sccgate.scc.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121510053100> Received: from sccgate.scc.com by SRI-NIC.ARPA with TCP; Tue 15 Dec 87 12:11:52-PST Received: by sccgate.scc.com (4.0/870914.1{Enger}) id AA20424; Tue, 15 Dec 87 15:05:31 EST Date: Tue, 15 Dec 87 15:05:31 EST From: oconnor@sccgate.scc.com (Michael J. O'Connor) Message-Id: <8712152005.AA20424@sccgate.scc.com> To: tcp-ip@sri-nic.arpa Subject: Further info on our X.25 problem Cc: arpaupgrade@bbn.com, brescia@bbn.com, enger@bluto.scc.com Dave Mills reports that the two Umdnet gateways that we used for testing are X.25 machines. Allison Mankin reports that the two Mitre machines that we used are 1822. Since the Mitre machines exhibit the problem and the UMD machines do not, it is our early suspiciion that the problem only occurs when 1822 machines attempt connections to X.25 machines over asymetric routes. We are trying to discover the flavor of interface used by all the other machines we ran tests through. The fact that sending a single packet out the jammed VC will free it, might indicate that somewhere in the 1822 to X.25 conversion, a piece of code is patiently awaiting some indication that the circuit is alive before pumping the data on through. Dave suggested some more machines to test with (I'm sure at least one is a fuzzball) and we'll give them a try. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121512120000> Received: from bluto.scc.com by SRI-NIC.ARPA with TCP; Tue 15 Dec 87 14:26:05-PST Date: 15 Dec 87 17:12:00 EST From: "GBURG::ENGER" Subject: rooting around down in the x.25 To: "malis" cc: oconnor@sccgate,melohn@sun.com, nowicki@sun.com,arpaupgrade@cc5.bbn.com, tcp-ip@sri-nic.arpa,enger Andy: Unfortunately we don't have the equipment to "get down" and muck around at the x.25 levels. Your questions will have to be answered by the implementers of the x.25 code that we run, Messrs. Melohn and Nowicki of Sun. It occurs to me that somehow, BBN must learn to work more closely with the researchers and vendors that use the facilities that the government is paying for. Somehow, BBN should provide more information on how its interfaces function, and what to expect from them. Two recent examples of misunderstanding come to mind. One is Bill Melohn's comment that he is now receiving x.25 control messages from the PSN that have never been seen before, and that his code is unprepared for. The other example is the comment made by Mike Karels that BSD unix makes use of the PSN going down time messages sent to him on 1822 (??). The BBN spokesperson with whom he was speaking indicated that the time values are not to be trusted, and probably shouldn't be used for anything usefull. I cannot claim to be knowledgable on these subjects, but they do seem to indicate that the (very) responsible people involved in interfacing a large portion of all machines used to connect to the DDN have not been provided with all the information that BBN could make available. If the government (and ultimately us, the taxpayers) are going to get our moneys worth out of all of this investment in equipment, trunking, and labor, it would seem that we must start to provide avenues of meaningfull technical exchange between the parties on each end of the PSN access circuits. It seems rediculous to waste engineering time "guessing" at how to engineer ones interface to the PSN. Best wishes, Bob Enger ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3209@tut.cis.ohio-state.edu] <1987121513412000> From: verber@tut.cis.ohio-state.edu (Mark A. Verber) Newsgroups: comp.protocols.tcp-ip Subject: Re: beginners guide to ... ? Message-ID: <3209@tut.cis.ohio-state.edu> Date: 15 Dec 87 13:41:20 GMT References: <298390.871212.PAP4@AI.AI.MIT.EDU> Organization: Ohio State University, Computer Science Lines: 13 Doug Comer's book is already out. It's title is Operating System Design Volume II: Internetworking with Xinu. In my opinion it is the best book for someone to learn about the TCP/IP protocol suite from the ground up. Doug has once again put out a book which is highly readable. This book is also the reference manual for Xinu volume 7 which is running on Sun3, Macs, and Vaxen. Cheers, ----------------------------------------------------------------------- Computer Science Department Mark A. Verber The Ohio State University verber@ohio-state.arpa +1 (614) 292-7344 cbosgd!osu-cis!verber ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121514010400> Received: from ccq.bbn.com by SRI-NIC.ARPA with TCP; Tue 15 Dec 87 16:12:34-PST Date: Tue, 15 Dec 87 19:01:04 EST From: Ken Pogran Subject: An ARPANET update To: TCP-IP@sri-nic.arpa Cc: pogran@ccq.bbn.com Several problems with regard to the New End-to-End Protocol deployed on the ARPANET with PSN Release 7 were discussed in messages to this list over the past couple of days. Here's a report on what we at BBN have uncovered so far. We are working on three general problems and one problem that is specific to a particular host. The "general" problems affect communication with some hosts (including some gateways) connected to the ARPANET with X.25 interfaces. 1. The "one packet problem." The scenario has been described by several folks, and runs about like this: An 1822-connected gateway has traffic for an X.25-connected host. Sending the first datagram into the net causes an X.25 VC to be opened to the destination host. One and only one packet is received by the host, and the flow stops. Various events can cause the flow to become "unblocked", such as sending traffic FROM the host back over the same VC. This problem has been observed with several, but by no means with all, DDN Standard X.25 implementations. This problem has especially been seen in situations where an X.25-connected ARPANET host establishes communication with a MILNET host (or vice-versa). In this situation, because of the Mailbridge "homing rules", traffic often flows across a different Mailbridge in each direction. Thus, user data flow is essentially unidirectional across each of two VCs. With other patterns of communication, a symmetric, bidirectional user data flow would generate one of those "events" that seems to "unblock" the flow over the VC. This problem is not observed in communication between pairs of hosts that are BOTH X.25-connected, or BOTH 1822-connected, or in situations where the X.25-connected host initiates the VC. It can arise when a host with a connection-less (i.e., 1822) interface initiates communication with a host with a connection-oriented (i.e., X.25) interface and "the network" has to initiate the connection. We believe that what's happening here is that the receiving host's X.25 isn't sending an RR to the PSN for the first data packet it receives when the PSN opens the VC. Under the New End-to-End Protocol, when going from an 1822-connected host to an X.25-connected host, the PSNs wait to see an RR for the first packet before subsequent packets are sent from the source PSN to the destination PSN (and a RFNM is returned to the originating 1822-connected host). Under the Old End-to-End Protcol, subsequent packets were sent as soon as the receiving host accepted the VC (up to the limit of the window); this could result in a RFNM being sent to the originating host before the destination host actually acknowledged the packet via an RR! (The different behavior of the New End-to-End was intended as a fix for what was a bug, or perhaps a "cheat", in the old design with respect to the meaning of a RFNM.) In the case of a symmetric traffic flow, an RR is typically piggybacked on a data packet. But, as was mentioned above, traffic flows involving Mailbridges frequently aren't symmetric. Typically, X.25 implementations send an RR after some brief timeout if there's no user packet going out over the VC on which to piggyback the RR. But if there is neither traffic nor a timeout, and no RR is sent, the flow will cease as described above. We're going to change the PSNs to behave as they did under the Old End-to-End in this regard, at least temporarily. This will give us time to work with implementors to resolve this issue. 2. The "pinging yourself" problem. We've found a timing bug in the PSN that is sometimes triggered when a host "pings" itself. Other situations can trigger it, but the timing of the sequence of events that occurs when some hosts ping themselves seems to be the most conducive to triggering the bug. The result is that the PSN doesn't acknowledge delivery of one or more messages to the host in question. We've found a race condition in the PSN code. A fix for this bug will be installed in the ARPANET within the next day or so. 3. The "multiple of 128 bytes" problem. Several people have reported a problem with packets apparently being dropped by the network when they are a multiple of 128 bytes (perhaps +/- a few?) in length. We are actively investigating this problem. Anyone with data or insight with regard to this is encouraged to contact Andy Malis (Malis@bbn.com) or ARPAUPGRADE@bbn.com. 4. The gateway at Yale has mostly been off the net since the cutover to the New End-to-End Protocol. They are the only gateway connected to the ARPANET via an HDH interface running at 9.6 kb/s, and are the only ones experiencing this particular problem. We believe there is a PSN bug that we haven't been able to find yet; so far, we have been unable to duplicate this problem in our lab. In the meantime, we have developed a work-around that will enable Yale to be up on the ARPANET while we work to find and fix the bug. We apologize for the inconvenience, and thank the folks at Yale for their patience and understanding. Finally, implementors have asked if they can be included on the "ARPAUPGRADE" mailing list. We use this list as a "hot line" for getting information from the community to us and to DCA, and for internal discussion about the problems. The idea of having an implementor's mailing list is a good one, however, and we will shortly set up a new list for those who are actively helping us track down these various problems. Please keep those cards and letters coming! Regards, Ken Pogran BBN COMMUNICATIONS CORPORATION ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712151436.aa15545@Huey.UDEL.EDU] <1987121519365400> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Timewarps, virtual-cirkosis and other twitches Message-ID: <8712151436.aa15545@Huey.UDEL.EDU> Date: 15 Dec 87 19:36:54 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 207 Folks, As I have been heard to mutter from time to time (pun), watching local clocks reveals all kinds of interesting information about network congestion and routing flaps. At the end of this message is a summary of clock flaps recorded over the last couple of weeks at fuzzball host udel2, which is synchronized via the Network Time Protocol (NTP) to WWVB-clock fuzzball umd1 across 1822 gateway dcn-gw, ARPANET and one or the other X.25 gateways at U Maryland. At issue are the Maryland gateways, which carry a lot of traffic between the NSFNET and ARPANET communities and are vulnerable to X.25 virtual-cirkosis, which occurs when the virtual-circuit demand exceeds the maximum of 64 supported by their ACC 5250 interface and driver. Under conditions of severe congestion packets may be dropped or delayed for relatively long periods, which mean relative clock offsets measured by NTP will become unstable, exceeding even the cope of the sophisticated median-filtering and smoothing algorithms used by the fuzzballs. When this happens a timewarp (step-change in local time) occurs, which is then logged for later analysis. It should be understood that timewarps over noncongested paths, including most NSFNET, ARPANET and local paths, are extremely rare and, when they do occur, very serious congestion, delay spikes and/or black holes are occuring. Over the last two weeks timewarps between udel2 and umd1 have been occuring with increasing frequency. Casual ping reveals occasional severe congestion and packet loss across the Maryland gateways, but relatively smooth sail on other paths within the NSFNET, ARPANET and local sloughs. The pattern of congestion suggests that black holes pop up between the gateways and specific destinations and then disappear after a few minutes. This is exactly the pattern expected when virtual-cirkosis strikes. Black holes would be expected to affect low-traffic hosts more than high-traffic ones, which tend to recapture virtual circuits more quickly. This problem threatens to become the single most damaging factor affecting quality service between the NSFNET and ARPANET communities. Warnings about the problem have been issued on a regular basis since early October, when the problem first showed up at another gateway. There is no doubt that its incidence can be reduced by spreading the NSFNET/ARPANET load over more gateways and, in fact, additional gateways are already in place, but not configured for this function. Clearly the ACC 5250 and/or driver must be overhauled to provide either more circuits or more creative management of the existing number. Solutions for the driver problem, which involve cache-management and replacement strategies familiar to any student of computer science, have not been forthcoming. There is very real need to capture resources, voluntary or coerced, to assist in the solution. The data below will give some idea of the incidence of the problem, time of occurance and severity. It may be possible for other users to correlate these data with their local logs and trouble reports to see if the pattern matches. Remember, these data reveal only the most severe disturbances. Many, less severe disturbances are also affecting connections. 20:37:22 012 ?TRAP-I-Clock reset 4 1130 30-Nov-87 20:46:26 012 ?TRAP-I-Clock reset 4 846 30-Nov-87 21:52:41 012 ?TRAP-I-Clock reset 4 1000 30-Nov-87 22:01:48 012 ?TRAP-I-Clock reset 4 653 30-Nov-87 4 flaps 4:32:12 012 ?TRAP-I-Clock reset 4 920 02-Dec-87 4:55:17 012 ?TRAP-I-Clock reset 4 659 02-Dec-87 5:22:33 012 ?TRAP-I-Clock reset 4 641 02-Dec-87 22:24:29 012 ?TRAP-I-Clock reset 4 992 02-Dec-87 22:33:14 012 ?TRAP-I-Clock reset 4 634 02-Dec-87 23:28:00 012 ?TRAP-I-Clock reset 4 737 02-Dec-87 6 flaps 5:26:20 012 ?TRAP-I-Clock reset 4 637 03-Dec-87 5:28:52 012 ?TRAP-I-Clock reset 4 1200 03-Dec-87 6:33:57 012 ?TRAP-I-Clock reset 4 627 03-Dec-87 6:36:36 012 ?TRAP-I-Clock reset 4 628 03-Dec-87 7:35:26 012 ?TRAP-I-Clock reset 4 1188 03-Dec-87 7:46:40 012 ?TRAP-I-Clock reset 4 647 03-Dec-87 12:46:36 012 ?TRAP-I-Clock reset 4 1088 03-Dec-87 12:55:39 012 ?TRAP-I-Clock reset 4 639 03-Dec-87 16:10:01 012 ?TRAP-I-Clock reset 4 937 03-Dec-87 22:11:06 012 ?TRAP-I-Clock reset 4 753 03-Dec-87 22:29:25 012 ?TRAP-I-Clock reset 4 691 03-Dec-87 22:37:21 012 ?TRAP-I-Clock reset 4 659 03-Dec-87 23:30:55 012 ?TRAP-I-Clock reset 4 717 03-Dec-87 13 flaps 2:35:37 012 ?TRAP-I-Clock reset 4 1212 04-Dec-87 2:35:56 012 ?TRAP-I-Clock reset 4 674 04-Dec-87 3:02:18 012 ?TRAP-I-Clock reset 4 785 04-Dec-87 3:33:11 012 ?TRAP-I-Clock reset 4 873 04-Dec-87 3:35:49 012 ?TRAP-I-Clock reset 4 6527 04-Dec-87 3:35:59 012 ?TRAP-I-Clock reset 4 872 04-Dec-87 3:36:31 012 ?TRAP-I-Clock reset 4 11793 04-Dec-87 3:36:41 012 ?TRAP-I-Clock reset 4 829 04-Dec-87 3:39:03 012 ?TRAP-I-Clock reset 4 810 04-Dec-87 4:48:35 012 ?TRAP-I-Clock reset 4 741 04-Dec-87 4:52:18 014 ?TRAP-I-Clock reset 3 1000 04-Dec-87 7:36:38 012 ?TRAP-I-Clock reset 4 675 04-Dec-87 18:17:08 012 ?TRAP-I-Clock reset 4 680 04-Dec-87 19:22:46 012 ?TRAP-I-Clock reset 4 663 04-Dec-87 14 flaps 1:40:42 012 ?TRAP-I-Clock reset 4 649 05-Dec-87 5:12:26 012 ?TRAP-I-Clock reset 4 660 05-Dec-87 5:19:16 012 ?TRAP-I-Clock reset 4 633 05-Dec-87 17:04:36 012 ?TRAP-I-Clock reset 4 660 05-Dec-87 (Saturday) 4 flaps 21:41:11 012 ?TRAP-I-Clock reset 4 3409 06-Dec-87 21:50:22 012 ?TRAP-I-Clock reset 4 832 06-Dec-87 23:55:00 012 ?TRAP-I-Clock reset 4 2142 06-Dec-87 (Sunday) 3 flaps 0:04:26 012 ?TRAP-I-Clock reset 4 652 07-Dec-87 1:24:14 012 ?TRAP-I-Clock reset 4 3407 07-Dec-87 1:33:22 012 ?TRAP-I-Clock reset 4 646 07-Dec-87 2:38:18 012 ?TRAP-I-Clock reset 4 2308 07-Dec-87 2:47:27 012 ?TRAP-I-Clock reset 4 665 07-Dec-87 3:48:37 012 ?TRAP-I-Clock reset 4 2844 07-Dec-87 3:58:05 012 ?TRAP-I-Clock reset 4 638 07-Dec-87 8:20:53 012 ?TRAP-I-Clock reset 4 3185 07-Dec-87 8:30:38 012 ?TRAP-I-Clock reset 4 622 07-Dec-87 9:20:32 012 ?TRAP-I-Clock reset 4 3310 07-Dec-87 9:29:59 012 ?TRAP-I-Clock reset 4 657 07-Dec-87 17:28:46 012 ?TRAP-I-Clock reset 4 405 07-Dec-87 17:29:18 014 ?TRAP-I-Clock reset 3 1000 07-Dec-87 18:47:11 012 ?TRAP-I-Clock reset 4 1624 07-Dec-87 18:55:58 012 ?TRAP-I-Clock reset 4 656 07-Dec-87 19:30:38 012 ?TRAP-I-Clock reset 4 926 07-Dec-87 20:12:21 012 ?TRAP-I-Clock reset 4 654 07-Dec-87 20:24:29 012 ?TRAP-I-Clock reset 4 1081 07-Dec-87 20:33:43 012 ?TRAP-I-Clock reset 4 636 07-Dec-87 19 flaps 16:08:28 012 ?TRAP-I-Clock reset 4 1547 08-Dec-87 16:16:37 012 ?TRAP-I-Clock reset 4 666 08-Dec-87 2 flaps 3:43:00 012 ?TRAP-I-Clock reset 4 1159 09-Dec-87 3:52:06 012 ?TRAP-I-Clock reset 4 665 09-Dec-87 7:22:50 014 ?TRAP-I-Clock reset 3 1000 09-Dec-87 7:24:07 012 ?TRAP-I-Clock reset 4 1263 09-Dec-87 7:33:04 012 ?TRAP-I-Clock reset 4 658 09-Dec-87 16:16:41 014 ?TRAP-I-Clock reset 3 1000 09-Dec-87 16:37:08 012 ?TRAP-I-Clock reset 4 1234 09-Dec-87 16:46:53 012 ?TRAP-I-Clock reset 4 660 09-Dec-87 17:27:01 012 ?TRAP-I-Clock reset 4 1261 09-Dec-87 17:35:10 012 ?TRAP-I-Clock reset 4 661 09-Dec-87 19:33:53 012 ?TRAP-I-Clock reset 4 1419 09-Dec-87 19:42:07 012 ?TRAP-I-Clock reset 4 967 09-Dec-87 19:52:34 012 ?TRAP-I-Clock reset 4 667 09-Dec-87 20:06:59 012 ?TRAP-I-Clock reset 4 1389 09-Dec-87 20:15:27 012 ?TRAP-I-Clock reset 4 634 09-Dec-87 15 flaps 1:19:09 012 ?TRAP-I-Clock reset 4 1200 10-Dec-87 1:28:19 012 ?TRAP-I-Clock reset 4 662 10-Dec-87 17:05:09 012 ?TRAP-I-Clock reset 4 669 10-Dec-87 21:37:20 012 ?TRAP-I-Clock reset 4 1223 10-Dec-87 21:48:40 012 ?TRAP-I-Clock reset 4 677 10-Dec-87 22:05:13 012 ?TRAP-I-Clock reset 4 3457 10-Dec-87 22:13:55 012 ?TRAP-I-Clock reset 4 673 10-Dec-87 7 flaps 1:59:20 012 ?TRAP-I-Clock reset 4 1668 11-Dec-87 2:07:31 012 ?TRAP-I-Clock reset 4 653 11-Dec-87 2:25:09 012 ?TRAP-I-Clock reset 4 1299 11-Dec-87 2:33:59 012 ?TRAP-I-Clock reset 4 650 11-Dec-87 4:43:39 012 ?TRAP-I-Clock reset 4 2021 11-Dec-87 4:52:44 012 ?TRAP-I-Clock reset 4 917 11-Dec-87 6:19:59 012 ?TRAP-I-Clock reset 4 2515 11-Dec-87 6:28:47 012 ?TRAP-I-Clock reset 4 1038 11-Dec-87 8 flaps 3:12:21 012 ?TRAP-I-Clock reset 4 892 12-Dec-87 3:23:19 012 ?TRAP-I-Clock reset 4 2437 12-Dec-87 3:29:57 012 ?TRAP-I-Clock reset 4 1269 12-Dec-87 3:39:08 012 ?TRAP-I-Clock reset 4 724 12-Dec-87 5:43:07 012 ?TRAP-I-Clock reset 4 629 12-Dec-87 5:49:06 012 ?TRAP-I-Clock reset 4 1134 12-Dec-87 6:11:27 012 ?TRAP-I-Clock reset 4 3019 12-Dec-87 6:11:45 012 ?TRAP-I-Clock reset 4 3020 12-Dec-87 6:18:56 012 ?TRAP-I-Clock reset 4 1251 12-Dec-87 6:27:43 012 ?TRAP-I-Clock reset 4 662 12-Dec-87 9:10:28 012 ?TRAP-I-Clock reset 4 1205 12-Dec-87 9:19:34 012 ?TRAP-I-Clock reset 4 696 12-Dec-87 14:01:31 012 ?TRAP-I-Clock reset 4 1101 12-Dec-87 14:10:35 012 ?TRAP-I-Clock reset 4 629 12-Dec-87 22:00:22 012 ?TRAP-I-Clock reset 4 1047 12-Dec-87 22:10:44 012 ?TRAP-I-Clock reset 4 722 12-Dec-87 23:07:13 012 ?TRAP-I-Clock reset 4 926 12-Dec-87 17 flaps 2:46:49 012 ?TRAP-I-Clock reset 4 1435 13-Dec-87 2:54:56 012 ?TRAP-I-Clock reset 4 647 13-Dec-87 5:20:21 012 ?TRAP-I-Clock reset 4 959 13-Dec-87 5:28:10 012 ?TRAP-I-Clock reset 4 871 13-Dec-87 5:37:37 012 ?TRAP-I-Clock reset 4 1201 13-Dec-87 5:49:14 012 ?TRAP-I-Clock reset 4 644 13-Dec-87 22:59:57 012 ?TRAP-I-Clock reset 4 2039 13-Dec-87 23:13:06 012 ?TRAP-I-Clock reset 4 819 13-Dec-87 23:24:59 012 ?TRAP-I-Clock reset 4 1316 13-Dec-87 23:47:33 012 ?TRAP-I-Clock reset 4 674 13-Dec-87 10 flaps 0:23:00 012 ?TRAP-I-Clock reset 4 1254 14-Dec-87 0:31:48 012 ?TRAP-I-Clock reset 4 1577 14-Dec-87 0:40:18 012 ?TRAP-I-Clock reset 4 669 14-Dec-87 1:34:40 012 ?TRAP-I-Clock reset 4 1375 14-Dec-87 1:43:28 012 ?TRAP-I-Clock reset 4 652 14-Dec-87 2:37:20 012 ?TRAP-I-Clock reset 4 3142 14-Dec-87 2:45:50 012 ?TRAP-I-Clock reset 4 656 14-Dec-87 2:46:09 012 ?TRAP-I-Clock reset 4 657 14-Dec-87 5:07:25 014 ?TRAP-I-Clock reset 3 1000 14-Dec-87 5:21:47 012 ?TRAP-I-Clock reset 4 650 14-Dec-87 15:53:09 012 ?TRAP-I-Clock reset 4 1231 14-Dec-87 16:04:25 012 ?TRAP-I-Clock reset 4 695 14-Dec-87 16:37:40 012 ?TRAP-I-Clock reset 4 1304 14-Dec-87 16:48:06 012 ?TRAP-I-Clock reset 4 889 14-Dec-87 16:59:06 012 ?TRAP-I-Clock reset 4 1855 14-Dec-87 17:22:23 014 ?TRAP-I-Clock reset 3 1000 14-Dec-87 19:49:59 012 ?TRAP-I-Clock reset 4 1486 14-Dec-87 19:58:27 012 ?TRAP-I-Clock reset 4 1000 14-Dec-87 18 flaps 1:22:00 012 ?TRAP-I-Clock reset 4 1508 15-Dec-87 1:29:50 012 ?TRAP-I-Clock reset 4 660 15-Dec-87 2:44:13 012 ?TRAP-I-Clock reset 4 1429 15-Dec-87 2:52:22 012 ?TRAP-I-Clock reset 4 1007 15-Dec-87 15:21:31 012 ?TRAP-I-Clock reset 4 1454 15-Dec-87 15:29:41 012 ?TRAP-I-Clock reset 4 665 15-Dec-87 16:51:20 012 ?TRAP-I-Clock reset 4 1724 15-Dec-87 17:00:28 012 ?TRAP-I-Clock reset 4 1060 15-Dec-87 17:58:35 012 ?TRAP-I-Clock reset 4 1431 15-Dec-87 18:08:36 012 ?TRAP-I-Clock reset 4 2431 15-Dec-87 18:19:03 012 ?TRAP-I-Clock reset 4 1080 15-Dec-87 11 flaps (so far) Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121519380000> Received: from bluto.scc.com by SRI-NIC.ARPA with TCP; Tue 15 Dec 87 21:46:19-PST Date: 16 Dec 87 00:38:00 EST From: "GBURG::ENGER" Subject: **** Medical Assistance Needed for Core Gateways **** To: "ietf" cc: tcp-ip@sri-nic.arpa,abauman@ddn1.arpa, gross@gateway.mitre.org,enger HO HO HO: Santa would like to bring the Internet better performance, but his elves are having a hard time finding the right parts. Three small, lonely, destitute EGP core gateways desperately need your help. Officially declared braindead years ago, these tenacious little guys have stubbornly clung to life. Although the respirator is scheduled to be pulled in about 6 months, you can improve the quality of their (and your!) life for the time remaining to them. Help give them a much needed brain transplant. Loan them your unused, probably unloved, LSI-11/73 CPU boards! Their little brothers and sisters, the mailbridges, would also benefit from this treatment. Won't you help? Please join Mike Petry and Louie Mamakos of U. of Md., the folks at BBN, who have upgraded the EGP core machines on the Arpanet, and CONTEL which has contributed an 11/73 to its local mailbridge. The three Milnet EGP core gateways, and the 6 or so remaining mailbridges need your charity. Won't you be a good Samaritan too? Search your surplus parts bins, locate your old unloved LSI 11-73's, blow the dust off and contact one of Santa's helpers listed below. * * * * * * * * * * * * * * * * * * * During this holiday season, instead of trying to give a thoughtful gift, give the gift of thought! Send some new brains to these deserving little machines. You'll be helping them, and your Internet response times. * * * * * * * * * * * * * * * * * * * We thank you for your support. Annette Bauman (abauman@ddn1.arpa) Phill Gross (gross@gateway.mitre.org) Bob Enger (enger@bluto.scc.com) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [319@cunixc.columbia.edu] <1987121519525800> From: alan@cunixc.columbia.edu (Alan Crosswell) Newsgroups: comp.protocols.tcp-ip Subject: Re: beginners guide to ... ? Message-ID: <319@cunixc.columbia.edu> Date: 15 Dec 87 19:52:58 GMT References: <298390.871212.PAP4@AI.AI.MIT.EDU> <8712141019.aa12180@Dewey.UDEL.EDU> Reply-To: alan@cunixc.columbia.edu (Alan Crosswell) Organization: Columbia University Lines: 175 In article <8712141019.aa12180@Dewey.UDEL.EDU> parulkar@UDEL.EDU (Gurudatta Parulkar) writes: > > (plug, plug, plug) >> >> Doug Comer ("Xinu", et al) is writing a book about Internetworking, >> pretty much outside of the context of an operating system, though he >> does talk briefly about 4.3BSD (sockets and utilites). The book >> is fairly exhaustive, and seems to be a timely replacement for >> the Tanenbaum book (is it still being printed with NCP references?). > >I believe Tanenbaum's book's Second edition is also coming out very >soon. Of course, it wouldn't have as much on ARPA internet as Comer's >book. (As per the local Prentice Hall Representative) > >-guru parulkar (unsolicited plug, but a plug just the same) You might also want to browse: Schwartz, Mischa. Telecommunication Networks: Protocols, Modeling and Analysis, Addison-Wesley, Reading, Mass., 1987. I like to read the protocol description sections and skip the modeling and analysis (aka queueing theory) parts :-) If you saw the grades I got a few years ago in Prof. Schwartz's modeling and performance analysis class you would know why. copied from the Table of Contents (sorry for the length; my little typing fingers got carried away): 1 Introduction and Overview Circuit and Packet Switching - A Brief Introduction The Need for Networks Interconnection of Networks Layered Communications Architectures Outline of the Book 2 Introduction to Queueing Theory Poisson Process The M/M/1 Queue Little's Formula, L=(lambda)W State-dependent Queues: Birth-death Processes M/G/1 Queue: Mean Value Analysis Nonpreemptive Priority Queueing Systems Problems 3 Layered Architectures in Data Networks OSI Standards Architecture and Protocols Unified View of OSI Protocols X.25 Protocol Systems Network Architecture(SNA) Problems 4 Data Link Layer: Examples and Performance Analysis Stop-and-Wait Protocol Go-Back-N Protocol Throughput Efficiency and Optimum Packet Length High-Level Data Link Control (HDLC) Throughput Analysis, Balanced HDLC Procedure Problems 5 Network Layer: Flow Control and Congestion Control X.25 Protocol X.25 Flow-control Mechanism Analysis of Window Flow-control Mechanisms Virtual Circuit Model Sliding-window Model Acknowledge-at-end-of-window Control SNA Path Control Virtual Route Pacing Control SNA Transmission Header Queueing Networks Product-form Solution, Exponential Network Open Queueing Networks Closed Queueing Networks Mean Value Analysis Input-buffer Limiting for Congestion Control Problems 6 Network Layer: Routing Function Bifurcated Routing Shortest-path Routing Decentralized Version of Algorithm B Examples of Routing in Networks and Network Architectures Virtual Circuit-oriented Networks Datagram-oriented Networks Performance Analysis of Distributed Routing Algorithms Distributed Algorithm B Predecessor Algorithm Loop-free Distributed Routing Algorithms Comparitve Performance Problems 7 Transport Layer OSI Transport Protocol Error-detection and Error-recovery Mechanisms in Transport Protocols Class-4 Transport Protocol Error-detection and Error-recovery Mechanisms Summary, Transport Protocols Class 4 - Finite State Machine Transmission Control Protocol (TCP) - Comparison with Transport Protocol, Class 4 Problems 8 Polling and Random Access in Data Networks Controlled-Access: Polling Roll-call Polling Hub Polling Random-access Techniques Pure Aloha Slotted Aloha Polling and Random Access Compared Metropolitan-area Networks: CATV Systems Random Access using CSMA/CD Problems 9 Local Area Networks Comparitive Performance, CSMA/CD and Token Ring IEEE 802 Local Area Network Standards Ethernet: CSMA/CD Local Area Network Token-passing Rings Problems 10 Introduction to Circuit Switching Simple Model, Circuit Switching: Queued Mode Circuit and Packet Switching Compared: Simple Model Elements of Traffic Engineering Digital Switching Networks Time Division Switching Block Probability Analysis of Multistage Switches: Lee Approximation Improved Approximate Analysis of Blocking Switch Examples of Digital Switching Systems AT&T No. 4 ESS Italtel UT 10/3 Switch System Problems 11 Call Processing in Digitial Circuit-switching Systems Software Organization and Call Processing Example: Italtel UT10/3 AT&T No. 5 ESS Analysis of Call-processing Procedure Overload Controls for Circuit-switching Machines Idealized Models of Overload Control Overload Controls for Hierarchical Distributed Systems Problems 12 The Evolution Toward Integrated Networks Routing in Circuit-switch Networks Hierarchical Routing Nonhierarchical Routing Control of Alternately Routed Traffic: Trunk Reservation for First-routed Traffic Common-channel Signaling for Circuit-switched Networks Message Transfer Part, Signalling Link Level Signalling System Performance High-level Features Integrated Services Digital Networks A Mathematical Prelude: Moment-generating Functions Models for Integrated Voice and Data Integration Using the FIFI Discipline Integration with Preemptive Priority Movable-boundary Strategy Continuous-time Analysis of Movable-boundary Scheme Movable-boundary Scheme: Approximate Analysis, Underload Region Movable-boundary Scheme: Fluid Flow Approximate Analysis, Overload Region Problems References Glossary Index /a ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712160516.AA27938@ucbvax.Berkeley.EDU] <1987121522120000> From: enger%gburg.DECnet@BLUTO.SCC.COM ("GBURG::ENGER") Newsgroups: comp.protocols.tcp-ip Subject: rooting around down in the x.25 Message-ID: <8712160516.AA27938@ucbvax.Berkeley.EDU> Date: 15 Dec 87 22:12:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 31 Andy: Unfortunately we don't have the equipment to "get down" and muck around at the x.25 levels. Your questions will have to be answered by the implementers of the x.25 code that we run, Messrs. Melohn and Nowicki of Sun. It occurs to me that somehow, BBN must learn to work more closely with the researchers and vendors that use the facilities that the government is paying for. Somehow, BBN should provide more information on how its interfaces function, and what to expect from them. Two recent examples of misunderstanding come to mind. One is Bill Melohn's comment that he is now receiving x.25 control messages from the PSN that have never been seen before, and that his code is unprepared for. The other example is the comment made by Mike Karels that BSD unix makes use of the PSN going down time messages sent to him on 1822 (??). The BBN spokesperson with whom he was speaking indicated that the time values are not to be trusted, and probably shouldn't be used for anything usefull. I cannot claim to be knowledgable on these subjects, but they do seem to indicate that the (very) responsible people involved in interfacing a large portion of all machines used to connect to the DDN have not been provided with all the information that BBN could make available. If the government (and ultimately us, the taxpayers) are going to get our moneys worth out of all of this investment in equipment, trunking, and labor, it would seem that we must start to provide avenues of meaningfull technical exchange between the parties on each end of the PSN access circuits. It seems rediculous to waste engineering time "guessing" at how to engineer ones interface to the PSN. Best wishes, Bob Enger ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712160723.AA00397@ucbvax.Berkeley.EDU] <1987121600010400> From: pogran@CCQ.BBN.COM (Ken Pogran) Newsgroups: comp.protocols.tcp-ip Subject: An ARPANET update Message-ID: <8712160723.AA00397@ucbvax.Berkeley.EDU> Date: 16 Dec 87 00:01:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 114 Several problems with regard to the New End-to-End Protocol deployed on the ARPANET with PSN Release 7 were discussed in messages to this list over the past couple of days. Here's a report on what we at BBN have uncovered so far. We are working on three general problems and one problem that is specific to a particular host. The "general" problems affect communication with some hosts (including some gateways) connected to the ARPANET with X.25 interfaces. 1. The "one packet problem." The scenario has been described by several folks, and runs about like this: An 1822-connected gateway has traffic for an X.25-connected host. Sending the first datagram into the net causes an X.25 VC to be opened to the destination host. One and only one packet is received by the host, and the flow stops. Various events can cause the flow to become "unblocked", such as sending traffic FROM the host back over the same VC. This problem has been observed with several, but by no means with all, DDN Standard X.25 implementations. This problem has especially been seen in situations where an X.25-connected ARPANET host establishes communication with a MILNET host (or vice-versa). In this situation, because of the Mailbridge "homing rules", traffic often flows across a different Mailbridge in each direction. Thus, user data flow is essentially unidirectional across each of two VCs. With other patterns of communication, a symmetric, bidirectional user data flow would generate one of those "events" that seems to "unblock" the flow over the VC. This problem is not observed in communication between pairs of hosts that are BOTH X.25-connected, or BOTH 1822-connected, or in situations where the X.25-connected host initiates the VC. It can arise when a host with a connection-less (i.e., 1822) interface initiates communication with a host with a connection-oriented (i.e., X.25) interface and "the network" has to initiate the connection. We believe that what's happening here is that the receiving host's X.25 isn't sending an RR to the PSN for the first data packet it receives when the PSN opens the VC. Under the New End-to-End Protocol, when going from an 1822-connected host to an X.25-connected host, the PSNs wait to see an RR for the first packet before subsequent packets are sent from the source PSN to the destination PSN (and a RFNM is returned to the originating 1822-connected host). Under the Old End-to-End Protcol, subsequent packets were sent as soon as the receiving host accepted the VC (up to the limit of the window); this could result in a RFNM being sent to the originating host before the destination host actually acknowledged the packet via an RR! (The different behavior of the New End-to-End was intended as a fix for what was a bug, or perhaps a "cheat", in the old design with respect to the meaning of a RFNM.) In the case of a symmetric traffic flow, an RR is typically piggybacked on a data packet. But, as was mentioned above, traffic flows involving Mailbridges frequently aren't symmetric. Typically, X.25 implementations send an RR after some brief timeout if there's no user packet going out over the VC on which to piggyback the RR. But if there is neither traffic nor a timeout, and no RR is sent, the flow will cease as described above. We're going to change the PSNs to behave as they did under the Old End-to-End in this regard, at least temporarily. This will give us time to work with implementors to resolve this issue. 2. The "pinging yourself" problem. We've found a timing bug in the PSN that is sometimes triggered when a host "pings" itself. Other situations can trigger it, but the timing of the sequence of events that occurs when some hosts ping themselves seems to be the most conducive to triggering the bug. The result is that the PSN doesn't acknowledge delivery of one or more messages to the host in question. We've found a race condition in the PSN code. A fix for this bug will be installed in the ARPANET within the next day or so. 3. The "multiple of 128 bytes" problem. Several people have reported a problem with packets apparently being dropped by the network when they are a multiple of 128 bytes (perhaps +/- a few?) in length. We are actively investigating this problem. Anyone with data or insight with regard to this is encouraged to contact Andy Malis (Malis@bbn.com) or ARPAUPGRADE@bbn.com. 4. The gateway at Yale has mostly been off the net since the cutover to the New End-to-End Protocol. They are the only gateway connected to the ARPANET via an HDH interface running at 9.6 kb/s, and are the only ones experiencing this particular problem. We believe there is a PSN bug that we haven't been able to find yet; so far, we have been unable to duplicate this problem in our lab. In the meantime, we have developed a work-around that will enable Yale to be up on the ARPANET while we work to find and fix the bug. We apologize for the inconvenience, and thank the folks at Yale for their patience and understanding. Finally, implementors have asked if they can be included on the "ARPAUPGRADE" mailing list. We use this list as a "hot line" for getting information from the community to us and to DCA, and for internal discussion about the problems. The idea of having an implementor's mailing list is a good one, however, and we will shortly set up a new list for those who are actively helping us track down these various problems. Please keep those cards and letters coming! Regards, Ken Pogran BBN COMMUNICATIONS CORPORATION ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4398@sdcsvax.UCSD.EDU] <1987121601561000> From: brian@sdcsvax.UCSD.EDU (Brian Kantor) Newsgroups: comp.protocols.tcp-ip Subject: Host as gateway - some advice needed on naming Message-ID: <4398@sdcsvax.UCSD.EDU> Date: 16 Dec 87 01:56:10 GMT Organization: UCSD wombat breeding society Lines: 40 This is perhaps not the right mailing-list/newsgroup to ask, but I can't find a better one, so be tolerant please. I'm stumped: UCSD has a connection to the MILNET, currently through 'sdcsvax.ucsd.edu' at 26.5.0.3. Sdcsvax is also on our local ethernet as 128.54.0.1. We are interested in the possibility of moving the interface electronics into another system to reduce the load on sdcsvax so that the researchers on there can have more cycles with which to do their research thing. We would probably move the interface to another system that would also be used to handle a lot of mail traffic, rather than something like a router that won't have any users or locally-originated traffic. I.e., it will be more than an IP switch. From our standpoint, naming the system 'UCSD.UCSD.EDU' is "a good thing", and that's the name we'd assign the new system at its ethernet interface and IP address on the local net. Ok, so what's the question: Would it be "a good thing" to also name the MILNET interface the same, or looking towards the future, would it make more sense to name the MILNET interface something like UCSD-GW.UCSD.EDU? I see some problems, in that packets bearing the MILNET address would have a different official hostname when translated back from their IP address, even though they originated on the same machine. Yet the advantage of not having to go through all the DDN paperwork to change the hostname when we next reorganize the local network is attractive. Oh yes, all this is on 4.3BSD systems currently, if that makes any real difference. What do you think I should do? Brian Kantor UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 USA brian@sdcsvax.ucsd.edu (619) 534-6865 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712160648.AA17129@spdcc.COM] <1987121605080700> From: jbvb@ftp.UUCP (James Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: Bridge IP routers & fragmentation - correction. Message-ID: <8712160648.AA17129@spdcc.COM> Date: 16 Dec 87 05:08:07 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Some time back, I posted a message indicating that some Bridge IP Routers fragmented packets at the inconvenient length of 540 bytes (IP). At that time, I had been told that the box which did so was their GS/3. I heard from several GS/3 users who hadn't encountered that problem, so after further communication with the guy who owns it, he corrected himself and said that the problem is associated with the GS/6. I hope this hasn't inconvenienced anyone. jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712160942.AA03364@ucbvax.Berkeley.EDU] <1987121605380000> From: enger%gburg.DECnet@BLUTO.SCC.COM ("GBURG::ENGER") Newsgroups: comp.protocols.tcp-ip Subject: **** Medical Assistance Needed for Core Gateways **** Message-ID: <8712160942.AA03364@ucbvax.Berkeley.EDU> Date: 16 Dec 87 05:38:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 47 HO HO HO: Santa would like to bring the Internet better performance, but his elves are having a hard time finding the right parts. Three small, lonely, destitute EGP core gateways desperately need your help. Officially declared braindead years ago, these tenacious little guys have stubbornly clung to life. Although the respirator is scheduled to be pulled in about 6 months, you can improve the quality of their (and your!) life for the time remaining to them. Help give them a much needed brain transplant. Loan them your unused, probably unloved, LSI-11/73 CPU boards! Their little brothers and sisters, the mailbridges, would also benefit from this treatment. Won't you help? Please join Mike Petry and Louie Mamakos of U. of Md., the folks at BBN, who have upgraded the EGP core machines on the Arpanet, and CONTEL which has contributed an 11/73 to its local mailbridge. The three Milnet EGP core gateways, and the 6 or so remaining mailbridges need your charity. Won't you be a good Samaritan too? Search your surplus parts bins, locate your old unloved LSI 11-73's, blow the dust off and contact one of Santa's helpers listed below. * * * * * * * * * * * * * * * * * * * During this holiday season, instead of trying to give a thoughtful gift, give the gift of thought! Send some new brains to these deserving little machines. You'll be helping them, and your Internet response times. * * * * * * * * * * * * * * * * * * * We thank you for your support. Annette Bauman (abauman@ddn1.arpa) Phill Gross (gross@gateway.mitre.org) Bob Enger (enger@bluto.scc.com) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2692@arthur.cs.purdue.edu] <1987121611484700> From: sjc@cs.purdue.EDU (Steve Chapin) Newsgroups: comp.protocols.tcp-ip Subject: Re: beginners guide to ... ? Summary: Well, he's somewhat right... Message-ID: <2692@arthur.cs.purdue.edu> Date: 16 Dec 87 11:48:47 GMT References: <298390.871212.PAP4@AI.AI.MIT.EDU} <3209@tut.cis.ohio-state.edu> Organization: Department of Computer Science, Purdue University Lines: 38 In article <3209@tut.cis.ohio-state.edu}, verber@tut.cis.ohio-state.edu (Mark A. Verber) writes: } } Doug Comer's book is already out. It's title is Operating System } Design Volume II: Internetworking with Xinu. In my opinion it is the } best book for someone to learn about the TCP/IP protocol suite from } the ground up. Doug has once again put out a book which is highly } readable. This book is also the reference manual for Xinu volume 7 } which is running on Sun3, Macs, and Vaxen. } } Cheers, } ----------------------------------------------------------------------- } Computer Science Department Mark A. Verber } The Ohio State University verber@ohio-state.arpa } +1 (614) 292-7344 cbosgd!osu-cis!verber Well, a few corrections are in order: First, although Doug does have out Volume II of the Xinu series, he is also bringing out a new book (it went to the typesetter's today!) which is titled "Internetworking With TCP/IP: Principles, Protocols, and Architecture". I agree with Mark that Doug has a way of writing easily understandable books, without seeming patronizing. Also, version 7 Xinu isn't quite ready for the Sun-3...we are, however, shipping version 6 for the Sun-3. (Version 7 is availabe for Macs and Vaxen, plus PDP-11) Sun-3 Version 7 should be out around the end of January, since the slaves, er, grad students working on Xinu these days are Shawn Ostermann and myself, and we're involved taking nasty ol' qualifying exams. Always plugging the boss's stuff... Steve 'Xinu is my life' Chapin --------------------------------------------------------------------------- Steve Chapin | Chapin's Law of Motion: ARPA: sjc@gwen.cs.purdue.edu | You can get anywhere in 10 minutes UUCP: ...!purdue!sjc | if you drive fast enough. --------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1147@trotter.usma.edu] <1987121612200100> From: bill@trotter.usma.edu (Bill Gunshannon) Newsgroups: rec.ham-radio.packet,comp.protocols.tcp-ip Subject: Re: NEEDED: KISS for TNC220 Message-ID: <1147@trotter.usma.edu> Date: 16 Dec 87 12:20:01 GMT References: <869@idec.stc.co.uk> Organization: US Military Academy, West Point, NY Lines: 27 Summary: out of luck Having spoken with PAC-COMM on this subject, I have bad news for you. Because the 220 is not a TNC-1 or TNC-2 clone but a complete redesign by PAC-COMM the existing KISS PROMs won't work and no one that PAC-COMM is aware of has written KISS for the 220 specificly. I know it is hardly comforting but the best solution I can think of is to purchase another TNC for just running KISS and TCP-IP. Again PAC-COMM has a new product called the TINY-2 which is a reduced size TNC-2 imitator. It does use the normal TNC-2 PROM so you can put in one of the existing KISS implementations. Good luck. P.S. If anyone can prove me wrong please do as I have a TNC220 also and would love to be able to run KISS in it as well as my KANTRONICS!!! 73's 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121613284400> Received: from PARK-STREET.BBN.COM by SRI-NIC.ARPA with TCP; Wed 16 Dec 87 18:52:40-PST To: egp-people@PARK-STREET.BBN.COM cc: tcp-ip@SRI-NIC.ARPA, satnet-outages@vax.bbn.com Subject: missing nets between Europe and U.S. Date: Wed, 16 Dec 87 21:48:44 -0500 From: Mike Brescia Especially to Bassen in Norway, Bruce in U.K., others who reported missing paths across the 'pond'. One of the two gateways on SATNET in the U.S. had not been updated in the software release, so that it was not sending full EGP updates (complete with fragmentation of 1200 bytes into 252 byte pieces). A test on Tuesday showed that of about 150 class B nets known to be reachable, the UCL gateway in the U.K. complained that it would not route to 140 of them. The CSS gateway was finally updated about noon EST today, and after that, only 7 of the class b nets were unreachable from the UCL gateway point of view. While this seems to fix one problem, it fails to explain why the second gateway at DCEC, already running the latest release, did not provide the routing information expected. There have been other reports of missing net paths; please check and report again if you find routes you cannot reach for a long time. Be specific about what host addresses are involved, and prove that the hosts and all intervening gateways are up. I have a chart of 350 by 350 nets, and await your data so that I can fill in all 122500 points with whether you can reach one another or not. (:-)/2 Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [838@louie.udel.EDU] <1987121616153600> From: garrett@udel.EDU (Joel Garrett) Newsgroups: comp.protocols.tcp-ip Subject: Re: beginners guide to ... ? Message-ID: <838@louie.udel.EDU> Date: 16 Dec 87 16:15:36 GMT References: <298390.871212.PAP4@AI.AI.MIT.EDU} <3209@tut.cis.ohio-state.edu> <2692@arthur.cs.purdue.edu> Reply-To: garrett@udel.EDU (Joel Garrett) Distribution: na Organization: University of Delaware Lines: 20 Summary: Publiser info, please? In article <2692@arthur.cs.purdue.edu> sjc@cs.purdue.EDU (Steve Chapin) writes: > >Well, a few corrections are in order: First, although Doug does >have out Volume II of the Xinu series, he is also bringing out >a new book (it went to the typesetter's today!) which is titled >"Internetworking With TCP/IP: Principles, Protocols, and >Architecture". I agree with Mark that Doug has a way of writing >easily understandable books, without seeming patronizing. > Who is the publisher for this series of books? I would be very interested in ordering books of this type. Joel J. Garrett Research Associate Center for Composite Materials University of Delaware Newark, DE 19716 arpa: garrett@udel.edu or: garrett@udel-ccm.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [759@unmvax.unm.edu] <1987121617015000> From: mcdermot@merlin.unm.edu (John McDermott) Newsgroups: comp.protocols.tcp-ip Subject: SLIP for CMU/TEK package? Message-ID: <759@unmvax.unm.edu> Date: 16 Dec 87 17:01:50 GMT Sender: news@unmvax.unm.edu Reply-To: mcdermot@merlin.UUCP (John McDermott) Distribution: na Organization: University of New Mexico, Albuquerque Lines: 10 Has anyone built SLIP for CMU/TEK tcp/ip? It would be a real easy way to route over a decnet link (by using DECNET's remote terminal stuff). It would also be nice for use the "normal" way. Any pointers would be nice. Thanks! --john John McDermott ARPA: mcdermott%atavax.decnet@afwl-vax.arpa Applied Technology Assoc W (505) 247-8371 1900 Randolph SE Albuquerque, NM 87106 H (505) 255-7796 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712161807.AA26263@mitre.arpa] <1987121618075400> From: mckee@MITRE.ARPA (H. Craig McKee) Newsgroups: comp.protocols.tcp-ip Subject: Re: beginners guide to ... ? Message-ID: <8712161807.AA26263@mitre.arpa> Date: 16 Dec 87 18:07:54 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The MITRE Corp., Washington, D.C. Lines: 3 Doug Comer's book, "Internetworking with TCP/IP ..." should be avaiable early February. It can be back-ordered from Prentice-Hall through their Order Dept. (201)767-5937. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9613@udenva.cair.du.edu] <1987121623312500> From: jrozbori@udenva.cair.du.edu (Jim Rozboril) Newsgroups: comp.os.vms,comp.protocols.tcp-ip Subject: CMU's TCP/IP V6.2 Message-ID: <9613@udenva.cair.du.edu> Date: 16 Dec 87 23:31:25 GMT Reply-To: jrozbori@udenva.UUCP (Jim Rozboril) Distribution: na Organization: U of Denver Lines: 24 Keywords: Help I would first like to thank everyone who has responded to my questions in the past. On to the latest problem... We have just installed CMU's TCP/IP V6.2 on our cluster. After spending lots of time editing the .config files, we still have not gotten it to work right. The daemon dies completely when trying to telnet using a node name, and returns an error (like event didn't happen) when using node adresses. However, we can telnet from one of our unix machines to the VMS machine. Things seem reasonable ok going that way. Likewise, we can login using ftp from a unix machine to vms, but when trying to do useful things (ls,get,put,etc) it fails. The documentation we got was not particularly useful in pointing us in the right direction to solve these problems. Has anyone else had similar problems? Any ideas what might be wrong? Does anyone have an email address or phone number of someone at CMU who might be able to help us? thanks for your help! roz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4431@caip.rutgers.edu] <1987121701213700> From: schen@caip.rutgers.edu (Shin Chen) Newsgroups: comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip Subject: What is the procedure to simulate the limits of protocols? Message-ID: <4431@caip.rutgers.edu> Date: 17 Dec 87 01:21:37 GMT Organization: Rutgers Univ., New Brunswick, N.J. Lines: 11 Keywords: throughput maximum I am new to network environment. I would like know how one goes about finding the theoretical and real limits (maximum, minimum, and average) of various protocols. This includes equipment, methodology and/or ideas. Thanks. -- - Shin Chen - TELEPHONE: SRAC -- (201) 932-5027 - ARPA: schen@caip.rutgers.edu - UUCP: {backbone}!rutgers!caip.rutgers.edu!schen ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1635@faline.bellcore.com] <1987121701274200> From: karn@faline.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Timewarps, virtual-cirkosis and other twitches Summary: solution to Virtual Cirkosis Message-ID: <1635@faline.bellcore.com> Date: 17 Dec 87 01:27:42 GMT References: <8712151436.aa15545@Huey.UDEL.EDU> Organization: Bell Communications Research, Inc Lines: 18 The solution to the problems Dave describes seems awfully obvious: JUNK X.25!! Valuable computer networking people like Dave Mills have enough important problems to solve without wasting time on artificial ones like limits on the number of virtual circuits a network interface will support. When we (Bellcore) came up on the ARPANET, we had a choice between X.25 and 1822/HDH. I chose the latter and I've never had cause to regret it. If people had X.25 DTEs that they REALLY have to have communicate through the ARPANET, this should have been done with separate end-to-end boxes that encapsulate X.25 inside 1822 messages. The decision to inflict X.25 on the rest of us innocent Internetters is still utterly incomprehensible to me. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712170157.AA01396@sccgate.scc.com] <1987121701573600> From: oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) Newsgroups: comp.protocols.tcp-ip Subject: re: PSN patch installed Message-ID: <8712170157.AA01396@sccgate.scc.com> Date: 17 Dec 87 01:57:36 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 92 Andy, First of all, I never received the message I'm replying to. When Enger asked me about the patch a few minutes ago, I asked him to forward his copy. As for the results of the patch, they looked mixed from our point of view. Our first retest, using good old twg.arpa, produced the following output fron Sun's X25 management software: x25manager: std LCN 3 from 10.4.0.51 ADDED x25manager: std LCN 0 from 10.4.0.51 REMOVED VC has timed out x25manager: std LCN 3 from 10.4.0.51 ADDED x25manager: std LCN 0 from 10.4.0.51 REMOVED VC has timed out x25manager: std LCN 3 from 10.4.0.51 ADDED x25manager: std LCN 0 from 10.4.0.51 REMOVED VC has timed out x25manager: std LCN 3 from 10.4.0.51 ADDED Sun's support organization tells me that the "REMOVED VC" message is printed when the PSN times the circuit out. As opposed to the "Removed Normal Timeout" message printed when the Sun software times out the circuit. Meanwhile the following was being output by ping: ping -v twg.arpa PING twg.arpa: 56 data bytes 64 bytes from 1a050049: icmp_seq=1. time=2499. ms 64 bytes from 1a050049: icmp_seq=3. time=3160. ms 64 bytes from 1a050049: icmp_seq=7. time=1480. ms 64 bytes from 1a050049: icmp_seq=10. time=1300. ms 10 packets transmitted ----twg.arpa PING Statistics---- 10 packets transmitted, 4 packets received, 60% packet loss round-trip (ms) min/avg/max = 1300/2109/3160 Every time the virtual circuit was added, I received a packet from twg.arpa via 10.4.0.51 (add the circuit 4 times, get 4 packets). We ran this test a couple of times with similar results (different packet counts and sequence numbers got through). If I pinged 10.4.0.51 the problem went away as reported previously. [7] ping -v 10.4.0.51 PING 10.4.0.51: 56 data bytes 64 bytes from a040033: icmp_seq=3. time=1880. ms 64 bytes from a040033: icmp_seq=4. time=1340. ms 64 bytes from a040033: icmp_seq=5. time=1180. ms ^C ----10.4.0.51 PING Statistics---- 7 packets transmitted, 3 packets received, 57% packet loss round-trip (ms) min/avg/max = 1180/1466/1880 [8] ping -v twg.arpa PING twg.arpa: 56 data bytes 64 bytes from 1a050049: icmp_seq=2. time=2220. ms 64 bytes from 1a050049: icmp_seq=3. time=1660. ms 64 bytes from 1a050049: icmp_seq=4. time=1520. ms 64 bytes from 1a050049: icmp_seq=5. time=2340. ms 64 bytes from 1a050049: icmp_seq=6. time=1940. ms 64 bytes from 1a050049: icmp_seq=7. time=1300. ms 64 bytes from 1a050049: icmp_seq=8. time=1140. ms 64 bytes from 1a050049: icmp_seq=9. time=1180. ms 64 bytes from 1a050049: icmp_seq=10. time=2219. ms ----twg.arpa PING Statistics---- 10 packets transmitted, 9 packets received, 10% packet loss round-trip (ms) min/avg/max = 1140/1724/2340 As I type this message I can see other Virtual circuits thrashing. I assume that whatever service they are trying to perform (SMTP, FTP) it is being accomplished 1 packet per add/remove cycle, if at all. I'm left with the impression that the patch simply lowered the PSN virtual circuit timeout value in an attempt to take advantage of the earlier observation that a packet would come through on each PSN==>Host VC setup. So yes, I believe the problem still exists, although in a mutated form. Additionally, if not this circuit thrashing, something is confusing the hell out our X25 circuit management software. Twice today the manager hung up, refusing to create outbound circuits or accept inbound ones. The program had to be manually stopped and restarted. Sun support tells me that their gateway works so I should contact BBN. It was previously suggested by BBN that I should be kvetching to Sun. What's a poor user to do? Mike ps: Bob asked me to mention that not only did I not receive the message, it took 10+ hours for him to receive his copy. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121705065800> Received: from sccgate.scc.com by SRI-NIC.ARPA with TCP; Thu 17 Dec 87 07:13:11-PST Received: by sccgate.scc.com (4.0/870914.1{Enger}) id AA00398; Thu, 17 Dec 87 10:06:58 EST Date: Thu, 17 Dec 87 10:06:58 EST From: oconnor@sccgate.scc.com (Michael J. O'Connor) Message-Id: <8712171506.AA00398@sccgate.scc.com> To: karn@faline.bellcore.com, tcp-ip@sri-nic.arpa Subject: Re: Timewarps, virtual-cirkosis and other twitches I second the motion! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712170521.AA25952@ucbvax.Berkeley.EDU] <1987121705230600> From: brescia@PARK-STREET.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: missing nets between Europe and U.S. Message-ID: <8712170521.AA25952@ucbvax.Berkeley.EDU> Date: 17 Dec 87 05:23:06 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 Especially to Bassen in Norway, Bruce in U.K., others who reported missing paths across the 'pond'. One of the two gateways on SATNET in the U.S. had not been updated in the software release, so that it was not sending full EGP updates (complete with fragmentation of 1200 bytes into 252 byte pieces). A test on Tuesday showed that of about 150 class B nets known to be reachable, the UCL gateway in the U.K. complained that it would not route to 140 of them. The CSS gateway was finally updated about noon EST today, and after that, only 7 of the class b nets were unreachable from the UCL gateway point of view. While this seems to fix one problem, it fails to explain why the second gateway at DCEC, already running the latest release, did not provide the routing information expected. There have been other reports of missing net paths; please check and report again if you find routes you cannot reach for a long time. Be specific about what host addresses are involved, and prove that the hosts and all intervening gateways are up. I have a chart of 350 by 350 nets, and await your data so that I can fill in all 122500 points with whether you can reach one another or not. (:-)/2 Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121708344000> Received: from ccd.bbn.com by SRI-NIC.ARPA with TCP; Thu 17 Dec 87 10:46:43-PST Date: Thu, 17 Dec 87 13:34:40 EST From: "Drew M. Powles" Subject: security option To: tcp-ip@sri-nic.arpa Cc: dpowles@ccd.bbn.com Can someone please refresh my memory? What is the status of the basic and extended IP security options verses the single security option in the standard? Have these options been adopted yet? Has the spec on them been turned into an RFC yet? If not, when will some of these things happen, if ever? Thanks for the help! dmp ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3313@tut.cis.ohio-state.edu] <1987121716191200> From: DUNLAP@OSU-20 (Bryan Dunlap) Newsgroups: comp.protocols.tcp-ip Subject: tn3270 for Tops-20 Message-ID: <3313@tut.cis.ohio-state.edu> Date: 17 Dec 87 16:19:12 GMT Sender: daemon@tut.cis.ohio-state.edu Lines: 5 Does anyone know of an implementation of tn3270 for Tops-20? ==BD dunlap%osu-20@ohio-state.arpa ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712171712.AA08471@uc.msc.umn.edu] <1987121717123500> From: jpt@UMN-REI-UC.ARPA (Joseph P. Thomas) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP for CMU/TEK package? Message-ID: <8712171712.AA08471@uc.msc.umn.edu> Date: 17 Dec 87 17:12:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Look at the SLIP package done at UC Davis. It does more than what you want it to do, and probably not in the way you want it done, but should be real easy to change. ( All the slip parts are there, but it has extra functionality. ) You can use anonymous ftp from ucdavis.edu and then look under dist/slip There was a mail message to this group dated Nov 25 and this subject. If you can't find it and want it, send e-mail and I ship it to you. Joseph Thomas Minnesota SuperComputer Center Affiliate of the Univ. of Minn. jpt@uc.msc.umn.edu ( jpt@umn-rei-uc.ARPA ) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712171946.AA10318@ucbvax.Berkeley.EDU] <1987121718344000> From: dpowles@CCD.BBN.COM ("Drew M. Powles") Newsgroups: comp.protocols.tcp-ip Subject: security option Message-ID: <8712171946.AA10318@ucbvax.Berkeley.EDU> Date: 17 Dec 87 18:34:40 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Can someone please refresh my memory? What is the status of the basic and extended IP security options verses the single security option in the standard? Have these options been adopted yet? Has the spec on them been turned into an RFC yet? If not, when will some of these things happen, if ever? Thanks for the help! dmp ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1637@faline.bellcore.com] <1987121718473700> From: karn@faline.bellcore.com (Phil R. Karn) Newsgroups: rec.ham-radio.packet,comp.protocols.tcp-ip Subject: Re: NEEDED: KISS for TNC220 Summary: Kantronics does support SLIP Message-ID: <1637@faline.bellcore.com> Date: 17 Dec 87 18:47:37 GMT References: <869@idec.stc.co.uk> <1147@trotter.usma.edu> Organization: Bell Communications Research, Inc Lines: 9 > P.S. If anyone can prove me wrong please do as I have a TNC220 also and > would love to be able to run KISS in it as well as my KANTRONICS!!! I'm not sure what you meant by the reference to Kantronics, but they now support SLIP on all their TNCs. They advertise it as "TCP/IP compatibility". I appreciate the plug, but "KISS compatibility" would have been more accurate and descriptive. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121801160000> Received: from acc.arpa by SRI-NIC.ARPA with TCP; Fri 18 Dec 87 09:16:22-PST Date: 18 Dec 87 09:16:00 PST From: Subject: RE: bridges vs routers To: "tcp-ip" Reply-To: >Actually, it's pretty easy to tell whether a box is a gateway (router) >or just a bridge. If it has a network address, it's a gateway. If it >doesn't, it's a bridge. Actually, there is no reason why a bridge cannot have both a MAC address and even a network level address. With the introduction of "brouters" (such as Wellfleet's) the distinction is getting very blurred. Having a network level address for a bridge will be desireable as standard network management protocols emerge. I believe that the real distinction has to made on the basis of what level of protocol address that packet forwarding is decided. Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [301310.871217.PAP4@AI.AI.MIT.EDU] <1987121802405200> From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") Newsgroups: comp.protocols.tcp-ip Subject: Re: beginners guide to ... ? Message-ID: <301310.871217.PAP4@AI.AI.MIT.EDU> Date: 18 Dec 87 02:40:52 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Well, since it is on it's way to press, Comer's new book will be published Prentice Hall, and is called (I think) 'An Introduction to Internetworking', or something very close. I'm too lazy to get it out of my car's back seat, downstairs in the parking lot... -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1825@hou2d.UUCP] <1987121804033600> From: n2dsy@hou2d.UUCP (G.BEATTIE) Newsgroups: comp.protocols.tcp-ip Subject: X.25 Implementation vs Protocol Message-ID: <1825@hou2d.UUCP> Date: 18 Dec 87 04:03:36 GMT Organization: AT&T Bell Laboratories, Holmdel Lines: 12 Keywords: X.25 It's a shame that some folks damn a protocol suite based on what seems to be a combination of implemtation problems and/or learning curve hassles. I have seen good X.25 interfaces and bad, both on the DTE side and the network side. Let's look at the gentleman's problem like PROFESSIONALS and keep the pompous babblings to ourselves. I rarely post comments, because of the endless rounds of this kind of stuff. I JUST DON'T SEE THE POINT. Alas, I just can't keep from asking for a bit of common sense. Thanks, J. Gordon Beattie, Jr. ihnp4!hotps!n2dsy-4!n2dsy Telephone: 201-615-4168 (O) 201-387-8896 (H) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [301351.871217.JBVB@AI.AI.MIT.EDU] <1987121804433300> From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: More than one IP (sub)network on one ethernet cable Message-ID: <301351.871217.JBVB@AI.AI.MIT.EDU> Date: 18 Dec 87 04:43:33 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 If a gateway is present, it should be configured as such. If there is no gateway, I can either return an error to the user, or ARP the address on the other network anyway. If it is on another subnet which has suddenly become irrelevant, re-configure and unset the subnet bits. If I ARP it, maybe it is a spurious broadcast, maybe it works. If it works, various clever bits of code that treat things routed via a gateway differently break down, but the connection probably survives. To me, the tradeoffs have seemed to favor returning the error. If the user is in the what I think to be the mainstream, he has a configuration problem, and should know about it. Our code was recently reported (by a customer) to be willing to ARP any address configured as a gateway, although it won't ARP off-net addresses if no gateway is configured. I didn't design it, but it seems reasonable. Comments? James B. VanBokkelen FTP Software ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121805144400> Received: from KAUAI.MCL.UNISYS.COM ([192.31.44.2]) by SRI-NIC.ARPA with TCP; Fri 18 Dec 87 09:13:59-PST Received: by KAUAI.MCL.UNISYS.COM [3.2Unisys/Domain/jbp/2.4] id AA03288; Fri, 18 Dec 87 10:14:44 EST Date: Fri, 18 Dec 87 10:14:44 EST From: perry@MCL.UNISYS.COM (Dennis Perry) Message-Id: <8712181514.AA03288@KAUAI.MCL.UNISYS.COM> To: enger%gburg.decnet@bluto.scc.com, ietf@gateway.mitre.org Subject: Re: **** Medical Assistance Needed for Core Gateways **** Cc: abauman@ddn1.arpa, enger@bluto.scc.com, gross@gateway.mitre.org, tcp-ip@sri-nic.arpa Ho, Ho, Ho! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121806115400> Received: from suvm.acs.syr.edu by SRI-NIC.ARPA with TCP; Fri 18 Dec 87 08:43:27-PST Received: from SUVM.BITNET by suvm.acs.syr.edu ; Fri, 18 Dec 87 11:19:36 LCL Received: by SUVM (Mailer X1.25) id 2807; Fri, 18 Dec 87 11:19:34 LCL Date: Fri, 18 Dec 1987 11:11:54 LCL From: John M Wobus To: TCP-IP Discussion Group Subject: Bridges vs Routers. The subject of Bridges vs Routers is of definite interest to TCP-IP people, but if we feel it is dominating this list too much, there is another appropriate list: BIG-LAN, the list on campus-sized local-area networks. See its blurb below. John Wobus Syracuse University ----------- (Internet) BIG-LAN@SUVM (Bitnet) This list is for the discussion of issues in designing and operating Campus-Size Local Area Networks, especially complex ones utilizing multiple technologies and supporting multiple protocols. Topics include repeaters, bridges, routers and gateways; how to incorporate smaller Personal-Computer type LANs into the campus-wide LAN; how to unify the mail systems, etc. This is an ideal list in which to debate the relative merits of bridges vs routers. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to BIG-REQ@SUVM.ACS.SYR.EDU (Internet) BIG-REQ@SUVM (Bitnet). Those familiar with revised LISTSERV can subscribe with LISTSERV@SUVM.ACS.SYR.EDU (Internet) or LISTSERV@SUVM (Bitnet). Archives are available through revised LISTSERV. Coordinator: John Wobus ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712180837.AA06536@gargoyle.uchicago.edu] <1987121806582300> From: root@vijit.UUCP Newsgroups: comp.protocols.tcp-ip Subject: tcp/ip books Message-ID: <8712180837.AA06536@gargoyle.uchicago.edu> Date: 18 Dec 87 06:58:23 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 36 Comer's new book is entitled "Internetworking With TCP/IP: Principles, Protocols, and Architecture", to be published by Prentice-Hall. It's not published yet. Another series of books that may be useful is "Handbook of Computer-Communications Standards". There are three volumes published separately by MacMillan. As far as I know, only the first volume is actually in print. The others are "Real Soon Now". Volume 1: The OSI Model and OSI-Related Standards Volume 2: Local Networks Standards Volume 3: The Department of Defense (DoD) Standards The author/editor of these three volumes is William Stallings. [I am told that the (take a deep breath) Library of Computer and Information Science Book Club (whew!) will be offering these 3 books both together and separately in their February mailing. I joined this club some years ago and have gotten some very good books from it cheaper than retail (even if you add in shipping). This book club is run by MacMillan. If you're interested, let me know, because I can get freebies (and so can you) when you join. This was not meant to be a commercial, but just to tell you how to get good books without paying an arm & leg.] Stallings also has written (among other books) "Data and Computer Communications", also published by MacMillan. The 2nd edition has just hit the streets, so don't buy the 1st edition unless you want/have to. This book is considered by MacMillan to be a college text rather than a "commercial" book, so try college book stores first. MacMillan will not let individuals order this book, only bookstores. A source in Chicago is IIT. Hope this informations helps those looking for TCP/IP books. Does anyone have a list of other books that might be of interest? Dave Madsen ---dcm ihnp4!vijit!madsen or vijit!madsen@gargoyle.uchicago.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712181124.AA29455@ucbvax.Berkeley.EDU] <1987121808191900> From: HANK@BARILVM.BITNET (Hank Nussbacher) Newsgroups: comp.protocols.tcp-ip Subject: Routers vs bridges revisited Message-ID: <8712181124.AA29455@ucbvax.Berkeley.EDU> Date: 18 Dec 87 08:19:19 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 260 I promised to post my results to the list. Here it is. Once again thanks to all those that supplied comments. Routers vs. Bridges revisited December 18th, 1988 Henry Nussbacher HANK@VM1.TAU.AC.IL Israel Network Information Center ================================= Acknowledgements: Rob Austein - MIT Bob Braden - ISI Scott Brim - Cornell University Charles Hedrick - Rutgers University John Lekashman - NASA Radia Perlman - MIT Yakov Rekhter - IBM G.A Sawkins, D. Crocker: Internetworking Connections: A Comparison of Options, May 1987 This paper will attempt to analyze the differences between routers and bridges. Routers operate at the Network Layer (level 3) and typically understand routing protocols inherent in Tcp/Ip or Decnet or XNS. Bridges operate at the Data Link Layer (level 2) and do not understand anything about any communications protocol other than the physical medium, which is typically an Ethernet. The difference with this paper will be the fact that in addition to "standard" routers and bridges, an attempt will be made to analyze multi-protocol routers and routing bridges. The differences between the two aspects (level II vs. level III) are slowly merging and in the near future the two technologies will meet somewhere in the middle. For further reading, look for the January 1988 issue of IEEE Network which is dedicated to the topic of bridges vs. routers. Performance: =========== Currently, bridges will outperform routers. The numbers generally quoted are that routers forward packets in the high hundreds, while bridges forward packets in the low thousands. Standard bridges like DEC's LANBRIDGE can easily forward 4,000 packets per second, whereas Rad's REB routing bridge claims to forward 2,500 pps. On the other hand, multiprotocol routers claim approximately 1200 pps (Proteon's p4200 and cisco's AGS) under peak conditions. Bridges need to examine every packet whereas routers only look at packets addressed to it. Since the time involved in scanning every packet is enormous, bridges must make use of specially designed hardware. But as bridges attempt to look deeper into each packet to perform such functions as security and access controls, their throughput will drop. As routers use faster technology (i.e. 68020) and special purpose hardware, their throughput should rise. But one aspect that is always ignored when examining the router vs. bridge controversy is the speed of the link used by the router or bridge. When dealing with 2 Ethernet segments connected via a T1 link, any bridge is able to pump out enough packets to utilize the full bandwidth of the T1 link. But when confronted with 64kb data links, both a router and a bridge can easily saturate a 64kb link to capacity. So the bottleneck is moved from the box to the line. If you purchase a bridge because it will pump 4 times as many packets through, but you work with 64kb links, you will be disappointed. On the other hand, if you have been using a router on a T1 link and upgrade to a bridge, you will notice a significant increase in throughput. Multi-media support =================== Routers have the ability to transcend differences in media. If one site runs a 50Mb Hyperchannel, another runs a token ring (i.e. Pronet-4) , and another runs an Ethernet, a router can be used to interconnect all of them. The address translation occurs at a layer above the MAC level, namely the IP layer. Proteon's p4200 supports Ethernet, token ring and x.25 networks. cisco's AGS supports Ethernet and X.25 and they are working on token ring. Current bridges cannot handle multi-media systems. Many bridge vendors are working on supporting multi-media networks. It is expected that both technologies will arrive at the same place in the very near future. The importance of being independent of other sites hardware requirements is a crucial factor in designing an adaptable network. Multi-protocol support ====================== A year ago, bridges were considered the only option if you had networks that needed to handle Tcp/Ip, Decnet and XNS, all at the same time. Today, there are routers available that can handle full Tcp/Ip, XNS's IDP (Internet Datagram Protocol - the equivelent of IP), and Decnet's specifications for a DNA Phase IV, Level 2 area router. These changes in routers required extensive software modifications and testing. Bridges have no problem accepting any new protocol thrown at them. They ignore anything above level II. This is one reason why bridges are ahead of routers in throughput. A "standard" bridge is inherently a simpler box. Software changes ================ Bridges almost never need software changes, since the basic operation is founded on the Ethernet packet format. Software changes are only necessary if new functions need to be added such as accounting, security, access controls or network management. Routers are almost all software. New releases of router software are very common as better algorithms and protocols are developed. This can either be viewed as a positive or negative aspect. The negative aspect is that you are always updating the software in the box and when you find a release level that works, you tend to fixate on it and reject all future updates (or until a major new function is introduced). The positive aspect is that you can easily implement new functionality with the ease of replacing a diskette. Broadcasts and Multicasts ========================= An Ethernet Broadcast is meant to be delivered to all nodes in the network. Bridges are designed to deliver all Broadcast and Multicast messages to all Ethernet segments (although certain bridges can be configured to filter some Multicasts). Routers do not transmit Broadcasts and Multicasts. ARP (Address Resolution Protocol), RWHO, and ROUTED are just three functions in Tcp/Ip that generate a significant amount of Ethernet Broadcast traffic. When analyzing router vs. bridge performance, care should be taken to generate sizable Broadcast traffic. Routers will not be affected, but bridges will. Network Isolation ================= In any network, a broken node can damage an entire network. A node that is transmitting legal but spurrious packets can easily saturate a network. With routers, that traffic is localized to the Ethernet segment where the "badly behaved" host is situated. With bridges, this traffic will propagate to the rest of the network. The Internet has heard stories of ARP storms, meltdowns, building firewalls and all sorts of exotic and dangerous sounding events. Bridges make the entire network susceptible to these events, while routers isolate the event to a specific Ethernet segment. Cost ==== Bridges usually cost less than routers, since most of the box is customized hardware with very little software, while routers have simpler hardware but extensive software. Most bridges come with 2 network interfaces vs. routers that usually come with four, so the total system cost tend to get closer when examining the entire network. Security ======== IP (level 3) addresses are logical rather than MAC (level 2) addresses, which are physical. Certain hosts may either accidentally or on purpose, select an IP address that is being used by another host. This is a security problem that has existed in Tcp/Ip since its inception but bridges tend to make the problem worse. Routers separate hosts into subnets, therefore an impersonator will be trapped inside a subnet. Since a bridge doesn't separate hosts into subnets, an impersonator (accidental or malicious) can inflict damage on all segments of the network. Routing ======= This is the area that has lately heated up. Simple bridges only support tree style networks with no closed loops among the Ethernets. Advanced bridges allow closing loops and support redundant links. Some of the advanced bridges handle loops by simply placing one link into standby mode, thereby opening the loop. When one of the links goes down, the "stand-by" link will be enabled for use. Other advanced bridges (Rad's REB) allow for complete network loops. The redundant path support is only supported between two adjacent bridges which limits the amount of network load balancing that can be accomplished. Routers use two basic protocols for forwarding IP packets: RIP - Routing Information Protocol and EGP - Exterior Gateway Protocol. The IP header basically controls how an IP router will function. Some of the fields that are used via routers are: TTL - Time to live - to prevent network loops; security; precedence; TOS - type of service; fragment - to assist transition between different types of media network; record route - to record the list of IP addresses the packet has passed through, useful as an audit trail. Each field in an IP header is there to do a specific function to assist in routing. Any bridge that attempts to perform routing would have to use all of these fields - but at the MAC layer. These bridges are basically reconstructing the IP layer at the MAC layer. In that case, if a bridge supplies the same routing capabilities as a router it would be a router, with the same slower performance throughput. Intelligent bridges only supply a small subset of the routing capabilities available at the IP layer and therefore can claim signficant performance differences. Bridges that attempt to perform routing need to keep track of distinct MAC addresses. They learn as they go along. Initially, the routing will not be optimal, but a learning bridge that performs routing would learn the best path, over a period of time. In small networks this may be feasible, but when interconnecting hundreds of Ethernets, each with hundreds of MAC addresses, these systems cease to function. The traffic between the bridges would be enough to saturate any 64kb link. The Arpanet has seen saturation levels with 300 IP networks interconnected. If routing were performed via MAC level addresses, saturation would have been achieved with but 10% of the defined network. Routers communicate with each other via RIP or EGP and can therefore know the entire status of the network (busy links, high cost links, down links, etc.) and route packets along various paths. With an IP router, some packets may travel a completely different path than others and it is up to the destination IP to reconstruct the packets. Routers choose the best path for each packet based on all the inforamtion they have at their disposal. Routers use the Ip layer with the network structure being viewed as a hierarchical tree. Therefore, routers do not need to cache all IP addresses that exist. Summary ======= There are still major differences between routers and bridges. If you have a small network (three to four Ethernet segments, with no more than 25 MAC addresses) then a routing bridge is the best solution. But if your network comprises many segments and subnets and you have hundreds of MAC addresses defined, then a multiprotocol router is the best solution. The exact metric of where one should be used instead of another is the matter of a holy discussion, and one that I do not intend to get into. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [173@quick.COM] <1987121809370000> From: srg@quick.COM (Spencer Garrett) Newsgroups: comp.protocols.tcp-ip Subject: Re: Routers vs. Bridges Message-ID: <173@quick.COM> Date: 18 Dec 87 09:37:00 GMT References: <12357379979.12.RADIA@XX.LCS.MIT.EDU> Organization: Quicksilver Engineering, Seattle Lines: 4 Actually, it's pretty easy to tell whether a box is a gateway (router) or just a bridge. If it has a network address, it's a gateway. If it doesn't, it's a bridge. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121812460400> Received: from sccgate.scc.com by SRI-NIC.ARPA with TCP; Fri 18 Dec 87 14:51:42-PST Received: by sccgate.scc.com (4.0/870914.1{Enger}) id AA04970; Fri, 18 Dec 87 17:46:04 EST Date: Fri, 18 Dec 87 17:46:04 EST From: oconnor@sccgate.scc.com (Michael J. O'Connor) Message-Id: <8712182246.AA04970@sccgate.scc.com> To: TCP-IP@sri-nic.arpa, pogran@ccq.bbn.com Subject: Re: An ARPANET update Cc: arpaupgrade@bbn.com Ken, Did I misunderstand or has the decision to change the PSNs so as "to behave as they did under the Old End-to_End", at least as regards the RR frame, been changed. The current mode of operation, letting one packet through per circuit setup, seems bizarre (at best). It's also apparently driving my L3 software crazy. Possibly you're not the person to ask the following question of but I've got to start somewhere. When BBN modifies the X.25 behavior (such as changing RR requirements) shouldn't DCA require recertification? My memory is (hopefully) older than your glasses, but I thought X.25 certification was required by DCA. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121814491900> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Fri 18 Dec 87 02:03:45-PST Received: from VM1.BIU.AC.IL by CUNYVM.CUNY.EDU ; Fri, 18 Dec 87 05:03:49 EST Received: by BARILVM (Mailer X1.24) id 6342; Fri, 18 Dec 87 11:22:29 P Date: Fri, 18 Dec 87 11:19:19 P From: Hank Nussbacher Subject: Routers vs bridges revisited To: tcp-ip@sri-nic.ARPA I promised to post my results to the list. Here it is. Once again thanks to all those that supplied comments. Routers vs. Bridges revisited December 18th, 1988 Henry Nussbacher HANK@VM1.TAU.AC.IL Israel Network Information Center ================================= Acknowledgements: Rob Austein - MIT Bob Braden - ISI Scott Brim - Cornell University Charles Hedrick - Rutgers University John Lekashman - NASA Radia Perlman - MIT Yakov Rekhter - IBM G.A Sawkins, D. Crocker: Internetworking Connections: A Comparison of Options, May 1987 This paper will attempt to analyze the differences between routers and bridges. Routers operate at the Network Layer (level 3) and typically understand routing protocols inherent in Tcp/Ip or Decnet or XNS. Bridges operate at the Data Link Layer (level 2) and do not understand anything about any communications protocol other than the physical medium, which is typically an Ethernet. The difference with this paper will be the fact that in addition to "standard" routers and bridges, an attempt will be made to analyze multi-protocol routers and routing bridges. The differences between the two aspects (level II vs. level III) are slowly merging and in the near future the two technologies will meet somewhere in the middle. For further reading, look for the January 1988 issue of IEEE Network which is dedicated to the topic of bridges vs. routers. Performance: =========== Currently, bridges will outperform routers. The numbers generally quoted are that routers forward packets in the high hundreds, while bridges forward packets in the low thousands. Standard bridges like DEC's LANBRIDGE can easily forward 4,000 packets per second, whereas Rad's REB routing bridge claims to forward 2,500 pps. On the other hand, multiprotocol routers claim approximately 1200 pps (Proteon's p4200 and cisco's AGS) under peak conditions. Bridges need to examine every packet whereas routers only look at packets addressed to it. Since the time involved in scanning every packet is enormous, bridges must make use of specially designed hardware. But as bridges attempt to look deeper into each packet to perform such functions as security and access controls, their throughput will drop. As routers use faster technology (i.e. 68020) and special purpose hardware, their throughput should rise. But one aspect that is always ignored when examining the router vs. bridge controversy is the speed of the link used by the router or bridge. When dealing with 2 Ethernet segments connected via a T1 link, any bridge is able to pump out enough packets to utilize the full bandwidth of the T1 link. But when confronted with 64kb data links, both a router and a bridge can easily saturate a 64kb link to capacity. So the bottleneck is moved from the box to the line. If you purchase a bridge because it will pump 4 times as many packets through, but you work with 64kb links, you will be disappointed. On the other hand, if you have been using a router on a T1 link and upgrade to a bridge, you will notice a significant increase in throughput. Multi-media support =================== Routers have the ability to transcend differences in media. If one site runs a 50Mb Hyperchannel, another runs a token ring (i.e. Pronet-4) , and another runs an Ethernet, a router can be used to interconnect all of them. The address translation occurs at a layer above the MAC level, namely the IP layer. Proteon's p4200 supports Ethernet, token ring and x.25 networks. cisco's AGS supports Ethernet and X.25 and they are working on token ring. Current bridges cannot handle multi-media systems. Many bridge vendors are working on supporting multi-media networks. It is expected that both technologies will arrive at the same place in the very near future. The importance of being independent of other sites hardware requirements is a crucial factor in designing an adaptable network. Multi-protocol support ====================== A year ago, bridges were considered the only option if you had networks that needed to handle Tcp/Ip, Decnet and XNS, all at the same time. Today, there are routers available that can handle full Tcp/Ip, XNS's IDP (Internet Datagram Protocol - the equivelent of IP), and Decnet's specifications for a DNA Phase IV, Level 2 area router. These changes in routers required extensive software modifications and testing. Bridges have no problem accepting any new protocol thrown at them. They ignore anything above level II. This is one reason why bridges are ahead of routers in throughput. A "standard" bridge is inherently a simpler box. Software changes ================ Bridges almost never need software changes, since the basic operation is founded on the Ethernet packet format. Software changes are only necessary if new functions need to be added such as accounting, security, access controls or network management. Routers are almost all software. New releases of router software are very common as better algorithms and protocols are developed. This can either be viewed as a positive or negative aspect. The negative aspect is that you are always updating the software in the box and when you find a release level that works, you tend to fixate on it and reject all future updates (or until a major new function is introduced). The positive aspect is that you can easily implement new functionality with the ease of replacing a diskette. Broadcasts and Multicasts ========================= An Ethernet Broadcast is meant to be delivered to all nodes in the network. Bridges are designed to deliver all Broadcast and Multicast messages to all Ethernet segments (although certain bridges can be configured to filter some Multicasts). Routers do not transmit Broadcasts and Multicasts. ARP (Address Resolution Protocol), RWHO, and ROUTED are just three functions in Tcp/Ip that generate a significant amount of Ethernet Broadcast traffic. When analyzing router vs. bridge performance, care should be taken to generate sizable Broadcast traffic. Routers will not be affected, but bridges will. Network Isolation ================= In any network, a broken node can damage an entire network. A node that is transmitting legal but spurrious packets can easily saturate a network. With routers, that traffic is localized to the Ethernet segment where the "badly behaved" host is situated. With bridges, this traffic will propagate to the rest of the network. The Internet has heard stories of ARP storms, meltdowns, building firewalls and all sorts of exotic and dangerous sounding events. Bridges make the entire network susceptible to these events, while routers isolate the event to a specific Ethernet segment. Cost ==== Bridges usually cost less than routers, since most of the box is customized hardware with very little software, while routers have simpler hardware but extensive software. Most bridges come with 2 network interfaces vs. routers that usually come with four, so the total system cost tend to get closer when examining the entire network. Security ======== IP (level 3) addresses are logical rather than MAC (level 2) addresses, which are physical. Certain hosts may either accidentally or on purpose, select an IP address that is being used by another host. This is a security problem that has existed in Tcp/Ip since its inception but bridges tend to make the problem worse. Routers separate hosts into subnets, therefore an impersonator will be trapped inside a subnet. Since a bridge doesn't separate hosts into subnets, an impersonator (accidental or malicious) can inflict damage on all segments of the network. Routing ======= This is the area that has lately heated up. Simple bridges only support tree style networks with no closed loops among the Ethernets. Advanced bridges allow closing loops and support redundant links. Some of the advanced bridges handle loops by simply placing one link into standby mode, thereby opening the loop. When one of the links goes down, the "stand-by" link will be enabled for use. Other advanced bridges (Rad's REB) allow for complete network loops. The redundant path support is only supported between two adjacent bridges which limits the amount of network load balancing that can be accomplished. Routers use two basic protocols for forwarding IP packets: RIP - Routing Information Protocol and EGP - Exterior Gateway Protocol. The IP header basically controls how an IP router will function. Some of the fields that are used via routers are: TTL - Time to live - to prevent network loops; security; precedence; TOS - type of service; fragment - to assist transition between different types of media network; record route - to record the list of IP addresses the packet has passed through, useful as an audit trail. Each field in an IP header is there to do a specific function to assist in routing. Any bridge that attempts to perform routing would have to use all of these fields - but at the MAC layer. These bridges are basically reconstructing the IP layer at the MAC layer. In that case, if a bridge supplies the same routing capabilities as a router it would be a router, with the same slower performance throughput. Intelligent bridges only supply a small subset of the routing capabilities available at the IP layer and therefore can claim signficant performance differences. Bridges that attempt to perform routing need to keep track of distinct MAC addresses. They learn as they go along. Initially, the routing will not be optimal, but a learning bridge that performs routing would learn the best path, over a period of time. In small networks this may be feasible, but when interconnecting hundreds of Ethernets, each with hundreds of MAC addresses, these systems cease to function. The traffic between the bridges would be enough to saturate any 64kb link. The Arpanet has seen saturation levels with 300 IP networks interconnected. If routing were performed via MAC level addresses, saturation would have been achieved with but 10% of the defined network. Routers communicate with each other via RIP or EGP and can therefore know the entire status of the network (busy links, high cost links, down links, etc.) and route packets along various paths. With an IP router, some packets may travel a completely different path than others and it is up to the destination IP to reconstruct the packets. Routers choose the best path for each packet based on all the inforamtion they have at their disposal. Routers use the Ip layer with the network structure being viewed as a hierarchical tree. Therefore, routers do not need to cache all IP addresses that exist. Summary ======= There are still major differences between routers and bridges. If you have a small network (three to four Ethernet segments, with no more than 25 MAC addresses) then a routing bridge is the best solution. But if your network comprises many segments and subnets and you have hundreds of MAC addresses defined, then a multiprotocol router is the best solution. The exact metric of where one should be used instead of another is the matter of a holy discussion, and one that I do not intend to get into.  ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121815192200> Received: from uc.msc.umn.edu by SRI-NIC.ARPA with TCP; Fri 18 Dec 87 19:20:35-PST Received: by uc.msc.umn.edu (5.51/4.40.2) id AA26455; Fri, 18 Dec 87 21:19:22 CST Date: Fri, 18 Dec 87 21:19:22 CST From: slevy@umn-rei-uc.arpa (Stuart Levy) Message-Id: <8712190319.AA26455@uc.msc.umn.edu> To: JBVB@ai.ai.mit.edu, dcatla!dnwcv@gatech.edu Subject: Re: More than one IP (sub)network on one ethernet cable Cc: big-lan@suvm.acs.syr.edu, tcp-ip@sri-nic.arpa Returning an error if a user tries to send to a subnet for which there's no route seems pretty reasonable to me too. But there should be a way to tell the software (and the routing information system...) that multiple nets are directly attached to the same wire. We've recently had trouble with this. Both 4.2 and 4.3 BSD UNIX allow for specifying multiple (sub)nets on one wire by creating interface routes: route add {(sub)network-X} {local-interface-address} 0 This works for routing packets. But it's not fully integrated. If you try to set up a route via a gateway which is on a network set up this way, e.g. route add {othernetwork} {gateway-on-network-X} 1 you get a Network unreachable error. Gateways are only allowed on the (sub)nets on which the local host has interface addresses. The only way we could think of to work around this, aside from changing the kernel routing code (easy, but not accessible on all machines) was with an ARP kludge. For every gateway on a wire, we dedicate a fake IP address in each subnet on that wire. Everybody on subnet-X routes to gateway-Y by specifying a route to "subnet-X-fake-address-for-Y". Gateway Y actually has no interface with that address, but we arrange to have some machine reply to ARPs for that IP address, giving Y's Ethernet address. It's pretty awful, and can't be extended very far, but does appear to work in our case -- where it's sufficient to have just one gateway Y, which can be everybody's default route. The problem would disappear if we actually created a gateway for each subnet, but this would be unpalatable to those groups having only a handful of hosts on their subnets. It would also disappear if we didn't use subnetting at all, connecting segments solely with MAC-layer bridges, but the isolation provided by IP routers is desirable for those with large collections of hosts. Looking at the subnetting-related RFCs (917, 932, 936, 950), it's not clear whether having multiple subnets coexist on one cable was intended or not. Would any internet architects care to comment on this? Stuart Levy Minnesota Supercomputer Center University of Minnesota slevy@uc.msc.umn.edu, (612) 626-0211 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712182139.AA04713@ucbvax.Berkeley.EDU] <1987121817160000> From: art@ACC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: RE: bridges vs routers Message-ID: <8712182139.AA04713@ucbvax.Berkeley.EDU> Date: 18 Dec 87 17:16:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 18 >Actually, it's pretty easy to tell whether a box is a gateway (router) >or just a bridge. If it has a network address, it's a gateway. If it >doesn't, it's a bridge. Actually, there is no reason why a bridge cannot have both a MAC address and even a network level address. With the introduction of "brouters" (such as Wellfleet's) the distinction is getting very blurred. Having a network level address for a bridge will be desireable as standard network management protocols emerge. I believe that the real distinction has to made on the basis of what level of protocol address that packet forwarding is decided. Art Berggreen art@acc.arpa ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2528@dcatla.UUCP] <1987121819551200> From: dnwcv@dcatla.UUCP (William C. VerSteeg) Newsgroups: comp.protocols.tcp-ip Subject: Re: More than one IP (sub)network on one ethernet cable Message-ID: <2528@dcatla.UUCP> Date: 18 Dec 87 19:55:12 GMT References: <301351.871217.JBVB@AI.AI.MIT.EDU> Reply-To: dnwcv@dcatla.UUCP (William C. VerSteeg) Organization: DCA Inc., Alpharetta, GA Lines: 36 The topic of discussion is how to tell a device that an IP network other than his own is on his local cable. This _is_ an atypical configuration, but one that can arise in the following situation. A user has two ethernet cables joined by a link level (hardware address) bridge. From each of these cables he has lots of IP traffic to the world at large. He would want an IP router for each cable. The network numbers should be different to limit traffic on the link level bridge. If the IP network numbers were the same, the world would be forced to guess which IP router to use, thus increasing load on the link level bridge. Assuming distinct IP network numbers, an IP speaking device on the first cable would then think that it had to go out the IP router to the world. Each packet would then rattle around the world, then go back in the second cable's router to gain access to a machine on the other cable. A more efficient, direct method would be to use the link level bridge. This could be done in two ways that I know of. 1- Each device (router or non-router) could be told of networks that co-reside with his own on a particular interface. Are there any implementations that do this? Does anybody have source code to a package that does this? 2- The router on each cable could know about multiple networks on a single interface. The router could then send ICMP redirects. These redirects should straighten the route. Proteon claims to support this. Sun, among others does not. Are there any other implementations that do this? Does anybody have source code to a package that does this? Thanks Bill VerSteeg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1482@rtech.UUCP] <1987121819580300> From: daveb@rtech.UUCP (Dave Brower) Newsgroups: comp.unix.wizards,comp.protocols.tcp-ip Subject: OOB problems, wisdom anyone? Message-ID: <1482@rtech.UUCP> Date: 18 Dec 87 19:58:03 GMT Reply-To: daveb@rtech.UUCP (Dave Brower) Organization: Relational Technology Inc, Alameda CA Lines: 44 Some people here have been trying to use the OOB mechanism to send "expedited data" between processes. No one here is all that familiar with using it, and they have run into some problems that make them want to give up and turn to something else. I'd appreciate hearing general thoughts about using the BSD oob mechanism for IPC, and specific comments on the problems they report below. I will forward responses to the interested parties. Thanks! -dB ------- forwarded message describing OOB headaches. 1. "Leapfrogging:" The fatal aspect of OOB data is that when two socket sends for OOB data are issued in sequence before the first has been read, the second send passes the first and is read out of sequence by the recipient. This is a gross violation of the stream socket abstraction and makes the mechanism fundamentally unusable except in the simplest and most restricted cases, not the situation here. 2. OOB receive loop: When an application has been notified of the availability of OOB data and issues a receive for it, a subsequent receive for normal data must be issued to "clear" the OOB notification mechanism. If instead a select requesting notification of OOB data is issued without an intervening receive for normal data, the caller is immediately notified of the availability of OOB data: the same data just received. This is at best a form of bizarre and undocumented behavior; at worst a serious bug. 3. The integer-character problem: The IOCTL system call to determine whether one has reached the OOB data in the stream is documented to return a character. Several coding examples support this. In fact, an integer is returned. It was necessary, after considerable grief, to go to kernel source code to find that in fact an integer is returned. It is not known how many similar major documentation errors exist. Each could cause major delays, with time spent in fruitless debugging. -- "If it was easy, we'd hire someone cheaper than you to do it." {amdahl, cbosgd, mtxinu, ptsfa, sun}!rtech!daveb daveb@rtech.uucp ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12359521472.59.STEVENS@A.ISI.EDU] <1987121819591100> From: Stevens@A.ISI.EDU (Jim Stevens) Newsgroups: comp.protocols.tcp-ip Subject: Much More Idle Chatter About Reference Models Message-ID: <12359521472.59.STEVENS@A.ISI.EDU> Date: 18 Dec 87 19:59:11 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: Rockwell International Lines: 409 DISCUSSION OF LAYERED PROTOCOL MODEL Jim Stevens (Stevens@A.ISI.EDU) 18 December 1987 INTRODUCTION Recently CMC has distributed a nice multi-colored wall chart showing the DoD Internet Architecture and the protocols at each layer. I only list CMC as reference because their chart caused a flurry of e-mail messages on TCP-IP. Note that their chart is just the latest of many papers and reference-type-material to contain the same type of problems. Since many of you may not have seen the CMC chart, it is included for reference as Figure 1 at the end of this message. There are 2 problems with this chart: (1) Location of EGP, GGP, and HMP and (2) Incorrect Physical and Data Link protocols under some networks (especially radio networks). LOCATION OF NETWORK MANAGEMENT PROTOCOLS The location of EGP, GGP, and HMP have caused a flurry of e-mail messages on TCP-IP. These 3 protocols are network management protocols. There has been a lot of work in the last decade on protocol architectures which include network management that provide an answer to the question of the network management protocol location. Some of the efforts include ISO (reference ISO 7498 Part 4), CCITT (ISDN, see recommendation I.320), and AT&T (J.W. Timko, AT&T Technology, Vol 2, No 3). I intend to locate EGP, GGP, HMP, and ICMP within the ISDN protocol stack using the OSI management structure categories. All three of the above named efforts basically came up with the same architecture. These architectures just added a new dimension to the current the 7-layer OSI reference model. The 7-layer OSI model contains only 1 dimension, which I'll call the X dimension. The X dimension described the different services performed upon User data as it is sent from one host to another. The new architectures added a Y dimension which showed the different functions which must be performed at each layer. The three different functions that are performed are: 1. The (N)-layer performs some service upon user data and send the data onward. (This function is identical to that described in the original X dimension.) 2. The (N)-layer performs signaling between the different layers. (For packet switched networks this signaling is typically provided in the packet headers.) 3. The (N)-layer performs internal management decisions. Figure 2 shows the ISDN protocol stack and the 2 dimensions of their model. The user service function is the vertical stack of layers labeled with a U. The signaling function is the vertical stack of layers labeled with a C. The management function is the vertical stack of layers labeled with an M. The OSI management framework describes 3 management structure categories: 1. Systems Management System Management Application-Process (SMAP) System Management Application-Entity (SMAE) 2. (N)-layer management coordinates multiple instances of communications 3. (N)-layer operation coordinates single instance of communications The Systems Management is an application process which can use the entire protocol stack when communicating. The difference between a Systems Management application process and another user application process (such as Terminal Emulation) is that the Systems Management application has access to the control/management data within each of the protocol layers. EGP, GGP, and HMP are system management applications. The (N)-layer management/operation are processes within the (N)-layer. Thus these processes can only use the protocols which lie under them. ICMP is a Network-layer management process. INCORRECT PHYSICAL AND DATA LINK PROTOCOLS UNDER SOME NETWORKS The CMC chart has confused the Physical and Data Link protocols used within some networks and the Physical and Data Link protocols used to interface to these networks. This has been a common problem and has shown up in several different papers. Figure 3 shows a layered protocol chart which did not have this problem. Since I have worked on the DARPA Packet Radio Program and its follow on Survivable Adaptive Networks (SURAN) Program, I will use older fielded Improved Packet Radio (IPR generation Packet Radios) as an example to explain how the confusion arises. Normally, the 7 protocol layers are implemented in a single box. The protocol drivers are then contained within either the OS kernel or applications residing above the OS. This is not true however in Packet Radio, where the 7 protocol layers are implemented in 3 different boxes interconnected via a BBN 1822 line. Figure 4 shows how the DOD protocols stack is implemented in 3 boxes interconnected together with BBN 1822. The Hosts interface to the Packet Radio Network via a Host Interface Unit (HIU). The actual interface between the HIU and the Hosts is a defined host access protocol running on top of BBN 1822. The hosts implements the Session and higher layer protocols such as FTP and mail. The HIU interface to the actual Packet Radios (PRs) using a defined device access protocol running on top of BBN 1822. The HIUs implement the Internet and Transport protocols such as IP and TCP. The PRs communicate to each other using the PR Channel Access Protocol (CAP) at the network and upper data link layers, CSMA at the lower data link layer, and spread spectrum at the physical layer. The PRs thus implement the Network, Link, and Physical layers. There is often confusion between the host or device interface to Packet Radio and the actual protocols used within Packet Radio. That is why the CMC chart shows BBN 1822 as the Packet Radio Network Physical protocol instead of spread spectrum. It is fairly easy to catch this type of error for radio networks, since the radio network physical layer must be some sort of RF transmission scheme such as Spread Spectrum (SS) or Amplitude Modulation (AM). ------------------------------------------------------------------------------ Figure 1 Layered Protocol Model Taken from CMC chart, Fall 1987 DOD MODEL +-------+ +------+ +-------+ +--------------------------+ +-------+ Appli- | File | | Mail | | Term- | | User Programs | | Name | cation | Trans-| | Text | | inal | | | | Server| | fer | | RFC | | Emul- | | | | | | Server| | 822 | | ation | | | | | +-------+ +------+ +-------+ +--------------------------+ +-------+ ^ ^ ^ ^ ^ ^ ^ . . . . . . . . . . . . . . v v v v v v v +-------+ +------+ +-------+ +-----------+ +------+ +-----+ +-------+ Util- | FTP | | SMTP | |Telnet | | NETBIOS | | TFTP | | NFS | | NSP | ity | MIL | | MIL- | | MIL- | | RFC | | | | | | | | STD | | STD | | STD | | 1001/ | | | | | | RFC | | 1780 | | 1781 | | 1782 | | 1002 | | | | | | 882 | +-------+ +------+ +-------+ +-----------+ +------+ +-----+ +-------+ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . . . .............................. ............................ . . v v +-----+ +-----+ +-----+ +------------------+ +-------+ Trans- | EGP | | GGP | | HMP | | TCP | | UDP | port | | | | | | | MIL-STD 1778 | | RFC | | | | | | | | | | 768 | +-----+ +-----+ +-----+ +------------------+ +-------+ ^ ^ ^ ^ ^ . . . . . . . . . . .................................................... . v Inter- +------------------------------------+----------------+ net- | Internet Protocol (IP) | ICMP | work | MIL-STD 1777 | RFC 792 | +------------------------------------+----------------+ ^ . . .............................................. . . . . . . . . . . v v v v v +-----+ +-------+ +---------+ +------------+ +--------------+ Net- | Pkt | | BBN | | Pkt | | CCITT X.25 | | Ethernet ARP | Work |Radio| | 1822 | |Satellite| |Packet Layer| | RFC 826 | +-----+ +-------+ +---------+ +------------+ +--------------+ ^ ^ ^ ^ ^ ^ . . . . . . . . . . . . ....... ......... ....... . . . . . . . . . . . . . . v v v v v . +------+ +-----+ +-----+ +-----+ +--------------+ +-------+ Data . | BBN | | BBN | |LAPB | |LAPB | |IP / Ethernet | | IEEE | Link . | HDH | | VDH | | BSC | |HDLC | | RFC 894 | | 802.2 . | | | | | | | | +--------------+ +-------+ . | | | | | | | | ^ ^ . | | | | | | | | . . . | | | | | | | | . ....................... . | | | | | | | | . . . . . . | | | | | | | | v v v v v . | | | | | | | | +------+ +-----+ +-----+ +----+ . +------+ +-----+ +-----+ +-----+ | | | | | | | | . ^ ^ ^ ^ | | | | | | | | . . . . . | | | | | | | | . .......................... | | | | | | | | . . . . . | | | | | | | | v v v v v | | | | | | | | +----+ +-----+ +-----+ +------+ +------+ | | | | | | | | Phys- |BBN | |CCITT| | EIA | | EIA | |MilStd| | IEEE | |IEEE | |IEEE | |FDDI| ical |1822| |V.35 | |RS449| |RS232C| | 188C | |802.3 | |802.4| |802.5| | | +----+ +-----+ +-----+ +------+ +------+ +------+ +-----+ +-----+ +----+ ------------------------------------------------------------------------------ FIGURE 2. ISDN Protocol Stack Taken from CCITT I.320 Control User Data System Management ________ ________ ________ | \ \ | \ \ | \ \ | \ \ | \ \ | \ \ \ \ ______\ \ \ ______\ \ \ ______\ \ | | \ | | o \ | | \|______| \|______| o \|______| @ @ o o @ @ @ o o @ @ oooooo@ooooooooo o @ @ o @ o @ @ o @ ooooooooooo @ ______@____ _o_____@_ o @ | \ @ \o @ \o @@@@@@@@@ | \ C o \ @ o \ @ | \ ________\@ o \ @ | \ |\ @ \ o M @\ | \ | \ U o\ @ \ | \ | \ _________\_________\ | \ |\ | | | | \ | \ | 7 - Appl | | | \ | \|__________| | | \ |\ | | | | \ | \ | 6 - Pres | | | \ | \|__________| | | \ |\ | | | | \ | \ | 5 - Sess | | | \ | \|__________| | | \ |\ | | | | \ | \ | 4 - Tran | | | \ | \|__________| | | \ |\ | | | | \ | \ | 3 - Netw | | ______________| \ | \|__________| | . \ |\ | | | . \ | \ | 2 - Link | | . . \ | \|__________| | . . \ | | | . . \ | 1 - Phys | | . . _______________\|__________|_________| . Physical Media | . ___________________________| ------------------------------------------------------------------------------ Figure 3. Layered DOD Reference Model Chart Taken from "Tactical Information Exchange (TIE) Framework Development (For the 1990s Time Frame" October 1981 +-----+ +----------+ +------------+ Application | MTP | |Multimedia| | Conference | | | |Message | | | +-----+ +----------+ +------------+ ^ ^ ^ ^ . . . . . . . . . . . . +------+ +---+ . . +----+ +------+ . . Utility |TELNET| |FTP| . . |TFTP| |Name | . . | | | | . . | | |Server| . . +------+ +---+ . . +----+ +------+ . . ^ ^ . . ^ ^ . . . . . . . . . . . . . . . . . . ................. ....... . . . . . . . . . . v v v . +------------------+ +---------+ +-----+ +--------+ . Transport | TCP | | UDP | | GGP | | NVP II | . +------------------+ +---------+ +-----+ +--------+ . ^ ^ ^ ^ . . . . . . . . . . . ................................ ......... . . . . v v +-----------------------------------------------+ - - - - - - - - - Internet | Internet Protocol | Stream Protocols ! +-----------------------------------------------+ - - - - - - - - - ^ . . ...................................................... . . . . . . . . . . . . v v v v v v +----------+ +------+ +------+ +-----+ +-----+ +------+ Network | ARPANET | |SATNET| |CCITT | |PRNET| |JTIDS| | DIN | | HOST/IMP | | | | X.25 | | | | | |2 SIP | +----------+ +------+ +------+ +-----+ +-----+ +------+ ^ ^ ^ ^ ^ ^ . . . . . . . . . . . . .............. ......... . . . . . . . . . . . . . . . . . . . . . . v v . v v v v v v +----+ +----+ . +-----+ +----+ +-----+ +-----+ +-----+ +------+ Link |HDH | |VDH | . | VDH | |HDH | |HDLC | |CSMA | |TDMA | |ADCCP | |HDLC| |RTP | . | RTP | |HDLC| | | | | | | | | +----+ +----+ . +-----+ +----+ +-----+ +-----+ +-----+ +------+ ^ ^ . ^ ^ ^ ^ ^ ^ . . . . . . . . . . . . . . . . . . v v v v v v v v v +---+ +-----+ +----+ +-----+ +----+ +-----+ +-----+ +-----+ +------+ Physical |M/W| |Modem| |BBN | |Modem| |M/W | |X.21 | | SS | |SS/FH| | M/W | | | | | |1822| | | | | | | | | | | | | +---+ +-----+ +----+ +-----+ +----+ +-----+ +-----+ +-----+ +------+ Key: ADCCP Advanced Data Communications Control Procedures DIN 2 SIP AUTODIN II Segment Interface Protocol FH Frequency Hop HDH HDLC Distant host JTIDS Joint Tactical Information Distribution System MTP Mail-Transport Protocol M/W Modem / Wire NVP II Network Voice Protocol PRNET Packet Radio Network RTP Real Time Protocol SATNET (Experimental) Satellite Network SS Spread Spectrum TDMA (Synchronous) Time Division Multiple Access VDH Very Distant Host ---------------------------------------------------------------------------- Figure 4 Host Interface to Packet Radio +---------------+ | | Host Application |FTP, Mail, etc.| | | Utility | | +---------------+ ^ . BBN 1822 and defined host access protocol . v +---------------+ | | Host Transport | TCP | Interface | | Unit | | Internetwork | IP | | | +---------------+ ^ . BBN 1822 and defined device access protocol . v +---------------+ | | Packet Network | Channel | Radio | Access | | Protocol | | | | | Link | CSMA | | | | | Physical | Spread | | Spectrum | | | +---------------+ ---------------------------------------------------------------------------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712182125.AA21125@ACC-SB-UNIX.ARPA] <1987121821254400> From: chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) Newsgroups: comp.protocols.tcp-ip Subject: TCP on the MAC Message-ID: <8712182125.AA21125@ACC-SB-UNIX.ARPA> Date: 18 Dec 87 21:25:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Does anyone have any solid information or(even better) practical experience with a TN3270 emulation that runs on the MAC? I have heard from Tim Krauskaupf at University of Illinois that they have provided source to several locations but haven't heard anything back yet. Surely with the incredible proliferation of MAC's someone wants to connect them to the Inter- net? Please send your thoughts to my mailbox or feel free to call if you have life or death info... Chris VandenBerg - ACC chris@acc-sb-unix.arpa 805-963-9431x296 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3076@phri.UUCP] <1987121823073300> From: roy@phri.UUCP (Roy Smith) Newsgroups: comp.protocols.tcp-ip Subject: Re: Routers vs. Bridges Message-ID: <3076@phri.UUCP> Date: 18 Dec 87 23:07:33 GMT References: <12357379979.12.RADIA@XX.LCS.MIT.EDU> <173@quick.COM> Reply-To: roy@phri.UUCP (Roy Smith) Organization: Public Health Research Inst. (NY, NY) Lines: 13 In article <173@quick.COM> srg@quick.COM (Spencer Garrett) writes: > Actually, it's pretty easy to tell whether a box is a gateway (router) > or just a bridge. If it has a network address, it's a gateway. If it > doesn't, it's a bridge. I'm really out of my league here, so don't hesitate to correct me if I'm wrong, but isn't it possible to have a bridge which has no IP address of its own as far as moving packets around goes, but does have an IP address for communicating with the box for control purposes? -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12359574041.18.SATZ@MATHOM.CISCO.COM] <1987121900475700> From: SATZ@MATHOM.CISCO.COM (Greg Satz) Newsgroups: comp.protocols.tcp-ip Subject: Re: An ARPANET update Message-ID: <12359574041.18.SATZ@MATHOM.CISCO.COM> Date: 19 Dec 87 00:47:57 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 51 From: Ken Pogran Subject: An ARPANET update We believe that what's happening here is that the receiving host's X.25 isn't sending an RR to the PSN for the first data packet it receives when the PSN opens the VC. Under the New End-to-End Protocol, when going from an 1822-connected host to an X.25-connected host, the PSNs wait to see an RR for the first packet before subsequent packets are sent from the source PSN to the destination PSN (and a RFNM is returned to the originating 1822-connected host). Under the Old End-to-End Protocol, subsequent packets were sent as soon as the receiving host accepted the VC (up to the limit of the window); this could result in a RFNM being sent to the originating host before the destination host actually acknowledged the packet via an RR! (The different behavior of the New End-to-End was intended as a fix for what was a bug, or perhaps a "cheat", in the old design with respect to the meaning of a RFNM.) In the case of a symmetric traffic flow, an RR is typically piggybacked on a data packet. But, as was mentioned above, traffic flows involving Mailbridges frequently aren't symmetric. Typically, X.25 implementations send an RR after some brief timeout if there's no user packet going out over the VC on which to piggyback the RR. But if there is neither traffic nor a timeout, and no RR is sent, the flow will cease as described above. We're going to change the PSNs to behave as they did under the Old End-to-End in this regard, at least temporarily. This will give us time to work with implementors to resolve this issue. The X.25 specification ommits any explanation on when to send RR acknowledgements. For a low bandwidth link, it is seems reasonable to wait until the window is (almost) full before sending an RR. It is also reasonable to want to send an RR (if you don't have an outgoing data packet ready) after every received data packet when the acknowledgements must traverse the network instead of having local significance. Our implementation has a parameter that lets you send an acknowledgment when N input data packets have been seen. An RR acknowledgement is sent if there aren't any outgoing data packets. The drawback is that RRs will be sent more often then necessary. Adding a timer is a very good idea. After rereading the "Procedures for flow control" I came across the section of "Delivery confirmation". I don't know if it is worth it, but maybe the D-bit could be used? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712190048.AA22086@violet.berkeley.edu] <1987121900484500> From: ucdla@VIOLET.BERKELEY.EDU (U.C. Div of Library Automation) Newsgroups: comp.protocols.tcp-ip Subject: tcp ip mailing list Message-ID: <8712190048.AA22086@violet.berkeley.edu> Date: 19 Dec 87 00:48:45 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 is there something wrong with the tcp mailing list. i havent gotten anything from it in 3 weeks? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1642@faline.bellcore.com] <1987121906102000> From: karn@faline.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Much More Idle Chatter About Reference Models Summary: Fundamental problems with reference models Message-ID: <1642@faline.bellcore.com> Date: 19 Dec 87 06:10:20 GMT References: <12359521472.59.STEVENS@A.ISI.EDU> Organization: Bell Communications Research, Inc Lines: 18 I think the reason there is so much argument about where things like network management protocols and packet radio protocols "go" in the ISO/OSI reference model is that the OSI reference model itself is fundamentally flawed. Face it, the OSI reference model is over a decade old, and even then it was inadequate to describe real working networks. (As opposed to, say, the paper networks ISO is *still* building...) What's far more important is the relationship between the various protocol modules (i.e., who runs "on top of" who), not which arbitrary "layers" they "belong" to. See Postel and Cohen's paper "The ISO Reference Model and Other Protocol Architectures" for an iron-clad proof that N = N+1 for 1 <= N <= 7, according to the ISO model. My math professors used to tell me that when you get a result like this and you haven't made an error in your logic, then your fundamental assumptions must be wrong... Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7899@g.ms.uky.edu] <1987121906180600> From: david@ms.uky.edu (David Herron -- Resident E-mail Hack) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP protocol on a chip(s) Keywords: Faster IP? MNP chip Message-ID: <7899@g.ms.uky.edu> Date: 19 Dec 87 06:18:06 GMT References: <4994@elroy.Jpl.Nasa.Gov> <1969@geac.UUCP> Reply-To: david@ms.uky.edu (David Herron -- Resident E-mail Hack) Organization: U of Kentucky, Mathematical Sciences Lines: 58 In article <1969@geac.UUCP> daveb@geac.UUCP (David Collier-Brown) writes: >In article <4994@elroy.Jpl.Nasa.Gov> david@elroy.Jpl.Nasa.Gov (David Robinson) writes: >>To increase TCP/IP performance has anyone looked into making an IP >>protocol chip or chipset? > .... One I know of in some detail is MNP, an combined >sync/async facility with Network, Host-host and Applications layers >(ie, it fits the ARM). ... > ... Another is the telebit "UUCP emulation" facility in their >high-speed modems. er.. I beg to differ ... At least in the Telebit modems there's a 68000 and a whoooole bunch of ROM That's not the same sort of thing as people are talking about with this Chesson Protocol Engine. I think (but don't know for certain) that MNP modems are in the same league. One of the lessons of recent computer history is that systems designers should, once the issues are understood, put things into hardware when there is gain to be made from doing so. For instance, you can make a machine that has a fairly "slow" processor and make it do really neat graphics with the addition of specialized hardware. (I'm talking about Amiga's here ... compare it's graphics to Mac's and realize that they're using essentially the same processors). So, to the extent that some of the gut-level things about routing and protocols and so forth are well-understood ... YES ... PLEASE PUT THESE THINGS ONTO A CHIP! For instance, one obvious thing to have is a co-processor for computing checksums. And not just one or two types of checksums, but LOTS of types of 'em. An example here is the DUP-11 we have here running our connection to BITNET. Either that board or the board from MDB (was it a DUPV-11 look-alike?) would run at some huge bit-rate like 500K baud. But it would only run at that baud rate if we were using a protocol which used the right kind of checksum. But since we're doing BISYNC to an IBM machine and the type of checksum used for BISYNC is different from those which DEC (MDB?) supplied on the board. Therefore this board we have eats up our 11/750 it's installed in because the Vax has to calculate the checksums itself. (Note, it's been awhile since I've looked at the details here ... I may have some of them wrong). > Neither of the above runs on an unprogrammable chip: even the >chip-level MNP being developed by two people on this net has a z80 >as part of the silicon. Oh sorry, you do understand ... > ... Deciding exactly what to put on >the chip is a design/marketing (ie $) issue. Yeah! -- <---- David Herron -- The E-Mail guy <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- Winter health warning: Remember, don't eat the yellow snow! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987121907204500> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Sat 19 Dec 87 12:46:00-PST To: "Michael J. O'Connor" cc: TCP-IP@SRI-NIC.ARPA, pogran@CCQ.BBN.COM, arpaupgrade@BBN.COM, malis@CC5.BBN.COM Subject: Re: An ARPANET update In-reply-to: Your message of Fri, 18 Dec 87 17:46:04 -0500. <8712182246.AA04970@sccgate.scc.com> Date: Sat, 19 Dec 87 15:40:45 -0500 From: Andy Malis Mike, If I may reply for Ken, letting one packet through per circuit setup was never an intended mode of operation, and it only seems to be affecting the Sun X.25 package. Every new release of PSN software has to pass a rigorous DCA test plan. PSN 7.0 has already passed that test. Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712191829.AA21329@gateway.mitre.org] <1987121918292400> From: tsuchiya@gateway.mitre.ORG (Paul Tsuchiya) Newsgroups: comp.protocols.tcp-ip Subject: Re: More than one IP (sub)network on one ethernet cable Message-ID: <8712191829.AA21329@gateway.mitre.org> Date: 19 Dec 87 18:29:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 I have a hard time believing that optimazation of non_local traffic through a bridge is a valid reason for going through the hassle of having two network numbers for what is otherwise a single network. If you have so much traffic that you need two gateways, then have two, but give them the same network number. If you really want to keep traffic from segment a on segment a and traffic from segment b on segment b, then put a gateway between the two Ethernet segments. What is the point between putting two different Internet networks on a single extended LAN? Is this commonly done? Is there a good reason that is not occuring to me? _________________________________________________________________ Paul F. Tsuchiya The MITRE Corp. tsuchiya@gateway.mitre.org 7525 Colshire Dr. 703-883-7352 McLean, VA 22102 USA _________________________________________________________________ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12359779647.19.STEVENS@A.ISI.EDU] <1987121919372300> From: Stevens@A.ISI.EDU (Jim Stevens) Newsgroups: comp.protocols.tcp-ip Subject: RE: Re: Much More Idle Chatter About Reference Models Message-ID: <12359779647.19.STEVENS@A.ISI.EDU> Date: 19 Dec 87 19:37:23 GMT References: <1642@faline.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: Rockwell International Lines: 80 Phil, I tried to address 2 problems in my note about protocol reference models: (1) where do things like network management protocols belong in general and (2) identification of a common problem in charts showing the packet radio network protocol layering. It is true that the answer to the first problem depends upon a persons acceptance of the different protocol reference models. However the second problem is independent of whether there are always 7 layers in a network or whether there are N layers in a network or whether layers can be skipped (i.e. null layers). In fact, I have seen this second problem in many different papers using both the ISO/OSI reference model and any of the several slightly different DoD reference models. The second problem is caused when people confuse the host/terminal interface to a network as being the protocols which run within the network. This has especially been true for radio networks (such as Packet Radio and Packet Satellite). I can create an alternate example of this confusion for the Ethernet. My PC is connected to a server on the Ethernet via an RS232 link. If I were to confuse my interface to the Ethernet as being the actual protocols used within the Ethernet, then I would say that the physical protocol used in the Ethernet is RS232 instead of IEEE 802.3. However, most of us would agree that this is incorrect. The reason why the confusion with radio networks continues is because there are many more people who use other networks such as Ethernet than Packet Radio. Thus when most people write a paper and create a chart, they do like I do. They (and I) look at earlier papers and assume that the information in the areas that they do not know is correct. Thus the goal of my earlier message with respect to this second problem was to provide the correct information about what Link and Physical Layer protocols are used within the DARPA Packet Radio Networks, and explain that there is confusion between interface protocols and network protocols so that this type of error is repeated less often. Jim P.S. I do not intend to argue about the absolute correctness of the OSI model for all types of actual networks. (I myself can list examples of things like networks that appear to be just a link to another network which then appears to be just a link to yet another higher network.) But the most important thing about the OSI model is that is has become ubiquitous and is a useful way to describe concepts. I would classify all of the existing network management protocols as being of 2 types: (a) lying within the network layer (ex. ICMP) or (b) lying above the network layer (ex. EGP). This is the same type of structure breakdown that was decided upon in the protocol model work that I referenced in my earlier message. Thus the goal of my earlier message with respect to the this first problem was to indicate that while I agree that EGP, GGP, and HMP lie above the Internet Protocol, I do not consider them to be transport protocols, and provide reference to the good work that is being performed on network management architectures. In particular, I feel that the CCITT I.320 Recommendation on the ISDN Protocol Reference Model contains many useful ideas. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712192118.AA26661@ucbvax.Berkeley.EDU] <1987121920404500> From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: An ARPANET update Message-ID: <8712192118.AA26661@ucbvax.Berkeley.EDU> Date: 19 Dec 87 20:40:45 GMT References: <8712182246.AA04970@sccgate.scc.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Mike, If I may reply for Ken, letting one packet through per circuit setup was never an intended mode of operation, and it only seems to be affecting the Sun X.25 package. Every new release of PSN software has to pass a rigorous DCA test plan. PSN 7.0 has already passed that test. Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712192222.AA04523@uc.msc.umn.edu] <1987121922220000> From: slevy@UMN-REI-UC.ARPA (Stuart Levy) Newsgroups: comp.protocols.tcp-ip Subject: Re: More than one IP (sub)network on one ethernet cable Message-ID: <8712192222.AA04523@uc.msc.umn.edu> Date: 19 Dec 87 22:22:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 The reason we do it is something like this, in my opinion ... a) Some of us want IP-router like isolation, so we either get a bunch of separate networks or we do subnetting. Being good Internet citizens we're doing the latter. b) Not all of us want to do subnetting (who needs a gateway for 3 machines). c) Not all of us can do subnetting (some implementations still can't). d) All subnetting implementations available to us demand that ALL subnets on a net be of the same size. e) We like to put separate groups in separate chunks of address space, with the idea that they can choose to become a subnet later without having to change all their IP addresses. f) We have enough groups who might potentially become subnets that we want to allow for a couple of hundred at least, and so chose class-C subnetting on our class-B net. g) The resulting subnets are too small to stuff all miscellaneous hosts in just one of them, even if we wanted to. One or a few large subnets plus a lot of small ones would be nice but we can't get it. A hierarchy of subnets would be nice too, but we can't get that either, at least not if we follow the normal rules. Stuart Levy, slevy@uc.msc.umn.edu Minn. Supercomputer Center & U. of Minnesota ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712200146.AA17980@ARES.MIT.EDU] <1987122001460400> From: martillo@ATHENA.MIT.EDU Newsgroups: comp.protocols.tcp-ip Subject: More than one IP (sub)network on one ethernet cable Message-ID: <8712200146.AA17980@ARES.MIT.EDU> Date: 20 Dec 87 01:46:04 GMT References: <8712191829.AA21329@gateway.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Wouldn't it be reasonable to have two network numbers if some machinese were relatively more secure and was encrypting the IP packets? It might be desirable to have a mail gateway between the somewhat more secure encrypted (logical) network and the unencrypted (logical) network. Yaqim Martillo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712200230.AA01623@gyre.umd.edu] <1987122002304900> From: chris@GYRE.UMD.EDU (Chris Torek) Newsgroups: comp.protocols.tcp-ip Subject: RE: Re: Much More Idle Chatter About Reference Models Message-ID: <8712200230.AA01623@gyre.umd.edu> Date: 20 Dec 87 02:30:49 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Sure, the ISORM is useful. But like the formula for adding velocities, v_sum = v_1 + v_2 one should remember that it is, in a fundamental sense, wrong, or perhaps better to say *limited*. I imagine what Phil dislikes is that ISORM proponents never mention the limitations. Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712200254.AA22098@clutx.clarkson.edu] <1987122002540300> From: nelson@CLUTX.CLARKSON.EDU (Russell Nelson) Newsgroups: comp.protocols.tcp-ip Subject: A,B,C-class vs subnetting Message-ID: <8712200254.AA22098@clutx.clarkson.edu> Date: 20 Dec 87 02:54:03 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 As far as I can tell, subnetting is a generalization of the A, B, and C class concept. Can someone explain this as sweetly as the recent paper on gateways versus routers did? Even if you can't do as good a job, I'd still like to know :-). -russ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122008042500> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Sun 20 Dec 87 10:04:38-PST Received: from NIHCU.BITNET by CUNYVM.CUNY.EDU ; Sun, 20 Dec 87 13:04:45 EST To: tsuchiya@gateway.mitre.org cc: TCP-IP@SRI-NIC.ARPA From: "Roger Fajman" Date: Sun, 20 Dec 87 13:04:25 EST Subject: Re: More than one IP (sub)network on one ethernet cable > What is the point between putting two different Internet networks > on a single extended LAN? Is this commonly done? Is there a good > reason that is not occuring to me? In the case of multiple subnets on one LAN with a class B address, a reason is that you have many small subnets and a few large ones. If you set your subnet mask to accomodate the size of the large subnets, then you may not have enough subnet numbers to accomodate the quantity of small subnets that you have. The reverse is also true. One possible solution is to have the subnet size be small, but assign multiple subnet numbers to the large LANs. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122008353200> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Sun 20 Dec 87 14:12:41-PST To: "Michael J. O'Connor" cc: malis@CC5.BBN.COM, TCP-IP@SRI-NIC.ARPA, arpaupgrade@BBN.COM, pogran@CCQ.BBN.COM, malis@CC5.BBN.COM Subject: Re: An ARPANET update In-reply-to: Your message of Sun, 20 Dec 87 15:23:32 -0500. <8712202023.AA08030@sccgate.scc.com> Date: Sun, 20 Dec 87 16:55:32 -0500 From: Andy Malis Mike, Thanks for the additional info. Are there any dates or version IDs available for your and Hilarie's Sun X.25 packages? Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122010452100> Received: from MITVMA.MIT.EDU by SRI-NIC.ARPA with TCP; Sun 20 Dec 87 12:46:22-PST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Sun, 20 Dec 87 15:46:30 EST Received: by MITVMA (Mailer X1.25) id 7453; Sun, 20 Dec 87 15:46:28 EST Date: Sun, 20 Dec 87 15:45:21 EST From: Frank Kastenholz To: TCP/IP List Subject: Response to Long Distance NFS Query A few months ago I made a general request to the list about running NFS internetwork gateways. The specific configuration that I have to deal with is two Ethernets separated by some physical distance (possibly intercontinental). There would be some kind of gateway/bridge/router/thing at each Ethernet and the things are connected by a medium to high speed serial link (anything from about 38K to 1.544M bits/sec). The responses that I received (minus the "gee, what a great idea's" or "Well, it had to come someday" etc etc responses) are: (I have left the originating party's name on each on - the rest of the SMTP/RFC822 junk has been removed). ====================================================================== From: "James B. VanBokkelen" By default, none of Sun's implementations of NFS use UDP checksums. If you enable them, the last release I heard anything about still had the 4.2 UDP checksum mis-calculation. They assume they're running one hop, on a CRC-protected medium like Ethernet. Accordingly, you're not too likely to catch any situation where the NFS packet is corrupted on the way through a gateway, or over an error-prone link. Instant filesystem corruption. It can certainly be fixed if you have source, but I don't own any Suns (2nd hand info, this), so I can't say exactly what must be done. ======================================================================= From: jas@MONK.PROTEON.COM (John A. Shriver) The nature of the Sun NFS fragmented UDP-grams causes many routers and bridges to have fits. You get 6 back-to-back IP fragments. If ANY of those fragments is lost, the entire UDP-gram must be retranmitted. You can, however, reduce the size of the UDP-gram. In /etc/fstab, you need to add the undocumented rsize & wsize switches. For example: across_gw_machine:/usr /usr nfs rw,noquota,soft,rsize=2048,wsize=2048 This will reduce the size of the UDP-gram to 2048 btyes of data, as opposed to the default 8192. This will cuase only two fragments instead of eight. (Do keep this parameter a multiple of 1024, as all the network code likes page-aligned buffers.) For reference, see bug 135 in Sun Software Technical Bulletin, February 1987, part number 812-8701-01. (The page numbering is botched in this one.) ==================================================================== From: slevy@umn-rei-uc.arpa (Stuart Levy) 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. ====================================================================== From: hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) We run NFS over cisco routers, either directly connecting two Ethernets or connecting Ethernets via a T1 line. The only problem is that the Ethernet cards used by cisco (and others) can't handle large numbers of consecutive packets. So you need to specify rsize=nnn,wsize=nnn in the mount. Typically we use 2048, though I think someting a bit closer to 3000 might give better performance. I haven't tried it over anything slower, though we understand that somebody a Univ. of Maryland mounted one of our disks over NSFnet. ===================================================================== From: John Romkey One problem you'll run into is that NFS does not checksum its packets. NFS packets are UDP-based instead of TCP-based, and the UDP checksum is optional. On a single ethernet, the ethernet's CRC is possibly reliable enough to detect bad packets, but through an IP router there is too high a probability of losing (.1% would mean one out of 1000 packets was damaged; you really desparately want 0% errors). The reason is that there are chances for corruption of data in the ethernet interface of the IP router, in the IP router's memory, and in the other interface it routes the NFS packet too. The corruption can be due to hardware errors, electrical noise, memory errors and software problems. In fact, you've got the same problem with just an NFS server and client on the same LAN, but since fewer components are involved, the chances of error are much smaller. I've spoken with people who've used NFS over a router, and they've actually seen files corrupted due to the lack of checksums. I'd recommend against it. BTW, the reason they turn off checksums is to up performance. - john romkey ================================================================= ================================================================= Any further discussion should go to the list, to the original author or directly to me (unfortinately I have recently moved from MIT-Multics to MITVMA but the list has yet to catch up to me (whoever is running the distribution list must be on a verryyyyy loooonnnnggg vacation:-)) Seasons greetings to all Frank Kastenholz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712201829.AA11787@ucbvax.Berkeley.EDU] <1987122018042500> From: RAF@NIHCU.BITNET ("Roger Fajman") Newsgroups: comp.protocols.tcp-ip Subject: Re: More than one IP (sub)network on one ethernet cable Message-ID: <8712201829.AA11787@ucbvax.Berkeley.EDU> Date: 20 Dec 87 18:04:25 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 > What is the point between putting two different Internet networks > on a single extended LAN? Is this commonly done? Is there a good > reason that is not occuring to me? In the case of multiple subnets on one LAN with a class B address, a reason is that you have many small subnets and a few large ones. If you set your subnet mask to accomodate the size of the large subnets, then you may not have enough subnet numbers to accomodate the quantity of small subnets that you have. The reverse is also true. One possible solution is to have the subnet size be small, but assign multiple subnet numbers to the large LANs. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712202023.AA08030@sccgate.scc.com] <1987122020233200> From: oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) Newsgroups: comp.protocols.tcp-ip Subject: Re: An ARPANET update Message-ID: <8712202023.AA08030@sccgate.scc.com> Date: 20 Dec 87 20:23:32 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Andy, I finally contacted Hilarie Orman (ho@tis) who is a fellow Sun sufferer (in the sense that she is also plagued by this X.25 problem). Hilarie tells me that the problem I'm currently seeing with my L3 software locking up is one that has been plaguing her system for a while. I believe she said the problem occured before the new End-to-End. I can assure you that we never had this problem under the old End-to-End or I would never have mentioned it to you. We maybe running older Sun X.25 software than Hilarie is, but whatever the reason, it sounds like that part of my problem is Sun's responsibility. Just to keep the record straight, I still have the 'thrashing circuits'. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712202159.AA13986@ucbvax.Berkeley.EDU] <1987122020452100> From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) Newsgroups: comp.protocols.tcp-ip Subject: Response to Long Distance NFS Query Message-ID: <8712202159.AA13986@ucbvax.Berkeley.EDU> Date: 20 Dec 87 20:45:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 108 A few months ago I made a general request to the list about running NFS internetwork gateways. The specific configuration that I have to deal with is two Ethernets separated by some physical distance (possibly intercontinental). There would be some kind of gateway/bridge/router/thing at each Ethernet and the things are connected by a medium to high speed serial link (anything from about 38K to 1.544M bits/sec). The responses that I received (minus the "gee, what a great idea's" or "Well, it had to come someday" etc etc responses) are: (I have left the originating party's name on each on - the rest of the SMTP/RFC822 junk has been removed). ====================================================================== From: "James B. VanBokkelen" By default, none of Sun's implementations of NFS use UDP checksums. If you enable them, the last release I heard anything about still had the 4.2 UDP checksum mis-calculation. They assume they're running one hop, on a CRC-protected medium like Ethernet. Accordingly, you're not too likely to catch any situation where the NFS packet is corrupted on the way through a gateway, or over an error-prone link. Instant filesystem corruption. It can certainly be fixed if you have source, but I don't own any Suns (2nd hand info, this), so I can't say exactly what must be done. ======================================================================= From: jas@MONK.PROTEON.COM (John A. Shriver) The nature of the Sun NFS fragmented UDP-grams causes many routers and bridges to have fits. You get 6 back-to-back IP fragments. If ANY of those fragments is lost, the entire UDP-gram must be retranmitted. You can, however, reduce the size of the UDP-gram. In /etc/fstab, you need to add the undocumented rsize & wsize switches. For example: across_gw_machine:/usr /usr nfs rw,noquota,soft,rsize=2048,wsize=2048 This will reduce the size of the UDP-gram to 2048 btyes of data, as opposed to the default 8192. This will cuase only two fragments instead of eight. (Do keep this parameter a multiple of 1024, as all the network code likes page-aligned buffers.) For reference, see bug 135 in Sun Software Technical Bulletin, February 1987, part number 812-8701-01. (The page numbering is botched in this one.) ==================================================================== From: slevy@umn-rei-uc.arpa (Stuart Levy) 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. ====================================================================== From: hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) We run NFS over cisco routers, either directly connecting two Ethernets or connecting Ethernets via a T1 line. The only problem is that the Ethernet cards used by cisco (and others) can't handle large numbers of consecutive packets. So you need to specify rsize=nnn,wsize=nnn in the mount. Typically we use 2048, though I think someting a bit closer to 3000 might give better performance. I haven't tried it over anything slower, though we understand that somebody a Univ. of Maryland mounted one of our disks over NSFnet. ===================================================================== From: John Romkey One problem you'll run into is that NFS does not checksum its packets. NFS packets are UDP-based instead of TCP-based, and the UDP checksum is optional. On a single ethernet, the ethernet's CRC is possibly reliable enough to detect bad packets, but through an IP router there is too high a probability of losing (.1% would mean one out of 1000 packets was damaged; you really desparately want 0% errors). The reason is that there are chances for corruption of data in the ethernet interface of the IP router, in the IP router's memory, and in the other interface it routes the NFS packet too. The corruption can be due to hardware errors, electrical noise, memory errors and software problems. In fact, you've got the same problem with just an NFS server and client on the same LAN, but since fewer components are involved, the chances of error are much smaller. I've spoken with people who've used NFS over a router, and they've actually seen files corrupted due to the lack of checksums. I'd recommend against it. BTW, the reason they turn off checksums is to up performance. - john romkey ================================================================= ================================================================= Any further discussion should go to the list, to the original author or directly to me (unfortinately I have recently moved from MIT-Multics to MITVMA but the list has yet to catch up to me (whoever is running the distribution list must be on a verryyyyy loooonnnnggg vacation:-)) Seasons greetings to all Frank Kastenholz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712202312.AA14761@ucbvax.Berkeley.EDU] <1987122021553200> From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: An ARPANET update Message-ID: <8712202312.AA14761@ucbvax.Berkeley.EDU> Date: 20 Dec 87 21:55:32 GMT References: <8712202023.AA08030@sccgate.scc.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Mike, Thanks for the additional info. Are there any dates or version IDs available for your and Hilarie's Sun X.25 packages? Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122104065000> Received: from LABS-N.BBN.COM by SRI-NIC.ARPA with TCP; Mon 21 Dec 87 06:09:00-PST Date: Mon, 21 Dec 87 9:06:50 EST From: Alex McKenzie To: Paul Tsuchiya cc: dcatla!dnwcv@GATECH.EDU, tcp-ip@SRI-NIC.ARPA Subject: Re: More than one IP (sub)network on one ethernet cable A (temporary) reason we had at BBN for having two IP nets on a single Ethernet was a restructuring of our campus network. We built one big Ethernet to replace several smaller ones. It was extremely convenient to be able to change which physical Ethernet a system was connected to asynchronously from changing what IP address that host was using. In fact, if I recall correctly, some hosts began using their new IP address before discontinuing use of their old IP address, as another way of maintaining uninterrupted service during the cutover. Alex McKenzie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122107030400> Received: from venera.isi.edu by SRI-NIC.ARPA with TCP; Mon 21 Dec 87 15:03:15-PST Received: from akamai.isi.edu by venera.isi.edu (5.54/5.51) id AA00610; Mon, 21 Dec 87 15:03:30 PST Date: Mon, 21 Dec 87 15:03:04 PST From: jkrey@venera.isi.edu Posted-Date: Mon, 21 Dec 87 15:03:04 PST Message-Id: <8712212303.AA23073@akamai.isi.edu> Received: by akamai.isi.edu (5.54/5.51) id AA23073; Mon, 21 Dec 87 15:03:04 PST To: dpowles@ccd.bbn.com Subject: re: security option Cc: jkrey@venera.isi.edu, tcp-ip@sri-nic.arpa Drew, Mike St. Johns' "Draft Revised IP Security Option" is about ready to be issued as an RFC, as soon as Mike provides us with additional information he wanted to include at the end of the document. The soon-to-be RFC is considered to be a pre-publication draft of the revised Internet Protocol Security Option. According to an excerpt taken from Mike's draft RFC Status of this Memo section: "This draft reflects the version as approved by the Protocol Standards Steering Group. It is provided for informational purposes only. The final version of this document will be available from Navy Publications and should not differ from this document in any major fashion." You may want to contact Mike (stjohns@sri-nic.arpa) if you require any further information. Happy Holidays!!! Joyce Reynolds ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122108092000> Received: from ACC-SB-UNIX.ARPA by SRI-NIC.ARPA with TCP; Mon 21 Dec 87 16:09:07-PST Received: by ACC-SB-UNIX.ARPA (5.51/4.7) id AA25278; Mon, 21 Dec 87 16:09:20 PST Date: Mon, 21 Dec 87 16:09:20 PST From: gary@ACC-SB-UNIX.ARPA (Gary Krall) Message-Id: <8712220009.AA25278@ACC-SB-UNIX.ARPA> To: tcp-ip@sri-nic.arpa Subject: 5250 Issues Dave, ACC recognizes the problem that has been reported with it's 5250 product. We are attempting to work with the customer base to clearly identify the problem and insure that the solution not only solves the immediate issue, but addresses longer term items as well. Toward that end we now have the tools in-house to replicate the problems noted in the field and are currently working working with BBN and PSN 7. I will be advising you directly of our progress in the near term. Regards, Gary. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1649@faline.bellcore.com] <1987122109225600> From: karn@faline.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Response to Long Distance NFS Query Message-ID: <1649@faline.bellcore.com> Date: 21 Dec 87 09:22:56 GMT References: <8712202159.AA13986@ucbvax.Berkeley.EDU> Organization: Bell Communications Research, Inc Lines: 7 Summary: NFS over bridges vs routers By the way, one advantage of bridges over routers for NFS traffic (at least for the Vitalink bridges we use) is that they maintain the original Ethernet CRC; they encapsulate the entire source packet (CRC included) over the HDLC link. This means that a broken Ethernet controller in the bridge won't corrupt your checksumless NFS/UDP packets like a broken Ethernet controller in an IP router would. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [479@hrc63.co.uk] <1987122111385100> From: trw@hrc63.co.uk (Trevor Wright Marconi Baddow) Newsgroups: comp.protocols.tcp-ip Subject: Cheap TCP/IP access to IBM/Amdahl's Message-ID: <479@hrc63.co.uk> Date: 21 Dec 87 11:38:51 GMT Organization: GEC Hirst Research Centre, Wembley, England. Lines: 18 Keywords: TCP/IP, Amdahl, CMS, MVS We are looking at options to connect our Ethernet network to an Amdahl 5860 operated by a sister company. We know of the Spartacus K200 running with Wollongong WIN/UTS under UTS. Is there however a cheaper, lower-but-acceptable performance alternative - say a PC/AT with channel one side and Ether the other. If so - what Amdahl s/w would be required if we were NOT working with UTS. Resident systems on the Amdahl are VM/CMS and MVS. Surely there must be a better way of talking to IBM's than serial RJE's, but at a reasonable cost... Thanks Trevor Wright, GEC Research, Chelmsford UK ArpaNet address: yc23%a.gec-mrc.co.uk@nss.cs.ucl.ac.uk ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122113522200> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Mon 21 Dec 87 19:23:37-PST To: tcp-ip@SRI-NIC.ARPA cc: malis@CC5.BBN.COM Subject: Any Cisco gateways on the ARPANET? Date: Mon, 21 Dec 87 22:12:22 -0500 From: Andy Malis An informal poll: Any of you have Cisco gateways on the ARPANET? If so, is traffic flowing through them OK? Any problems to report? Please send reports (yea or nea) to arpaupgrade@bbn.com and satz@mathom.cisco.com. Thanks much, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712211456.AA26212@ucbvax.Berkeley.EDU] <1987122114065000> From: mckenzie@LABS-N.BBN.COM (Alex McKenzie) Newsgroups: comp.protocols.tcp-ip Subject: Re: More than one IP (sub)network on one ethernet cable Message-ID: <8712211456.AA26212@ucbvax.Berkeley.EDU> Date: 21 Dec 87 14:06:50 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 A (temporary) reason we had at BBN for having two IP nets on a single Ethernet was a restructuring of our campus network. We built one big Ethernet to replace several smaller ones. It was extremely convenient to be able to change which physical Ethernet a system was connected to asynchronously from changing what IP address that host was using. In fact, if I recall correctly, some hosts began using their new IP address before discontinuing use of their old IP address, as another way of maintaining uninterrupted service during the cutover. Alex McKenzie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1461@saturn.ucsc.edu] <1987122117154000> From: eshop@saturn.ucsc.edu (Jim Warner) Newsgroups: comp.protocols.tcp-ip Subject: Re: Response to Long Distance NFS Query Message-ID: <1461@saturn.ucsc.edu> Date: 21 Dec 87 17:15:40 GMT References: <8712202159.AA13986@ucbvax.Berkeley.EDU> <1649@faline.bellcore.com> Reply-To: eshop@saturn.ucsc.edu (Jim Warner) Organization: University of California, Santa Cruz; CIS/CE Lines: 11 In article <1649@faline.bellcore.com> karn@faline.bellcore.com (Phil R. Karn) writes: >By the way, one advantage of bridges over routers for NFS traffic (at >least for the Vitalink bridges we use) is that they maintain the >original Ethernet CRC; they encapsulate the entire source packet (CRC >included) over the HDLC link.... This is *NOT* a general characteristic of all bridges. It is true for DEC and Vitalink. If this characteristic is important, you should be sure to ask your vendor how they handle it. jim ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712211726.AA04950@TOTO.MIT.EDU] <1987122117265400> From: mar@ATHENA.MIT.EDU Newsgroups: comp.protocols.tcp-ip Subject: More than one IP (sub)network on one ethernet cable Message-ID: <8712211726.AA04950@TOTO.MIT.EDU> Date: 21 Dec 87 17:26:54 GMT References: <8712190319.AA26455@uc.msc.umn.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 But there is a simpler solution to the one you described, and it is even documented in RFC 1027. This is ARP subnet routing, or the ARP hack, as it is sometimes called. This means having your gateway respond to arp requests for machines on other subnets, giving it's own ethernet address. For instance, if you have a machine on subnet 1 of your class B network which does not understand subnet routing, and this machine wants to send a packet to a host on subnet 2, not knowing about subnets it would assume that it can send directly and arp for the destination host's IP address. The gateway on subnet 1 receives this ARP, and responds with it's own hardware address so that the packet gets sent to the gateway, which can forward it to the correct destination. So the ARP hack works in the case of smart gateways and dumb hosts. Proteon gateways support this, and I think Cisco ones do too. There are mods available for the 4.2 kernel, and it is already in 4.3, if you enable it. -Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [302407.871221.JBVB@AI.AI.MIT.EDU] <1987122117284600> From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: OOB problems, wisdom anyone? Message-ID: <302407.871221.JBVB@AI.AI.MIT.EDU> Date: 21 Dec 87 17:28:46 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 There are at least two interpretations of the TCP "URG" bit and its associated pointer. The Berkeley Unix interpretation is as you describe in your posting. Out-of-band reads return the (16-bit value, I guess) that the Urgent pointer points at (the byte & the byte before, maybe?). Another interpretation has the TCP pass the caller the number of bytes that are to be treated as Urgent (from where the caller has read so far), and it is up to the caller to read/process so as to consume the urgent information. This doesn't imply that the urgent information is any particular size, or even that it is all in one place in the pending data (the caller is assumed to be able to figure it out). The only widely-implemented spec that uses Urgent (that I know of) is Telnet, where a number of IAC-x sequences are sent as Urgent data. In the cases I've seen, Telnet uses the 2nd interpretation. Given the disparate interpretations, I've advised people to stay away from it, and we haven't been particularly eager to expand (or document to the user) our implementation thereof. When I read RFC-793, the 2nd (non-BSD) interpretation seems more reasonable, but I wasn't there when it was written. James B. VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712211820.AA14705@ACC-SB-UNIX.ARPA] <1987122118204900> From: gary@ACC-SB-UNIX.ARPA (Gary Krall) Newsgroups: comp.protocols.tcp-ip Subject: 5250 Issues Message-ID: <8712211820.AA14705@ACC-SB-UNIX.ARPA> Date: 21 Dec 87 18:20:49 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Dave, ACC recognizes the problem that has been reported with it's 5250 product. We are attempting to work with the customer base to clearly identify the problem and insure that the solution not only solves the immediate issue, but addresses longer term items as well. Toward that end we now have the tools in-house to replicate the problems noted in the field and are currently working working with BBN and PSN 7. I will be advising you directly of our progress in the near term. Regards, Gary. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712211826.AA10567@uc.msc.umn.edu] <1987122118262900> From: slevy@UMN-REI-UC.ARPA (Stuart Levy) Newsgroups: comp.protocols.tcp-ip Subject: Re: More than one IP (sub)network on one ethernet cable Message-ID: <8712211826.AA10567@uc.msc.umn.edu> Date: 21 Dec 87 18:26:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 We're already doing subnet (proxy) ARP -- not exactly with our gateways, which don't have this feature built in (they're things like SUNs) but using a program employing the SUN `nit' ethernet-tap interface to listen for ARPs and respond from a table, giving the Ethernet address of the gateway, just as you suggest. This works fine for really dumb hosts that aren't using subnetting, and gives us "transparent" subnets. The case where it -doesn't- work is for hosts that -are- using subnetting, e.g. for the subnet gateways themselves. Say we want to give a default route (to 128.101.1.3) to one of them on a subnet other than 128.101.1.*. The UNIX routing software won't permit this -- it demands that gateways be on the same (sub)net as some interface address. So we synthesize these fake gateways (actually by building them into the same table that handles subnet ARPs) so that every subnet has a fake gateway within reach. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712212300.AA20666@ce.hp.com] <1987122123005300> From: wunder@HPCEA.CE.HP.COM (Walter Underwood) Newsgroups: comp.protocols.tcp-ip Subject: Re: A,B,C-class vs subnetting Message-ID: <8712212300.AA20666@ce.hp.com> Date: 21 Dec 87 23:00:53 GMT References: <8712200254.AA22098@clutx.clarkson.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 The best explanation of subnets is probably in RFC-917, Jeff Mogul's original proposal for the now-standard scheme. That RFC includes some case studies and explanations which were cut when it was edited into RFC-950. The additional material explains the tradeoffs in the design. wunder ----MESSAGE-END---- ----MESSAGE-BEGIN---- [299@otc.oz] <1987122123035500> From: anido@otc.oz (Gary Anido) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: FDDI interfaces and bridges : summary Message-ID: <299@otc.oz> Date: 21 Dec 87 23:03:55 GMT Organization: OTC Development Unit, Australia Lines: 49 Keywords: bridges, gateways, LAN, FDDI, Ethernet A few weeks ago I asked for information regarding implementations (preferably board-level) of FDDI interfaces for Ethernet, Token Ring and so on. Now that responses have essentially ceased I will provide a summary. First off, however, I wish to thank those who replied to my request for information: URBANIAK@g.bbn.com hedrick@aramis.rutgers.edu enger@sccgate.scc.com kwe@bu-it.bu.edu don@wiley BILLW@mathom.cisco.com akt@cos.com sm@pbhya.uucp gold@sdsu.sdcsvax bc@halley.esc-bb 1. Fibronics (617) 778-0700 have announced an FDDI product called FX80000 which interfaces to 802.3 LANs. It is apparently a multiple-board product built into a VME sub-rack. Discrete logic is used while the FDDI standards are in flux. Cost is reported to be us$39,000 plus us$3,200 for each additional Ethernet interface. 2. The AMD FDDI chipset should be available in quantity in first quarter 88, with products appearing mid-88. There is some confusion as to whether all five chips of the AMD chipset will, in fact, be buyable. 3. The AMD chipset is, at this time, the only FDDI silicon. Presumably other chip manufacturers are not too far behind. 4. A number of companies (including Cisco Systems and Proteon) are planning FDDI products when the standards are finalised. Note that I have not confirmed the information contained in all the replies. I would be pleased if inaccuracies are brought to my attention. Gary Anido Systems Development |||| OTC || UUCP: {uunet,mcvax}!otc.oz!anido ACSnet:anido@otc.oz Postal Address: Systems Development Phone :(02) 2874849 OTC Intl :+612 2874849 GPO Box 7000 Fax :(02) 2874990 Sydney NSW AUSTRALIA 2001 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122123055700> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Mon 21 Dec 87 19:44:41-PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA10321; Mon, 21 Dec 87 18:49:25 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Dec 87 23:05:57 GMT From: wencu@cunyvm.bitnet Organization: The City University of New York - New York, NY Subject: ftp problems Message-Id: <951WENCU@CUNYVM> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa We here at CUNYVM.CUNY.EDU have recently been able to use the tcp/ip suite through the vm/tcp machine.I has been running well thanks to our network administrators. I have used TELNET and been succeccful. Our problem comes when I use FTP to transfer pc or macintosh executable programs in a binary or packed format. I get garbage. Is there a problem with the transfer method? There are 3 'TYPE' options: Ascii, Binary, Image. Which do we use? Is the problem because the files are being sent through the vm mainframe and are being translated before getting to the micro? Is anyone also having this problem and found a work around solution? As a lot of people are beginning to use ftp this problem is coming up more frequently at our site. The questions fall on us. Any help will be appreciated Wendell P. Brown a.k.a. "Splash" Senior Technician at CUNY University Computer Center Microcomputer Resource Laboratory ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712220038.AA15289@gr.utah.edu] <1987122200385900> From: haas%gr@CS.UTAH.EDU (Walt Haas) Newsgroups: comp.protocols.tcp-ip Subject: Fibronics TCP/IP/Ethernet for IBM mainframe Message-ID: <8712220038.AA15289@gr.utah.edu> Date: 22 Dec 87 00:38:59 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Forgive me if I'm asking in the wrong place, but has anybody out there had any real-world experience with a series of products from Fibronics designed to connect an IBM mainframe to an Ethernet? A local sales rep just sent me some advertisements for a K310x product line that hooks a block multiplexer channel to an Ethernet and a software package called KNET TCP/MVS that implements guess which protocol on guess which os. Thanks in advance--Walt Haas ARPA: haas@cs.utah.edu uucp: ...utah-cs!haas ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712221106.AA18298@ucbvax.Berkeley.EDU] <1987122203122200> From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Any Cisco gateways on the ARPANET? Message-ID: <8712221106.AA18298@ucbvax.Berkeley.EDU> Date: 22 Dec 87 03:12:22 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 An informal poll: Any of you have Cisco gateways on the ARPANET? If so, is traffic flowing through them OK? Any problems to report? Please send reports (yea or nea) to arpaupgrade@bbn.com and satz@mathom.cisco.com. Thanks much, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [302655.871221.JBVB@AI.AI.MIT.EDU] <1987122204425600> From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: More than one IP (sub)network on one ethernet cable Message-ID: <302655.871221.JBVB@AI.AI.MIT.EDU> Date: 22 Dec 87 04:42:56 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 37 Ok. There are a number of situations where this configuration (more than one net or subnet on a single broadcast medium) seems to bring some benefit. However, it goes against a fairly fundamental paradigm of RFC 791 and RFC 950, the use of the network (and subnet) mask to make a simple routing decision. My present code, and its installation, configuration, debugging & documentation all benefit from this. I assume that if you're going to break the paradigm, you want to go whole hog and have different classes of networks, and different numbers of subnet bits, all on the same cable? So the configuration would have to look like: mask 255.255.224.0 net 128.4.32.0 local ; class B, 3 subnet bits mask 255.255.0.0 net 18.10.0.0 local ; Class A, 8 subnet bits mask 255.255.255.0 net 192.9.1.0 local ; Class C, 0 subnet bits Three nets wouldn't be enough - I'd better design for 8, or 16. The list gets scanned for every miss on the ARP cache. Not too expensive. However, the configuration would have to be set, correctly, on every host on the net. Is it still safe to assume that everything which is not on the list should go through a default gateway, or do workstations need explicit routes there, too? We can write the code, we can document it, we can probably even explain it to the non-guru (to whom setting up an IP network is already a major adventure). Right now, I don't think it is justified. Maybe once automatic, central configuration initialization & control is available, maybe once the Unix manufacturers all get into agreement about the nature of broadcast packets, maybe once IP Multicast is generally understood, and implementations are beginning to show up (in DC, Postel warned that this was something vendors should keep their eyes on). It looks like a low priority to me. Are there people with money to spend that say otherwise? jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122204530000> Received: from CUNYVM.CUNY.EDU by SRI-NIC.ARPA with TCP; Tue 22 Dec 87 09:28:11-PST Received: from ISUMVS.BITNET by CUNYVM.CUNY.EDU ; Tue, 22 Dec 87 12:14:15 EST Date: Tue, 22 Dec 87 10:53:00 CST To: From: "Paul Lustgraaf" Subject: Naming schemes Does anyone out there care to comment about naming schemes? I have to choose between a 3 level and a 4 level machine name, ie. vaxa.iastate.edu vs. vaxa.cc.iastate.edu, Where vaxa is the machine and cc is the subnet (usually a department name). Any comments either way? Paul Lustgraaf GR.PJL@ISUMVS.BITNET Computation Center Iowa State University Ames, IA 50011 515-294-0324 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122206350000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 22 Dec 87 08:37:02-PST Date: 22 Dec 1987 11:35-EST Sender: CERF@A.ISI.EDU Subject: Re: OOB problems, wisdom anyone? From: CERF@A.ISI.EDU To: JBVB@AI.AI.MIT.EDU Cc: amdahl!rtech!daveb@AMES.ARPA, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]22-Dec-87 11:35:55.CERF> In-Reply-To: <302407.871221.JBVB@AI.AI.MIT.EDU> The intent of the URGENT indicator was to say where (at what byte) in the datastream the URGENT data ended - the TCP level provided an absolute pointer (sequence number reference) to the last urgent byte. If two instances of urgent data were injected into the data stream, the urgent indicator would flag the latest of them, requiring the next level up to scan the data stream from wherever the "next" input byte was to the end of urgent data. No semantics was associated with urgency. The translation into "how many bytes to read" was not part of the TCP spec, as I recall it. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712220701.AA02500@sluggo.sun.com] <1987122207015700> From: melohn@SUN.COM (Bill Melohn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Response to Long Distance NFS Query Message-ID: <8712220701.AA02500@sluggo.sun.com> Date: 22 Dec 87 07:01:57 GMT References: <8712202159.AA13986@ucbvax.Berkeley.EDU> <1649@faline.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 You can corrupt an NFS file system invisably by sending NFS/UDP packets over an unreliable datalink (like the current version of SLIP) without first turning on UDP checksums, which has been possible since SunOS 3.2. With our point to point IP router, we do a CRC at the serial chip level, making it act like an ethernet. Other people have done NFS over SLIP using error-detecting modems like the Telebit Trailblazer. In any case, the trend is towards error-free or at least error correcting hardware/networks, so the NFS/UDP default seems even more reasonable in a high-fibre future. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122208043500> Received: from MVSA.USC.EDU ([128.125.1.142]) by SRI-NIC.ARPA with TCP; Tue 22 Dec 87 13:08:55-PST Date: 22 Dec 87 13:04:35 From: Leonard D Woren Subject: Re: Fibronics TCP/IP/Ethernet for IBM mainframe To: TCP-IP@SRI-NIC.ARPA Anyone looking into TCP/IP for MVS should also look at the ACS 9310 and Acces/MVS, from Advanced Computer Communications. We're installing one now. /Leonard ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712221300.AA18419@devvax.TN.CORNELL.EDU] <1987122213003500> From: jch@DEVVAX.TN.CORNELL.EDU (Jeffrey C Honig) Newsgroups: comp.protocols.tcp-ip Subject: Re: Fibronics TCP/IP/Ethernet for IBM mainframe Message-ID: <8712221300.AA18419@devvax.TN.CORNELL.EDU> Date: 22 Dec 87 13:00:35 GMT References: <8712220038.AA15289@gr.utah.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 >Forgive me if I'm asking in the wrong place, but has anybody out there >had any real-world experience with a series of products from Fibronics >designed to connect an IBM mainframe to an Ethernet? Try knet-l@tamvm1.bitnet, it is primarily about the VM product but may have useful information. To subscribe send mail to listserv@tamvm1.bitnet with a single line of data: subscribe knet-l Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712221526.AA25462@cod.nosc.mil] <1987122215265900> From: neerma@COD.NOSC.MIL (Merle A. Neer) Newsgroups: comp.protocols.tcp-ip Subject: PC/AT UNIX TCP/IP software development Message-ID: <8712221526.AA25462@cod.nosc.mil> Date: 22 Dec 87 15:26:59 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Hi, We at the Naval Ocean Systems Center (NOSC) are interested in developing application programs including net protocols on TCP/IP for UNIX on an IBM/AT. Rather than re-invent something that may already exist I thought I would canvas the list to see what others are doing in this environment. We are particularly interested in applications where the AT serves as front-end to some non networking systems. Respond to : neerma at nosc Thanks in advance, Merle Neer. ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712221618.AA13714@gateway.mitre.org] <1987122216184000> From: tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya) Newsgroups: comp.protocols.tcp-ip Subject: Re: More than one IP (sub)network on one ethernet cable Message-ID: <8712221618.AA13714@gateway.mitre.org> Date: 22 Dec 87 16:18:40 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 38 Maybe I am about to say something that is obvious and that everybody already knows, but here goes............ The purpose of subnetting (as I understand it) is to allow gateways and separated (sub)networks to exist in what appears to be a single network outside, therefore making routing decisions outside of the network to not be concerned with is going on inside the network. This does not, however, mean that one can change the topology inside their network without expecting some IP addresses to change, just as one would not expect to move their host from MITRE to SRI with getting a new IP address. The problem is that the name-domain function apparently does not allow other hosts to dynamically rediscover that some host has a new IP address. I don't know is this is an implementation problem or a design problem, although I assume the former. If I might indulge in a little self-promotion, the algorithms I have been working on, which are collectively called Landmark Routing, cause gateways to self-configure automatically, assign addresses to gateways, and bind host "names" to those addresses in an efficient and dynamic fashion (at least they do if my design is correct. We have no implementation to date, although we are now embarking on simulation). What this means is that hosts are assign permanent IP addresses that NEVER change even if the host moves, and that the Landmark Routing function automatically handles all (landmark) address assignments. Then assignment of IP addresses is then purely an administrative consideration, and not a topological one. If this is of interest to folks, please let me know so that I can focus my work appropriately and work towards a testbed. I plan some RFCs on this topic later in 1988. _________________________________________________________________ Paul F. Tsuchiya The MITRE Corp. tsuchiya@gateway.mitre.org 7525 Colshire Dr. 703-883-7352 McLean, VA 22102 USA _________________________________________________________________ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712221626.AA02583@trantor.UMD.EDU] <1987122216264700> From: louie@TRANTOR.UMD.EDU ("Louis A. Mamakos") Newsgroups: comp.protocols.tcp-ip Subject: Re: Fibronics TCP/IP/Ethernet for IBM mainframe Message-ID: <8712221626.AA02583@trantor.UMD.EDU> Date: 22 Dec 87 16:26:47 GMT References: <8712220038.AA15289@gr.utah.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 I've used both a Fibronics K200 and a K320, but on a UNIVAC/Sperry/UniSys 1100 mainframe system. We bought the K200, and have a K320 on loan in a beta test mode. Personally, I prefer the K200. It seems to have good performence, and costs less than the K320. However, the K320 is "smart" and programmable. By default, the K320 emulates a K200, but in the future can/could be upgraded to do processing and offload the host. We don't need that capability. We wrote our own TCP/IP implementation for the 1100 series; I have no experience with the KNET package. louie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]22-Dec-87.11:35:55.CERF] <1987122216350000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: OOB problems, wisdom anyone? Message-ID: <[A.ISI.EDU]22-Dec-87.11:35:55.CERF> Date: 22 Dec 87 16:35:00 GMT References: <302407.871221.JBVB@AI.AI.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 The intent of the URGENT indicator was to say where (at what byte) in the datastream the URGENT data ended - the TCP level provided an absolute pointer (sequence number reference) to the last urgent byte. If two instances of urgent data were injected into the data stream, the urgent indicator would flag the latest of them, requiring the next level up to scan the data stream from wherever the "next" input byte was to the end of urgent data. No semantics was associated with urgency. The translation into "how many bytes to read" was not part of the TCP spec, as I recall it. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712230037.AA02479@ucbvax.Berkeley.EDU] <1987122216530000> From: GR.PJL@ISUMVS.BITNET ("Paul Lustgraaf") Newsgroups: comp.protocols.tcp-ip Subject: Naming schemes Message-ID: <8712230037.AA02479@ucbvax.Berkeley.EDU> Date: 22 Dec 87 16:53:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Does anyone out there care to comment about naming schemes? I have to choose between a 3 level and a 4 level machine name, ie. vaxa.iastate.edu vs. vaxa.cc.iastate.edu, Where vaxa is the machine and cc is the subnet (usually a department name). Any comments either way? Paul Lustgraaf GR.PJL@ISUMVS.BITNET Computation Center Iowa State University Ames, IA 50011 515-294-0324 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712221655.AA01731@ACC-SB-UNIX.ARPA] <1987122216554300> From: chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) Newsgroups: comp.protocols.tcp-ip Subject: Re: ftp problems Message-ID: <8712221655.AA01731@ACC-SB-UNIX.ARPA> Date: 22 Dec 87 16:55:43 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Wendell, I have been doing transfers from our ACCES/MVS product(TCP/IP for the MVS environment) to 4.3 BSD hosts and PC hosts(running the FTP Software). What you have to make sure of is that both parties are talking **BINARY IMAGE*** both when you put things on the mainframe and when you take them back off. Since the IBM likes to see EBCDIC and the others want to see ASCII most packages default to their respective prefered data mode. So you have to specifically go in and tell both parties to just send binary data streams without the conversionIf you'd like more info give me a call at ACC. Hope that helps, Chris VandenBerg Advanced Computer Communications (805) 963-9431 chris@acc-sb-unix.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1655@faline.bellcore.com] <1987122220393200> From: karn@faline.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Response to Long Distance NFS Query Message-ID: <1655@faline.bellcore.com> Date: 22 Dec 87 20:39:32 GMT References: <8712202159.AA13986@ucbvax.Berkeley.EDU> <1649@faline.bellcore.com> <1461@saturn.ucsc.edu> Organization: Bell Communications Research, Inc Lines: 15 > This [maintaining original Ethernet CRCs] is *NOT* a general > characteristic of all bridges. Don't I know it. Before the DEC Lanbridge came out, I built my own out of PDP-11/73s and DEQNAs. Big mistake! The DEQNA has *major* problems running in promiscuous mode. One common manifestation was undetected packet corruption. Lots of funny entries showed up in our routing and ruptime tables because UDP checksums were disabled on the Sun routers. This experience made me a firm believer in end-to-end checksums for *all* packets. The performance impact of UDP checksums in NFS is minimal, but even if it weren't they would still be worth it. Even ARP suffers from the lack of an internal checksum. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712230137.AA03908@ucbvax.Berkeley.EDU] <1987122221043500> From: LDW@MVSA.USC.EDU (Leonard D Woren) Newsgroups: comp.protocols.tcp-ip Subject: Re: Fibronics TCP/IP/Ethernet for IBM mainframe Message-ID: <8712230137.AA03908@ucbvax.Berkeley.EDU> Date: 22 Dec 87 21:04:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Anyone looking into TCP/IP for MVS should also look at the ACS 9310 and Acces/MVS, from Advanced Computer Communications. We're installing one now. /Leonard ----MESSAGE-END---- ----MESSAGE-BEGIN---- [155@tsdiag.UUCP] <1987122221142000> From: tom@tsdiag.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Timewarps, virtual-cirkosis and other twitches Message-ID: <155@tsdiag.UUCP> Date: 22 Dec 87 21:14:20 GMT References: <8712151436.aa15545@Huey.UDEL.EDU> <1635@faline.bellcore.com> Reply-To: tom@tsdiag.UUCP (Tom Moulton) Organization: CONCURRENT COMPUTER CORP. SVC Neptune NJ Lines: 19 Phil, you of all people should not confuse an implementation problem with a protocol problem, Dave CLEARLY states that the problem is the atrifical limit on the number of VC's SUPPORTED BY THE ACC 5250 interface and driver. The interface (ACC 5250) should be trashed (Dave suggests re-vamping it). so i think your statement should correctly read: JUNK ACC 5250! not x.25 as you all to well know I prefer the basic assumptions of x.25 over the ones of a datagramme based protocol. but we agree that we disagree! -- Thomas A. Moulton, W2VY Life is too short to be mad about things. Home: (201) 779-W2VY Packet: w2vy@kd6th Voice: 145.190 (r) Work: (201) 492-4880 x3226 FAX: (201) 493-9167 Concurrent Computer Corp. uucp: ...!ihnp4!hotps!ka2qhd!w2vy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [303026.871222.JBVB@AI.AI.MIT.EDU] <1987122300361500> From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: OOB problems, wisdom anyone? Message-ID: <303026.871222.JBVB@AI.AI.MIT.EDU> Date: 23 Dec 87 00:36:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 ..... The translation into "how many bytes to read" was not part of the TCP spec, as I recall it. Vint Sorry, I was projecting how I'd implement it onto the bare RFC there, and I didn't issue a warning. jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [303033.871222.JBVB@AI.AI.MIT.EDU] <1987122300494700> From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: More than one IP (sub)network on one ethernet cable Message-ID: <303033.871222.JBVB@AI.AI.MIT.EDU> Date: 23 Dec 87 00:49:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 One point I hadn't made in the earlier messages is that I am looking at the issue from the standpoint of a single-user PC workstation. We don't presently support more than one interface, and so we aren't blessed with all the configuration issues (and problems) that a multi-homed host has from the beginning. Support for multiple networks on one cable (however primitive) seems to be associated with multi-homedness, and I think I see why. If I wind up doing it, my routing code gets elaborate, but the primitive O/S prevents me from taking much advantage of it. Hi ho. jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3310@ulysses.homer.nj.att.com] <1987122301350500> From: smb@ulysses.homer.nj.att.com (Steven Bellovin) Newsgroups: comp.protocols.tcp-ip Subject: Re: security option Message-ID: <3310@ulysses.homer.nj.att.com> Date: 23 Dec 87 01:35:05 GMT References: <8712212303.AA23073@akamai.isi.edu> Organization: AT&T Bell Laboratories, Murray Hill Lines: 50 Summary: a short tutorial on how to use it Understanding the IP security option requires an understanding of the military computer security model, as outlined in the ``Orange Book''. What follows is a somewhat-simplified version of the model. All objects in the computer system, such as files or network channels, and all data exported from them, must have a label indicating the sensitivity of the information in them. This label includes hierarchical components (i.e., Confidential, Secret, and Top Secret) and non-hierarchical components. Subjects -- i.e., processes within the computer system -- are similarly labeled. A subject may read an object if its label has a higher or equal hierarchical level and if all of the object's non-hierarchical components are included in the subject's label. In other words, the process must have sufficient clearance for the information in a file. Similarly, a subject may write to an object if the object has a higher or equal level and the object's non-hierarchical components include all of those in the subject's level. That is, the sensitivity level of the file must be at least as high as that of the process. If it were not, a program with a high clearance could write classified data to a file that is readable by a process with a low security clearance. A corollary to this is that for read/write access to any file, its security label must exactly match that of the process. The same applies to any form of bidirectional interprocess communication (i.e., a TCP virtual circuit): both ends must have identical labels. We can now see how to apply this model to the TCP/IP protocol suite. When a process creates a TCP connection, that connection is given the process's label. This label is encoded in the IP security option. The remote TCP must ensure that the label on received packets matches that of the receiving process. Servers awaiting connections may be eligible to run at multiple levels; when the connection is instantiated, however, the process must be forced to the level of the connection request packet. IP also makes use of the security option. A packet may not be sent over a link with a lower clearance level. If a link is rated for Secret traffic, it may carry Unclassified or Confidential traffic, but it may not carry Top Secret data. Thus, the security option constrains routing decisions. The security level of a link depends on its inherent characteristics, the strength of any encryption algorithms used, the security levels of the hosts on that network, and even the location of the facility. For example, an Ethernet cable located in a submarine is much more secure than if the same cable were running down a deserted hallway. It is obvious from this description that the IP security option is not easily used in civilian environments. The entire strength of the scheme depends on the reliability of the security labels attached to processes; if the system does not maintain such labels -- and most UNIX systems do not -- the IP security option cannot be used. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122302541900> Received: from NNSC.NSF.NET (WS6.NNSC.NSF.NET) by SRI-NIC.ARPA with TCP; Wed 23 Dec 87 08:16:16-PST To: tcp-ip@sri-nic.ARPA Subject: what a checksum is for Date: Wed, 23 Dec 87 11:14:19 -0500 From: Craig Partridge I was reminded a couple of weeks ago that checksum do more than catch corrupted bits. They help catch some formatting errors in headers (such as byte and bit order mistakes). One should not dispense with transport level checksums simply because one's media is uncorruptable. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712222243.aa06675@Huey.UDEL.EDU] <1987122303431200> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: NBS station WWV problems Message-ID: <8712222243.aa06675@Huey.UDEL.EDU> Date: 23 Dec 87 03:43:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Folks, At least two WWV-synchronized clocks, one at U Michigan and the other at U Delaware, have wandered out of lock for the last day or two. In an effort to find out why, I discovered a scrofulous, apparently spurious, modulation on at least the lowest four of the five WWV broadcast frequencies. The result after demodulation is a rogue baseband frequency in the 100-Hz range, which is close to the synchronizing signal itself and scrambles the clocks. I don't know how the spur originates, but since it appears on several broadcast frequencies, I assume it is due to something like a broken synthesizer or baseband equipment at the transmitters. The problem does not seem to affect the 60-Khz transmissions from WWVB, so the NCAR, ISI and UMd clocks normally used by most of us are well. If WWVB goes bust, we can always camp on CHU, LORAN-C or go sight a star. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122304210000> Received: from TUCC.TUCC.EDU by SRI-NIC.ARPA with TCP; Wed 23 Dec 87 06:21:19-PST Date: Wed, 23 Dec 87 09:21 EST To: tcp-ip@sri-nic.arpa From: Joe Ragland Subject: ACC TCP/IP for IBM MVS systems CC: Joe Ragland Someone was asking about the Fibronics TCP/IP for IBM MVS systems. We have no experience with this product but we have been using the ACC ACS-9310 and ACC's ACCES/MVS software for about a year now. At the time we needed TCP/IP for an MVS system we could not locate a supplier other than ACC. Investigation of the ACC product revealed that the software was actually the UCLA ACP (Arpanet Control Program) which was developed over many years under the direction of Bob Braden when he was at UCLA. ACC had at that time just added Ethernet code to replace the communications interface code in ACP. I believe that I am correct to state that the ACS-9310 is basically a hardware derivative of an earlier controller built for the DDN by ACC (mil-spec construction) which replaced a communications interface with an Ethernet interface. What all this meant to us at the time was that both the hardware and software had a 'track record' and some non-trivial user experience. The 9310 and ACCES has worked out rather well at TUCC. We are certainly pleased with ACC support. We installed the hardware with telephone consults from ACC and since have had one minor hardware problem for which ACC quickly supplied a replacement. ACC supports this product through their Columbia, Md. offices where they have a group actively working on ACCES support. Our major complaint with ACCES/MVS is that it is table driven and lacks a name resolver. Along with some other users I believe we have convinced ACC to up the priority for providing a name resolver to about the early April timeframe. ACCES/MVS provides line mode and 3270 telnet and suffers like all IBM implementations with telnet sessions between 3270s and other vendor support for full-screen ASCII software. Problems here are with IBM TCAM and VTAM. Getting transparent screen control through this IBM software from a remote ASCII host is impossible. 3270 to remote 3270 works great. TCAM line mode to remote ASCII line mode works well too and VTAM support as a 3270 application program to remote ASCII line mode support is fine. Also provided is FTP (no complaints) and SMTP. We use a mail program called UCLA MAIL and have integrated ACCES/MVS SMTP to the UCLA mailer. The mailer handles mail to/from ACCES SMTP, Bitnet, ARPAnet, etc. Conclusion: we're generally pleased with what the 9310 and ACCES/MVS provides for our IBM MVS users and are pleased with the support efforts of ACC. This list contribution is submitted via UCLA MAIL, ACCES/MVS, ACS-9310 and the ARPANET. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [SRA.12360664021.BABYL@XX.LCS.MIT.EDU] <1987122304350000> From: SRA@XX.LCS.MIT.EDU (Rob Austein) Newsgroups: comp.protocols.tcp-ip Subject: Response to Long Distance NFS Query Message-ID: Date: 23 Dec 87 04:35:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Date: Tuesday, 22 December 1987 02:01-EST From: melohn@Sun.COM (Bill Melohn) ... In any case, the trend is towards error-free or at least error correcting hardware/networks, so the NFS/UDP default seems even more reasonable in a high-fibre future. Sorry, but this is a bad idea. You really do need end-to-end software checksuming. MIT discovered this the hard way years ago when a Chaosnet "bridge" (a level 3 router in spite of the name) developed a stuck bit. Chaosnet hardware does hardware checksumming, like Ethernet (in fact, these days, most of it IS Ethernet, even at MIT there are only two subnets left still using Chaosnet hardware). The Chaosnet hardware faithfully transported all the bits entrusted to it, but the packets were corrupted nonetheless. Things only get worse when you start talking about long haul nets. --Rob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122309240000> Received: from oly.acs.washington.edu ([128.95.64.250]) by SRI-NIC.ARPA with TCP; Wed 23 Dec 87 22:46:46-PST Received: from UWAVM.ACS.WASHINGTON.EDU by oly.acs.washington.edu ; Wed, 23 Dec 87 22:46:53 PST P1-Message-Id: US**EDU;UWAVM.ACS.WASHINGTON.EDU:LBaZKn9S Date: Wed, 23 Dec 87 22:44-0800 X400-Trace: US**EDU; arrival Wed, 23 Dec 87 22:44-0800 action Relayed X400-Trace: US**EDU; arrival Wed, 23 Dec 87 22:46-0800 action Relayed From: The Mail Server Subject: Undeliverable mail To: Message-Id: Message had a bad or missing To address. The entire text of the message follows: Received: by BYUADMIN (Mailer X1.25) id 1930; Wed, 23 Dec 87 23:44:02 MST Date: Wed, 23 Dec 87 20:16:05 EST From: Mills@UDEL.EDU Subject: Further to the WWV problem Sender: "(TCP-IP ARPA Discussions)" To: "(no name)" Reply-to: X-To: tcp-ip@sri-nic.arpa X-cc: ineng-interest@isi.edu, nsfnet@sh.cs.net Folks, Phil Karn confirms that on at least one frequency (10 MHz) the WWV signal from Ft. Collins is currupted. As the result of careful measurements here using high-grade communications receivers and antennas, I found the same problem on 5, 10 and 15 MHz: The 100-Hz subcarrier does not disappear between bauds, but is suppressed only about ten decibels. It happens in fact that the WWVB transmission on 60 KHz modulates its carrier by 10-dB power reductions, but there is no reason that I can fathom why doing this on the HF subcarrier is anything but broken. It appears that a call to the station engineering staff is in order. Say a prayer to the God of Christmas Now and hope someone answers the phone tomorrow. I don't know if this problem has killed radio clocks other than Heath. Can somebody squawk on whether the Precision Time Standards gizmos are coping? Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122309282900> Received: from ccq.bbn.com by SRI-NIC.ARPA with TCP; Wed 23 Dec 87 12:19:39-PST Date: Wed, 23 Dec 87 14:28:29 EST From: Ken Pogran Subject: Re: Was "The Patch" removed? In-Reply-To: Your message of Wed, 23 Dec 87 11:40:22 EST To: "Michael J. O'Connor" Cc: arpaupgrade@bbn.com, ho@tis.arpa, malis@bbn.com, melohn@sun.com, tcp-ip@sri-nic.arpa Mike, Yes, last week's patch was removed last night. Unfortunately, it didn't solve the problem Andy Malis thought it would solve. He is about to test (in our own network, since we now have a Sun with an X.25 interface hooked up to it) a new patch that should work. If it does work, it should be out in the ARPANET in the near future. Actually, we're suprised to learn from your message that the patch that went in last week made things that much WORSE for you. I think you and we mis-communicated. You did mention in a message to Andy, "Occasionally, maybe once or twice a day, the X25 manager refuses to make outgoing or accept incoming calls ... This has only occured since the midnight patch of a few days ago." You mentioned that you were referring this problem to Sun, so we took it to be a minor point for us; we didn't take it as a request or a reason to pull the patch. In hindsight, I guess we should have. Instead, we continued to view the patch as "harmless" although not particularly successful in correcting the problem it was supposed to correct. Please accept our apologies in this regard. Ken ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122310464900> Received: from ccq.bbn.com by SRI-NIC.ARPA with TCP; Wed 23 Dec 87 13:17:58-PST Date: Wed, 23 Dec 87 15:46:49 EST From: Ken Pogran Subject: Santa's PSN 7 status To: TCP-IP@sri-nic.arpa Cc: arpaupgrade@bbn.com Folks, Here's where we stand on resolving ARPANET PSN 7 problems: Please refer to my message of 15 December entitled "An ARPANET Update" for a description of the problems referred to here. We have successfully tested fixes for the "one packet problem" and the "pinging yourself" problem. These patches should be deployed ARPANET-wide within the next day or so. We have identified the "multiple of 128 bytes" problem as a host software problem. Here are the details: 1. The "one packet problem" (otherwise known as the "stuck VC problem," "thrashing VC problem," etc.). Known to affect Sun X.25 hosts. When an 1822-connected host begins to send data to an X.25-connected host, the destination PSN, to which the X.25-connected host is attached, must open an X.25 VC with to the destination host. Under PSN 7, the PSN opens the VC, sends the first IP datagram, and waits for an RR from the host before allowing the source PSN to send additional data across the network (and to return a RFNM to the source host for the first packet). This behavior is different from PSN 6, where up to 8 datagrams could be sent to the destination host. Under PSN 6, a source host could conceivably receive the RFNM for the first such datagram before the datagram was acknowledged by the destination host. RRs are often piggy-backed on traffic flowing over the same VC in the opposite direction. However, conditions such as Mailbridge homing in the DDN can produce asymmetric flows. Many X.25 implementations send an RR to acknowledge a packet based on the expiration of a timer, if there is no reverse traffic. Sun X.25 does not, however, but instead waits for the window to become "half full". The behavior of the "interoperability" mechanism of PSN 7, together with the behavior of the Sun X.25, created a "deadly embrace" in which only one datagram would be received on the VC. Behavior of the PSN 7 interoperability mechanism is being changed to eliminate this condition. The patch to do this has been tested in our lab and will be deployed to the ARPANET shortly. NOTE: A patch was deployed last week in an attempt to fix this problem. That patch did not work, and was removed from the network last night. We had been unable to test that patch in the lab beforehand, because at the time we did not have a Sun with an X.25 interface hooked up to our lab net. 2. The "pinging yourself" problem. The timing bug described in my message of 15 December has been fixed in a patch tested earlier today. Mike Petry at UMd was our "guinea pig", and reports that the problem he saw has in fact been corrected by this patch. This patch will also be deployed to the ARPANET shortly. 3. The "multiple of 128 bytes" problem. Using our Sun with X.25 interface in our lab net, and with a data scope on the X.25 link between the PSN and the Sun, we tried "pinging" the Sun from another host. We found that with packets of length 127, 128, 255, 256 ... the datascope showed the "ping" going to the Sun, but no response from the Sun. With packets of other length, the datascope showed the "ping" and its reply going across the link. The packets from the PSN are well-formed in every respect. At this point we can only assume there's a bug in the host code. --> Has anyone OTHER than folks with Suns with X.25 interfaces seen this problem? If so, please send a message to ARPAUPGRADE@BBN.COM. Happy holidays, everyone. Ken Pogran BBN COMMUNICATIONS ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712231055.AA16412@dogie.macc.wisc.edu] <1987122310550400> From: ejnorman%dogie@UNIX2.MACC.WISC.EDU (Eric Norman) Newsgroups: comp.protocols.tcp-ip Subject: Re: More that one IP (sub)network on one cable. Message-ID: <8712231055.AA16412@dogie.macc.wisc.edu> Date: 23 Dec 87 10:55:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Stuart Levy and others talk about: > But there should be a way to tell the software (and the routing information > system...) that multiple nets are directly attached to the same wire. > Looking at the subnetting-related RFCs (917, 932, 936, 950), it's not clear > whether having multiple subnets coexist on one cable was intended or not. There's an aspect of this problem that doesn't seem to have anything to do with subnets being on the same wire. Suppose I have two subnets of, for instance, 192.12.220 that are on different cables but the route between them goes through a gateway that has no interfaces on 192.12.220. How do I configure that gateway? What I really want to say is route add net 192.12.220.64 netmask 0xFFFFFFF0 gateway 128.104.38.20 1 Eric Norman ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712231247.AA11077@KAUAI.MCL.UNISYS.COM] <1987122312472000> From: perry@MCL.UNISYS.COM (Dennis Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: NBS station WWV problems Message-ID: <8712231247.AA11077@KAUAI.MCL.UNISYS.COM> Date: 23 Dec 87 12:47:20 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 As a last resort, we can also try the calendar. They haven't changed for a few centuries :-) dennis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [289@nvpna1.UUCP] <1987122313095900> From: khan@nvpna1.UUCP (Osman Khan 42779) Newsgroups: comp.protocols.tcp-ip Subject: Remote Job Entry Procedures Message-ID: <289@nvpna1.UUCP> Date: 23 Dec 87 13:09:59 GMT Organization: Philips Research Labs, Eindhoven Lines: 14 Keywords: RJE, TCP/IP, VAX/VMS, UNIX Does anyone have Remote Job Entry (RJE) procedures (including remote query, queue manipulation, etc.) based on TCP/IP for UNIX-based workstation users to submit jobs to VAX/VMS (or possibly IBM VM/CMS and MVS) systems. Someone at Apollo mentioned the availability of procedures developed at NASA-Ames called NQB (or something like that). Does anyone know about this or have programs that do something similar? osman khan. uucp: ...decwrl!mcvax!philmds!prle!nvpna1!khan post: Philips Netherlands. Building BC-136A. Postbox 80000, 5600 MD Eindhoven, The Netherlands. fax : +31-40-722861 tel : +31-40-723802 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [290@nvpna1.UUCP] <1987122313144200> From: khan@nvpna1.UUCP (Osman Khan 42779) Newsgroups: comp.protocols.tcp-ip Subject: Secure IP Routers Message-ID: <290@nvpna1.UUCP> Date: 23 Dec 87 13:14:42 GMT Organization: Philips Research Labs, Eindhoven Lines: 17 Keywords: IP-Routers, TCP/IP, Secure We are looking for IP routers that allow limiting traffic between specified systems and of a protocol type. For example: system X, Y and Z should be allowed to communicate to each other but to no other system; in addition no TELNET should be possible between these systems. The IP routers will be linked to each other at speeds up to 64 Kbit/s (2 Mbit/s later) - no X.25 will be used initially. Does anyone have products or are using products that could meet these requirements? osman khan. uucp: ...decwrl!mcvax!philmds!prle!nvpna1!khan post: Philips Netherlands. Building BC-136A. Postbox 80000, 5600 MD Eindhoven, The Netherlands. fax : +31-40-722861 tel : +31-40-723802 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [291@nvpna1.UUCP] <1987122313180700> From: khan@nvpna1.UUCP (Osman Khan 42779) Newsgroups: comp.protocols.tcp-ip Subject: Portable Bulletin Board (like READNEWS) Message-ID: <291@nvpna1.UUCP> Date: 23 Dec 87 13:18:07 GMT Organization: Philips Research Labs, Eindhoven Lines: 15 Keywords: Bulletin Board, VAX/VMS, READNEWS, TCP/IP We are embarking on using TCP/IP to link geographically separate sites where VAX/VMS and UNIX-based workstations are mainly used. For information sharing between users on the different systems we are looking for a portable bulletin board system (READNEWS-like) based on TCP/IP for VMS and UNIX (possibly for IBM VM/CMS too). Is such a product available or is someone willing to port READNEWS for us? osman khan. uucp: ...decwrl!mcvax!philmds!prle!nvpna1!khan post: Philips Netherlands. Building BC-136A. Postbox 80000, 5600 MD Eindhoven, The Netherlands. fax : +31-40-722861 tel : +31-40-723802 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712231458.AA15190@ucbvax.Berkeley.EDU] <1987122314210000> From: TUCJRR@TUCC.TUCC.EDU (Joe Ragland) Newsgroups: comp.protocols.tcp-ip Subject: ACC TCP/IP for IBM MVS systems Message-ID: <8712231458.AA15190@ucbvax.Berkeley.EDU> Date: 23 Dec 87 14:21:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 38 Someone was asking about the Fibronics TCP/IP for IBM MVS systems. We have no experience with this product but we have been using the ACC ACS-9310 and ACC's ACCES/MVS software for about a year now. At the time we needed TCP/IP for an MVS system we could not locate a supplier other than ACC. Investigation of the ACC product revealed that the software was actually the UCLA ACP (Arpanet Control Program) which was developed over many years under the direction of Bob Braden when he was at UCLA. ACC had at that time just added Ethernet code to replace the communications interface code in ACP. I believe that I am correct to state that the ACS-9310 is basically a hardware derivative of an earlier controller built for the DDN by ACC (mil-spec construction) which replaced a communications interface with an Ethernet interface. What all this meant to us at the time was that both the hardware and software had a 'track record' and some non-trivial user experience. The 9310 and ACCES has worked out rather well at TUCC. We are certainly pleased with ACC support. We installed the hardware with telephone consults from ACC and since have had one minor hardware problem for which ACC quickly supplied a replacement. ACC supports this product through their Columbia, Md. offices where they have a group actively working on ACCES support. Our major complaint with ACCES/MVS is that it is table driven and lacks a name resolver. Along with some other users I believe we have convinced ACC to up the priority for providing a name resolver to about the early April timeframe. ACCES/MVS provides line mode and 3270 telnet and suffers like all IBM implementations with telnet sessions between 3270s and other vendor support for full-screen ASCII software. Problems here are with IBM TCAM and VTAM. Getting transparent screen control through this IBM software from a remote ASCII host is impossible. 3270 to remote 3270 works great. TCAM line mode to remote ASCII line mode works well too and VTAM support as a 3270 application program to remote ASCII line mode support is fine. Also provided is FTP (no complaints) and SMTP. We use a mail program called UCLA MAIL and have integrated ACCES/MVS SMTP to the UCLA mailer. The mailer handles mail to/from ACCES SMTP, Bitnet, ARPAnet, etc. Conclusion: we're generally pleased with what the 9310 and ACCES/MVS provides for our IBM MVS users and are pleased with the support efforts of ACC. This list contribution is submitted via UCLA MAIL, ACCES/MVS, ACS-9310 and the ARPANET. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712231536.AA14700@monk.proteon.com] <1987122315363400> From: jas@MONK.PROTEON.COM (John A. Shriver) Newsgroups: comp.protocols.tcp-ip Subject: Subnets connected by a gateway not part of the subnetted network Message-ID: <8712231536.AA14700@monk.proteon.com> Date: 23 Dec 87 15:36:34 GMT References: <8712231055.AA16412@dogie.macc.wisc.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 You can't do that. A network must be contiguous. This is stated on RFC1009 page 5: "The distinction between subnets of such a subnetted network must not be visible outside that network". Since that gateway is not part of the partitioned subnetted network, how in the dickens would it know which half of the network to send a given packet to? It would not have the subnet routing table. Gateways outside a subnetted network send a packet to the nearest point on that network. Then subnet routing carries the packet to the right subnet. While this may take more hops than is optimal, the benefits of abstraction make it worthwhile. Exactly the same restriction applies to DECnet. A DECnet area must be contiguous. It also has the same extra-hop phenomenon in inter-area routing. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712231733.AA17567@ucbvax.Berkeley.EDU] <1987122316141900> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: what a checksum is for Message-ID: <8712231733.AA17567@ucbvax.Berkeley.EDU> Date: 23 Dec 87 16:14:19 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 I was reminded a couple of weeks ago that checksum do more than catch corrupted bits. They help catch some formatting errors in headers (such as byte and bit order mistakes). One should not dispense with transport level checksums simply because one's media is uncorruptable. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712231640.AA03858@sccgate.scc.com] <1987122316402200> From: oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) Newsgroups: comp.protocols.tcp-ip Subject: Was "The Patch" removed? Message-ID: <8712231640.AA03858@sccgate.scc.com> Date: 23 Dec 87 16:40:22 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Apparently last week's attempt to patch around one of the problems in PSN 7.0, the problem being hanging X.25 virtual circuits originating on 1822 hosts, has been removed. At 1900 hours yesterday the problems caused by the patch still plagued our gateway. But, since approximately 0200 hours today, we have been able to maintain normal reachability with our EGP peers. I assume the change occured between those hours. My question is, did this occur on purpose or can I expect imminent redisconnection? As troublesome as the orignal problem in 7.0 is, it doesn't compare to the troubles caused by "The Patch". Mike ps: I've certainly learned my lesson, I'll never mention the problem with 7.0 again, please just don't disconnect me again. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712232201.AA22257@ucbvax.Berkeley.EDU] <1987122319282900> From: pogran@CCQ.BBN.COM (Ken Pogran) Newsgroups: comp.protocols.tcp-ip Subject: Re: Was "The Patch" removed? Message-ID: <8712232201.AA22257@ucbvax.Berkeley.EDU> Date: 23 Dec 87 19:28:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Mike, Yes, last week's patch was removed last night. Unfortunately, it didn't solve the problem Andy Malis thought it would solve. He is about to test (in our own network, since we now have a Sun with an X.25 interface hooked up to it) a new patch that should work. If it does work, it should be out in the ARPANET in the near future. Actually, we're suprised to learn from your message that the patch that went in last week made things that much WORSE for you. I think you and we mis-communicated. You did mention in a message to Andy, "Occasionally, maybe once or twice a day, the X25 manager refuses to make outgoing or accept incoming calls ... This has only occured since the midnight patch of a few days ago." You mentioned that you were referring this problem to Sun, so we took it to be a minor point for us; we didn't take it as a request or a reason to pull the patch. In hindsight, I guess we should have. Instead, we continued to view the patch as "harmless" although not particularly successful in correcting the problem it was supposed to correct. Please accept our apologies in this regard. Ken ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122320460000> Received: from MVSA.USC.EDU ([128.125.1.142]) by SRI-NIC.ARPA with TCP; Thu 24 Dec 87 05:22:16-PST Date: Thu, 24 Dec 87 4:46 PST From: Leonard D Woren Subject: Re: Cheap TCP/IP access to IBM/Amdahl's To: TCP-IP@SRI-NIC.ARPA > Is there however a cheaper, lower-but-acceptable performance alternative - > say a PC/AT with channel one side and Ether the other. The IBM 8232 LAN Channel Station is an industrial PC/AT with a channel on one side and LAN connections (Ethernet or/and Token Ring) on the other. I believe the performance is close to the K200, at least in the same ballpark. The problem is, the 8232 may cost as much as the K200. (As an IBM & PCM bigot, I hate to say this, but you pay $$$ for those 3 letters.) And there's another big problem that caused us to go for the ACS 9310 from ACC: IBM has no (announced) software for MVS for the 8232. Their response: "we recognize the requirement." Our requirement was "get something now". I understand the 8232 is being marketed only to Universities, and is only being sold in the U.S. It is marketed through a special IBM group known as ACIS, for ACademic Information Systems. > If so - what Amdahl s/w would be required if we were NOT working with > UTS. Resident systems on the Amdahl are VM/CMS and MVS. The IBM software for the 8232 runs under VM. The ACC software for the 9310 runs under MVS. ACC also sells VM software; I know nothing about it. (But they listen to this list, so ...) > Surely there must be a better way of talking to IBM's than serial RJE's, > but at a reasonable cost... Sigh. Two conflicting terms... IBM and reasonable cost. If you don't already have a copy, you might want to check out the DDN Protocol Implementations and Vendors Guide. It's available via anonymous FTP at SRI-NIC.ARPA as NETINFO:VENDORS-GUIDE.DOC , or you can buy a printed copy from them. The following paragraph is extracted from the file: Additional copies of this document may be obtained from the DDN Network Information Center, SRI International, 333 Ravenswood Avenue, Room EJ291, Menlo Park, CA 94025. Price is $30.00 domestic, $35.00 overseas. Copies may also be obtained from the Defense Technical Information Center (DTIC), Cameron Station, Alexandria, VA 22314. The table of contents lists a number of products for IBM systems, around a half dozen of which appear to be for mainframes. /Leonard , ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712240031.AA24978@ucbvax.Berkeley.EDU] <1987122320464900> From: pogran@CCQ.BBN.COM (Ken Pogran) Newsgroups: comp.protocols.tcp-ip Subject: Santa's PSN 7 status Message-ID: <8712240031.AA24978@ucbvax.Berkeley.EDU> Date: 23 Dec 87 20:46:49 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 80 Folks, Here's where we stand on resolving ARPANET PSN 7 problems: Please refer to my message of 15 December entitled "An ARPANET Update" for a description of the problems referred to here. We have successfully tested fixes for the "one packet problem" and the "pinging yourself" problem. These patches should be deployed ARPANET-wide within the next day or so. We have identified the "multiple of 128 bytes" problem as a host software problem. Here are the details: 1. The "one packet problem" (otherwise known as the "stuck VC problem," "thrashing VC problem," etc.). Known to affect Sun X.25 hosts. When an 1822-connected host begins to send data to an X.25-connected host, the destination PSN, to which the X.25-connected host is attached, must open an X.25 VC with to the destination host. Under PSN 7, the PSN opens the VC, sends the first IP datagram, and waits for an RR from the host before allowing the source PSN to send additional data across the network (and to return a RFNM to the source host for the first packet). This behavior is different from PSN 6, where up to 8 datagrams could be sent to the destination host. Under PSN 6, a source host could conceivably receive the RFNM for the first such datagram before the datagram was acknowledged by the destination host. RRs are often piggy-backed on traffic flowing over the same VC in the opposite direction. However, conditions such as Mailbridge homing in the DDN can produce asymmetric flows. Many X.25 implementations send an RR to acknowledge a packet based on the expiration of a timer, if there is no reverse traffic. Sun X.25 does not, however, but instead waits for the window to become "half full". The behavior of the "interoperability" mechanism of PSN 7, together with the behavior of the Sun X.25, created a "deadly embrace" in which only one datagram would be received on the VC. Behavior of the PSN 7 interoperability mechanism is being changed to eliminate this condition. The patch to do this has been tested in our lab and will be deployed to the ARPANET shortly. NOTE: A patch was deployed last week in an attempt to fix this problem. That patch did not work, and was removed from the network last night. We had been unable to test that patch in the lab beforehand, because at the time we did not have a Sun with an X.25 interface hooked up to our lab net. 2. The "pinging yourself" problem. The timing bug described in my message of 15 December has been fixed in a patch tested earlier today. Mike Petry at UMd was our "guinea pig", and reports that the problem he saw has in fact been corrected by this patch. This patch will also be deployed to the ARPANET shortly. 3. The "multiple of 128 bytes" problem. Using our Sun with X.25 interface in our lab net, and with a data scope on the X.25 link between the PSN and the Sun, we tried "pinging" the Sun from another host. We found that with packets of length 127, 128, 255, 256 ... the datascope showed the "ping" going to the Sun, but no response from the Sun. With packets of other length, the datascope showed the "ping" and its reply going across the link. The packets from the PSN are well-formed in every respect. At this point we can only assume there's a bug in the host code. --> Has anyone OTHER than folks with Suns with X.25 interfaces seen this problem? If so, please send a message to ARPAUPGRADE@BBN.COM. Happy holidays, everyone. Ken Pogran BBN COMMUNICATIONS ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712232053.AA23401@ACC-SB-UNIX.ARPA] <1987122320533800> From: gary@ACC-SB-UNIX.ARPA (Gary Krall) Newsgroups: comp.protocols.tcp-ip Subject: Objectivity Message-ID: <8712232053.AA23401@ACC-SB-UNIX.ARPA> Date: 23 Dec 87 20:53:38 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Tom, As I mentioned in an earlier message ACC is actively working the problem. And while we argee with Dave that in cases where the 5250 is being used in a gateway with significant traffic there seems to be virtual circuit resource limitations. Please note that when used in a end-host configuration, which the product was designed for, the 5250 works well. Also it is important to keep in mind that the vc limit is not artifical but has to do with available resources both in the host and the front-end board. ACC is preparing to release a version of the 5250 which will double the number of virtual circuits available. In addition, members of our technical staff off-line from this forum have had a number of conversations with both Dave and technical personnel from BBN concerning PSN 7 deployment. Yes, life is too short to be mad about things; however if you have detailed and constructive criticism we would be happy to discuss it in an OBJECTIVE manner. Gary. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1987.12.24.0.16.56.Eugene.Hastings@morgul] <1987122400272500> From: Eugene.Hastings@MORGUL.PSC.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: 5250 and VCs Message-ID: <1987.12.24.0.16.56.Eugene.Hastings@morgul> Date: 24 Dec 87 00:27:25 GMT References: <8712232053.AA23401@ACC-SB-UNIX.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Well, we have 5250s, and they are in use on gateways. We have inquired several times of both BBN and ACC, and for all we know both groups have been on vacation. Until your latest post, I had no idea that there really was any activity aimed specifically at treating this problem. We're still new at this, and at first we didn't know who to ask. We found out, and we asked several times. Alright, I haven't called every day, but nevertheless - WHY DO WE ONLY SEE STATUS REPORTS ON A GENERAL MAILING LIST??? Gene ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712232016.aa17502@Huey.UDEL.EDU] <1987122401160500> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Further to the WWV problem Message-ID: <8712232016.aa17502@Huey.UDEL.EDU> Date: 24 Dec 87 01:16:05 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Folks, Phil Karn confirms that on at least one frequency (10 MHz) the WWV signal from Ft. Collins is currupted. As the result of careful measurements here using high-grade communications receivers and antennas, I found the same problem on 5, 10 and 15 MHz: The 100-Hz subcarrier does not disappear between bauds, but is suppressed only about ten decibels. It happens in fact that the WWVB transmission on 60 KHz modulates its carrier by 10-dB power reductions, but there is no reason that I can fathom why doing this on the HF subcarrier is anything but broken. It appears that a call to the station engineering staff is in order. Say a prayer to the God of Christmas Now and hope someone answers the phone tomorrow. I don't know if this problem has killed radio clocks other than Heath. Can somebody squawk on whether the Precision Time Standards gizmos are coping? Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712240201.AA04896@sccgate.scc.com] <1987122402015900> From: oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) Newsgroups: comp.protocols.tcp-ip Subject: Re: Was "The Patch" removed? Message-ID: <8712240201.AA04896@sccgate.scc.com> Date: 24 Dec 87 02:01:59 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Ken, We certainly must have miscommunicated. The patch changed what was a bad situation into a horrible one. Our gateway would cease to gateway several times a day and our EGP software couldn't cope. We called Sun, BBN, DCA, DARPA, and anyone else we could think of in an attempt to keep our box on the air. Last I heard, we still have service requests in with BBN and Sun. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712240419.AA02557@hydra.riacs.edu] <1987122404191500> From: ari@riacs.EDU (Ari Ollikainen) Newsgroups: comp.protocols.tcp-ip Subject: End-to-End Checksums Message-ID: <8712240419.AA02557@hydra.riacs.edu> Date: 24 Dec 87 04:19:15 GMT References: <1655@faline.bellcore.com> Sender: usenet@ucbvax.BERKELEY.EDU Organization: RIACS, NASA Ames Research Center, Moffett Field, CA Lines: 18 I believe that Vitalink has actually applied for a patent on what they call End-to-End FCS. Their first generation of TransLAN product did NOT carry the Ethernet CRC across the serial link. Back in 1985 when we made our earliest experiments using Vitalink bridges across a point-to-point satellite link we had some DECnet users complain about garbaged files. It turned out that the DECnet hosts assumed that, since they were operating on an ethernet, the Ether CRC was sufficient protection against corruption. And we, using FTP/TCP/IP, didn't have any realy problem EXCEPT that the transmission times for files seemed to vary more than could be explained by the load on the communicating hosts. It turned out that we were using some RF modems which were 1) sensetive to RFI/EMI, and 2) used the same polynomial for "scrambling" that was used to compute the CRC on the HDLC frame that Vitalink used on the p-t-p link. Some frames were sufficiently corrupted to pass the CRC re-computation at the receiving end, thus these frames would have a NEW Ether CRC generated for them and be sent forth to fill the DEC users' file. OF COURSE, the TCP (and IP header cksums) caught the garbage storms and prevented the Internet protocols suite users from suffering file corruption! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712241342.AA06542@ucbvax.Berkeley.EDU] <1987122412460000> From: LDW@MVSA.USC.EDU (Leonard D Woren) Newsgroups: comp.protocols.tcp-ip Subject: Re: Cheap TCP/IP access to IBM/Amdahl's Message-ID: <8712241342.AA06542@ucbvax.Berkeley.EDU> Date: 24 Dec 87 12:46:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 44 > Is there however a cheaper, lower-but-acceptable performance alternative - > say a PC/AT with channel one side and Ether the other. The IBM 8232 LAN Channel Station is an industrial PC/AT with a channel on one side and LAN connections (Ethernet or/and Token Ring) on the other. I believe the performance is close to the K200, at least in the same ballpark. The problem is, the 8232 may cost as much as the K200. (As an IBM & PCM bigot, I hate to say this, but you pay $$$ for those 3 letters.) And there's another big problem that caused us to go for the ACS 9310 from ACC: IBM has no (announced) software for MVS for the 8232. Their response: "we recognize the requirement." Our requirement was "get something now". I understand the 8232 is being marketed only to Universities, and is only being sold in the U.S. It is marketed through a special IBM group known as ACIS, for ACademic Information Systems. > If so - what Amdahl s/w would be required if we were NOT working with > UTS. Resident systems on the Amdahl are VM/CMS and MVS. The IBM software for the 8232 runs under VM. The ACC software for the 9310 runs under MVS. ACC also sells VM software; I know nothing about it. (But they listen to this list, so ...) > Surely there must be a better way of talking to IBM's than serial RJE's, > but at a reasonable cost... Sigh. Two conflicting terms... IBM and reasonable cost. If you don't already have a copy, you might want to check out the DDN Protocol Implementations and Vendors Guide. It's available via anonymous FTP at SRI-NIC.ARPA as NETINFO:VENDORS-GUIDE.DOC , or you can buy a printed copy from them. The following paragraph is extracted from the file: Additional copies of this document may be obtained from the DDN Network Information Center, SRI International, 333 Ravenswood Avenue, Room EJ291, Menlo Park, CA 94025. Price is $30.00 domestic, $35.00 overseas. Copies may also be obtained from the Defense Technical Information Center (DTIC), Cameron Station, Alexandria, VA 22314. The table of contents lists a number of products for IBM systems, around a half dozen of which appear to be for mainframes. /Leonard , ----MESSAGE-END---- ----MESSAGE-BEGIN---- [122487.100322.elinsky@ibm.com] <1987122415032000> From: ELINSKY@IBM.COM (Jay Elinsky) Newsgroups: comp.protocols.tcp-ip Subject: IBM 8232 Message-ID: <122487.100322.elinsky@ibm.com> Date: 24 Dec 87 15:03:20 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 The 8232 is marketed to commercial customers as well as universities, and it has been announced in at least some European countries. Jay Elinsky IBM T.J. Watson Research Center Yorktown Heights, NY ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1617@julian.UWO.CDN] <1987122416460100> From: peter@julian.UWO.CDN (Peter Marshall) Newsgroups: comp.protocols.tcp-ip Subject: Re: tcp/ip books Message-ID: <1617@julian.UWO.CDN> Date: 24 Dec 87 16:46:01 GMT References: <8712180837.AA06536@gargoyle.uchicago.edu> Reply-To: peter@julian.UUCP (Peter Marshall) Organization: University of Western Ontario, London Lines: 17 In article <8712180837.AA06536@gargoyle.uchicago.edu> root@vijit.UUCP writes: >Another series of books that may be useful is "Handbook of >Computer-Communications Standards".... >The author/editor of these three volumes is William Stallings. > >[I am told that the (take a deep breath) Library of Computer and Information >Science Book Club (whew!) will be offering these 3 books both together >and separately in their February mailing. ... These books appeared in the December mailing for response by January 31, 1988 (at least in Canada). The first volume is a "selection" and the others are optional. -- Peter Marshall, Data Comm. Manager CCS, U. of Western Ontario, London, Canada N6A 5B7 (519)661-2151x6032 pm@uwovax.BITNET; pm@uwovax.uwo.cdn; peter@julian.uucp; ...!watmath!julian!peter ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712241211.aa23482@Huey.UDEL.EDU] <1987122417110400> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: WWV update Message-ID: <8712241211.aa23482@Huey.UDEL.EDU> Date: 24 Dec 87 17:11:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 Folks, A phone call to the WWV Engineer in Charge revealed that yes, they did realign the timecode generator a couple of days ago, which corresponds to the time the Heath clocks lost theirs. Happens the ancient generators (15-20 years old) had drifted from the Inter-Range Instrumentation Group (IRIG) specification, which does say "10 dB down," not "all the way down," as apparently assumed by the Heath designers. Well, the subcarrier has been misadjusted then since before I've been watching clocks, almost a decade now. Anyway, The EinC kindly offered to return the adjustment to its "original" state early next week, so our clocks might get a Christmas present after all. Turns out Precision Standard Time, Inc., is actively lobbying WWV to replace their wheezing timecode generators and there is a good possibility that might come to pass. If so, there may be a good opportunity to lobby the "advance-warning-leap-second" issue, which comes down again at the last second of the year and which will cause zillions of clocks all over the world to hiccup. Therefore, we might do well to widely publicize our outrage when, as expected, our clocks swish and sway in the first few minutes to hours after the leap. Phil Karn, I was wrong. The new transmitters have not arrived WWV yet, although they have been running at WWVH for about a year. Yes, the reason for the backwave was continuous phase tracking and yes, today's technology doesn't need that. If anybody from IRIG is alive today, punch him in the nose. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712241814.AA06202@trantor.UMD.EDU] <1987122418142300> From: louie@TRANTOR.UMD.EDU ("Louis A. Mamakos") Newsgroups: comp.protocols.tcp-ip Subject: Re: WWV update Message-ID: <8712241814.AA06202@trantor.UMD.EDU> Date: 24 Dec 87 18:14:23 GMT References: <8712241211.aa23482@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Hey, if we're gonna insist on an advance-warning-leap-second, then we really should insist on having the YEAR be transmitted as well. Please! louie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4844@well.UUCP] <1987122502553200> From: johnl@well.UUCP (John A. Limpert) Newsgroups: comp.protocols.tcp-ip Subject: Re: PC/AT UNIX TCP/IP software development Message-ID: <4844@well.UUCP> Date: 25 Dec 87 02:55:32 GMT References: <8712221526.AA25462@cod.nosc.mil> Reply-To: johnl@well.UUCP (John A. Limpert) Organization: Whole Earth 'Lectronic Link, Sausalito, CA Lines: 19 I have ported KA9Q's TCP/IP software to several UNIX machines, an AT clone running Microport System V/AT and a Heurikon 68010 running UniPlus+ 5.0. It currently supports SLIP and KISS on asynchronous lines. I am using it on a packet radio TCP/IP net. I haven't added any support for Ethernet since I do not have the hardware. It is running reliably and supports FTP, SMTP and TELNET. After I finish cleaning up some things and add the revisions from the latest KA9Q release, I will make the sources and binaries available to anyone who is interested in them. I expect that they will eventually show up in the KA9Q distributed sources along with the Macintosh, Amiga and UNIX code that is already in there. I started with Jere Sandidge's (sp?) UNIX PC (68000) port and made some changes so that it would run on an 80286 system. Also fixed a few bugs while I was at it. John A. Limpert, N3DMC johnl@n3dmc.UUCP, bellcore!wb6rqn!n3dmc!johnl, n3dmc@wa3pxx ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712250010.aa27048@Huey.UDEL.EDU] <1987122505100400> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: WWV update Message-ID: <8712250010.aa27048@Huey.UDEL.EDU> Date: 25 Dec 87 05:10:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Louie, Yes, you remember that I honk on the advance-year issue every year. I in fact raised it with the EinC, but he complained that the format is out of bits. Well, the info could be coded as a superframe, since the data rate is pretty low for that kind of stuff. Time to lobby PSTI on that, too. Ahem. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [502@athos.rutgers.edu] <1987122507021200> From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Response to Long Distance NFS Query Message-ID: <502@athos.rutgers.edu> Date: 25 Dec 87 07:02:12 GMT References: Organization: Rutgers Univ., New Brunswick, N.J. Lines: 15 I guess I'm about to jump on the bandwagon for turning on NFS checksumming. We just had Sun field service replace an Ethernet board because we started noticing corrupted files transported via NFS. No gateways or bridges involved. It was apparently a failure in the Ethernet interface board. After the vacation I'm going to look into turning on checksumming everywhere. This was not our first problem. The other one was due to a design bug in the ACC 1822 Multibus card. When put into a gateway with more than one Ethernet card, the load got too heavy for the chips they used to drive it. The bus arbitration didn't work. It stomped on the bus cycles of other devices. Result was random garbaging of data. TCP worked fine, but NFS files were garbaged. The board has just recently been fixed. Of course with these low-rate failures, if checksumming were turned on, we would probably never even know we had a problem. On the other hand, it seems a bit drastic to use garbage in user files as a diagnostic. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12361366289.20.LYNCH@A.ISI.EDU] <1987122520530400> From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: Response to Long Distance NFS Query Message-ID: <12361366289.20.LYNCH@A.ISI.EDU> Date: 25 Dec 87 20:53:04 GMT References: <502@athos.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Gee, when I used to work in a computer center we had this marvelous procedure called "running diagnostics". We did it to make sure all the equipmetn was in proper working order. Now that we have networking have we forgotten our past??? What I see missing is a definite package of diagnostic prodecures to check out each "piece of the system". If the "network IS the computer" it needs to be treated like one. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7137.8712280332@wrtfac.cdc.com] <1987122702051300> From: hassler@wrtfac.UUCP (Barry D. Hassler) Newsgroups: comp.protocols.tcp-ip Subject: IP class B and C to X.25 address translation Message-ID: <7137.8712280332@wrtfac.cdc.com> Date: 27 Dec 87 02:05:13 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Has there been any standardization on the translation of Class B or C IP addresses to X.25 addresses? I am aware of the translation standard for Class A addresses, but have not seen any for B or C. Thanks, Barry D. Hassler hassler%wrtfac@lognet2.arpa System Software Analyst Control Data Corporation ----MESSAGE-END---- ----MESSAGE-BEGIN---- [304205.871227.JBVB@AI.AI.MIT.EDU] <1987122723493200> From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") Newsgroups: comp.protocols.tcp-ip Subject: Re: Response to Long Distance NFS Query Message-ID: <304205.871227.JBVB@AI.AI.MIT.EDU> Date: 27 Dec 87 23:49:32 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 In the Chaosnet example mentioned, the router was running just fine, and the memory problem was corrupting one in N packets forwarded. Yeah, a diagnostic would have found it, but networks are big and fuzzy, and the failure was intermittent, and I think the people who first realized there was a problem spent some time just locating it, and some more time thinking it was a software bug. It would be nice if everything ran memory diagnostics as the idle task, and it would be nice if there weren't interfaces which corrupt packets silently under some conditions. Maybe someday. For the moment, I think end-to-end error detection is a good thing. jbvb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712272002.aa03319@BWAY.BWAY.UUCP] <1987122801023000> From: dpk@bway.UUCP (Doug Kingston) Newsgroups: comp.protocols.tcp-ip Subject: Re: Remote Job Entry Procedures Message-ID: <8712272002.aa03319@BWAY.BWAY.UUCP> Date: 28 Dec 87 01:02:30 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 The system is "NQS" (the Network Queueing System) and was based on the earlier MDQS system I wrote but is pretty much a complete rewrite. It was done by a contractor for the NASA Ames Research Center (I believe NAS specifically). Hopefully someone can get you specifics on it. They use it to feed jobs into the Cray-2. BRL has a copy as well. -Doug- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122811530000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 28 Dec 87 13:57:57-PST Date: 28 Dec 1987 16:53-EST Sender: CERF@A.ISI.EDU Subject: Re: tcp/ip books From: CERF@A.ISI.EDU To: clyde!watmath!julian!peter@RUTGERS.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]28-Dec-87 16:53:02.CERF> In-Reply-To: <1617@julian.UWO.CDN> A short but very nice introduction to TCP/IP protocols was recently published by Ungermann-Bass via Springer-Verlag: An Introduction to TCP/IP John Davidson, (c) 1988 ISBN 0-387-96651-X ISBN 3-540-96651-X Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712281208.aa23838@Huey.UDEL.EDU] <1987122817084400> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Tocking clocks Message-ID: <8712281208.aa23838@Huey.UDEL.EDU> Date: 28 Dec 87 17:08:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Folks, On or about 1550Z this day the 100-Hz WWV subcarrier was readjusted to its original (nonstandard) configuration in use for the last several years. As of twenty minutes after that all the WWV clocks I can reach out and tock to via the Internet once again were ticking to WWV chimes. I warmly thanked John Melton, Engineer in Charge at WWV, on behalf of all Heath clock owners. I have not heard from Precision Standard Time clockers on how their ticks were tocking. I have updated and am now in procwss of distributing new code to all the fuzzball time servers that should properly handle the leap second promised at the end of this year. I will attempt to read as many clocks as I can during that second and report. I should mention that I did in fact inquire of the local power utility who pays for the extra second of steam and how the utilities coordinate nominal mains-frequency time before and after the event, since neither of these appears in the tariff. The answer to the first question is the ratepayer pays for the steam and the utility pays for the depreciation. The answer to the second is in a lovely graph taken during the last leap which I can make available in a Sun-format image file. Well, you guys probably think I'm nuts over the network-time issue, but in a quirky kind of way it's a lot of fun. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712281751.AA05557@lear.ultra.com] <1987122817512200> From: wayne@ultra.UUCP (Wayne Hathaway) Newsgroups: comp.protocols.tcp-ip Subject: Re: Remote Job Entry Procedures Message-ID: <8712281751.AA05557@lear.ultra.com> Date: 28 Dec 87 17:51:22 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 As Doug Kingston mentioned, NQS (The Network Queueing System) was written by Sterling Software (then Informatics), as the System Software Contractor for the Numerical Aerodynamic Simulation (NAS) Project at NASA's Ames Research Center. NQS was delivered to NASA as part of the contract, and Cray adopted it as their standard RJE mechanism for UNICOS (their port of UNIX System V). The author was Brent Kingsbury, who has since joined Cray in Mendota Heights, MN, where he is continuing to work on NQS. I don't have an electronic address for Brent, but Cray should certainly be in the Mendota Heights phone book [ :-) ]. It's a good system; Brent did a hell of a job. Wayne Hathaway ultra!wayne@Ames.ARPA Ultra Network Technologies 2140 Bering drive with a domain server: San Jose, CA 95131 wayne@Ultra.COM 408-922-0100 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D28-Dec-87.16:53:02.CERF] <1987122821530000> From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: tcp/ip books Message-ID: <[A.ISI.EDU]28-Dec-87.16:53:02.CERF> Date: 28 Dec 87 21:53:00 GMT References: <1617@julian.UWO.CDN> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 A short but very nice introduction to TCP/IP protocols was recently published by Ungermann-Bass via Springer-Verlag: An Introduction to TCP/IP John Davidson, (c) 1988 ISBN 0-387-96651-X ISBN 3-540-96651-X Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712282332.aa27722@Huey.UDEL.EDU] <1987122904320600> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Leaping clocks Message-ID: <8712282332.aa27722@Huey.UDEL.EDU> Date: 29 Dec 87 04:32:06 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Folk, Q: What time is it DURING the impending leap second scheduled for Thursday? A: The leap is considered the 61st second of the last minute of the day in which scheduled. Thus, the time indicated midway in the leap would be 23:59:60.5. I challenge anybody to write clean code that would do that trick and compare it to the code that would produce 24:00:00.5 when given the number of milliseconds past midnight and the number of milliseconds in any given day (including the leap). Grumble. If you happen to tickle a fuzzy during the leap, you get the latter. Life is too short. Reference NBS Publication 432. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987122909490000> Mail-From: STJOHNS created at 29-Dec-87 17:50:48 Date: 29 Dec 1987 17:49-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: UVax Ultrix Blues From: Mike StJohns To: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]Tue, 29 Dec 87 17:49:59 PST.STJOHNS> And the answer is... ifconfig qe0 -trailers My thanks to all (at last count 8) the people who submitted this answer, but I regret I can't award duplicate prizes *grin*. And my boss doesn't understand why I like the net so much. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19871229153813.4.DCP@SWAN.SCRC.Symbolics.COM] <1987122915380000> From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: Naming schemes Message-ID: <19871229153813.4.DCP@SWAN.SCRC.Symbolics.COM> Date: 29 Dec 87 15:38:00 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Date: Tue, 22 Dec 87 10:53:00 CST From: "Paul Lustgraaf" Does anyone out there care to comment about naming schemes? I have to choose between a 3 level and a 4 level machine name, ie. vaxa.iastate.edu vs. vaxa.cc.iastate.edu, Where vaxa is the machine and cc is the subnet (usually a department name). Any comments either way? I think you should plan on growth and give other departments the opportunity to name machines independently. This opinion says you should use vaxa.cc.iastate.edu. I don't think you should break up names based on "subnet" as subnets are physical things but naming hierarchies are more administrative things. There may be associatations between subnets and departments at your site, however, I know of some places that have many subnets within one department as well as places that have many departments on one subnet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12362433592.14.STJOHNS@SRI-NIC.ARPA] <1987122922355600> From: STJOHNS@SRI-NIC.ARPA (Michael St. Johns) Newsgroups: comp.protocols.tcp-ip Subject: UVax ULTRIX Blues Message-ID: <12362433592.14.STJOHNS@SRI-NIC.ARPA> Date: 29 Dec 87 22:35:56 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 27 I'm in the process of trying to get a micro vax II running Ultrix up and operational on an ether net behind a cisco gateway attached to the Arpanet. I am experiencing some problems. When I try to transfer (FTP or TELNET) more data than will fill a 512 byte TCP segment, the connection hangs on me. This transfer is either by doing something like "more /etc/termcap" or starting an FTP transgfer of a file larger than 512 bytes . Here's the kicker... this only happens on transfers outbound from the micro vax, inbound transfers seems to work fine. Transfers on the same ethernet seem to work fine in either direction and with any amount of data. Raw PINGs seems to work fine for ANY size ping packet. In either direction. We've swapped the ether interface card in the gateway with no effect. Has anyone else seen this type of behavior? This is an ULTRIX 2.0 system (binary version *sigh*) so I haven't been able to peek real closely at the innards. Help! Mike ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987123000100000> Mail-From: STJOHNS created at 30-Dec-87 08:11:48 Date: 30 Dec 1987 08:10-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: UVax Ultrix Blues also Pyramid-98xe Blues From: STJOHNS@SRI-NIC.ARPA To: W8SDZ@SIMTEL20.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]Wed, 30 Dec 87 08:10:47 PST.STJOHNS> In-Reply-To: Heh heh... I think I understand the 3-4 second pause at the TAC. TAC buffers are only 64 characters in size. (Per port) I'm not sure what window they advertise though, but 64*3 = 192 does sound suspicious. Your other problem sounds interesting, but you need to supply a bit more detailed info about it. Like, does the transfer hang up regardless of the direction? Is there a gateway or two involved? How about PINGs? Mike . ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]Tue,.29.Dec.87.17:49:59.PST.STJOHNS] <1987123001490000> From: StJohns@SRI-NIC.ARPA (Mike StJohns) Newsgroups: comp.protocols.tcp-ip Subject: Re: UVax Ultrix Blues Message-ID: <[SRI-NIC.ARPA]Tue,.29.Dec.87.17:49:59.PST.STJOHNS> Date: 30 Dec 87 01:49:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 And the answer is... ifconfig qe0 -trailers My thanks to all (at last count 8) the people who submitted this answer, but I regret I can't award duplicate prizes *grin*. And my boss doesn't understand why I like the net so much. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712300249.AA16711@ames-titan.arpa] <1987123002490400> From: medin@AMES-TITAN.ARPA (Milo S. Medin, NASA ARC Code ED) Newsgroups: comp.protocols.tcp-ip Subject: Re: UVax Ultrix Blues Message-ID: <8712300249.AA16711@ames-titan.arpa> Date: 30 Dec 87 02:49:04 GMT References: <[SRI-NIC.ARPA]Tue,.29.Dec.87.17:49:59.PST.STJOHNS> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 I thought Ultrix 2.0 did what 4.3 does, that is negotiate during the ARP for trailer use? That way you can use trailers to hosts who support it, and not use them to hosts who don't... Oh well, maybe next time. Vendors should note that 4.2 networking code just isn't good enough anymore... Milo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712300401.AA15931@trantor.UMD.EDU] <1987123004011000> From: louie@TRANTOR.UMD.EDU ("Louis A. Mamakos") Newsgroups: comp.protocols.tcp-ip Subject: Re: UVax Ultrix Blues Message-ID: <8712300401.AA15931@trantor.UMD.EDU> Date: 30 Dec 87 04:01:10 GMT References: <8712300249.AA16711@ames-titan.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Gee, another chance to bash Ultrix networking code :-> The networking code isn't as bad as that Milo; they've moved up to a 4.3 alpha or beta release before the tailer negotiation went in. I'd be real suprised if the release version of Ultrix 2.2 has the trailer negotiation in it either. I guess after putting in DECnet, LAT, and other stuff most UNIX customers don't want, they ran out of time and didn't get a chance to port the release 4.3 stuff. It's not that Ultrix is crummy or that the folks in the Ultrix Engineering group are stupid. They're not. They've done some real neat stuff. It's just not stuff that I (the customer) really wants. Oh well, maybe in 2.4 we'll even get Van's new TCP (though I doubt it). louie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [KPETERSEN.12362514574.BABYL@SIMTEL20.ARPA] <1987123006000000> From: W8SDZ@SIMTEL20.ARPA (Keith Petersen) Newsgroups: comp.protocols.tcp-ip Subject: UVax Ultrix Blues also Pyramid-98xe Blues Message-ID: Date: 30 Dec 87 06:00:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 I'm having similar problems on a Pyramid-98xe running OSx with the dual universe Unix 4.2BSD/SYSV. It's even worse on this one. If one attempts to FTP a file larger than about 80k either to or from this Pyramid machine it dies, giving the appearance to user that the system crashed but it eventually comes back after 4-5 minutes. If you use telnet to connect to another machine and "cat" a large text file that also kills it in the same way. The rc.local file does have ifconfig portname -trailers Another strange thing is that users who connect to this machine from a TAC get a 3-4 second pause in terminal output every 192 characters. These have been long-standing problems for about a year now. Pyramid doesn't seem to know how to fix it. --Keith Petersen ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]Wed,.30.Dec.87.08:10:47.PST.STJOHNS] <1987123016100000> From: STJOHNS@SRI-NIC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: UVax Ultrix Blues also Pyramid-98xe Blues Message-ID: <[SRI-NIC.ARPA]Wed,.30.Dec.87.08:10:47.PST.STJOHNS> Date: 30 Dec 87 16:10:00 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Heh heh... I think I understand the 3-4 second pause at the TAC. TAC buffers are only 64 characters in size. (Per port) I'm not sure what window they advertise though, but 64*3 = 192 does sound suspicious. Your other problem sounds interesting, but you need to supply a bit more detailed info about it. Like, does the transfer hang up regardless of the direction? Is there a gateway or two involved? How about PINGs? Mike . ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712301724.AA08788@csc-lons.ARPA] <1987123017240000> From: scottr@csc-lons.csv001.tv.ARPA (Scott W. Rogers) Newsgroups: comp.protocols.tcp-ip Subject: TCP/SMTP ULTRIX <-> MULTICS PROBLEM Message-ID: <8712301724.AA08788@csc-lons.ARPA> Date: 30 Dec 87 17:24:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 38 I'm having a problem receiving some (SMTP) mail from a MULTICS host on my ULTRIX 1.2 and 2.0 (binary, sigh) VAX 8600 and 8650 systems. I can send mail to MULTICS without any problem, and most mail is received. The problem is as follows: After the SMTP initialization, MULTICS sends a 51 character 'MAIL From: ' string which is never acknowledged by ULTRIX. The MULTICS engineer says that his system is not receiving the TCP ACK even after several retrys and changing his timeout from 1 to 2 minutes. ULTRIX nevers sees the connection drop, and sendmail hangs. The next time MULTICS mail is received (every 15 minutes), a new sendmail process is spawned, and the same problem occurs. This quickly stuffs the process table full of sendmail processes. The problem is completely reproducable through MAIL. Using TELNET, the Multics engineer was able to produce it only sometimes. Notes: The same problem occurs with ULTRIX 2.0 over DDN thru 2 PSN's and ULTRIX 1.2 when MULTICS is on the same PSN. I don't know if this provides any great insight to anyone. Also, TELNET connections to MULTICS work, but tend to hang/drop after some period of time. I'm not sure of the relation, but if the problem lies in the TCP/IP code ... DEC, are you listening ! If anyone has had similar problems, or has a solution, or even any idea's, please let me know. Thanks. Scott W. Rogers scottr@csc-lons.arpa ---- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19871230175619.3.DCP@SWAN.SCRC.Symbolics.COM] <1987123017560000> From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: TCP/SMTP ULTRIX <-> MULTICS PROBLEM Message-ID: <19871230175619.3.DCP@SWAN.SCRC.Symbolics.COM> Date: 30 Dec 87 17:56:00 GMT References: <8712301724.AA08788@csc-lons.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Date: Wed, 30 Dec 87 12:24:00 est From: scottr@csc-lons.csv001.tv.ARPA (Scott W. Rogers) If anyone has had similar problems, or has a solution, or even any idea's, please let me know. Look for TCP checksum errors on both ends. If you don't have a counter for such things, you should. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712301938.AA18131@ames-titan.arpa] <1987123019380000> From: medin@AMES-TITAN.ARPA (Milo S. Medin, NASA ARC Code ED) Newsgroups: comp.protocols.tcp-ip Subject: Re: UVax Ultrix Blues Message-ID: <8712301938.AA18131@ames-titan.arpa> Date: 30 Dec 87 19:38:00 GMT References: <8712300401.AA15931@trantor.UMD.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Hmmm. That's pretty amusing. The Wollongong TCP/IP code we run here at Ames (v 3.1) is all 4.3 BSD based kernel code (thanks mostly to Jerry Scott), and they've even found 4.3 bugs and fixed them! This means that a VAX running VMS with the TWG code has better TCP/IP support than the same hardware running Ultrix. Gads, I never thought I'd see the day... Of course, 4.3 BSD (Unix) itself runs really well... Milo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [18098@bu-cs.BU.EDU] <1987123020153100> From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.tcp-ip Subject: Re: Leaping clocks Message-ID: <18098@bu-cs.BU.EDU> Date: 30 Dec 87 20:15:31 GMT References: <8712282332.aa27722@Huey.UDEL.EDU> Reply-To: kwe@bu-it.bu.edu (Kent England) Organization: Boston Univ. Information Tech. Dept. Lines: 14 Keywords: leaping fuzzballs Summary: What about relativistic effects? I should think that if and when there are airborne routers or orbital routers (fuzzballs in space!) that Dave Mills is the man to do the relativistic corrections to the clocks and time-servers. He certainly handled the leap-seconds crisis well, don't you think? :-) -- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6070@j.cc.purdue.edu] <1987123020351400> From: ad2@j.cc.purdue.edu (Bill Bormann) Newsgroups: comp.org.decus,comp.protocols.tcp-ip,comp.sys.dec Subject: Need TCP/IP on RSTS/E Message-ID: <6070@j.cc.purdue.edu> Date: 30 Dec 87 20:35:14 GMT Reply-To: ad2@j.cc.purdue.edu (Bill Bormann) Organization: Purdue University Lines: 12 We are interested in finding some combination of hardware and software that will give a PDP-11/70 running RSTS/E V9.1 TCP/IP capability. Any pointers or assistance would be greatly appreciated; please send any information to: ad2@j.cc.purdue.edu (Internet) -or- bormann@purccvm (BITNET) Thanks for your help. Bill Bormann Purdue University Computing Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1705@orstcs.CS.ORST.EDU] <1987123022175600> From: nomad@mist.cs.orst.edu (Lee Vincent Damon) Newsgroups: comp.protocols.tcp-ip Subject: Subnetting and 0 numbers Message-ID: <1705@orstcs.CS.ORST.EDU> Date: 30 Dec 87 22:17:56 GMT Sender: netnews@orstcs.CS.ORST.EDU Lines: 41 Keywords: subnetting zero-numbers I have just finished reading rfc950 (finally). I notice in this doc that the "zero address" of each subnet is supposed to remain unused, along with the "all-one" address. When I issued numbers on my subnet I knew about the all ones, but not about the zeros. None of our machines have complained so I was wondering if the zero's "this net" requirement has been removed and we just have an old doc? Perhaps I am still misinterpreting something, so here is the data and you can see for yourself: Our net is a class B (128.193), we used 5 bits for subnetting (mask is 255.255.248.0 or 0xffff8000), with the lowest bit of that mask held in reserve (so nets are assigned on the higher four bits, leaving the lowest as 0 in all subnets) in case we need to "fine tune." The subnet for the CS department is 00100xxx or 32 to 39. We have no problem (well, not much anyway) with the broadcast address of 128.193.39.255, but some of our machines are in the 128.193.32 subnet (all of our CPUs to be exact). The e-net is one cable, but I have all classes of machines defined differently (CPUs are 128.193.32.x, Mac's are 33.x, terminal servers are 34.x and misc is 35.x, we aren't using 36.x thru 38.x). As I said none of our machinery is complaining about being in the "0 address" of our subnet (I didn't use 128.193.x.0 or 128.193.x.255 at all). Is there a problem that I just don't know about, or is what I am doing relatively safe? (If there is a problem and I was totally wrong with my assignments, please tell me why it still worked...). I should probably add that we are using a Cisco AGS router to interface our subnet to the rest of the campus net (& the Internet) and it is set up to do proxy-arping. We have a mix of 4.3 and 4.2 machines here, some know about subnetting, some don't. Any insight on this would be appreciated. (The above address might be wrong, please use the ones below...) ADVthanksANCE, nomad ------------------------- LEE DAMON FidoNet: 152/201 (The Castle) - (503) 757-8841 nomad@cs.orst.edu Internet: nomad@cs.orst.edu UUCP : {hp-pcd,tektronix}!orstcs!nomad "Say what you like, the bicycle has a great past ahead of it!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- [305232.871231.PAP4@AI.AI.MIT.EDU] <1987123105442100> From: PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") Newsgroups: comp.protocols.tcp-ip Subject: Re: Cheap TCP/IP access to IBM/Amdahl's Message-ID: <305232.871231.PAP4@AI.AI.MIT.EDU> Date: 31 Dec 87 05:44:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Besides DACUs (now defunct) and 8232s (not all that quick?) what about using an RT? If anyone has any experience/performace figures to share, please speak up... I purposely omitted 9370s because that is a little expensive (plus power requirements plus maintenance plus floor space...). (Post to both lists please) -Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987123106290400> Received: from NNSC.NSF.NET by SRI-NIC.ARPA with TCP; Thu 31 Dec 87 11:50:43-PST To: tcp-ip@sri-nic.ARPA Subject: ICMP type #7? Date: Thu, 31 Dec 87 14:49:04 -0500 From: Craig Partridge Hi folks, A curiousity here. Looking at one of the CSNET machines, I discovered that out of 170,000 IP packets received, 20,000 were ICMP messages with type code #7. Type code #7 isn't listed in RFC-792. Am I remiss in my reading? Should I not be worried about this rogue ICMP message type which consumes over 10% of our packet processing? Thanks, Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987123113410000> Received: from NSS.Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Thu 31 Dec 87 10:45:06-PST Received: from rsre.mod.uk by NSS.Cs.Ucl.AC.UK via PSS with NIFTP id aa06675; 31 Dec 87 18:43 GMT To: Phill Gross <@NSS.Cs.Ucl.AC.UK:gross@gateway.mitre.org> Cc: kwe <@NSS.Cs.Ucl.AC.UK:kwe@"bu-cs.bu.edu)">, tcp-ip <@NSS.Cs.Ucl.AC.UK:tcp-ip@sri-nic.arpa> From: John Laws (on UK.MOD.RSRE) Date: Thu, 31 Dec 87 18:41 In-reply-to: <8712311505.AA13253@gateway.mitre.org> Message-Id: <31 DEC 1987 18:41:57 LAWS@RSRE> Subject: Re: Leaping clocks Phill, Meanwhile what happens over here in Europe? Since you officially leap at 7pm EST and UK is 5 hours advance on you - it sounds as if the UK (as the 'owner' of the long. 0 just east of the centre of London all associated with the high tech work on timekeeping done here over 200 years ago so as to sail the seas with better effect to found and hold the empire.....) is the point of origin for the world leaping. Prehaps Dave knows more detail. Happy new year from the time-centre of the universe - (and of course that is why we invented Dr. Who and the Time Lords...) John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712311505.AA13253@gateway.mitre.org] <1987123115051600> From: gross@GATEWAY.MITRE.ORG (Phill Gross) Newsgroups: comp.protocols.tcp-ip Subject: Re: Leaping clocks Message-ID: <8712311505.AA13253@gateway.mitre.org> Date: 31 Dec 87 15:05:16 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 In case you leap-watchers out there missed it, the leap second will be celebrated as part of the midnight festivities in New York City. Although the leap second is to be officially inserted at 7pm EST, the New York revelers will celebrate it as the 61st second of the last minute of the year. According to a report on NPR this morning, the traditional countdown accompanying the falling ball will be changed for this occasion to `5..4.. 3..2..1..LEAP!..0..'. During the additional second, the falling ball will stop and some additional fireworks or light displays will happen. I guess this means that NYC will be one second off from 7pm EST to midnight. Dave, how will this startling development affect network time in NYSERnet for those 5 hours?! Phill ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712311527.AA13825@gateway.mitre.org] <1987123115275300> From: gross@GATEWAY.MITRE.ORG (Phill Gross) Newsgroups: comp.protocols.tcp-ip Subject: Re: Leaping Clocks Message-ID: <8712311527.AA13825@gateway.mitre.org> Date: 31 Dec 87 15:27:53 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 In case you leap-watchers out there missed it, the leap second will be celebrated as part of the midnight festivities tonight in New York City. Although the leap second is to be officially inserted at 7pm EST, the New York revelers will celebrate it as the 61st second of the last minute of the year. According to a report on NPR this morning, the traditional countdown accompanying the falling ball will be changed for this occasion to `5..4.. 3..2..1..LEAP!..0..'. During the additional second, the falling ball will stop and some additional fireworks or light displays will happen. I guess this means that NYC will be one second off from 7pm EST to midnight. Dave, how will this startling development affect network time in NYSERnet for those 5 hours?! Phill ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7793@hc.DSPO.GOV] <1987123116461800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tomlin@hc.DSPO.GOV (Bob Tomlinson) Newsgroups: comp.protocols.tcp-ip Subject: Re: DELUA interface driver needed Message-ID: <7793@hc.DSPO.GOV> Date: Thu, 31-Dec-87 20:46:18 EDT Article-I.D.: hc.7793 Posted: Thu Dec 31 20:46:18 1987 Date-Received: Sun, 23-Aug-87 03:15:24 EDT References: <8708211505.AA13694@decvax.dec.com> Distribution: world Organization: Los Alamos National Laboratory Lines: 28 in article <8708211505.AA13694@decvax.dec.com>, templin@DECVAX.DEC.COM (Fred Templin) says: > The DELUA should be plug-compatible with the 4.3BSD if_de.c driver. It isn't (*exactly*). >I work > with the ULTRIX network drivers, and the only change we've made for DELUA's > is a check in the "deprobe" routine to make sure the board has passed power- > up self test before forcing an interrupt. I don't believe this is done in the > 4.3BSD driver, but I really don't see this as being a problem. It is a problem. The DELUA takes a LONG time to run its self-check. On Unibus reset it runs its self-check. So there are two ways to get it up: 1) Fix the probe routine to wait until the device is back from self test (or at least DELAY a long time so you're sure it's done with the self check) before trying to get it to interrupt. or 2) Boot the kernel by (on a 780) B ANY and by the time you can type in the name of your kernel and hit return the DELUA's self check will be done. Of course this isn't convient in a long term, but you can at least get the machine up to go in and fix the source. bob -- Bob Tomlinson -- tomlin@hc.dspo.gov -- (505) 667-8495 Los Alamos National Laboratory -- MEE-10/Data Systems ----MESSAGE-END---- ----MESSAGE-BEGIN---- [871231171431.988445@RADC-MULTICS.ARPA] <1987123117140000> From: Ata@RADC-MULTICS.ARPA ("John G. Ata") Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/SMTP ULTRIX <-> MULTICS PROBLEM Message-ID: <871231171431.988445@RADC-MULTICS.ARPA> Date: 31 Dec 87 17:14:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 42 Delivery-Date: 30 December 1987 12:36 est Delivery-By: Network_Server.Daemon (tcp-ip-RELAY@SRI-NIC.ARPA) Date: Wednesday, 30 December 1987 12:24 est From: scottr at CSC-LONS.CSV001.TV (Scott W. Rogers) Subject: TCP/SMTP ULTRIX <-> MULTICS PROBLEM To: tcp-ip at SRI-NIC cc: cscmaint at RADC-LONS I'm having a problem receiving some (SMTP) mail from a MULTICS host on my ULTRIX 1.2 and 2.0 (binary, sigh) VAX 8600 and 8650 systems. I can send mail to MULTICS without any problem, and most mail is received. The problem is as follows: After the SMTP initialization, MULTICS sends a 51 character 'MAIL From: ' string which is never acknowledged by ULTRIX. The MULTICS engineer says that his system is not receiving the TCP ACK even after several retrys and changing his timeout from 1 to 2 minutes. The connection seems to go comotose. We send the 51 character packet out, and retransmit a number of times, but the ACK never arrives. Our logs show no checksum errors or any other kind of error. We have tried it with different size packets, but strangly enough 51 seems to be the magic number causing this problem. . . . The problem is completely reproducable through MAIL. Using TELNET, the Multics engineer was able to produce it only sometimes. This problem is also completely reproducable by opening a TELNET connection to CSC-LONS mail server and simulating a message. This problem appears to affect certain ULTRIX sites, but not all of them. We chose some ULTRIX sites at random and they seemed to work ok. Suspect that they are running a different version of TCP/SMTP. John G. Ata Site Technical Specialist at RADC-MULTICS ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712311735.AA13976@nisc.nyser.net] <1987123117352900> From: schoff@NISC.NYSER.NET ("Marty Schoffstall") Newsgroups: comp.protocols.tcp-ip Subject: Re: Leaping Clocks Message-ID: <8712311735.AA13976@nisc.nyser.net> Date: 31 Dec 87 17:35:29 GMT References: <8712311527.AA13825@gateway.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Dave, how will this startling development affect network time in NYSERnet for those 5 hours?! Actually only the three mobile packet radio gateways will be affected: schoffstall's-red-chevy-S10-4x4.nyser.net fedor's-tiny-blue-nissan.nyser.net brim's-orange-junker-volvo.nyser.net All other gateways are awaiting a new software load to be developed by the vendor. Marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712312046.AA01429@ucbvax.Berkeley.EDU] <1987123119490400> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: ICMP type #7? Message-ID: <8712312046.AA01429@ucbvax.Berkeley.EDU> Date: 31 Dec 87 19:49:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Hi folks, A curiousity here. Looking at one of the CSNET machines, I discovered that out of 170,000 IP packets received, 20,000 were ICMP messages with type code #7. Type code #7 isn't listed in RFC-792. Am I remiss in my reading? Should I not be worried about this rogue ICMP message type which consumes over 10% of our packet processing? Thanks, Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712312007.AA15323@zaphod.ncsa.uiuc.edu] <1987123120072600> From: timk@NCSA.UIUC.EDU (Tim Krauskopf) Newsgroups: comp.protocols.tcp-ip Subject: EtherTalk broadcast invasion Message-ID: <8712312007.AA15323@zaphod.ncsa.uiuc.edu> Date: 31 Dec 87 20:07:26 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 43 Here are some facts which should interest anyone running Ethernet networks, especially those who have a lot of MAC level bridges. How will EtherTalk broadcast packets affect you? 1. AppleTalk over Ethernet, known as EtherTalk, has a registered Ethernet packet type of Hex 809B. Your network analyzer probably doesn't recognize this one yet, but you will want it soon. 2. RTMP is the AppleTalk routing information scheme. It calls for a broadcast packet every 10 seconds. We can live with this one, we know other routers do this, but what interval would you like to encourage Apple to use? I would like to see these packets closer to one minute apart. 3. Look out for AARP broadcasts! Apple has a registered AppleTalk Address Resolution Protocol (AARP) packet type for Ethernet (Hex 80F3) and the packet format looks a lot like ARP. There is a special broadcast packet under AARP called a "probe" which prompted this warning message. When EtherTalk is initialized (machine is booted), an EtherTalk node must defend its unique 8-bit node number. Probe packets are sent out to try to identify any machine with a matching node number. If no machine responds, then the number is assumed to be unique. Here's the kicker: The official EtherTalk specification calls for 20 retries of this broadcast packet spaced at intervals of 1/30th of a second. Measurements confirm this is true for all of the EtherTalk implementations that we have. So, you get a 20 packet broadcast storm every time a Mac is booted. What effect will this have on our networks? What about when there are 100 Macs on the same physical wire as your Suns? This obviously is of some concern because we get bug reports from people who have noticed. Our problem is that EtherTalk sometimes chooses to defend its node number when our NCSA Telnet application is launched. Then we get blamed for an EtherTalk problem. Note for Ethernet snoopers: If the packet type is 80F3 or 809B, then we didn't generate it. We only generate IP (0800) and ARP (0806) packet types. Tim Krauskopf timk@ncsa.uiuc.edu (ARPA) National Center for Supercomputing Applications 14013@ncsavmsa (BITNET) (217)244-0638 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712311645.aa28586@Huey.UDEL.EDU] <1987123121450100> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Leaping Clocks Message-ID: <8712311645.aa28586@Huey.UDEL.EDU> Date: 31 Dec 87 21:45:01 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Phill, Well, I have good news and bad. The good news is that the umd1.umd.edu timeteller host will offer rigorous standard time pre-attack, trans-attack and post-attack the Leap. It is now squawking "danger: leap imminent" to its Network Time Protocol peers even now as per RFC-958. All fuzzballs on the U Delaware, U Maryland and Linkabit LANs will automatically follow the leap as required and relay the leap indicator to their pals. The bad news is that the wwvb.isi.edu timeteller got its clock punched, or something like that, since I can't reach out and touch its leap switch. It will miss the leap, at least until its radio clock notices, and thus keep NYT for probably about ten minutes while the radio clock resynchronizes. The remaining timetellers at Ford and NCAR have not had the software update required to leap correctly. Having said that, understand the radio clocks themselves have no provision to trach the leap, so will experience a period of befuddlement immediately following the Leap of from a few minutes to hours. Thus, my exquisitely crafted timewarp will come down at the leap, only to be yanked back maybe a minute later when the disagreement with the radio clock is noticed, then when the radio clock regains its marbles the unleaped leap will be releaped. Got that? Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8712311721.aa28871@Huey.UDEL.EDU] <1987123122213700> From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP type #7? Message-ID: <8712311721.aa28871@Huey.UDEL.EDU> Date: 31 Dec 87 22:21:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Craig, I can't even find code #7 in GGP, from which ICMP was divorced some years ago. Are you sure the Type and Code fields are not swabbed? Also, who is sending those drat things? Gather up all the packets you see during the coming leap second and send them back there encapsulated in source-quench messages. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [591@ihnet.ATT.COM] <1987123122225000> From: moshe@ihnet.ATT.COM (Moshe Yudkowsky) Newsgroups: comp.protocols.tcp-ip Subject: 300 Megabit/second national network? Message-ID: <591@ihnet.ATT.COM> Date: 31 Dec 87 22:22:50 GMT Reply-To: moshe@ihnet.UUCP (Moshe Yudkowsky) Distribution: comp.protocols.tcp-ip Organization: AT&T Bell Laboratories Lines: 18 Keywords: Big and Fast Summary: Scientific American had this -- is it true? Expires:2/28/88 I have a question about a report in the December 1987 edition of Scientific American, page 22. The White Houses's office of Sciece and Technology is portrayed as planning a 300 megabit/second integrated national network. This high-speed net would allow access in reasonable time to the gigaflop machines now on the drawing boards. Query: Who knows more about this? Who do I call? I find this subject interesting. Please send replies to me via e-mail, to "moshe@ihnet.att.com" or "ihnp4!ihnet!moshe" . Thank you all. Moshe Yudkowsky The views expressed herein are certainly not my bosses'! ----MESSAGE-END----