The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1987)
DOCUMENT: TCP-IP Distribution List for December 1987 (271 messages, 139513 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1987/12.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Tue, 01 Dec 87 08:22:25 -0500
From:      haverty@CCV.BBN.COM
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: MRC: NFS over ARPANET
Mark -- you might want to describe the BOJ/JOB machinery that was the
underpinning for MLDEV et al; we didn't just have NFS over the Arpanet,
we had a general network I/O and RPC facility, which was the infrastructure
for creation of things like the MLDEV NFS and a variety of other strange
things.
Jack
(I'd describe it but I don't trust my memory for the details)
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1-Dec-87 08:07:13 EST
From:      jsloan@wright.UUCP
To:        comp.protocols.tcp-ip
Subject:   Ethers, Copper, Fiber, Microwaves, Etc.

Some time ago I helped write an RFP for a 10 Mb/sec ethernet-to-ethernet
link via microwave (thanks, Kent England at BU for the info!). We have
since contracted with the vendor and installation should be completed
around Christmas. In the process there has been some mutual education
between the microwave group and the networking group on campus.

There are now incredibly cheap (a few thousand $s) microwave systems,
with dishes that you could put in a briefcase, that could conceivably
be pushed to 10 Mb/sec over very short distances. How long will it be
before it will be cheaper to run networks between adjacent buildings on
a campus or research park etc. using these tiny microwave systems
instead of running copper or fiber? I suspect the major cost would
be the ether bridges on either end that may be necessary (and maybe
not), but it could also be that you would want packet filtering with
bridges even if you used copper or fiber.

I remember reading about lasers doing similar things. Also an
interesting thought.

Our RBOC bid a optical fiber link. Although their ethernet-to-ethernet
product (if its not vaporware) was not available by our deadline, this
too is an interesting idea, not for short distances (a solution which
has been around for a while) but for long distances, like over five
miles or more. Managing a geographically dispersed ethernet would be
challenging, but the functionality is appealing.

Anyone have any concrete ideas on any of this? Those little microwave
dishes are looking better and better.


-- 
John Sloan                     Wright State University Research Center
jsloan@SPOTS.Wright.Edu       3171 Research Blvd., Kettering, OH 45420
...!cbosgd!wright!jsloan               (513) 259-1384   (513) 873-2491
Logic Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1-Dec-87 09:00:13 EST
From:      haverty@CCV.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: MRC: NFS over ARPANET

Mark -- you might want to describe the BOJ/JOB machinery that was the
underpinning for MLDEV et al; we didn't just have NFS over the Arpanet,
we had a general network I/O and RPC facility, which was the infrastructure
for creation of things like the MLDEV NFS and a variety of other strange
things.
Jack
(I'd describe it but I don't trust my memory for the details)

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1-Dec-87 13:29:21 EST
From:      slevy@UMN-REI-UC.ARPA (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re:  Fwd: NFS over arpanet?

One problem we've had in NFSing between disparate machines is with
naming them.  The mount request passes the originating machine -name-
rather than having the server use gethostbyaddr().  It's important
to check that "hostname" on the client yields a name known to the
server and vice versa.  That's probably not the whole problem but
can cause things to break.

A guy from Proteon, Mick Scully (mcs@proteon.com) recently visited here
and mentioned that he had mounted NFS filesystems at Berkeley across ARPAnet.

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 87 09:05:59 GMT
From:      howellg@idec.stc.co.uk (Gareth Howell)
To:        rec.ham-radio.packet,comp.protocols.tcp-ip
Subject:   NEEDED: KISS for TNC220

I have a Pacomm TNC220 on which I want to run KISS and thence the KA9Q
tcp/ip package.  Unfortunately I don't have a KISS for the TNC.
Can anybody help.  I would prefer the co-resident bootstrap with a
downloaded KISS module if possible.
ta Gareth
====

-- 
Gareth Howell  <howellg@idec.stc.co.uk>  G6KVK @ IO91VX
ICL NS PNBC, England, SG1 1YB    Tel:+44 (0)438 738294
howellg%idec%ukc@mcvax.uucp, mcvax!ukc!idec!howellg@uunet.uu.net
G6KVK @ G4SPV (uk packet 144.650MHz)

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2-Dec-87 11:14:22 EST
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   ARPANET UPGRADE SCHEDULE

A meeting will be held on Thursday, December 3, to furthur discuss the
new ARPANET End-to-End protocol (PSN 7.0).

Due to necessary software patches, 2 test period options are being considered:

1) Testing of the new End-to-End on two week-ends, December 5th and 6th,
and December 12th and 13th for a total of 4 days.

2) Testing of the new End-to-End beginning December 5th running through
December 13th, for a total of 9 days.

Hosts experiencing problems during this test period are asked to call 
the ARPANET Monitoring Center at (617) 873-3571/3070 or (800) 492-4992.


-------

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2-Dec-87 11:34:00 EST
From:      YBMCU@CUNYVM.CUNY.EDU (Ben Yalow)
To:        comp.protocols.tcp-ip
Subject:   BITNET-Internet gateway changes

As has been announced in a number of places, the Internet <-> BITNET
gateway at WISCVM (WISCVM.WISC.EDU) is going away.  The final date
for using that gateway is Dec 15, 1987.

BITNET has been working with the Internet administration to provide a
set of multiple regional gateways between the two networks.  Until that
time when a suitable technical solution is developed, an interim
solution has been put in place, effective immediately.

From the BITNET side, mail should be sent to SMTP@INTERBIT.  The node
is currently in the tables distributed by BITNIC, and now points
towards CUNYVM.  At a later date, this will point to the appropriate
regional gateway.  The distributed DOMAIN NAMES file is being updated
to point at SMTP@INTERBIT instead of SMTP@WISCVM.  The updated file
will be distributed as the normal distribution on Monday, Dec 7.
All sites, especially those other than end nodes, should ensure
that the latest tables are installed.

For those on the Internet side, the first of the gateways is at
CUNYVM.CUNY.EDU (CUNYVM on the BITNET side).  Any mail formerly
sent to user%node.BITNET@WISCVM.WISC.EDU should now be sent to
user%node.BITNET@CUNYVM.CUNY.EDU.  This is an interim solution
until the full set of gateways is in place.  At that time, notice
will be sent out giving details of the new gateways.

Those users on other networks who use WISCVM as a gateway to BITNET
need to modify their mailer tables appropriately.

The code running in the gateway is fully compatible with the code
currently running at the WISCVM gateway.  Any mail which worked at
the WISCVM gateway will work with the CUNYVM gateway.

If any problems are experienced, you may direct any discussion to
POSTMASTER@CUNYVM.CUNY.EDU.


Note:  The node CUNYVM.CUNY.EDU on the Internet is the same as
CUNYVM.BITNET.  This node now has a direct connection to the
Internet.


Ben Yalow
Director of Systems & Programming
City University of New York/University Computer Center
BITNET: YBMCU@CUNYVM           Internet: YBMCU@CUNYVM.CUNY.EDU

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Wed, 02 Dec 87 11:34:00 EST
From:      Ben Yalow <YBMCU@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   BITNET-Internet gateway changes
As has been announced in a number of places, the Internet <-> BITNET
gateway at WISCVM (WISCVM.WISC.EDU) is going away.  The final date
for using that gateway is Dec 15, 1987.

BITNET has been working with the Internet administration to provide a
set of multiple regional gateways between the two networks.  Until that
time when a suitable technical solution is developed, an interim
solution has been put in place, effective immediately.

From the BITNET side, mail should be sent to SMTP@INTERBIT.  The node
is currently in the tables distributed by BITNIC, and now points
towards CUNYVM.  At a later date, this will point to the appropriate
regional gateway.  The distributed DOMAIN NAMES file is being updated
to point at SMTP@INTERBIT instead of SMTP@WISCVM.  The updated file
will be distributed as the normal distribution on Monday, Dec 7.
All sites, especially those other than end nodes, should ensure
that the latest tables are installed.

For those on the Internet side, the first of the gateways is at
CUNYVM.CUNY.EDU (CUNYVM on the BITNET side).  Any mail formerly
sent to user%node.BITNET@WISCVM.WISC.EDU should now be sent to
user%node.BITNET@CUNYVM.CUNY.EDU.  This is an interim solution
until the full set of gateways is in place.  At that time, notice
will be sent out giving details of the new gateways.

Those users on other networks who use WISCVM as a gateway to BITNET
need to modify their mailer tables appropriately.

The code running in the gateway is fully compatible with the code
currently running at the WISCVM gateway.  Any mail which worked at
the WISCVM gateway will work with the CUNYVM gateway.

If any problems are experienced, you may direct any discussion to
POSTMASTER@CUNYVM.CUNY.EDU.


Note:  The node CUNYVM.CUNY.EDU on the Internet is the same as
CUNYVM.BITNET.  This node now has a direct connection to the
Internet.


Ben Yalow
Director of Systems & Programming
City University of New York/University Computer Center
BITNET: YBMCU@CUNYVM           Internet: YBMCU@CUNYVM.CUNY.EDU
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2-Dec-87 11:35:00 EST
From:      rrv@uxc.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Connexions - Magazine (defunct ??)


ConneXions
Advanced Computing Environments
21370 Vai Avenue
Cupertino, CA 95014, USA

phone 408/996-2042

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2-Dec-87 14:52:40 EST
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Ethers, Copper, Fiber, Microwaves, Etc.

In article <203@wright.EDU> jsloan@wright.EDU (John Sloan) writes:
>
>There are now incredibly cheap (a few thousand $s) microwave systems,
>with dishes that you could put in a briefcase, that could conceivably
>be pushed to 10 Mb/sec over very short distances.

	Now this is something new to me.  If you can put them in a
briefcase they must be around 100GHz.  That would probably limit the
range to a mile or so.  The problem with infrared laser technology is
the atmospheric attenuation of smog, fog, and rain.  Sounds like this
new ultra-high freq microwave fills the gap between low freq uwave and
infrared. 
>
>Our RBOC bid a optical fiber link. Although their ethernet-to-ethernet
>product (if its not vaporware) was not available by our deadline, this
>too is an interesting idea, not for short distances (a solution which
>has been around for a while) but for long distances, like over five
>miles or more. Managing a geographically dispersed ethernet would be
>challenging, but the functionality is appealing.

	I like fiber.  I can't wait to see what happens to FDDI as it
develops.  Fiber optic FDDI will be robust, high speed, and simpler
than broadband.  I think the ring circumference is around 23 km which
will cover a lot of campuses.  Speed is 100/200 Mbps.  Of course,
Pronet-80 is here now and works much the same way FDDI will.

	I won't repeat the arguments regarding routers versus bridges
or introduce a new argument about slow routers versus smart/fast
bridges, but I definitely favor routers if we can get some new
hardware architectures that will run thousands of packets per second
in a multi-protocol environment.  Multibus and Interlan Enet cards
won't cut it with FDDI and embryonic ISO protocols.  Fiber optic token
ring is my preference over a fiber optic monolithic Ethernet.  You
should be excited about managing a geographically dispersed internet,
but appalled at the thought of managing a geographically dispersed
(large) Ethernet.-- 
     -------------------------------------------------------------------
     Kent W. England                      |       Boston University
     Network & Systems Engineering Group  |       Information Technology
     kwe@bu-it.bu.edu        internet     |       111 Cummington Street
     itkwe@bostonu           BITnet       |       Boston, MA      02215
     harvard!bu-cs!kwe       UUCP         |       (617) 353-2780
     -------------------------------------------------------------------
     

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2-Dec-87 17:49:21 EST
From:      rob@PRESTO.IG.COM (Rob Liebschutz)
To:        comp.protocols.tcp-ip
Subject:   Re: NFS over arpanet?

While casually playing around during a recent visit to Rutgers, I was
able to sucessfully mount and access an NFS file system over the
Arpanet (cross-country).  Things were a bit slow and I experienced
timeouts, but it did work (and that was back when the performance of
our Arpanet connection was quite bad).  I didn't even bother to
specify anything other than the default NFS mount parameters.

I was waiting to see if the operator at Rutgers would come running
into the systems office complaining about messages on the console "NFS
server presto.ig.com not responding" what should I do :-).

Rob

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3-Dec-87 00:21:31 EST
From:      henry@utzoo.UUCP.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Networks & vendor upgrades/fixes

> For example, one could simply demand, as with all warrantees, that
> software will not be maintained if monkeyed with...

I dimly recall a software vendor who would sell you source *or* support
but not both.  They had the right idea.

				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3-Dec-87 11:04:33 EST
From:      AD@BROWNVM.BITNET.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Connexions - Magazine (defunct ??)

Subscription information for Connexions:
                     conneXions
                     21370 Vai Avenue
                     Cupertino, CA  95014

US/Canada  $360/12 issues/year
University $240/ " / "

They accept POs, MC, and VISA.

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Thu, 03 Dec 87 11:04:33 EST
From:      Arif Diwan <AD%BROWNVM.BITNET@WISCVM.WISC.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Connexions - Magazine (defunct ??)
Subscription information for Connexions:
                     conneXions
                     21370 Vai Avenue
                     Cupertino, CA  95014

US/Canada  $360/12 issues/year
University $240/ " / "

They accept POs, MC, and VISA.
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3-Dec-87 18:08:51 EST
From:      jerry@oliveb.UUCP
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Can I print on a terminal server port

A while back I posted a request for information on printing using
a telnet terminal server from a 4.3bsd host.  Here is the prommised
summary of responses.

Several people pointed out that one can run telnet<filename to send a
file to a printer connected to a terminal server port.  (All of this
assumes that the terminal server will allow you to configure a port as a
host and assign an IP address to it.)  It was also pointed out that it
is possible to modify telnet and turn it into a filter program for the
lpd spooler.

Many responses stated that the Encore Annex terminal servers provide
support for the Berkeley lpd protocol as well as providing a centronics
parallel port.  It does require modification to the lpd software
though.

Cisco also supplies a "filter" to allow printing on one of its terminal
servers.

Finally, some people are working on making the changes in lpd to support
this.  (Roy Marantz at Rutgers.)  This seems the correct sollution as it
does not lock one into a particular brand of server.  Apparently there
are problems with implementing this.  One mentioned was the terminal
server flushing the buffered portion of the data when the connection is
closed.

The edited responses follow:
--
From: eshop%saturn.UCSC.EDU@ucscc.UCSC.EDU (Jim Warner)

Bridge Communications application note #12 contains a printer
server program that looks like it would do what you want.  The
program is intended to be run on a 4.2BSD machine.

If you send me a US mail address, I will send you a paper copy.
This is coming up soon for us, too.  I will probably hand it
to a secretary to see how well they can type in c-code.

jim warner
--
From: unisoft!suntea!carl@ucbvax.Berkeley.EDU (Carl Smith)

	We do this with our cisco ASM terminal servers.  It's trivial to
take telnet and hack it a bit to act as a filter to a port on a terminal
server.
			Carl
--
From: sun!tundra!dave%rosevax.Rosemount.COM (Dave Marquardt)

I've been able to print to terminals attached to Bridge TCP/IP terminal
servers.  I've also managed to integrate this into the 4.3 BSD lpr spooling
system, in a primitive sort of way.

	Dave
--
From: Scott Brim <swb@tcgould.tn.cornell.edu>

Encore terminal servers come with instructions on how to set this up.
--
From: jsalmi@eta.eta.com (John Salmi)

a couple of us hacked out a tcp print server to enable us to print from
our sun network on a big imagen connected to a very large apollo ring.

lemme know if you want the code.  it's really quite simple :-)
--
From: ames!uw-beaver!ssc-vax!jeff (Jeffrey Jongeward)

We do this to 2 LW+'s from VMS & 4.3BSD, talking
telnet to a bridge box in listen mode.  This gives
us connectivity w/o having to rely on any one host
which seemed like a good thing at the time tho' if I
were doing it again, I'd just make VMS talk to lpd
and hardwire the LW+'s  to one of the 4.3 systems.
Works quite well, s/w is home grown.

		- jeff jongeward @ boeing aerospace
--
From: Milo S. Medin (NASA ARC Code ED) <medin@orion.arpa>

Encore Corp's Annex terminal server lets you do just this.  In fact, they include
a Centronics parallel port too, in case you like parallel printers better.
They have tons of other features, and I just can't praise them enough.
And people who know me will tell you I rarely give that complement.
They understand the UCB lpd protocol as well.  All very good stuff.
We've tried many terminal servers here, and the Annex is by far the 
best.
--
From: William Westfield <BILLW@MATHOM.CISCO.COM>

cisco Systems terminal servers fully support the use of terminal
ports in the reverse direction (eg host establishes a connection
to a specific terminal port of the server).  Various types of
connections are supported (eg telnet, telnet binary, and 8 bit
stream), along with rotary groups (get the first free port in
a group) and miscellaneous other options.  In fact, we use such
an arangement internally at cisco to allow spooling from our
tops20 and unix systems to an apple laserwriter.  We will supply
source code for a unix filter that sends data over a TCP connection,
that can be used to build full-fledged spoolers, or in a simpler
configuration for smaller networks.

At least one of our competitiors also supports using a terminal
server in ths manner, though of course not as well :-)

Give us a call at (415)-326-1941 if you would like more information.

Bill Westfield
cisco Systems.
--
From: jas@monk.proteon.com (John A. Shriver)

The Encore TIU (which we also sell as the Proteon TIU) has support for
this.  It requires some changes to the lpd software on the UNIX
system.  The box even has a Centronics printer port, or you can use
an async port.
--
From: ron@topaz.rutgers.edu (Ron Natalie)

Roy Marantz here at Rutgers is working on this for lpd.  The printcap
has a terminal server name/ TCP port number entry for these printers.
There is currently still some bug that prevents this from working.
--
From: hplabs!hpda!uunet!unido!iaoobel!woerz (Dieter Woerz)

We had several terminal servers for test here. (CS/100 from Bridge
Communicatios, Spider Ports from Spider systems, Micom/Interlan
Terminalservers and an ANNEX box from Encore).
Encore gives you all you want in this direction. Their software is
host based and they have included a patch for the line printer
spooler (at least for 4.2BSD) to use either the parallel port or one
of the seriell ports as a printer port driven from the printer
spooler. You have to add two fields in the printcap file, apply the
patch, recompile and then it works.
Spider systems has a small program in their documentation to print
onto a specified port. This doesn't use the Berkeley spooler, but
perhaps you could use it as an output-filter out for the line printer
daemon.
The other servers don't provide such a feature (or I didn't notice
it).

Hope this helps
--
From: ames!harvard!talcott!encore!xenna!loverso (John Robert LoVerso)

I'm one of the software engineers who works on development of the Encore
Annex Terminal Server.  Not only do we currently support both parallel and
serial printers, but we've got some new things cooking for the next release
that will make it possible to run either a bi-directional serial printer
or even a host's getty on an Annex serial port!

The Annexes currently available contain 1 parallel printer port
and 16 serial ports.  Current printer support (for all BSD-compatible
hosts) is by means of either small modifications to the Berkeley
Printer Spooler, or by a program we distribute called "aprint",
both of which are included in source form on our distribution tape.
The Annex operational image (the software you boot onto the Annex
- its loaded from any BSD host on the network) contains a modified
LPD server.  The mods to the Berkeley spooler support a small
extension to the printcap file that allows an annex & port to be
specified as the hardware device.  This is used just like an
"lp=/dev/xxx" entry had been specified.  If you don't have source
for lpd, then you can just use our "aprint" program, which talks
to the Annex LPD daemon and prints (not spools) a file.  An example
of how aprint could be used as a printcap "of=" filter is included
in the administrators manual.

John Robert LoVerso
Encore Computer Corp
encore!loverso, loverso@multimax.arpa
617-450-0600 x2638
--
From: Andy Linton <asjl@cheviot.ncl.ac.uk>

We are currently doing what you want using Encore Annexes attached to an
Encore Multimax. Special case you might say but the same thing can be done
from a Vax or whatever. Robert Claeson <seismo!enea!pvab!robert> has written
some code to do it. He says that Encore will possibly make it available with
the next release of the Annex UX software. I include it for your info.

The Annex is a nice box and cheap!
andy
[Contact Andy for the code.  JA]
--
From: ll-xn!budd@bu-it.bu.edu

What kind of terminal server?  Encore UMAX lpd can drive printers
attatched to Annex printer and terminal ports.  They also distribute
diffs for you to modify your lpd.

	Phil Budne
	Boston University
--

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4-Dec-87 00:35:57 EST
From:      mikep@ism780c.UUCP (Michael A. Petonic)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Software Raves Wanted

Hey, I'm new in the terrain, so go easy on me.  I need help determining
what would be the best product for TCP/IP and mail software to
run on a VAX and a MicroVAX (VMS 4.4).  I'm trying to help
a friend make an informed decision, so I don't know all the
specifics.  He doesn't have access to the net, so....

I'd appreciate and references, suggestions, flames or any other
general comments on TCP/IP products that you have run into.

He's looking into something called MultiNet Plus (and is there
a MultiNet?).  In any case, any comments on this product would
be appreciated, also.

Please reply to the net or to me via mail.  I'm sure there
are other's out there who would like this sort of info, also.

I'll summarize any info that I get.

TNX 1.0e06
-MikeP
--------------------
Michael A. Petonic   			(213) 453-8649 x3247
INTERATIVE Systems Corporation		"My opinions in no way influences
2401 Colorado Blvd.			the price of tea in China."
Santa Monica, CA. 90404
{sdcrdcf|attunix|microsoft|sfmin}!ism780c!mikep

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4-Dec-87 10:08:38 EST
From:      scott@scirtp.UUCP
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.std.internat
Subject:   Inter-Domain Addressing Standards

I'd appreciate pointers to material concerning address protocols
for inter-network communication.

Thanks very much !

-- 
	   Scott Crenshaw		{akgua,decvax}!mcnc!rti-sel!scirtp!scott
	   SCI Systems , Inc. 		Research Triangle Park, NC 

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4-Dec-87 13:24:52 EST
From:      scott@scirtp.UUCP
To:        comp.std.internat,comp.protocols.tcp-ip
Subject:   ISDN Specs Wanted

From where can I obtain CCITT publications related to
ISDN ?  Addresses and phone numbers are appreciated.

Thanks very much. 

-- 
	   Scott Crenshaw		{akgua,decvax}!mcnc!rti-sel!scirtp!scott
	   SCI Systems , Inc. 		Research Triangle Park, NC 

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4-Dec-87 14:54:03 EST
From:      wjc@LL-VLSI.ARPA (Bill Chiarchiaro)
To:        comp.protocols.tcp-ip
Subject:   IP options under 4.? BSD


Does anyone know how to set and get IP options (LSRR, SSRR, RR) on
outgoing and incoming datagrams under any version of 4 BSD?  I would
be especially interested in ways of doing this under Sun's releases
of 4.2 BSD.

Thanks,
Bill

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5-Dec-87 23:17:14 EST
From:      cyrus@hi.UUCP (Tait Cyrus)
To:        comp.protocols.tcp-ip
Subject:   best version of UN*X


The University of New Mexico will shortly be attached to the Internet
via NSFnet.  What versions of UN*X are best when it comes to networking?

I have heard that Ultrix 2.2 is VERY bad when it comes to handling the
Internet protocols (routing protocols for example) correctly and that
it won't handle them correctly until around release 2.4.  I have heard
that BSD 4.3 DOES handle the Internet protocols correctly.  Since one
of the reasons that we are even considering Ultrix is because of NFS,
Mt. Zinu (sp?) BSD 4.3 would be another viable choice.  Our CS department
is going with Mt. Zinu and REALLY like the support that they are getting
are REALLY like the op sys.

What I am looking for are some 'responses' from you good folks
out there (is it getting too thick? :-) that I can use in convincing
the administrative types here which release to go to.  Which op sys's
are best, which have problems, which don't, etc.....

Oh, the machines in questions are microvax II's (currently running 
BSD 4.3).  We also have a lot of SUN's running SUNos 3.4, Bridge
Inc. Terminal servers, and DEC LAN 100 bridges isolating us (the
ECE department) from the rest of the UNM backbone.

I hope my question is clear enough, though any answers don't necessarly
have to be clear (I can translate, I hope, for the admin types).

Thanks in advance.

-- 
    @__________@    W. Tait Cyrus   (505) 277-0806
   /|         /|    University of New Mexico
  / |        / |    Dept of EECE - Hypercube Project
 @__|_______@  |    Albuquerque, New Mexico 87131
 |  |       |  |
 |  |  hc   |  |    e-mail:
 |  @.......|..@       cyrus@hc.dspo.gov
 | /        | /        
 @/_________@/

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6-Dec-87 21:27:00 EST
From:      W8SDZ@SIMTEL20.ARPA (Keith Petersen)
To:        comp.protocols.tcp-ip
Subject:   Latest KA9Q TCP/IP for MSDOS now available from SIMTEL20

The latest version of KA9Q's TCP/IP for MSDOS is now available via
standard anonymous FTP from SIMTEL20...

Filename			Type	 Bytes	 CRC

Directory PD1:<MSDOS.KA9Q-TCPIP>
NELSON.ARC.1			BINARY	  7385  1825H
NET_BM.ARC.2			BINARY	 23171  48BBH
NET_DES.ARC.2			BINARY	 18721  E18CH
NET_DOC.ARC.2			BINARY	104826  B348H
NET_EXE.ARC.2			BINARY	104944  244DH
NET_READ.ME.2			ASCII	  3381  9A51H
NET_SRC.ARC.2			BINARY	233582  16A4H
PXX107.ARC.1			BINARY	 46952  3F49H
TNC_ASH.ARC.2			BINARY	 53998  9927H
TNC_LDR.ARC.2			BINARY	 15790  0D43H
TNC_TNC1.ARC.2			BINARY	 33058  1B49H
TNC_TNC2.ARC.2			BINARY	 47427  D326H

[Here is the NET_READ.ME file]

Welcome to the KA9Q Internet Package!
(Updated 25 November 1987 by KA9Q)

This file reflects the changes made up to version 870829.16.  The major
new feature since 870829.0 is the addition of full-blown support for
AX.25 Level 2.  It may be used to acknowledge IP datagrams on a
hop-by-hop basis and also to communicate with conventional (i.e.,
non-TCP) AX.25 stations from the keyboard. 

A number of the commands relating to specific protocols (e.g., AX.25,
TCP, IP, UDP) have been restructured in a hierarchical fashion.  For
example, the "digipeat" and "mycall" commands have been made subcommands
under the "ax25" main command.  See useguide.doc for details.  NOTE: you
will have to change your autoexec.net with this release!

In addition to commands added to support the new AX.25 functions,
several utility commands have been added for your convenience.  "dir"
lists directories on the console without leaving net, "cd" (alias "pwd")
prints and changes the current working directory, and "shell" (alias
"!") allows you to suspent net.exe temporarily to run other commands
(note that this freezes any network activity in progress).  The "record"
command allows you to record your Telnet and AX.25 sessions in a file,
and "upload" allows you to send files as though they were typed at the
keyboard. 

Lots of little bug fixes and enhancements have been made. TCP round trip
timing when sending into large windows has been fixed.

The .ARC files that make up the distribution are compressed archives that
were created with version 3.5 of the PKXARC archive program.  They may
not be compatible with the ARC program produced by System Enhancement 
Associates, because the PKARC program knows more compression methods than
ARC.  For your benefit, a self-extracting archive PKX35A35.EXE has been
provided.  Run it to extract a program that can be used to extract the
archives.

The distribution is structured based on the directory structure used to
create the software:

NET_BM.ARC	.\BM	- sources to Bdale's Mailer, and Gerard's Gateway
NET_DES.ARC	.\DES	- an implementation of DES (Data Encryption Standard)
			  for possible use in validating logins, etc.
NET_DOC.ARC	.\DOC	- all of the doc files
NET_EXE.ARC	.\EXE	- executable programs and config files
NET_SRC.ARC	.\SRC	- sources to NET.EXE
NELSON.ARC	.\SRC	- alternative assembler source files for net.exe
			  not dependent on Aztec macros. Contributed by Russ
			  Nelson (nelson@clutx.clarkson.edu).

TNC_ASH.ARC	.\TNC\ASH	- KISS for the VADCG and ASHBY boards (AJ9X)
TNC_LDR.ARC	.\TNC\LDR	- N4HY's KISS downloader in Turbo Pascal
TNC_TNC1.ARC	.\TNC\TNC1	- KISS for the TAPR TNC-1 and clones (WB6ECE)
TNC_TNC2.ARC	.\TNC\TNC2	- KISS for the TAPR TNC-2 and clones (K3MC)


Whatever you do, *PLEASE* don't unpack all of the .ARC files in one directory,
as there are duplicate names all over the place... Makefiles, README files,
etc.

After unpacking, look for a README file in each archive.  Read this first,
before you do *anything* else.  Some are just informative, some are very
important.

Finally, we're constantly striving to improve this software, and the 
distribution as a whole.  Comments may be forwarded to Bdale Garbee, N3EUA.
Several of the Doc files include info on how to reach me...

Above all, HAVE FUN!

73
Bdale, N3EUA
Phil, KA9Q

-----
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6-Dec-87 22:50:13 EST
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Using Kinetics boxes an an etherbridge


	A couple of weeks ago, I asked what people thought about my idea of
rolling my own bargain-basement etherbridge by putting two Kinetics KFPS-2's
back-to-back on opposite ends of a LADC (4-wire leased) circuit, with Farallon
PhoneNet drivers.  Thanks to the following people for responding:

husc6!sob (Scott Bradner)
ucscc.UCSC.EDU!haynes (Jim Haynes)
bu-it.bu.edu!ccjap (John Papadopoulos)
bu-cs!bu-it.bu.edu!kwe (???)
reed!goetz (Norman Goetz)

	I said that the PhoneNet could drive up to 4000 feet of twisted-pair
cable, and that I hoped that our 2000-foot line-of-sight circuit would be
withing that limit as-the-cable-snakes.  Several people pointed out that phone
lines run radially from the CO, with an LADC circuit consisting of two pairs
(one from here to the CO, the other from there to the CO) patched together,
and thus my 4000-foot hope was unrealistic.  Perhaps, but I suspect that the
people who suggested that have never been to Manhattan.  CO's are every few
blocks around here.  I'm still hoping I'll make the 4000-foot limit, but I'm
not holding my breath.

	Anyway, with much random editing, some of the more interesting
comments.

----------------
From: allegra!likewise!uunet!ucscc.UCSC.EDU!haynes (Jim Haynes)

Well, a guy here has been trying it for months and it still hasn't worked.  I
guess he doesn't have 'appropriate software' to download.  The problem, as I
understand it, is that the Kinetics software isn't prepared to cope with
having two Kinetics boxes on the same Appletalk line.

----------------
From: cmcl2!harvard!husc6!bu-cs!bu-it.bu.edu!kwe

	It's crazy enough that it just might work!  It's a novel idea.
I like your inventiveness.
	I'm not sure you want to risk the investment on the Kboxes,
since I would guess that the Appletalk link will not work.  If you
have the need for the Kboxes anyway, I would recommend trying the
set-up you suggest.
	You can run anything you want on a LADC, but the telco will
only guarantee (and it's a weak guarantee) service up to 9600 baud.
19.2k is usually worth a try, 38k is very iffy, and 56k is not going to
cut it.  230k is way out there.
	You can get a good idea of how long your circuit is by knowing
where your Central Office is physically located.  If it's two miles
away, you have a four mile LADC (20k ft).  All local circuits
originate in a CO, that's the definition of a CO.  There is no
patching on the pole.  Chances are slim you will get a 4k ft circuit.
But I like the idea anyway.

----------------
From: cmcl2!rutgers!mimsy.umd.edu!uunet!tektronix!reed!goetz (Norman Goetz)

I think the Farralon hardware would work fine this way. [...]
Unfortunately I don't think this will work.  The hardware connections
are fine but the Kinetics boxes are neither routers nor half-repeaters
which is the role you are asking them to play.  I've heard it described
that the K-boxes are not true IP gateways but more remote front ends
for devices on AppleTalk.

Have you looked into twisted-pair Ethernet as a link?

----------------

	In addition, I had a conversation with Bill Russell (russell@nyu.edu)
who pointed out that even if the LADC could support AppleTalk over whatever
length the circuit turns out to be, and if the boxes could be taught to be
proper level-2 IP bridges, there is the problem of speed.  We were talking
about Ungermann-Bass etherbridges, which would cost about $16k for a pair,
running 56 kbps over the LADC.  Why so much, I asked, when it's obvious you
can put together a reasonable stab at the same end result for about a quarter
the price, and at five times the serial line speed?  Bill's answer was that
the limiting factor was not line speed, but CPU cycles.  The U-B bridge can
pass hundreds of packets per second.  A kbox, with a poor little 6809 (?)
processor in it, couldn't hope to keep up with a fraction of that traffic, not
to mention the minimal amount of ram available (i.e. minimal routing tables,
minimal packet buffering, etc).
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7-Dec-87 08:21:45 EST
From:      mckenzie@LABS-N.BBN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  ISDN Specs Wanted

I suggest that you contact

   Omnicom, Inc.
   501 Church Street
   Suite 304
   Vienna, VA  22180
   phone: 703/281-1135
   fax: 703/281-1505
   telex: 279678 OMNI UR

Tell them you want ISDN info and ask what they have.  The currently-official
version is contained in the CCITT "Red Book", Volume III, Fascile III.5.  This
was adopted in 1984.  There are undoubtedly also newer versions which are
expected to be adopted in 1988, but I don't know what is available.  However,
the Omnicom people are quite likely to know. 

By the way, Omnicon is required by CCITT to charge the "official" price for
"official" documents - they are likely to seem expensive.

Regards,
Alex McKenzie
 

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Dec 87 8:21:45 EST
From:      Alex McKenzie <mckenzie@LABS-N.BBN.COM>
To:        Scott Crenshaw <rti!scirtp!scott@MCNC.ORG>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  ISDN Specs Wanted
I suggest that you contact

   Omnicom, Inc.
   501 Church Street
   Suite 304
   Vienna, VA  22180
   phone: 703/281-1135
   fax: 703/281-1505
   telex: 279678 OMNI UR

Tell them you want ISDN info and ask what they have.  The currently-official
version is contained in the CCITT "Red Book", Volume III, Fascile III.5.  This
was adopted in 1984.  There are undoubtedly also newer versions which are
expected to be adopted in 1988, but I don't know what is available.  However,
the Omnicom people are quite likely to know. 

By the way, Omnicon is required by CCITT to charge the "official" price for
"official" documents - they are likely to seem expensive.

Regards,
Alex McKenzie
 
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7-Dec-87 12:25:14 EST
From:      root@sbcs.UUCP
To:        comp.protocols.tcp-ip
Subject:   bsd4.3 network (IP/TCP) code

I've heard recently that the networking code for IP/TCP from bsd4.3
Unix has been placed into the public domain.  The only ftp'able sources
I have seen so far is a port of 4.3 TCP for Suns, though.  Are the
sources PD?  If so, where may I ftp (or otherwise obtain) them from?

					Advance thanks,

					Rick Spanbauer
					SUNY/Stony Brook

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7-Dec-87 23:24:57 EST
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Using Kinetics boxes an an etherbridge

In article <3057@phri.UUCP> roy@phri.UUCP I wrote:

> The U-B bridge can pass hundreds of packets per second.  A kbox, with a
> poor little 6809 (?) processor in it, couldn't hope to keep up with a
> fraction of that traffic.

	Two corrections to add.  First, I got a note from kinetics!swan
(Michael J. Swan), who is Director of Software Products.  Michael says:

	[...] no, that type of setup wouldn't work because our
	gateway is not a true IP router (I assume you were routing IP
	style packets).  The KFPS code routes according to what's
	commonly refered to as Mac/IP routing which implements a subset
	of IP-style routing.  Also, to dispell some other misinformation
	you received, the KFPS uses a 68008 processor, not a 6809.

	Also, from glancing at my newly-arrived Ungermann-Bass product
literature, I see that my estimate of "hundreds of packets per second" was
low by about an order of magnitude.
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 87 02:45:43 GMT
From:      gore@nucsrl.UUCP (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   How to set up lpd with CMU IP/ACP

(Is there a better place than this newsgroup (or mailing list) to discuss the
CMU implementation of TCP/IP for VMS?)

I am trying to install the lpd server and symbiont that was distributed with
CMU's IP/ACP(V6.2) (TCP/IP for VAX/VMS), but I can find no instructions on how
to do it, and my intuition didn't get me far.  Could somebody who has done it
give me some instructions (or at least hints)?

Thanks,

Jacob Gore				gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept.		{gargoyle,ihnp4,chinet}!nucsrl!gore

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Dec-87 07:45:50 EST
From:      daveb@geac.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Networks & vendor upgrades/fixes

In article <8712040041.AA00504@ucbvax.Berkeley.EDU> henry@utzoo.UUCP.UUCP writes:
>I dimly recall a software vendor who would sell you source *or* support
>but not both.  They had the right idea.

Two vendors (not necessarily of network code) which have this policy
are Honeywell (now -Bull) and the University of Waterloo SDG.
--dave
-- 
 David Collier-Brown.                 {mnetor|yetti|utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind)
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Dec-87 11:20:42 EST
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   ARPANET UPGRADE SCHEDULE


Testing of the new ARPANET End-to-End Protocol resumed on Saturday,
December 5th and will continue running through Sunday, December 13th.
Most problems have been fixed and/or identified.  Those problems
that have been identified are awaiting software patches.

Hosts experiencing problems during this test period are asked to call 
the ARPANET Monitoring Center at (617) 873-3571/3070 or (800) 492-4992.


-------

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Dec-87 17:02:42 EST
From:      lazear@gateway.mitre.ORG
To:        comp.protocols.tcp-ip
Subject:   Protocols in Ada

I am trying to gather information on companies that are using Ada to
implement communication protocols.  Please send me any leads or rumors
about such endeavors, implementation experiences, performance issues,
etc.  I will summarize back to the net if there is interest.

	Walt (Lazear@gateway.mitre.org)

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Dec-87 19:40:35 EST
From:      david@elroy.Jpl.Nasa.Gov (David Robinson)
To:        comp.protocols.tcp-ip
Subject:   IP protocol on a chip(s)


I frequently hear that TCP/IP is too slow of a protocol.  I have seen
good ethernet boards on a Sun push packets as fast as 5Mbps and claims
of Crays pushing > 10Mbps on hyperchannels.

The throughput on most machines appears to be the speed that the 
CPU can process the packets, whether the CPU is the main CPU or
an on board CPU.

To increase TCP/IP performance has anyone looked into making an IP
protocol chip or chipset?  Would this be practical to do given
the complexity of IP?  IP on a chip would also be interesting from
a routing point of view.

Any comments on the idea and potential problems that I may not
have thought of?


-- 
	David Robinson		elroy!david@csvax.caltech.edu     ARPA
				david@elroy.jpl.nasa.gov	  ARPA
				{cit-vax,ames}!elroy!david	  UUCP
Disclaimer: No one listens to me anyway!

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 87 15:41:24 GMT
From:      cel@MITRE-BEDFORD.ARPA
To:        comp.protocols.tcp-ip
Subject:   NETMAN meeting at TCP/IP Interoperability Conference


	Members of the IETF Network Management committee met at the TCP/IP
Interoperability Conference in Washington on Dec. 1.  The following decisions
were made to progress the development of network management for TCP/IP.

     PROTOCOL

	O Develop an RFC for using CMIP/RO on TCP/UDP transport.
	  (Presentation and Session layers will not be used.)

	O Clarify the Management Services document and document the
	  differences between its services and those provided by HEMS.

	O Provide the above documents to the HEMS developers.

	O Reexamine the use of CMIP/RO or HEMS at the end of February 1988.

     TCP/IP Management Information

	O Review the HEMS RFC and ANSI X3S3 on transport/network layer
	  management information.

	O Work with HEMS developers to create separate RFCs for TCP and IP
	  layers.

     802.2, 802.3, 802.4, and X.25 Management Information

	O Using as input MAP/TOP and IEEE network management documents,
	  develop RFCs for each layer.

     Structure of Management Information

	O Using as input ISO, HEMS, MAP/TOP and IEEE documents develop an RFC
	  defining the structure of management information.


	We welcome assistance in developing these RFCs -- especially those
related to specification of management information and its structure.  People
wishing to participate may contact:

	Lee LaBarre
	The MITRE Corp.
	Burlington Road
	Bedford, MA 01730
	(617) 271 8507
	cel@mitre-bedford.arpa

	Again, we welcome your assistance in this endeavor.

	Lee LaBarre

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 87 20:32:00 GMT
From:      holt@inco.UUCP (Mark Holt)
To:        comp.protocols.tcp-ip
Subject:   KA9Q TCP/IP

I'm not sure if you are the person I should be sending this to, but
I figure you can lead me in the right direction.  

We have the KA9Q TCP/IP package here and have had great success with
using it to talk to our Sun.  What I thought you might be interested
in is the fact that I ported the software to our VAX 11/780 running
VMS 4.2.  We have a DEUNA interface to the Ethernet and so far
have managed to do file transfers among all three machines (Sun, VAX, PC)
and Telnet from the VAX to the Sun.  I only made changes that were
necessary (ie., I/O to the Ethernet, file I/O, etc.) and so far
it seems to work OK.

Thank you for making such a valuable product available to the public!
Sincerely,

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 1987 0915-EST
From:      hsw@TYCHO.ARPA  (Howard Weiss)
To:        david at elroy.jpl.nasa.gov
Cc:        tcp-ip at sri-nic.arpa
Subject:   re: IP protocol on a chip(s)


There was a TCP/IP 40-pin chip implementation built back in 1983 by
a company called Quanta Microtique.  I actually still have the
data sheets on the chip (called the QM10 - Advanced Communications
Controller).  Steve Holmgren developed the chip and ran the company -
he now runs CMC in Santa Barbara, Ca.

The "General Description" of the chip (from the QM-10 literature) says:
   "The QM10 is an LSI circuit designed to support virtual connection and
    packet functions previoulsy found in larger digital communications
    processors.  A 40-pin, dual inline form factor makes integration into
    existing hardware straightforward."

The "Device Characteristics" were listed as:
	* DoD Standard TCP connection protocol firmware.
	* DoD Standard IP packet protocol firmware.
	* Single Connection per device.
	* IP address filtering for ganged device configurations.
	* Flexible shared memory user interface.
	* Configurable network interfaces.
		- Onboard UART configuration.
		- Outborrad USART configuration.
		- Outboard shared memory network interface.
	* Single +5 volt power supply
	* 12mW stand-by power for connection state retention.
	* Standard 40-pin package.

Howard Weiss
-------

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 87 06:31:12 GMT
From:      beach.cis.ufl.edu!esj@bikini.cis.ufl.edu  (Eric S. Johnson)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: ARPANET UPGRADE SCHEDULE

Forgive me if this question is obvious, but Im not very knowledgable
about routeing issues.

During the recent ARPANET testing (12-5 to 12-13) I have noticed 
strange behavior in the internet. 

We are a SURANET/NSF net site here and during the testing, I find 
I am not able to connect to many hosts that are within LAN's that
are gatewayed on to the ARPANET proper. Yet I am able to make connections
with hosts actually on the ARPANET. For example, some mail has been
sitting in our mailq here waiting to be delivered to violet.berkeley.edu.
No connection can be made to that machine, but a connection can be made
to ucbvax.berkeley.edu and ucbarpa.berkeley.edu. I know violet is up
becuase a finger @violet.berkeley.edu@ucbarpa.berkeley.edu happily
lists the users. 

This is only one example; many other sites that are gatewayed 
via a 10.*.*.* are not reachable directly, but via finger @host@arpahost
I am able to confirm that the host is up and running.

It seems to me (and my armchair tests) that some routeing information
is getting lost somewhere. 

Everything was fine, and I none of these problems, before last
saturday (12-5). Also, I have no problem reaching other
NSFnet sites.

Would someone care to fill me in on the details. Is this problem seen
from only our LAN here? Have others noted this kind of problem? 
Is it limited to NSFnet or SURAnet? 

Thanks for any enlightenment.


--
In Real Life:			UUCP: ...ihnp4!codas!ufcsv!beach.cis.ufl.edu!esj
Eric S. Johnson II              Internet: esj@beach.cis.ufl.edu
University of Florida           "Your species is always dying and suffering" -Q
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 87 06:31:12 GMT
From:      beach.cis.ufl.edu!esj%bikini.cis.ufl.edu%CRNLVAX2.BITNET@CUNYVM.CUNY.EDU  (Eric S. Johnso, n)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: ARPANET UPGRADE SCHEDULE
I noticed what may be the same problem.  For a period of at least days
at the end of November, I could FTP to SRI-NIC.ARPA at its 10.0.0.51
address, but not at its 26.0.0.73 address (I got "Network Unreachable").
I just tried it and both address are working now.

Mark Bodenstein     (mab%cornellc.bitnet@cunyvm.cuny.edu)
Cornell University
----------------------------Original message----------------------------
...
During the recent ARPANET testing (12-5 to 12-13) I have noticed
strange behavior in the internet.

We are a SURANET/NSF net site here and during the testing, I find
I am not able to connect to many hosts that are within LAN's that
are gatewayed on to the ARPANET proper. Yet I am able to make connections
with hosts actually on the ARPANET.
...
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 87 13:10:38 GMT
From:      fair@ucbarpa.Berkeley.EDU (Erik E. Fair)
To:        comp.protocols.tcp-ip
Subject:   Re: IP protocol on a chip(s)

In the referenced article, david@elroy.Jpl.Nasa.Gov (David Robinson) writes:

>To increase TCP/IP performance has anyone looked into making an IP
>protocol chip or chipset?

Greg Chesson of Silicon Graphics in Mountain View, CA has been
looking into this. He gave a paper at the Summer 1987 USENIX
Conference in Phoenix, entitled "Protocol Engine Design." The paper
starts on page 209 in the proceedings from that conference, which
are available from the USENIX Association. His design goal was to
produce a chipset capable of keeping up with FDDI data rate
(100Mbit/sec) by doing protocol processing in a packet-time.

The technology he described was reported sold by Silicon Graphics
two months ago to a company called "Protocol Engines, Inc." in
Santa Barbara, CA. Greg Chesson's reply to an inquiry I made about
the sale was as follows:

-------------------------------------------------------------------------------

Date: 23 Oct 87 22:47:56 GMT
From: sgi!greg@ucbvax.berkeley.edu  (Greg Chesson)
Organization: Silicon Graphics Inc, Mountain View, CA
Subject: Re: Greg Chesson's Protocol Engine technology sold by SGI
Message-Id: <7237@sgi.SGI.COM>
References: <21255@ucbvax.BERKELEY.EDU>

to: Erik Fair, Dave Farber, and others:

The newspaper article quoted in this news group created some undeserved
speculation and masked the enthusiastic and public spirited support
that SGI has for the project and the concept.  SGI has given over
protocol engine technology to Protocol Engines Inc for nominal
reimbursement of costs.  It was not a significant financial
transaction.  SGI engineers and people at other companies continue to
work on the project.

Protocol engine details - protocol, state machines, software emulation
- will be placed in the public domain as has been stated before.  PEI
is modeled after other multi-company consortia such as the group that
standardized the SCSI bus.  It is a corporate shell intended to achieve
the following:
	1) provide a neutral repository for P-engine technology

	2) fund chip fabrication

	3) focus on standards activities

	4) provide multiple sources for chips

	5) push the technology beyond 100 Mbit/sec

Item (1) helps preserve the open  nature of the design and to ensure
that there exists an organization dedicated to P-engine technology.
Item (2) should be obvious, since prototype production is more than I
can accomplish as an internal skunkworks.  Item (4) means that PEI is
working with semiconductor houses to make P-engines become standard
products.  The other items should be self-explanatory.

	Greg Chesson Silicon Graphics 2011 Stierlin Road Mountain View,
	Ca, 94043 (415)962-3496 {sun,pyramid,adobe,allegra,decwrl}!sgi!greg

-------------------------------------------------------------------------------

If you (or anyone else) knows about other efforts in this general
direction, I would appreciate hearing about it.

	Erik E. Fair	ucbvax!fair	fair@ucbarpa.berkeley.edu

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 87 13:15:19 GMT
From:      sra@MITRE-BEDFORD.ARPA (Stan Ames)
To:        comp.protocols.tcp-ip
Subject:   Re: IP protocol on a chip(s)

As part of an IR&D project MITRE developed several experimental
chips to see if performance improvements could be obtained
several chips were developed for the TP4 protocol.

The most useful was an ip checksum chip.  For more information
you can call Jerry Freedman at 617-271-6248

Stan Ames

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 87 13:42:15 GMT
From:      heath@ncrcae.Columbia.NCR.COM (Robert Heath)
To:        comp.std.internat,comp.protocols.tcp-ip
Subject:   Re: ISDN Specs Wanted

Scott,
	For CCITT documents, including the Series I, which describes ISDN,
you can contact:

	OMNICOM, Inc.
	501 Church St., N.E.
	Suite 304
	Vienna, VA 22180
	(703) 281-1135

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 87 14:15:00 GMT
From:      hsw@TYCHO.ARPA (Howard Weiss)
To:        comp.protocols.tcp-ip
Subject:   re: IP protocol on a chip(s)



There was a TCP/IP 40-pin chip implementation built back in 1983 by
a company called Quanta Microtique.  I actually still have the
data sheets on the chip (called the QM10 - Advanced Communications
Controller).  Steve Holmgren developed the chip and ran the company -
he now runs CMC in Santa Barbara, Ca.

The "General Description" of the chip (from the QM-10 literature) says:
   "The QM10 is an LSI circuit designed to support virtual connection and
    packet functions previoulsy found in larger digital communications
    processors.  A 40-pin, dual inline form factor makes integration into
    existing hardware straightforward."

The "Device Characteristics" were listed as:
	* DoD Standard TCP connection protocol firmware.
	* DoD Standard IP packet protocol firmware.
	* Single Connection per device.
	* IP address filtering for ganged device configurations.
	* Flexible shared memory user interface.
	* Configurable network interfaces.
		- Onboard UART configuration.
		- Outborrad USART configuration.
		- Outboard shared memory network interface.
	* Single +5 volt power supply
	* 12mW stand-by power for connection state retention.
	* Standard 40-pin package.

Howard Weiss
-------

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 87 18:02:02 GMT
From:      zeeff@b-tech.UUCP (Jon Zeeff)
To:        comp.protocols.tcp-ip
Subject:   Re: Latest KA9Q TCP/IP for MSDOS now available from SIMTEL20

Is this the version that includes support for running as a single task under
Unix?  If not, what is the status of that version (I heard is was almost
done months ago).

--Jon

-- 
Jon Zeeff           		Branch Technology,
uunet!umix!b-tech!zeeff  	zeeff%b-tech.uucp@umix.cc.umich.edu

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 87 18:42:39 GMT
From:      evan@ndcheg.UUCP (Evan Bauman)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip,comp.sys.mac
Subject:   software to use with Kinetics box

We just got our first Kinetics FastPath box to bridge our
appletalk net to our ethernet.  I was wondering if anyone
had any suggestions for software that we could use with it.

We already have NCSA telnet and we are expecting our copy of
K-Spool from Kinetics anyday now.  Someone else has ordered
UNIX Tops.

Our configuration:  10 Sun 3's, a few Convergent SYS V boxes,
2 appletalk nets with a total of about 30 nodes, various modems,
imagewriters, and laserwriters.  A few PC's with appletalk cards
will be added soon.

Thanks in advance.

	Evan Bauman
	Univ. of Notre Dame
	..!iuvax!ndcheg!evan

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Dec 87 16:18:40 IST
From:      Hank Nussbacher <HANK%TAUNIVM.BITNET@WISCVM.WISC.EDU>
To:        tcp-ip@sri-nic.ARPA
Subject:   Routers vs. Bridges
I know this has been covered once before but I am preparing a paper
on the benefits of routers over bridges and bridges over routers.

Specifically, there are routers today that handle multiple protocols
(cisco and proteon to name two) and there are bridges that are starting
to handle alternate routing and allow the construction of a closed
network loop.

What I would like to receive (please reply directly to me and not to
the list) are examples and explanations of what a router can do at level
3 that a bridge just cannot handle.  And why is it so important to be
able to do it.

When I have finished creating my document I will post it to the this list.
If you have any articles or papers you would like to send to me on the
subject, please send them to:

Henry Nussbacher
Computer Center
Tel Aviv University
Ramat Aviv
Israel

Thanks,
Hank
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 87 20:05:21 GMT
From:      michaud@irisa.UUCP (Michaud Franck INSA BN205)
To:        comp.protocols.tcp-ip
Subject:   virtual circuit


	I'd like to have a good definition of :
- virtual circuit.

 	If you have a good definition, send me a mail.
		thanck you.
	franck

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 87 22:22:58 GMT
From:      percy@amdcad.AMD.COM (Percy Irani)
To:        comp.protocols.tcp-ip
Subject:   Vitalink Bridges..


We have a Vitalink sales guy trying to sell Vitalink Bridges to our
Company. We primarily have TCP/IP hosts on the net. We also have
some DECNET hosts.

What is attractive to some people (Sigh!) is that the Vitalink's will
be able to do protocol independant connections. I guess we can beat
the Vitalinks iff there is a router that does both IP and DECNET.

IS THERE ONE AVAILABLE LIKE THAT TODAY????
------------------------------------------

Also, the Vitalink sales and tech support (I beleive the sales guy
talked to them) do **NOT** understand the problem of "Ethernet 
Meltdown". Has *anyone*, yes anyone, encountered this problem
using bridges?

Also, to be specific, has anyone, encountered this problem using
Vitalink boxes? (DEC sells Vitalinks too!!).

(Come on some one from DEC can shed light on that!!).

Besides, our friends do not understand the advantages of alternat 
routing (routed type), support of triangles in a net instead of
spanning trees.......

Sigh!
-- 
Ignorance is bliss but can be embarassing at times!

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 87 22:33:36 GMT
From:      don@SRI-LEWIS.ARPA (Donald Holman)
To:        comp.protocols.tcp-ip
Subject:   Why wait for the rabid bite of a problem withou a solution?




To those that listen with appologies to those that don't:

I left the TCP/IP conference (Monterey East) with a few items
that appeared to be without solution in the near future. I query
the mailing list in an effort to solicit for ideas from
the collective body on each of these areas. One or all of these will
be of interest to my efforts in the near future, thus why wait for
the rabid bite of a problem without solution. Probably be inundated with
flaming broadcast storms over these questions, but here goes.

PLEASE; IF YOUR RESPONSE IS NOT ENTIRELY APPLICABLE TO THE
TCP/IP MAILING LIST RESPOND DIRECTLY TO ME.

Glossary of terms and acronyms:
---------------------

Standard - an accepted degree or level of excellence.
TIA - That Is All.

1) SLIP LINK ESTABLISHMENT, there is no standard link establishment 
procedure/protocol for SLIP which presents problems when attempting 
to utilize SLIP in a dialup or various other modes. There are additional 
problems which are related to address mapping for the user of a 
SLIP port, which incidently may cause problems with security. 
Is anyone working on a solution to this, or is there
an existing solution may have the pleasing aroma of a standard?

2) SECURITY, various vendors of IP routers touted the ability to discriminate
for/against packets based on the security field found in the IP portion of a 
datagram header. The present problem with this is that there is no 
provision in any of the ARPA/DDN upper layer protocols for setting 
this security bit (or is there?). How does one determine to set the bit 
since SMTP, FTP etc. does not provide the mechanics for passing this 
security information to the network layer?

3) ROUTING METRICS. Most gateway routing decisions are determined by hop count
or minimum path. This is not always the best approach since the minimum path may
not be the best path. Example: who cares if the packet traverses 5 hops 
to get to the destination if the 5 hop path is more economical/better than the 2 
hop path. Is there a published method that is better than min_hop?

4) LEASED LINES FOR DDN. The DDN may not be able to afford all of the dedicated
leased lines which are to be in service over the next several years. Is there an 
alternative to leased lines? Perhaps something that utilizes dial-up in conjunction
with a machine-machine (read uucp-uucp) transfer of queued information. This
could reduce the need for high-cost leased lines in selected cases.

TIA, 
Don

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 87 22:42:29 GMT
From:      castillo.osbunorth@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   smtp on Unix (sun) machines



According to the BNF's on RFCs 822 & 821 in its reference to qstrings (quoted
text on user names of the form user@host), you can have any of the 128 ASCII
chars (except for CR, LF, ", \, unless preceded by \) on the user name as long
as it is enclosed between double quotes (") chars.

I found that on the Sun implementation, even after modifying one of the Mailer
Flags (removed 's) in the sendmail.cf, so that the mailer passes the strings
without removing the quotes, it still manages to find the Spaces 
procedes to separate the user name.

Esentially I'm interesting in passing along user names of the form "xx:xx
xx:xx".
Are there any known workarounds or modifications to the sendmail.cf on Sun
machines, or for that matter in the any of the BSD Unix machines?

thanks for you suggestions

** julio

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 00:01:25 GMT
From:      PULLEN@VAX.DARPA.MIL (Mark Pullen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP protocol on a chip(s)

David,

Michael Foster and Yechaim Yemini and Columbia University are working
on VLSI implementations of protocols.

Mark Pullen
DARPA Program Manager
Advanced Networking
-------

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 00:40:35 GMT
From:      len@SPAM.ISTC.SRI.COM (Len Schlegel)
To:        comp.protocols.tcp-ip
Subject:   POP2, etc.


I am interesting in finding out about POP versions other than that
specified in RFC937.  I also would like to know who funded the development
of the protocol.  Also, any references to other distributed mail access
work and who funded it would be appreciated (aside from RFC984 on pcmail).
Thanks in advance.

Len Schlegel (len@spam.istc.sri.com)

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 1987 07:52:15 CST
From:      Link Verstegen@GUNTER-ADAM.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Cc:        LINK@GUNTER-ADAM.ARPA, lan-EPS@GUNTER-ADAM.ARPA, afddn.beACH@GUNTER-ADAM.ARPA
Subject:   LAN Presentation and Security Packages
Gentlemen,

	The Standard Systems Center (AFCC) is preparing an Air Force wide
acquisition of LAN Presentation Software (ULANA Compatible) and PC (8088,
80286, and 80386) Security Hardware/Software.  The Equipment Performance
Specification is available for FTP on the Gunter-Adam.  The account name
is LAN-EPS and the password is the same.  

	Comments may be addressed to LAN-EPS@GUNTER-ADAM.ARPA.  If you
have comments that you do not wish to share with other vendors, address
them to LINK@GUNTER-ADAM.ARPA.

	Remember, this is an informal medium, and the Standard Systems
Center will NOT be held accountable for the disposition of the comments
received.  This is provided as a courtesy to the vendor community and 
provides them a chance to point out any glaring errs we may have made.


		    /|                  /|
===================/ |=================/ |===================
 Link N. Verstegen                     Link@Gunter-ADAM.ARPA
 Computer Systems/Network Engineer
 HQ SSC/PRS                               (205)279-5151
 Gunter AFS, AL  36114-6343                AV 446-5151

-------
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Dec 87 14:24:47 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        holman@sri-lewis.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: Why wait....

Sounds like we didn't get the word out at Monterey East.  I believe
that all the problems you list are currently being worked on by various task
forces.

Craig
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Dec 87 14:39:24 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   Current State of Network Management

I got a couple of inquiries today from people who mis-interpreted Lee's
note to suggest that all network management activities are being
coordinated through him.  That's not what the note was intended to
say.

Regretfully, network management work is still a multi-headed beast.
Here's a short Who's Who:

    NETMAN (Network Management) Working Group of the IETF.  Chaired
    by Lee LaBarre.  As Lee's note indicated, they are working on
    fashioning their own network management proposal, based in part
    on work done by the HEMS group.  Contact Lee (cel@mitre-bedford.arpa)
    for information.

    GWMON (Gateway Management) Working Group of the IETF.  Chaired
    by me, and the source of the High-Level Entity Management System
    (HEMS) proposal, documented in RFC1021-1024 and recently implemented.
    Operates the GWMON mailing list, which is the mailing list for
    all general interest announcements/correspondence on network
    management.  Mail to gwmon-request@sh.cs.net to join.

    SGMP (Simple Gateway Monitoring Protocol).  Affiliated with the
    IETF but not a working group (for odd historical reasons).
    Documented in RFC 1028 (which I believe has not yet been released).
    Several test implementations exist.  I believe most SGMP announcements
    appear on GWMON, although there is a separate mailing list for
    SGMP implementors.

There are also activities attempted to build applications or protocols
that work at a higher level that these protocols (which primarily address
the problem of data extraction).  These activities include:

    The Network Computing Forum (NCF) is trying to develop higher level
    management applications/protocols.  This is being led by Terry
    Hardgraves (pardon any mis-spelling, his business card is in
    my briefcase at home) of the Software Productivity Consortium.

    ANM (Automated Network Management), a project at BBN Laboratories
    which uses a distributed database system and AI tools to effect
    network management.  Contact Jil Westcott, jwestcott@bbn.com, for
    more information.

    An IETF working group led by Jeff Case (one of the SGMP authors).
    case@utkcs2.cs.utk.edu

I hope this all helps.

Craig
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 06:39:55 GMT
From:      HANK@TAUNIVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Routers vs. Bridges

I know this has been covered once before but I am preparing a paper
on the benefits of routers over bridges and bridges over routers.

Specifically, there are routers today that handle multiple protocols
(cisco and proteon to name two) and there are bridges that are starting
to handle alternate routing and allow the construction of a closed
network loop.

What I would like to receive (please reply directly to me and not to
the list) are examples and explanations of what a router can do at level
3 that a bridge just cannot handle.  And why is it so important to be
able to do it.

When I have finished creating my document I will post it to the this list.
If you have any articles or papers you would like to send to me on the
subject, please send them to:

Henry Nussbacher
Computer Center
Tel Aviv University
Ramat Aviv
Israel

Thanks,
Hank

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Dec 87 12:46:37 EST
From:      Ross Callon <rcallon@PARK-STREET.BBN.COM>
To:        don@SRI-LEWIS.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, rcallon@PARK-STREET.BBN.COM
Subject:   re: rabid bite of problems
Don;

In response to part (3) of your message:  The BBN Butterfly gateways do NOT use
a simple hop count for routing decisions, for essentially the reason that you
gave.  Instead we use a cost which is administratively set as a function of 
the network characteristics.  Each gateway-to-gateway link may in principle 
be given a different cost.  For example, the cost (over the Arpanet) between
gateways at BBN and MIT could be administratively set to be different than the
cost between gateways at BBN and ISI.  In practice, we tend to assign a single
cost for all links over a single network.  As an example, we currently use a
single fixed cost for links over the Arpanet, which is greater than the cost
which we use for links over LANs.  The routes calculated by the Butterfly SPF
algorithm minimize the sum of these costs, and do reflect differences in
network characteristics.  A link up/down algorithm is used to determine whether
each gateway-to-gateway link is operating successfully, but as long as the link
is up its metric is stable.  We have been having good success with operational
use of this algorithm since it was installed about a year and a half ago.

The IS to IS routing proposal which is being progressed in ANSI X3S3.3 (and
is being taken to the next ISO network layer meeting in Guernsey) also uses
administratively set costs.  Here again a link up/down protocol is used to
determine whether a link is operational.  

You asked if there is a "published" method which is better than hop count.
We are intending to publish a description of our SPF, but haven't done so yet.
The ANSI proposal is semi-available.  The most recent version was passed out at
the last X3S3.3 meeting, and should be mailed out to the X3S3.3 mailing list
soon.

Ross
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10-Dec-87 14:15:45 EST
From:      oattes@gpu.utcs.toronto.edu (Lee Oattes)
To:        comp.protocols.tcp-ip
Subject:   micro-vax with more than one ether-net board?

I am interested in knowing whether any one out there has had experience
in connecting more than two ethernet boards to a micro-vax (Q-bus)
running Ultrix 2.0. The application is to use such micro-vaxen as
gateways between many ether(sub)nets (ie. more than two!). As it is
now, we can only use each micro-vax as the gateway between two ether
networks and it would definitely be nice to have more capability to
handle more ether networks without having to purchase more micro
vaxes!  The standard deqna boards have switches for only two csr
addresses, though the device driver will allow more than two.  Is there
any trick to get around this? It seems a little silly to allow only two
deqna boards (?).

An alternative would be to install another type of ethernet board with
its own driver. Does any one know of any such products? We have considered
the Interlan NI2010 board, but Interlan only supports device drivers for
the multibus. Has anyone developed an Ultrix device driver for the Q-bus
for this board?

Any suggestions would be welcome.

-- 
Lee Oattes, University of Toronto Computing Services, CTS.
UUCP - {ihnp4!decwrl!utai!, uunet!utai!, allegra!utai! } utgpu!oattes
BITNET - oattes@utorgpu.bitnet
INTERNET - oattes@gpu.utcs.toronto.edu

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Dec 87 16:52:05 EST
From:      Bob Dixon <TS0400%OHSTVMA.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Vitalink Bridges..
We are using Proteon routers with tcp/ip and decnet today, and very
successfully.

                         Bob Dixon
                         Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 13:52:15 GMT
From:      Link.Verstegen@GUNTER-ADAM.ARPA
To:        comp.protocols.tcp-ip
Subject:   LAN Presentation and Security Packages

Gentlemen,

	The Standard Systems Center (AFCC) is preparing an Air Force wide
acquisition of LAN Presentation Software (ULANA Compatible) and PC (8088,
80286, and 80386) Security Hardware/Software.  The Equipment Performance
Specification is available for FTP on the Gunter-Adam.  The account name
is LAN-EPS and the password is the same.  

	Comments may be addressed to LAN-EPS@GUNTER-ADAM.ARPA.  If you
have comments that you do not wish to share with other vendors, address
them to LINK@GUNTER-ADAM.ARPA.

	Remember, this is an informal medium, and the Standard Systems
Center will NOT be held accountable for the disposition of the comments
received.  This is provided as a courtesy to the vendor community and 
provides them a chance to point out any glaring errs we may have made.


		    /|                  /|
===================/ |=================/ |===================
 Link N. Verstegen                     Link@Gunter-ADAM.ARPA
 Computer Systems/Network Engineer
 HQ SSC/PRS                               (205)279-5151
 Gunter AFS, AL  36114-6343                AV 446-5151

-------

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 15:55:36 GMT
From:      radia@XX.LCS.MIT.EDU (Radia Perlman)
To:        comp.protocols.tcp-ip
Subject:   Re: Routers vs. Bridges

The January, 1988 issue of IEEE Network magazine has multiple articles
on bridges vs routers.  I wrote one of them.  The main problem with
the "bridge vs router" issue is defining what a bridge vs a router is.
You could define an entire network architecture and declare that to
be your data link layer, and claim then that the box that forwards
packets is a "bridge" because it operates at the "data link layer".

My contention, though, is that a Data Link layer header only has
in it information to deal with one hop -- one pair of addresses, (source
and destination), no route, no hop count, etc.  Since the Network
Layer handles multiple hops, if a header is defined with two pairs
of addresses (ultimate source, ultimate destination plus immediate
source and immediate destination), hop counts, routes, etc, then I
claim it's a Network Layer protocol.

For instance, I claim the DEC bridge is clearly a bridge (although it allows
store and forward) because as far as the end stations are concerned, they
are dealing only with a Data Link protocols -- the header they
see fits my description of a Data Link header.  The "source routing
bridge", on the other hand, I'd claim is clearly a router and not
a bridge, because it requires end stations to discover and place
a route in the header.

You may want to wait until the January IEEE Network comes out for
many different viewpoints on this issue.  If you'd like to study
the issue independently, I'd suggest starting with a rigorous
definition of "routers" and "bridges" that clearly places
a box in one category or another, before trying to argue the
merits of each kind of box.

Radia
-------

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 16:22:18 GMT
From:      dennist@tektronix.TEK.COM (Dennis Thomas)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.sys.dec
Subject:   AT&T ISN


	I am interested in contacting or receiving input from any one
that has experience in using AT&T's ISN product in a networking environment.
The environment to be considered is a single communications link, connected
by 2 ISN's concentrating Ethernet (TCP/IP, DECNET, LAT), IBM 3274, IBM 3270
and DECNET synchronous traffic.

	Some of the concerns relate to the effect of file transfer
rates for TCP/IP and DECNET when the other traffic is active. Since
the ISN moves data in small packets (180bits) with an 8.64 Mb transmit and
receive bus, it would seem that large TCP/IP or DECNET packets (file transfer)
would suffer at the expense of terminal activity.

	Thank you in advance for your input.

Dennis Thomas
Tektronix, Inc.
dennist@tektronix.TEK.COM
(503) 627-5030

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 17:40:07 GMT
From:      rdhobby@ucdavis.edu (Russ Hobby)
To:        comp.protocols.tcp-ip
Subject:   SLIP discussion at the Interoperability Conference

Here  is what  happened at  the TCP/IP  Interoperability Conference with 
regards to SLIP. 

The  BOF session was too large to  get any protocol standards work done, 
but  the group provided input as to what  needs to be covered by the the 
standard  and some  of the  potential uses  for SLIP connections.  There 
seemed  to be two types of usage for the new standard SLIP protocol. One 
is  the connection of  isolated computers that  do not have  access to a 
LAN.  PCs would be a  big proportion of the  computers in this category, 
but certainly any type of computer can use the capability. 

The  other use of SLIP  connections is for temporary  network links. The 
idea  is to advertise a  route to another location  all the time, but to 
dialup  and establish the connection to that location only when there is 
traffic.  The first packet will be delayed while the connection is being 
made,  but  there  after  traffic  would  flow smoothly. After a certain 
period  of no traffic  the connection would  be dropped, thus  saving on 
communications costs. 

The  evening after the BOF  session, a smaller group  of us got together 
and  got some productive  work done towards  the writing of an RFC for a 
SLIP  type protocol.  Here is an overview of what  was decided (at least 
what I can decipher from my notes). 

       1) The RFC will cover both connection and line protocols 

       2) Connection specifications will cover negotiation of items such 
       as  network  addresses,  authentication,  line speed, compression 
       used, and probably other items. 

       3)  The line  protocol will  contain one  byte in  the header  to 
       indicate  the protocol in the packet. This allows the use of line 
       control  packets  for  maintaining  the  serial  link, as well as 
       allowing  other protocols in addition to  IP and the line control 
       to use the connection. 

Much  more detail was  discussed, but I  don't want to  bore you with it 
now.   It  was  thought  that  an  RFC   draft  could  be  done  and  an  
implementation to test it in a couple of months. 

UC  Davis will be implementing the new standard by modifying our current 
work.  So some of you  may want to wait  for the standard version rather 
than using what we have available now. But then if you have an immediate 
need,  out old version will be there. Since the standard version will be 
more  than  experimental  software,  it  will  more  complete and better 
documented. 
                                Russell Hobby               
                         Data Communications Manager 
     U. C. Davis                 
     Computing Services       BITNET:    RDHOBBY@UCDAVIS 
     Davis Ca 95616           UUCP:      ...!ucbvax!ucdavis!rdhobby 
     (916) 752-0236           INTERNET:  rdhobby@ucdavis.edu

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 17:42:18 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Routers vs. Bridges

Here is one way you might decide if a given box is a bridge or an IP gateway
(aka router): see if it forwards a local network broadcast packet. A
bridge "must" forward broadcasts, while a gateway "must never" forward one.

Another test: see if the IP network number changes when the packet is
forwarded.  A bridge must not change anything in the IP header, while a
gateway "must" change the IP destination address.

These two tests give some clues about the advantages of gateways over
bridges.

   Bob Braden
   

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 17:46:37 GMT
From:      rcallon@PARK-STREET.BBN.COM (Ross Callon)
To:        comp.protocols.tcp-ip
Subject:   re: rabid bite of problems

Don;

In response to part (3) of your message:  The BBN Butterfly gateways do NOT use
a simple hop count for routing decisions, for essentially the reason that you
gave.  Instead we use a cost which is administratively set as a function of 
the network characteristics.  Each gateway-to-gateway link may in principle 
be given a different cost.  For example, the cost (over the Arpanet) between
gateways at BBN and MIT could be administratively set to be different than the
cost between gateways at BBN and ISI.  In practice, we tend to assign a single
cost for all links over a single network.  As an example, we currently use a
single fixed cost for links over the Arpanet, which is greater than the cost
which we use for links over LANs.  The routes calculated by the Butterfly SPF
algorithm minimize the sum of these costs, and do reflect differences in
network characteristics.  A link up/down algorithm is used to determine whether
each gateway-to-gateway link is operating successfully, but as long as the link
is up its metric is stable.  We have been having good success with operational
use of this algorithm since it was installed about a year and a half ago.

The IS to IS routing proposal which is being progressed in ANSI X3S3.3 (and
is being taken to the next ISO network layer meeting in Guernsey) also uses
administratively set costs.  Here again a link up/down protocol is used to
determine whether a link is operational.  

You asked if there is a "published" method which is better than hop count.
We are intending to publish a description of our SPF, but haven't done so yet.
The ANSI proposal is semi-available.  The most recent version was passed out at
the last X3S3.3 meeting, and should be mailed out to the X3S3.3 mailing list
soon.

Ross

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 17:54:28 GMT
From:      percy@amdcad.AMD.COM (Percy Irani)
To:        comp.protocols.tcp-ip
Subject:   Proteon Routers..


This may be dumb, but my efforts to get the Proteon (the
router company :-) ) number for a sales guy has lead to
a futile chase. Can anyone tell me the number of 
Proteon. Leads will also be appreciated. If this helps,
Im in the 408 area code.

Lets not clutter the net with responses. Send me mail
directely.

Thanks in advance.

-Percy Irani
percy@amdcad.amd.com
{decwrl,ihnp4,gatech,sun,ucbvax}!amdcad!percy
-- 
Ignorance is bliss but can be embarassing at times!

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 18:10:03 GMT
From:      dab@ALLSPICE.LCS.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Ethers, Copper, Fiber, Microwaves, Etc.


>	Now this is something new to me.  If you can put them in a
>briefcase they must be around 100GHz.  That would probably limit the
>range to a mile or so.  The problem with infrared laser technology is
>the atmospheric attenuation of smog, fog, and rain.  Sounds like this
>new ultra-high freq microwave fills the gap between low freq uwave and
>infrared. 

	In the ham radio community for several years there have been
devices called Gunnplexers available (I don't know if that's a brand
name or a generic name) which are a 10 GHz microwave system for about
$200.  When they first showed up there were several articles in ham
radio magazines descibing how to send video through them, so 10 Mb/sec
is probably not too far out of line.  Except for maybe the feedhorn
(or the dish itself) it would easily fit into a briefcase.  The range
is limited but I think to line of sight rather than 1 mile.
						Dave Bridgham

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 18:55:14 GMT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Vitalink Bridges..


Yes, we've encountered meltdowns and broadcast storms across bridges.
Watch for Chuck Hedrick and Len Bosack's article on such network phenomena
in an upcoming IEEE Network Magazine.

We do run IP and DECNET through our CISCO routers.  I don't know if CISCO
has made it a product yet (although it is likely that they will).  Also
Proteon, I believe, has already marketed the product.  Noel's code has
always been aimed at multiple protocol support (originally IP/CHAOS).

As a slight bit of humor, when hooking up my sun, I managed to crash every
VMS machine at Rutgers (including two in NEWARK that were 20 miles away)
because all the VMS machines (being primarily DECNET speakers) were on the
data link repeated parts of the Rutgers net.

-Ron

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 19:41:19 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Routers vs. Bridges (CORRECTION)

As Bill Westfield immediately pointed out to me (SIX MINUTES later!), my
brain was disengaged when I sent a message earlier.  Sorry. Here is what
I meant to say:
___________________________________________________

Here is one way you might decide if a given box is a bridge or an IP gateway
(aka router): see if it forwards a local network broadcast packet. A
bridge "must" forward broadcasts, while a gateway "must never" forward one.

Another test: see if the destination local network address changes when
the packet is forwarded.

These two tests give some clues about the advantages of gateways over
bridges.

   Bob Braden
   



----- End Forwarded Message -----

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 20:44:31 GMT
From:      haas%gr@CS.UTAH.EDU (Walt Haas)
To:        comp.protocols.tcp-ip
Subject:   Re: Vitalink Bridges..

In article <19509@amdcad.AMD.COM>, percy@amdcad.AMD.COM (Percy Irani) writes:
> 
> We have a Vitalink sales guy trying to sell Vitalink Bridges to our
> Company. We primarily have TCP/IP hosts on the net. We also have
> some DECNET hosts.
> 
> What is attractive to some people (Sigh!) is that the Vitalink's will
> be able to do protocol independant connections. I guess we can beat
> the Vitalinks iff there is a router that does both IP and DECNET.
> 
> IS THERE ONE AVAILABLE LIKE THAT TODAY????
> ------------------------------------------

There are at least two, cisco and Proteon.

However the real advantage of level two bridges like the Vitalink is
that they let you also run ISO, XNS, Ethertalk, Novell and what have
you with no further modification.  Given the dynamic state of protocols
today this is a big advantage.  For example, the low level protocols
of DECnet will change drastically next year.  Proteon and cisco may
or may not keep up, but a level two bridge won't even notice.

Cheers  -- Walt Haas    arpa: haas@cs.utah.edu   uucp: ...utah-cs!haas

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 21:35:25 GMT
From:      ruffwork@orstcs.CS.ORST.EDU (Ritchey Ruff)
To:        comp.protocols.tcp-ip
Subject:   Re: ARPANET UPGRADE SCHEDULE

We are having the same problem here - before the new protocall went
into testing orstcs.cs.orst.edu and uwchem.acs.washington.edu could
talk directly to each other, now they can't (it's actually intermitent
but I have not been keeping that close a track of when the new
protocall is in/out).  I can do a 
	finger @uwchem.acs.washington.edu@washington.edu
now and see uwchem, but directly to uwchem, which use to work ALL
the time, works less and less (and has not worked for the last week
that I know of).

Is this a problem with the new protocall ???

--ritchey ruff			ruffwork@cs.orst.edu -or- 
"It's against my programming	ruffwork%oregon-state@relay.cs.net -or-
 to impersonate a deity" --C3PO	{ hp-pcd | tektronix }!orstcs!ruffwork

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 21:52:05 GMT
From:      TS0400@OHSTVMA.BITNET (Bob Dixon)
To:        comp.protocols.tcp-ip
Subject:   Re: Vitalink Bridges..

We are using Proteon routers with tcp/ip and decnet today, and very
successfully.

                         Bob Dixon
                         Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 87 22:52:07 GMT
From:      leiner@riacs.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Vitalink Bridges..


Proteon makes a gateway that can deal with both Decnet and IP (so they
tell me).  NASA is exploring their use in the NASA Science Internet.

Barry

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 87 00:51:01 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Why wait....


Sounds like we didn't get the word out at Monterey East.  I believe
that all the problems you list are currently being worked on by various task
forces.

Craig

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 87 01:50:09 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Current State of Network Management


I got a couple of inquiries today from people who mis-interpreted Lee's
note to suggest that all network management activities are being
coordinated through him.  That's not what the note was intended to
say.

Regretfully, network management work is still a multi-headed beast.
Here's a short Who's Who:

    NETMAN (Network Management) Working Group of the IETF.  Chaired
    by Lee LaBarre.  As Lee's note indicated, they are working on
    fashioning their own network management proposal, based in part
    on work done by the HEMS group.  Contact Lee (cel@mitre-bedford.arpa)
    for information.

    GWMON (Gateway Management) Working Group of the IETF.  Chaired
    by me, and the source of the High-Level Entity Management System
    (HEMS) proposal, documented in RFC1021-1024 and recently implemented.
    Operates the GWMON mailing list, which is the mailing list for
    all general interest announcements/correspondence on network
    management.  Mail to gwmon-request@sh.cs.net to join.

    SGMP (Simple Gateway Monitoring Protocol).  Affiliated with the
    IETF but not a working group (for odd historical reasons).
    Documented in RFC 1028 (which I believe has not yet been released).
    Several test implementations exist.  I believe most SGMP announcements
    appear on GWMON, although there is a separate mailing list for
    SGMP implementors.

There are also activities attempted to build applications or protocols
that work at a higher level that these protocols (which primarily address
the problem of data extraction).  These activities include:

    The Network Computing Forum (NCF) is trying to develop higher level
    management applications/protocols.  This is being led by Terry
    Hardgraves (pardon any mis-spelling, his business card is in
    my briefcase at home) of the Software Productivity Consortium.

    ANM (Automated Network Management), a project at BBN Laboratories
    which uses a distributed database system and AI tools to effect
    network management.  Contact Jil Westcott, jwestcott@bbn.com, for
    more information.

    An IETF working group led by Jeff Case (one of the SGMP authors).
    case@utkcs2.cs.utk.edu

I hope this all helps.

Craig

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 87 04:46:12 GMT
From:      RCONN@SIMTEL20.ARPA (Rick Conn)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocols in Ada

The software submitted to the Ada Software Repository on communications
protocols written in Ada (namely, TCP/IP) was written by E_Systems, Inc.
Details are contained in the PROlogues files in PD2:<ADA.DDN> and
in PD2:<ADA.WIS-TOOLS>

	Rick Conn
-------

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 87 08:08:30 GMT
From:      hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Routers vs. Bridges

>Another test: see if the IP network number changes when the packet is
>forwarded.  A bridge must not change anything in the IP header, while a
>gateway "must" change the IP destination address.

One hopes the IP network number doesn't change when a gateway forwards
a packet.  The only thing that would normally change is TTL.

The problem with trying to define these things is that there are
hybrid beasts, e.g. bridges that allow the user to specify filtering
using boolean operations on arbitrary bytes in the header.  One could
(and indeed probably should) set up such a bridge so it did not pass
IP broadcasts.  There seems to be a continuum possible.  I have
evidence that as time goes on, we're going to see a lot more points in
that continuum.  E.g. boxes that act as true gateways for IP packets
and bridges for everything else, and bridges whose routing is as
complex as an IP router, but applied to the MAC address instead of the
IP address.  

I'd say that to qualify as an IP gateway by modern standards you need
to process correctly most of the fields in the IP header, including
decrementing the TTL, doing type of service routing, implementing
source quench, source routing, record route, etc., and doing
fragmentation.  The claim that a bridge is all you need is equivalent
to the following claims:

  - that everything in the IP header other than source and destination
	is unnecessary.

  - that it makes sense to build routing on top of an address with no
	internal structure.  (That is, the MAC addresses have no pattern
	to them.  IP gateways normally have to figure out a route to
	each network that they can reach.  A bridge has to keep track
	of distinct MAC addresses.  The thought of a gateway that
	knows every address in the Internet is absurd.  So in effect
	the bridge's knowledge may be just a cache.  But then you need
	a way to find a route initially.  There are many such schemes,
	but they all run into trouble for very big networks.)

  - that ICMP functions, e.g. unreachable, and source quench, are
	unnecessary.  (I don't mention redirects, because they obviously
	are unnecessary in a system using bridges.)

In short, that the IP network layer is unnecessary.  In my opinion,
you can survive without a full network layer in a small, homogeneous
system.  So I have no problem with using LANbridges to connect a few
Ethernets (though I wouldn't do it myself).  But if the network layer
is unnecessary, how come every protocol has one, and attempts to do
routing at the MAC layer end up reinventing them (e.g. the IBM
MAC-level source routing, and other ISO MAC-level network functions)?
Again, I have no doubt that there are uses for LANbridges and similar
gadgets.  But at some point you have to draw the line, and start
using the facilities that the protocol designers have supplied for you.
The question is where that line is.  One has a suspicion that when you
start having a network of bridges running a full-scale routing protocol,
there's a good chance you've crossed the line.  On the other hand, there
may be cases where for various practical reasons, such a product would
actually be useful.

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 87 08:23:21 GMT
From:      slevy@UMN-REI-UC.ARPA (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Determining gateway buffer capacity

Some recent messages on this list described efforts to define a scheme for
hosts to find a network path's maximum preferred message size, e.g. the
largest datagram which could be sent without some gateway fragmenting it.

Has anyone considered having gateways give advice to hosts on how -much- data
they should send, either in terms of total amount of outstanding data
(which TCPs could use to limit windows) or data flow rate (which, say,
NETBLTs could use to set rate parameters)?

This seems like a natural function to piggyback onto a max-message-size
probe.  It suffers from some of the same limitations, that there may be
multiple paths with different behavior.

A gateway giving buffering advice would have to make some assumption about
what fraction of its capacity (or its links' capacity) should be available
to a given session.  It might make a static decision ("I expect to have <= 10
active connections passing through me at once, so I advise everybody to use
no more than 1/10th of my capacity") or a dynamic one ("Things are getting
too crowded, so I'll tell everyone to send no more than 1000 bytes per second").
If implemented as an IP option it could be hung on Source Quenches to give
some crude quantitative information.  Capacity assumptions could be wrong,
but at least they would prevent hosts with 32K TCP windows from swamping
gateways with 20K of buffer space.

Is anything along these lines being discussed?  (Or has it already been
discussed and abandoned?)

			Stuart Levy,  Minnesota Supercomputer Center
			slevy@uc.msc.umn.edu,  (612) 626-0211

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 87 10:25:23 GMT
From:      jgh@root.co.uk (Jeremy G Harris)
To:        comp.protocols.tcp-ip
Subject:   Subnetting questions

A whole bunch of questions:


Does anybody run multiple subnets on a single Ethernet?

    If so, do you use subnet broadcasts or net broadcasts?
    Do you find it worthwhile to use ethernet multicast for
    subnet broadcasts? How do you assign the multicast addresses?
    For what purposes do you still use net broadcast?

    Should redirects be provided by an inter-subnet gateway,
    when both subnets are on the same Ethernet?


What are the semantics of 'ICMP redirect to net' in a subnettted environment?


Does anybody run multiple classes of subnet on a single net?

    Does the mechanism proposed in rfc950 ( ICMP broadcasts to
    discover the subnet mask ) still work? Do you use it?


Thanks for your time
    Jeremy
-- 
Jeremy Harris			jgh@root.co.uk

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 87 13:14:07 GMT
From:      bill@trotter.usma.edu (Bill Gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: Latest KA9Q TCP/IP for MSDOS now available from SIMTEL20

In article <4063@b-tech.UUCP>, zeeff@b-tech.UUCP (Jon Zeeff) writes:
> Is this the version that includes support for running as a single task under
> Unix?  If not, what is the status of that version (I heard is was almost
> done months ago).
> 

The latest word on the next release of KA9Q's TCP/IP is to look for it
in your Christmas stocking.
As there appears to be a lot of interest any more I will post a message 
as soon as it becomes available if noone beats me to it.  I check on it 
just about every day.  The UNIX support is supposed to be for SYS V but
I will be converting that over to Version 7 and probbly XENIX (SYS III)
as soon as I lay my hands on it as those are what I run.

bill gunshannon


UUCP: {philabs}\		 	US SNAIL: Martin Marietta Data Systems 
      {phri   } >!trotter.usma.edu!bill           USMA, Bldg 600, Room 26 
      {sunybcs}/			          West Point, NY  10996	     
RADIO:         KB3YV		        PHONE: WORK    (914)446-7747
AX.25:         KB3YV @ K3RLI	        PHONE: HOME    (914)565-5256

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 87 13:24:00 GMT
From:      holt@inco.UUCP (Mark Holt)
To:        comp.protocols.tcp-ip
Subject:   KA9Q TCP/IP on VMS 4.2

[In answer to Mark Eggers' questions]

> Could you send me more information ?? 
Yes.

> What language, 
C.

> how much CPU does it use (on average), 
I haven't checked into this yet.  We're running under VMS 4.2 and
it run as one *big* task.  CPU cycles aren't a big deal, memory
might be on some systems. 

> can you run DECnet at the
> same time ?
Yes, DECnet, ARP, and IP each have unique Ethernet protocol types.

> 
> More importantly, can you either give me a list of mods or
> make the code available ?
Eventually, I plan to send the changes to Bdale Garbee at 
winfree.n3eua.ampr.  I still have some work to do, though.

> We are just starting out with our campus TCP/IP network, and
> the Ultrix - DECnet gateway running on a microVAX has some
> problems with ACCESS/MVS running on an IBM 3033. Running
> your code on the VAXes would sure make life simpler.
As noted above, we're using VMS, and my changes to the KA9Q package
were *very* VMS specific, so I'm not sure we can help.

> Thanks
> for any information,
You are welcome.

> 
>        Mark Eggers, Network Communications Analyst
>                     Computing Center, University of Notre Dame

/*--------------------------------------------------------------*
*  Mark L Holt                                                  * 
*  McDonnell Douglas - Inco, Inc.      800-DOT-INCO             *
*  ...!seismo!sundc!hadron!inco!holt                            *
*  "If you ain't the lead dog, the scenery never changes"       *
*  DISCLAIMER: The opinions expressed are my own and in no way  *
*  reflect the views of McDonnell Douglas or its subsidiaries.  *
*--------------------------------------------------------------*/

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 87 15:06:24 GMT
From:      radia@XX.LCS.MIT.EDU (Radia Perlman)
To:        comp.protocols.tcp-ip
Subject:   Re: Routers vs. Bridges (CORRECTION)

Just a clarification -- bridges don't HAVE to forward multicasts (broadcasts)
in order to be a bridge.  The Vitalink and DEC bridges have the capability
to manually set certain multicast addresses as "don't forward".  This
is very important for various reasons.  The default is "forward", but
some finite number (large enough for all practical purposes, I claim)
of multicast addresses can be manually configured to be localized, i.e.
not forwarded by the bridge.

Once people agree on what a bridge vs a router is, I'd summarize the
tradeoffs as:
  1) bridges don't require a standard layer 3 (win for bridges unless
     suddenly layer 3 standards crystallized and universalized)
  2) routers can do much fancier stuff because of the extra layer
     of header and explicit cooperation from the stations, like
     utilizing better routes, or utilizing hierarchical addresses
  3) even if layer 3 standards crystallized, a mixture of bridges and
     routers might be desirable because it gives an extra level
     of hierarchy "for free".  In other words, it might be efficient
     to clump LANs into big LANs, and then the layer 3 protocol
     doesn't have to trouble itself with the inner topology of
     the bridged extended LANs.

Radia
-------

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 87 15:59:23 GMT
From:      hoffmann@BITSY.MIT.EDU (Ron M. Hoffmann)
To:        comp.protocols.tcp-ip
Subject:   multiple DEQNAs in microvaxen

The DEQNA manual goes as far as to state that more than one in a
Microvax-II could exceed the FCC specified RF emission levels.

-Ron

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 87 19:01:09 GMT
From:      paulf@umunhum.STANFORD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Ethers, Copper, Fiber, Microwaves, Etc.

In article <8712101810.AA00864@PTT.LCS.MIT.EDU> dab@ALLSPICE.LCS.MIT.EDU writes:
>	In the ham radio community for several years there have been
>devices called Gunnplexers available (I don't know if that's a brand
>name or a generic name) which are a 10 GHz microwave system for about
>$200.  When they first showed up there were several articles in ham
>radio magazines descibing how to send video through them, so 10 Mb/sec
>is probably not too far out of line.  Except for maybe the feedhorn
>(or the dish itself) it would easily fit into a briefcase.  The range
>is limited but I think to line of sight rather than 1 mile.
>						Dave Bridgham

	The biggest problem with using GunnPlexers (TM) for digital 
communications is their lack of linearity.  GunnPlexers have both phase and
amplitude distortion, and have some real temperature - frequency dependence
problems.

	Despite this, by using FSK or MSK combined with some equalization, one
can make an incredibly cheap digital link.  We're currently working on a modem
that uses temperature stabilized GunnPlexers, and MSK with some simple 
adaptive equalization, to be used by the 230.4kbps AppleTalk protocol.

	Look for the article in the March '88 issue of _MacWorld_.



-=Paul Flaherty, N9FZX		 | "The only thing that we've learned from
Computer Systems Laboratory	 |history is that we havn't learned anything
Stanford University		 |from history..."
Domain: paulf@shasta.Stanford.EDU|		-- William Jennings Bryant

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 87 19:25:29 GMT
From:      mminnich@UDEL.EDU (Mike Minnich)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP discussion at the Interoperability Conference

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

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 87 22:13:59 GMT
From:      dnwcv@dcatla.UUCP (William C. VerSteeg)
To:        comp.protocols.tcp-ip
Subject:   More than one IP (sub)network on one ethernet cable


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

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 87 22:46:58 GMT
From:      mcs@MONK.PROTEON.COM (Mick Scully)
To:        comp.protocols.tcp-ip
Subject:   Proteon Routers..

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

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 87 00:09:33 GMT
From:      berner@apple.UUCP (William Berner)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Using Kinetics boxes an an etherbridge

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

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 87 04:03:29 GMT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   Re:  Vitalink Bridges..

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)

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 87 05:59:44 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: IP protocol on a chip(s)

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

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 87 07:25:15 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re:  beginners guide to ... ?


			(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

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 87 18:55:45 GMT
From:      rhorn@infinet.UUCP (Rob Horn)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethers, Copper, Fiber, Microwaves, Etc.

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)

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 87 21:03:45 GMT
From:      karels@OKEEFFE.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: micro-vax with more than one ether-net board?

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

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 87 08:01:09 GMT
From:      davew@gvgpsa.UUCP (David C. White)
To:        comp.protocols.tcp-ip
Subject:   Re: Vitalink Bridges..

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

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 87 13:33:21 GMT
From:      daveb@geac.UUCP (David Collier-Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: IP protocol on a chip(s)

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.

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 87 16:42:41 GMT
From:      tektronix!dennist@ucbvax.Berkeley.EDU  (Dennis Thomas)
To:        tcp-ip@sri-nic.arpa
Subject:   AT&T ISN

	I am interested in contacting or receiving input from any one
that has experience in using AT&T's ISN product in a networking environment.
The environment to be considered is a single communications link, connected
by 2 ISN's concentrating Ethernet (TCP/IP, DECNET, LAT), IBM 3274, IBM 3270
and DECNET synchronous traffic.

	Some of the concerns relate to the effect of file transfer
rates for TCP/IP and DECNET when the other traffic is active. Since
the ISN moves data in small packets (180bits) with an 8.64 Mb transmit and
receive bus, it would seem that large TCP/IP or DECNET packets (file transfer)
would suffer at the expense of terminal activity.

	Thank you in advance for your input.

Dennis Thomas
Tektronix, Inc.
dennist@tektronix.TEK.COM
(503) 627-5030
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 87 17:37:10 GMT
From:      mac@MONK.PROTEON.COM (Michael A. Curtis)
To:        comp.protocols.tcp-ip
Subject:   Proteon Routers..

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.

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 87 18:13:17 GMT
From:      don@SRI-LEWIS.ARPA (Donald Holman)
To:        comp.protocols.tcp-ip
Subject:   Final comments, Rabid Bite.


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

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 87 02:02:58 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Determining gateway buffer capacity

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.)

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 87 04:35:20 GMT
From:      alison@TCGOULD.TN.CORNELL.EDU (Alison Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: IP protocol on a chip(s)

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.....

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 87 06:31:27 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: Determining gateway buffer capacity


    [ 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

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 87 06:52:11 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: beginners guide to ... ?

My apologies for being ambiguous -- apparently I left some people in
doubt.  The new Comer book is unrelated to the Xinu series...

-Philip

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 87 07:26:08 GMT
From:      parulkar@UDEL.EDU (Gurudatta Parulkar)
To:        comp.protocols.tcp-ip
Subject:   Re: beginners guide to ... ?


    			(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

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 87 07:30:52 GMT
From:      oconnor@SCCGATE.SCC.COM (Michael J. O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Suspected problem with new end-to-end


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

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Dec 87 15:05:31 EST
From:      oconnor@sccgate.scc.com (Michael J. O'Connor)
To:        tcp-ip@sri-nic.arpa
Cc:        arpaupgrade@bbn.com, brescia@bbn.com, enger@bluto.scc.com
Subject:   Further info on our X.25 problem
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

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 87 17:12:00 EST
From:      "GBURG::ENGER" <enger%gburg.decnet@bluto.scc.com>
To:        "malis" <malis@cc5.bbn.com>
Cc:        oconnor@sccgate,melohn@sun.com, nowicki@sun.com,arpaupgrade@cc5.bbn.com, tcp-ip@sri-nic.arpa,enger
Subject:   rooting around down in the x.25
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

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 87 13:41:20 GMT
From:      verber@tut.cis.ohio-state.edu (Mark A. Verber)
To:        comp.protocols.tcp-ip
Subject:   Re:  beginners guide to ... ?


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

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Dec 87 19:01:04 EST
From:      Ken Pogran <pogran@ccq.bbn.com>
To:        TCP-IP@sri-nic.arpa
Cc:        pogran@ccq.bbn.com
Subject:   An ARPANET update
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
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 87 19:36:54 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Timewarps, virtual-cirkosis and other twitches

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

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 87 00:38:00 EST
From:      "GBURG::ENGER" <enger%gburg.decnet@bluto.scc.com>
To:        "ietf" <ietf@gateway.mitre.org>
Cc:        tcp-ip@sri-nic.arpa,abauman@ddn1.arpa, gross@gateway.mitre.org,enger
Subject:   ****  Medical Assistance Needed for Core Gateways  ****
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)



-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 87 19:52:58 GMT
From:      alan@cunixc.columbia.edu (Alan Crosswell)
To:        comp.protocols.tcp-ip
Subject:   Re: beginners guide to ... ?

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

  

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 87 22:12:00 GMT
From:      enger%gburg.DECnet@BLUTO.SCC.COM ("GBURG::ENGER")
To:        comp.protocols.tcp-ip
Subject:   rooting around down in the x.25

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

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 87 00:01:04 GMT
From:      pogran@CCQ.BBN.COM (Ken Pogran)
To:        comp.protocols.tcp-ip
Subject:   An ARPANET update

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

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 87 01:56:10 GMT
From:      brian@sdcsvax.UCSD.EDU (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Host as gateway - some advice needed on naming

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

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 87 05:08:07 GMT
From:      jbvb@ftp.UUCP (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Bridge IP routers & fragmentation - correction.

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

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 87 05:38:00 GMT
From:      enger%gburg.DECnet@BLUTO.SCC.COM ("GBURG::ENGER")
To:        comp.protocols.tcp-ip
Subject:   ****  Medical Assistance Needed for Core Gateways  ****

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)

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 87 11:48:47 GMT
From:      sjc@cs.purdue.EDU (Steve Chapin)
To:        comp.protocols.tcp-ip
Subject:   Re: beginners guide to ... ?

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.
---------------------------------------------------------------------------

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 87 12:20:01 GMT
From:      bill@trotter.usma.edu (Bill Gunshannon)
To:        rec.ham-radio.packet,comp.protocols.tcp-ip
Subject:   Re: NEEDED: KISS for TNC220


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

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Dec 87 21:48:44 -0500
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
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.
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
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 87 16:15:36 GMT
From:      garrett@udel.EDU (Joel Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: beginners guide to ... ?

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

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 87 17:01:50 GMT
From:      mcdermot@merlin.unm.edu (John McDermott)
To:        comp.protocols.tcp-ip
Subject:   SLIP for CMU/TEK package?

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

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 87 18:07:54 GMT
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: beginners guide to ... ?

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.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 87 23:31:25 GMT
From:      jrozbori@udenva.cair.du.edu (Jim Rozboril)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   CMU's TCP/IP V6.2

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

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 87 01:21:37 GMT
From:      schen@caip.rutgers.edu (Shin Chen)
To:        comp.protocols.misc,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   What is the procedure to simulate the limits of protocols?


	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

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 87 01:27:42 GMT
From:      karn@faline.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Timewarps, virtual-cirkosis and other twitches

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

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 87 01:57:36 GMT
From:      oconnor@SCCGATE.SCC.COM (Michael J. O'Connor)
To:        comp.protocols.tcp-ip
Subject:   re: PSN patch installed

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.

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Dec 87 10:06:58 EST
From:      oconnor@sccgate.scc.com (Michael J. O'Connor)
To:        karn@faline.bellcore.com, tcp-ip@sri-nic.arpa
Subject:   Re: Timewarps, virtual-cirkosis and other twitches
I second the motion!
-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 87 05:23:06 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   missing nets between Europe and U.S.

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

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Dec 87 13:34:40 EST
From:      "Drew M. Powles" <dpowles@ccd.bbn.com>
To:        tcp-ip@sri-nic.arpa
Cc:        dpowles@ccd.bbn.com
Subject:   security option
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

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 87 16:19:12 GMT
From:      DUNLAP@OSU-20 (Bryan Dunlap)
To:        comp.protocols.tcp-ip
Subject:   tn3270 for Tops-20

Does anyone know of an implementation of tn3270 for Tops-20?

	==BD
	dunlap%osu-20@ohio-state.arpa
-------

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 87 17:12:35 GMT
From:      jpt@UMN-REI-UC.ARPA (Joseph P. Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP for CMU/TEK package?


	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 )

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 87 18:34:40 GMT
From:      dpowles@CCD.BBN.COM ("Drew M. Powles")
To:        comp.protocols.tcp-ip
Subject:   security option

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

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 87 18:47:37 GMT
From:      karn@faline.bellcore.com (Phil R. Karn)
To:        rec.ham-radio.packet,comp.protocols.tcp-ip
Subject:   Re: NEEDED: KISS for TNC220

> 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

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 87 09:16:00 PST
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   RE: bridges vs routers

>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

------
-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 87 02:40:52 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: beginners guide to ... ?

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

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 87 04:03:36 GMT
From:      n2dsy@hou2d.UUCP (G.BEATTIE)
To:        comp.protocols.tcp-ip
Subject:   X.25 Implementation vs Protocol

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)

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 87 04:43:33 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: More than one IP (sub)network on one ethernet cable

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

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Dec 87 10:14:44 EST
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        enger%gburg.decnet@bluto.scc.com, ietf@gateway.mitre.org
Cc:        abauman@ddn1.arpa, enger@bluto.scc.com, gross@gateway.mitre.org, tcp-ip@sri-nic.arpa
Subject:   Re:  ****  Medical Assistance Needed for Core Gateways  ****
Ho, Ho, Ho!

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Dec 1987 11:11:54 LCL
From:      John M Wobus <JMWOBUS@suvm.acs.syr.edu>
To:        TCP-IP Discussion Group <TCP-IP@SRI-NIC.ARPA>
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

-----------

<BIG-LAN@SUVM.ACS.SYR.EDU>               (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 <JMWOBUS@SUVM.ACS.SYR.EDU>
                           <JMWOBUS@SUVM>
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 87 06:58:23 GMT
From:      root@vijit.UUCP
To:        comp.protocols.tcp-ip
Subject:   tcp/ip books

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

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 87 08:19:19 GMT
From:      HANK@BARILVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Routers vs bridges revisited

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.

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 87 09:37:00 GMT
From:      srg@quick.COM (Spencer Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: Routers vs. Bridges


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.

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Dec 87 17:46:04 EST
From:      oconnor@sccgate.scc.com (Michael J. O'Connor)
To:        TCP-IP@sri-nic.arpa, pogran@ccq.bbn.com
Cc:        arpaupgrade@bbn.com
Subject:   Re:  An ARPANET update
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
-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Dec 87 11:19:19 P
From:      Hank Nussbacher <HANK%BARILVM.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.ARPA
Subject:   Routers vs bridges revisited
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.

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Dec 87 21:19:22 CST
From:      slevy@umn-rei-uc.arpa (Stuart Levy)
To:        JBVB@ai.ai.mit.edu, dcatla!dnwcv@gatech.edu
Cc:        big-lan@suvm.acs.syr.edu, tcp-ip@sri-nic.arpa
Subject:   Re: More than one IP (sub)network on one ethernet cable
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
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 87 17:16:00 GMT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   RE: bridges vs routers


>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

------

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 87 19:55:12 GMT
From:      dnwcv@dcatla.UUCP (William C. VerSteeg)
To:        comp.protocols.tcp-ip
Subject:   Re: More than one IP (sub)network on one ethernet cable


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

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 87 19:58:03 GMT
From:      daveb@rtech.UUCP (Dave Brower)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   OOB problems, wisdom anyone?

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

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 87 19:59:11 GMT
From:      Stevens@A.ISI.EDU (Jim Stevens)
To:        comp.protocols.tcp-ip
Subject:   Much More Idle Chatter About Reference Models



                  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    |
                  |               |
                  +---------------+


----------------------------------------------------------------------------
-------

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 87 21:25:44 GMT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   TCP on the MAC


	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

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 87 23:07:33 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Routers vs. Bridges

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

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 87 00:47:57 GMT
From:      SATZ@MATHOM.CISCO.COM (Greg Satz)
To:        comp.protocols.tcp-ip
Subject:   Re: An ARPANET update


    From: Ken Pogran <pogran@ccq.bbn.com>
    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?
-------

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 87 00:48:45 GMT
From:      ucdla@VIOLET.BERKELEY.EDU (U.C. Div of Library Automation)
To:        comp.protocols.tcp-ip
Subject:   tcp ip mailing list

is there something wrong with the tcp mailing list. i havent gotten anything
from it in 3 weeks?

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 87 06:10:20 GMT
From:      karn@faline.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Much More Idle Chatter About Reference Models

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

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 87 06:18:06 GMT
From:      david@ms.uky.edu (David Herron -- Resident E-mail Hack)
To:        comp.protocols.tcp-ip
Subject:   Re: IP protocol on a chip(s)

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            <david@ms.uky.edu>
<---- or:                {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<----
<---- Winter health warning:  Remember, don't eat the yellow snow!

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Dec 87 15:40:45 -0500
From:      Andy Malis <malis@CC5.BBN.COM>
To:        "Michael J. O'Connor" <oconnor@SCCGATE.SCC.COM>
Cc:        TCP-IP@SRI-NIC.ARPA, pogran@CCQ.BBN.COM, arpaupgrade@BBN.COM, malis@CC5.BBN.COM
Subject:   Re: An ARPANET update
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

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 87 18:29:24 GMT
From:      tsuchiya@gateway.mitre.ORG (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   Re: More than one IP (sub)network on one ethernet cable

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
_________________________________________________________________

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 87 19:37:23 GMT
From:      Stevens@A.ISI.EDU (Jim Stevens)
To:        comp.protocols.tcp-ip
Subject:   RE: Re: Much More Idle Chatter About Reference Models


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.

-------

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 87 20:40:45 GMT
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: An ARPANET update

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

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 87 22:22:00 GMT
From:      slevy@UMN-REI-UC.ARPA (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re: More than one IP (sub)network on one ethernet cable

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

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 87 01:46:04 GMT
From:      martillo@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   More than one IP (sub)network on one ethernet cable


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

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 87 02:30:49 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   RE: Re: Much More Idle Chatter About Reference Models

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

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 87 02:54:03 GMT
From:      nelson@CLUTX.CLARKSON.EDU (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   A,B,C-class vs subnetting

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

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Dec 87  13:04:25 EST
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
To:        tsuchiya@gateway.mitre.org
Cc:        TCP-IP@SRI-NIC.ARPA
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.
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Dec 87 16:55:32 -0500
From:      Andy Malis <malis@CC5.BBN.COM>
To:        "Michael J. O'Connor" <oconnor@SCCGATE.SCC.COM>
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
Mike,

Thanks for the additional info.  Are there any dates or version
IDs available for your and Hilarie's Sun X.25 packages?

Andy
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Dec 87 15:45:21 EST
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        TCP/IP List <TCP-IP@SRI-NIC.ARPA>
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" <JBVB@AI.AI.MIT.EDU>

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 <ROMKEY@XX.LCS.MIT.EDU>

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
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 87 18:04:25 GMT
From:      RAF@NIHCU.BITNET ("Roger Fajman")
To:        comp.protocols.tcp-ip
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.

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 87 20:23:32 GMT
From:      oconnor@SCCGATE.SCC.COM (Michael J. O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Re: An ARPANET update

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

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 87 20:45:21 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
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" <JBVB@AI.AI.MIT.EDU>

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 <ROMKEY@XX.LCS.MIT.EDU>

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

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 87 21:55:32 GMT
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: An ARPANET update

Mike,

Thanks for the additional info.  Are there any dates or version
IDs available for your and Hilarie's Sun X.25 packages?

Andy

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Dec 87 9:06:50 EST
From:      Alex McKenzie <mckenzie@LABS-N.BBN.COM>
To:        Paul Tsuchiya <tsuchiya@GATEWAY.MITRE.ORG>
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
 
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Dec 87 15:03:04 PST
From:      jkrey@venera.isi.edu
To:        dpowles@ccd.bbn.com
Cc:        jkrey@venera.isi.edu, tcp-ip@sri-nic.arpa
Subject:   re: security option
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

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Dec 87 16:09:20 PST
From:      gary@ACC-SB-UNIX.ARPA (Gary Krall)
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.

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 87 09:22:56 GMT
From:      karn@faline.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Response to Long Distance NFS Query

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

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 87 11:38:51 GMT
From:      trw@hrc63.co.uk (Trevor Wright Marconi Baddow)
To:        comp.protocols.tcp-ip
Subject:   Cheap TCP/IP access to IBM/Amdahl's


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

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Dec 87 22:12:22 -0500
From:      Andy Malis <malis@CC5.BBN.COM>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        malis@CC5.BBN.COM
Subject:   Any Cisco gateways on the ARPANET?
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
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 87 14:06:50 GMT
From:      mckenzie@LABS-N.BBN.COM (Alex McKenzie)
To:        comp.protocols.tcp-ip
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
 

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 87 17:15:40 GMT
From:      eshop@saturn.ucsc.edu (Jim Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: Response to Long Distance NFS Query

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

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 87 17:26:54 GMT
From:      mar@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   More than one IP (sub)network on one ethernet cable

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

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 87 17:28:46 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: OOB problems, wisdom anyone?

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.

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 87 18:20:49 GMT
From:      gary@ACC-SB-UNIX.ARPA (Gary Krall)
To:        comp.protocols.tcp-ip
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.

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 87 18:26:29 GMT
From:      slevy@UMN-REI-UC.ARPA (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re:  More than one IP (sub)network on one ethernet cable

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.

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 87 23:00:53 GMT
From:      wunder@HPCEA.CE.HP.COM (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   Re: A,B,C-class vs subnetting

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

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 87 23:03:55 GMT
From:      anido@otc.oz (Gary Anido)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   FDDI interfaces and bridges : summary


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            

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 87 23:05:57 GMT
From:      wencu@cunyvm.bitnet
To:        tcp-ip@sri-nic.arpa
Subject:   ftp problems
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
     
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 87 00:38:59 GMT
From:      haas%gr@CS.UTAH.EDU (Walt Haas)
To:        comp.protocols.tcp-ip
Subject:   Fibronics TCP/IP/Ethernet for IBM mainframe

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

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 87 03:12:22 GMT
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Any Cisco gateways on the ARPANET?

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

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 87 04:42:56 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: More than one IP (sub)network on one ethernet cable

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

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Dec 87 10:53:00 CST
From:      "Paul Lustgraaf" <GR.PJL%ISUMVS.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
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

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 1987 11:35-EST
From:      CERF@A.ISI.EDU
To:        JBVB@AI.AI.MIT.EDU
Cc:        amdahl!rtech!daveb@AMES.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: OOB problems, wisdom anyone?

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
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 87 07:01:57 GMT
From:      melohn@SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: Response to Long Distance NFS Query

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.

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 87 13:04:35
From:      Leonard D Woren <LDW@MVSA.USC.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  Fibronics TCP/IP/Ethernet for IBM mainframe
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

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 87 13:00:35 GMT
From:      jch@DEVVAX.TN.CORNELL.EDU (Jeffrey C Honig)
To:        comp.protocols.tcp-ip
Subject:   Re: Fibronics TCP/IP/Ethernet for IBM mainframe

>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

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 87 15:26:59 GMT
From:      neerma@COD.NOSC.MIL (Merle A. Neer)
To:        comp.protocols.tcp-ip
Subject:   PC/AT UNIX TCP/IP software development


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.
-------
-------

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 87 16:18:40 GMT
From:      tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   Re: More than one IP (sub)network on one ethernet cable

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
_________________________________________________________________

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 87 16:26:47 GMT
From:      louie@TRANTOR.UMD.EDU ("Louis A. Mamakos")
To:        comp.protocols.tcp-ip
Subject:   Re: Fibronics TCP/IP/Ethernet for IBM mainframe

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

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 87 16:35:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: OOB problems, wisdom anyone?


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

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 87 16:53:00 GMT
From:      GR.PJL@ISUMVS.BITNET ("Paul Lustgraaf")
To:        comp.protocols.tcp-ip
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

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 87 16:55:43 GMT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   Re:  ftp problems

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

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 87 20:39:32 GMT
From:      karn@faline.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Response to Long Distance NFS Query

> 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

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 87 21:04:35 GMT
From:      LDW@MVSA.USC.EDU (Leonard D Woren)
To:        comp.protocols.tcp-ip
Subject:   Re:  Fibronics TCP/IP/Ethernet for IBM mainframe

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

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 87 21:14:20 GMT
From:      tom@tsdiag.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Timewarps, virtual-cirkosis and other twitches


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

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 00:36:15 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: OOB problems, wisdom anyone?


    ..... 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

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 00:49:47 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: More than one IP (sub)network on one ethernet cable

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

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 01:35:05 GMT
From:      smb@ulysses.homer.nj.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: security option

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.

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Dec 87 11:14:19 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   what a checksum is for

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
-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 03:43:12 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   NBS station WWV problems

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

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Dec 87 09:21 EST
From:      Joe Ragland <TUCJRR@TUCC.TUCC.EDU>
To:        tcp-ip@sri-nic.arpa
Cc:        Joe Ragland <TUCJRR@TUCC.TUCC.EDU>
Subject:   ACC TCP/IP for IBM MVS systems
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.

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 04:35:00 GMT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   Response to Long Distance NFS Query


    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

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Dec 87 22:44-0800
From:      The Mail Server<Postmaster@locke.BITNET>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Undeliverable mail
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)" <TCPIP-L@BYUADMIN>
To: "(no name)" <BRUCE@UWALOCKE>
Reply-to: <TCP-IP@SRI-NIC.ARPA>
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
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Dec 87 14:28:29 EST
From:      Ken Pogran <pogran@ccq.bbn.com>
To:        "Michael J. O'Connor" <oconnor@sccgate.scc.com>
Cc:        arpaupgrade@bbn.com, ho@tis.arpa, malis@bbn.com, melohn@sun.com, tcp-ip@sri-nic.arpa
Subject:   Re: Was "The Patch" removed?
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
-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Dec 87 15:46:49 EST
From:      Ken Pogran <pogran@ccq.bbn.com>
To:        TCP-IP@sri-nic.arpa
Cc:        arpaupgrade@bbn.com
Subject:   Santa's PSN 7 status
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
-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 10:55:04 GMT
From:      ejnorman%dogie@UNIX2.MACC.WISC.EDU (Eric Norman)
To:        comp.protocols.tcp-ip
Subject:   Re: More that one IP (sub)network on one cable.

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 <ejnorman@unix2.macc.wisc.edu>

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 12:47:20 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re:  NBS station WWV problems

As a last resort, we can also try the calendar.  They haven't changed
for a few centuries :-)

dennis

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 13:09:59 GMT
From:      khan@nvpna1.UUCP (Osman Khan  42779)
To:        comp.protocols.tcp-ip
Subject:   Remote Job Entry Procedures


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

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 13:14:42 GMT
From:      khan@nvpna1.UUCP (Osman Khan  42779)
To:        comp.protocols.tcp-ip
Subject:   Secure IP Routers


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

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 13:18:07 GMT
From:      khan@nvpna1.UUCP (Osman Khan  42779)
To:        comp.protocols.tcp-ip
Subject:   Portable Bulletin Board (like READNEWS)


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

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 14:21:00 GMT
From:      TUCJRR@TUCC.TUCC.EDU (Joe Ragland)
To:        comp.protocols.tcp-ip
Subject:   ACC TCP/IP for IBM MVS systems

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.

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 15:36:34 GMT
From:      jas@MONK.PROTEON.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   Subnets connected by a gateway not part of the subnetted network

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. 

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 16:14:19 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   what a checksum is for


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

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 16:40:22 GMT
From:      oconnor@SCCGATE.SCC.COM (Michael J. O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Was "The Patch" removed?

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.

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 19:28:29 GMT
From:      pogran@CCQ.BBN.COM (Ken Pogran)
To:        comp.protocols.tcp-ip
Subject:   Re: Was "The Patch" removed?

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

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Dec 87  4:46 PST
From:      Leonard D Woren <LDW@MVSA.USC.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Cheap TCP/IP access to IBM/Amdahl's
> 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  <LDW@USCMVSA.BITNET>, <LDW@MVSA.USC.EDU>

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 20:46:49 GMT
From:      pogran@CCQ.BBN.COM (Ken Pogran)
To:        comp.protocols.tcp-ip
Subject:   Santa's PSN 7 status

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

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 87 20:53:38 GMT
From:      gary@ACC-SB-UNIX.ARPA (Gary Krall)
To:        comp.protocols.tcp-ip
Subject:   Objectivity

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.

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 87 00:27:25 GMT
From:      Eugene.Hastings@MORGUL.PSC.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: 5250 and VCs

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

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 87 01:16:05 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Further to the WWV problem

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

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 87 02:01:59 GMT
From:      oconnor@SCCGATE.SCC.COM (Michael J. O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Re: Was "The Patch" removed?

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

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 87 04:19:15 GMT
From:      ari@riacs.EDU (Ari Ollikainen)
To:        comp.protocols.tcp-ip
Subject:   End-to-End Checksums

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!

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 87 12:46:00 GMT
From:      LDW@MVSA.USC.EDU (Leonard D Woren)
To:        comp.protocols.tcp-ip
Subject:   Re: Cheap TCP/IP access to IBM/Amdahl's

> 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  <LDW@USCMVSA.BITNET>, <LDW@MVSA.USC.EDU>

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 87 15:03:20 GMT
From:      ELINSKY@IBM.COM (Jay Elinsky)
To:        comp.protocols.tcp-ip
Subject:   IBM 8232

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

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 87 16:46:01 GMT
From:      peter@julian.UWO.CDN (Peter Marshall)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip books

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

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 87 17:11:04 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   WWV update

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

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 87 18:14:23 GMT
From:      louie@TRANTOR.UMD.EDU ("Louis A. Mamakos")
To:        comp.protocols.tcp-ip
Subject:   Re: WWV update

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

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      25 Dec 87 02:55:32 GMT
From:      johnl@well.UUCP (John A. Limpert)
To:        comp.protocols.tcp-ip
Subject:   Re: PC/AT UNIX TCP/IP software development

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

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      25 Dec 87 05:10:04 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  WWV update

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

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      25 Dec 87 07:02:12 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Response to Long Distance NFS Query

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.

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      25 Dec 87 20:53:04 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Response to Long Distance NFS Query

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
-------

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 87 02:05:13 GMT
From:      hassler@wrtfac.UUCP (Barry D. Hassler)
To:        comp.protocols.tcp-ip
Subject:   IP class B and C to X.25 address translation


        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

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 87 23:49:32 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Response to Long Distance NFS Query

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

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 87 01:02:30 GMT
From:      dpk@bway.UUCP (Doug Kingston)
To:        comp.protocols.tcp-ip
Subject:   Re:  Remote Job Entry Procedures

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-

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 1987 16:53-EST
From:      CERF@A.ISI.EDU
To:        clyde!watmath!julian!peter@RUTGERS.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: tcp/ip books
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
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 87 17:08:44 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Tocking clocks

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

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 87 17:51:22 GMT
From:      wayne@ultra.UUCP (Wayne Hathaway)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote Job Entry Procedures

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

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 87 21:53:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip books

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

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 87 04:32:06 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Leaping clocks

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

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 1987 17:49-PST
From:      Mike StJohns <StJohns@SRI-NIC.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: UVax Ultrix Blues
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
-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 87 15:38:00 GMT
From:      DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Naming schemes


    Date:      Tue, 22 Dec 87 10:53:00 CST
    From:      "Paul Lustgraaf" <GR.PJL%ISUMVS.BITNET@CUNYVM.CUNY.EDU>

    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.

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 87 22:35:56 GMT
From:      STJOHNS@SRI-NIC.ARPA (Michael St. Johns)
To:        comp.protocols.tcp-ip
Subject:   UVax ULTRIX Blues

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
-------

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 1987 08:10-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        W8SDZ@SIMTEL20.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: UVax Ultrix Blues also Pyramid-98xe Blues
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
. 
-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 87 01:49:00 GMT
From:      StJohns@SRI-NIC.ARPA (Mike StJohns)
To:        comp.protocols.tcp-ip
Subject:   Re: UVax Ultrix Blues

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

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 87 02:49:04 GMT
From:      medin@AMES-TITAN.ARPA (Milo S. Medin, NASA ARC Code ED)
To:        comp.protocols.tcp-ip
Subject:   Re: UVax Ultrix Blues


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

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 87 04:01:10 GMT
From:      louie@TRANTOR.UMD.EDU ("Louis A. Mamakos")
To:        comp.protocols.tcp-ip
Subject:   Re: UVax Ultrix Blues

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

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 87 06:00:00 GMT
From:      W8SDZ@SIMTEL20.ARPA (Keith Petersen)
To:        comp.protocols.tcp-ip
Subject:   UVax Ultrix Blues also Pyramid-98xe Blues

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

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 87 16:10:00 GMT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: UVax Ultrix Blues also Pyramid-98xe Blues

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
. 

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 87 17:24:00 GMT
From:      scottr@csc-lons.csv001.tv.ARPA (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   TCP/SMTP ULTRIX <-> MULTICS PROBLEM


 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: <username.mailbox.qualification.etc>' 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
----

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 87 17:56:00 GMT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   TCP/SMTP ULTRIX <-> MULTICS PROBLEM


    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.

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 87 19:38:00 GMT
From:      medin@AMES-TITAN.ARPA (Milo S. Medin, NASA ARC Code ED)
To:        comp.protocols.tcp-ip
Subject:   Re: UVax Ultrix Blues


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

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 87 20:15:31 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Leaping clocks


	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
     -------------------------------------------------------------------
     

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 87 20:35:14 GMT
From:      ad2@j.cc.purdue.edu (Bill Bormann)
To:        comp.org.decus,comp.protocols.tcp-ip,comp.sys.dec
Subject:   Need TCP/IP on RSTS/E

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

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 87 22:17:56 GMT
From:      nomad@mist.cs.orst.edu (Lee Vincent Damon)
To:        comp.protocols.tcp-ip
Subject:   Subnetting and 0 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!"

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 87 05:44:21 GMT
From:      PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: Cheap TCP/IP access to IBM/Amdahl's

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

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 Dec 87 14:49:04 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@sri-nic.ARPA
Subject:   ICMP type #7?

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
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 Dec 87 18:41
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@NSS.Cs.Ucl.AC.UK>
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>
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
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 87 15:05:16 GMT
From:      gross@GATEWAY.MITRE.ORG (Phill Gross)
To:        comp.protocols.tcp-ip
Subject:   Re: Leaping clocks

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

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 87 15:27:53 GMT
From:      gross@GATEWAY.MITRE.ORG (Phill Gross)
To:        comp.protocols.tcp-ip
Subject:   Re: Leaping Clocks


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

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31-Dec-87 20:46:18 EDT
From:      tomlin@hc.DSPO.GOV (Bob Tomlinson)
To:        comp.protocols.tcp-ip
Subject:   Re:  DELUA interface driver needed

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

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 87 17:14:00 GMT
From:      Ata@RADC-MULTICS.ARPA ("John G. Ata")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/SMTP ULTRIX <-> MULTICS PROBLEM


    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: <username.mailbox.qualification.etc>' 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

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 87 17:35:29 GMT
From:      schoff@NISC.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: Leaping Clocks


    
    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

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 87 19:49:04 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   ICMP type #7?


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

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 87 20:07:26 GMT
From:      timk@NCSA.UIUC.EDU (Tim Krauskopf)
To:        comp.protocols.tcp-ip
Subject:   EtherTalk broadcast invasion


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

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 87 21:45:01 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Leaping Clocks

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

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 87 22:21:37 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP type #7?

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

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 87 22:22:50 GMT
From:      moshe@ihnet.ATT.COM (Moshe Yudkowsky)
To:        comp.protocols.tcp-ip
Subject:   300 Megabit/second national network?


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'!

END OF DOCUMENT