The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 88 03:01:35 GMT
From:      jra@jc3b21.UUCP (Jay R. Ashworth)
To:        rec.ham-radio.packet,comp.protocols.tcp-ip
Subject:   SLIP Info please?

Can anybody email me more details about SLIP (Serial Link Internet
Protocol)?  I am interested in the possibility of supporting multiple
telnet type login sessions on one physical radio channel, using a
standard, albeit high speed (38.4Kb?) serial line between TNC and
computer.

Does KA9Q do this?  Are other possible sources PD?  I need to have
source code available.  I (read: my employer) would be interested in
discussing commercial licensing at some future point.  For now,
though, folks, I'd just like to know what I'm talking about.

Can you help?

Email ONLY, please.  The .sig path should work just fine.

Tnx,
-- jra
KA1FJX
-- 
Jay R. Ashworth ---+-- Suncoast Television Productions--+ ...!uunet!codas!
10974 111th St. N. |   producers of Suncoast Magazine   |  !usfvax2!jc3b21!jra
Seminole FL 34648  +------------------------------------------------+---------
(813) 397-1859 ----+-- Premiering on Vision Cable Ch. 24 in July ---+ :-) !$

Robert Heinlein, 1901-1988, alas, not as long-lived as Lazarus Long.  R. I. P.

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 88 06:54:36 GMT
From:      per@erix.UUCP (Per Hedeland)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Subnetting


While it may be a bit late, I thought I should post a short summary of the
information I got in response to my query a few weeks back - it did generate
some discussion, after all. If you recall, the issue was how to use subnetting
on a network structure with a big backbone net and many small ones hanging
off of it. I think the below is the essence of what I found out; I also have
a pile of mail for those particularly interested.

- Unequal-sized subnets, whether or not a Good Thing, is not currently
  implemented in any generally accepted way (and thus of little interest to
  us).

- Partitioned subnets (i.e. subnets of a given net interconnected only by some
  other net) are out.

- One can have several logical subnets on the same wire (i.e. the backbone in
  our case), thus effectively increasing the address space, at the expense of
  some manual "routing" (i.e. gateways have to be explicitly told that the
  different subnets can be accessed via the same interface - hosts on such
  a wire can be "fooled" into believing that it's all one (bigger) subnet).

We will probably go for the latter method, with a long-term goal of splitting
our backbone by using dedicated routers.

Thanks to all who offered help and advice!
---Per Hedeland

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 88 07:09:14 GMT
From:      tmanos@aocgl.UUCP (Theodore W. Manos)
To:        comp.protocols.tcp-ip
Subject:   Re: non-*NIX implementations

Ya Mike, what are you looking for?  VM/CMS?  VMS?  MS/DOS?  Macintosh?  MPE?
There's stuff all over the place.

-Ted
---------
Ted Manos   tmanos@aocgl.{COM,UUCP,UU.NET}  or ...!{uunet,mcdchg}!aocgl!tmanos

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 88 07:44:49 GMT
From:      jh@tut.fi (Juha Hein{nen)
To:        comp.protocols.misc,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Linking LAN's via Public X.25

SunLink X.25 indeed allows connecting two IP networks over X.25 but it
requires a PVC and cannot dynamically open and close the connection.
You may want to check the Cisco router product that also has the later
capability.
-- 
	Juha Heinanen, Tampere Univ. of Technology, Finland
	jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 88 14:06 EST
From:      AIVANO@Venus.YCC.Yale.Edu
To:        tcp-ip@sri-nic.arpa
Subject:   Moderated Newsgroup Posting
Path: venus!aivano
From: aivano@venus.ycc.yale.edu
Newsgroups: mail.tcp-ip
Subject: Public Domain TN3270
Message-ID: <27@venus.ycc.yale.edu>
Date: 1 Jun 88 14:05:48 GMT
Organisation: VMS NEWS V4.0
Lines: 11

Is there a public domain TN3270 program that runs under VMS and can
interface with Wollongong's TCP/IP?  We would prefer to have source code
so that we could write our own interface, but could live with a
documented executable that includes an interface to the Wollongong
TCP/IP.

Please send replies directly to me,
Sandy Aivano
Yale Computer Center
AIVANO@YALEVMS (BITNET)
AIVANO@YALEVMS.YCC.YALE.EDU (ARPA)
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 88 18:45 EDT
From:      PMDF Mail Server <Postmaster%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
The message could not be delivered to:

Addressee: DAVIS
Reason:
  %MAIL-E-NOSUCHUSR, no such user DAVIS at node

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

Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 18:40 EDT
Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6415 for DAVIS@BKNLVMS;
 Wed,  1 Jun 88 18:39 EDT
Received: by OHSTVMA (Mailer X1.25) id 6412; Wed, 01 Jun 88 18:36:57 EDT
Date: Wed, 1 Jun 88 07:09:14 GMT
From: "Theodore W. Manos" <aocgl!tmanos@uunet.uu.NET>
Subject: Re: non-*NIX implementations
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@OHSTVMA.BITNET>
To: jeff davis <DAVIS@BKNLVMS.BITNET>, 'Ralph Droms' <DROMS@BKNLVMS.BITNET>,
 JERRY MEAD <MEAD@BKNLVMS.BITNET>, "CARL I. NEWMAN" <NEWMAN@BKNLVMS.BITNET>,
 CHRIS RILEY <RILEY@BKNLVMS.BITNET>, "TIMOTHY M. SCHREYER"
 <SCHREYER@BKNLVMS.BITNET>
Reply-to: TCP-IP@SRI-NIC.ARPA
Comments:     Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa
X-To:         tcp-ip@sri-nic.arpa

Ya Mike, what are you looking for?  VM/CMS?  VMS?  MS/DOS?  Macintosh?  MPE?
There's stuff all over the place.

-Ted
---------
Ted Manos   tmanos@aocgl.{COM,UUCP,UU.NET}  or ...!{uunet,mcdchg}!aocgl!tmanos
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 88 18:50 EDT
From:      PMDF Mail Server <Postmaster%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
The message could not be delivered to:

Addressee: SCHREYER
Reason:
  %MAIL-E-NOSUCHUSR, no such user SCHREYER at node

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

Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 18:46 EDT
Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6421 for
 SCHREYER@BKNLVMS; Wed,  1 Jun 88 18:41 EDT
Received: by OHSTVMA (Mailer X1.25) id 6412; Wed, 01 Jun 88 18:36:58 EDT
Date: Wed, 1 Jun 88 07:09:14 GMT
From: "Theodore W. Manos" <aocgl!tmanos@uunet.uu.NET>
Subject: Re: non-*NIX implementations
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@OHSTVMA.BITNET>
To: jeff davis <DAVIS@BKNLVMS.BITNET>, 'Ralph Droms' <DROMS@BKNLVMS.BITNET>,
 JERRY MEAD <MEAD@BKNLVMS.BITNET>, "CARL I. NEWMAN" <NEWMAN@BKNLVMS.BITNET>,
 CHRIS RILEY <RILEY@BKNLVMS.BITNET>, "TIMOTHY M. SCHREYER"
 <SCHREYER@BKNLVMS.BITNET>
Reply-to: TCP-IP@SRI-NIC.ARPA
Comments:     Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa
X-To:         tcp-ip@sri-nic.arpa

Ya Mike, what are you looking for?  VM/CMS?  VMS?  MS/DOS?  Macintosh?  MPE?
There's stuff all over the place.

-Ted
---------
Ted Manos   tmanos@aocgl.{COM,UUCP,UU.NET}  or ...!{uunet,mcdchg}!aocgl!tmanos
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 88 18:55 EDT
From:      PMDF Mail Server <Postmaster%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
The message could not be delivered to:

Addressee: SCHREYER
Reason:
  %MAIL-E-NOSUCHUSR, no such user SCHREYER at node

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

Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 18:51 EDT
Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6556 for
 SCHREYER@BKNLVMS; Wed,  1 Jun 88 18:46 EDT
Received: by OHSTVMA (Mailer X1.25) id 6547; Wed, 01 Jun 88 18:38:26 EDT
Date: Wed, 1 Jun 88 03:01:35 GMT
From: "Jay R. Ashworth" <ukma!uflorida!usfvax2!jc3b21!jra@nrl-cmf.ARPA>
Subject: SLIP Info please?
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@OHSTVMA.BITNET>
To: jeff davis <DAVIS@BKNLVMS.BITNET>, 'Ralph Droms' <DROMS@BKNLVMS.BITNET>,
 JERRY MEAD <MEAD@BKNLVMS.BITNET>, "CARL I. NEWMAN" <NEWMAN@BKNLVMS.BITNET>,
 CHRIS RILEY <RILEY@BKNLVMS.BITNET>, "TIMOTHY M. SCHREYER"
 <SCHREYER@BKNLVMS.BITNET>
Reply-to: TCP-IP@SRI-NIC.ARPA
Comments:     Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa
X-To:         tcp-ip@sri-nic.arpa

Can anybody email me more details about SLIP (Serial Link Internet
Protocol)?  I am interested in the possibility of supporting multiple
telnet type login sessions on one physical radio channel, using a
standard, albeit high speed (38.4Kb?) serial line between TNC and
computer.

Does KA9Q do this?  Are other possible sources PD?  I need to have
source code available.  I (read: my employer) would be interested in
discussing commercial licensing at some future point.  For now,
though, folks, I'd just like to know what I'm talking about.

Can you help?

Email ONLY, please.  The .sig path should work just fine.

Tnx,
-- jra
KA1FJX
--
Jay R. Ashworth ---+-- Suncoast Television Productions--+ ...!uunet!codas!
10974 111th St. N. |   producers of Suncoast Magazine   |  !usfvax2!jc3b21!jra
Seminole FL 34648  +------------------------------------------------+---------
(813) 397-1859 ----+-- Premiering on Vision Cable Ch. 24 in July ---+ :-) !$

Robert Heinlein, 1901-1988, alas, not as long-lived as Lazarus Long.  R. I. P.
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 88 19:00 EDT
From:      PMDF Mail Server <Postmaster%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
The message could not be delivered to:

Addressee: RILEY
Reason:
  %MAIL-E-NOSUCHUSR, no such user RILEY at node

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

Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 18:56 EDT
Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6555 for RILEY@BKNLVMS;
 Wed,  1 Jun 88 18:46 EDT
Received: by OHSTVMA (Mailer X1.25) id 6547; Wed, 01 Jun 88 18:38:25 EDT
Date: Wed, 1 Jun 88 03:01:35 GMT
From: "Jay R. Ashworth" <ukma!uflorida!usfvax2!jc3b21!jra@nrl-cmf.ARPA>
Subject: SLIP Info please?
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@OHSTVMA.BITNET>
To: jeff davis <DAVIS@BKNLVMS.BITNET>, 'Ralph Droms' <DROMS@BKNLVMS.BITNET>,
 JERRY MEAD <MEAD@BKNLVMS.BITNET>, "CARL I. NEWMAN" <NEWMAN@BKNLVMS.BITNET>,
 CHRIS RILEY <RILEY@BKNLVMS.BITNET>, "TIMOTHY M. SCHREYER"
 <SCHREYER@BKNLVMS.BITNET>
Reply-to: TCP-IP@SRI-NIC.ARPA
Comments:     Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa
X-To:         tcp-ip@sri-nic.arpa

Can anybody email me more details about SLIP (Serial Link Internet
Protocol)?  I am interested in the possibility of supporting multiple
telnet type login sessions on one physical radio channel, using a
standard, albeit high speed (38.4Kb?) serial line between TNC and
computer.

Does KA9Q do this?  Are other possible sources PD?  I need to have
source code available.  I (read: my employer) would be interested in
discussing commercial licensing at some future point.  For now,
though, folks, I'd just like to know what I'm talking about.

Can you help?

Email ONLY, please.  The .sig path should work just fine.

Tnx,
-- jra
KA1FJX
--
Jay R. Ashworth ---+-- Suncoast Television Productions--+ ...!uunet!codas!
10974 111th St. N. |   producers of Suncoast Magazine   |  !usfvax2!jc3b21!jra
Seminole FL 34648  +------------------------------------------------+---------
(813) 397-1859 ----+-- Premiering on Vision Cable Ch. 24 in July ---+ :-) !$

Robert Heinlein, 1901-1988, alas, not as long-lived as Lazarus Long.  R. I. P.
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 88 19:05 EDT
From:      PMDF Mail Server <Postmaster%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
The message could not be delivered to:

Addressee: NEWMAN
Reason:
  %MAIL-E-NOSUCHUSR, no such user NEWMAN at node

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

Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 19:01 EDT
Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6554 for NEWMAN@BKNLVMS;
 Wed,  1 Jun 88 18:46 EDT
Received: by OHSTVMA (Mailer X1.25) id 6547; Wed, 01 Jun 88 18:38:25 EDT
Date: Wed, 1 Jun 88 03:01:35 GMT
From: "Jay R. Ashworth" <ukma!uflorida!usfvax2!jc3b21!jra@nrl-cmf.ARPA>
Subject: SLIP Info please?
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@OHSTVMA.BITNET>
To: jeff davis <DAVIS@BKNLVMS.BITNET>, 'Ralph Droms' <DROMS@BKNLVMS.BITNET>,
 JERRY MEAD <MEAD@BKNLVMS.BITNET>, "CARL I. NEWMAN" <NEWMAN@BKNLVMS.BITNET>,
 CHRIS RILEY <RILEY@BKNLVMS.BITNET>, "TIMOTHY M. SCHREYER"
 <SCHREYER@BKNLVMS.BITNET>
Reply-to: TCP-IP@SRI-NIC.ARPA
Comments:     Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa
X-To:         tcp-ip@sri-nic.arpa

Can anybody email me more details about SLIP (Serial Link Internet
Protocol)?  I am interested in the possibility of supporting multiple
telnet type login sessions on one physical radio channel, using a
standard, albeit high speed (38.4Kb?) serial line between TNC and
computer.

Does KA9Q do this?  Are other possible sources PD?  I need to have
source code available.  I (read: my employer) would be interested in
discussing commercial licensing at some future point.  For now,
though, folks, I'd just like to know what I'm talking about.

Can you help?

Email ONLY, please.  The .sig path should work just fine.

Tnx,
-- jra
KA1FJX
--
Jay R. Ashworth ---+-- Suncoast Television Productions--+ ...!uunet!codas!
10974 111th St. N. |   producers of Suncoast Magazine   |  !usfvax2!jc3b21!jra
Seminole FL 34648  +------------------------------------------------+---------
(813) 397-1859 ----+-- Premiering on Vision Cable Ch. 24 in July ---+ :-) !$

Robert Heinlein, 1901-1988, alas, not as long-lived as Lazarus Long.  R. I. P.
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 88 19:20 EDT
From:      PMDF Mail Server <Postmaster%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
The message could not be delivered to:

Addressee: DAVIS
Reason:
  %MAIL-E-NOSUCHUSR, no such user DAVIS at node

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

Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 19:16 EDT
Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6550 for DAVIS@BKNLVMS;
 Wed,  1 Jun 88 18:45 EDT
Received: by OHSTVMA (Mailer X1.25) id 6547; Wed, 01 Jun 88 18:38:24 EDT
Date: Wed, 1 Jun 88 03:01:35 GMT
From: "Jay R. Ashworth" <ukma!uflorida!usfvax2!jc3b21!jra@nrl-cmf.ARPA>
Subject: SLIP Info please?
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@OHSTVMA.BITNET>
To: jeff davis <DAVIS@BKNLVMS.BITNET>, 'Ralph Droms' <DROMS@BKNLVMS.BITNET>,
 JERRY MEAD <MEAD@BKNLVMS.BITNET>, "CARL I. NEWMAN" <NEWMAN@BKNLVMS.BITNET>,
 CHRIS RILEY <RILEY@BKNLVMS.BITNET>, "TIMOTHY M. SCHREYER"
 <SCHREYER@BKNLVMS.BITNET>
Reply-to: TCP-IP@SRI-NIC.ARPA
Comments:     Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa
X-To:         tcp-ip@sri-nic.arpa

Can anybody email me more details about SLIP (Serial Link Internet
Protocol)?  I am interested in the possibility of supporting multiple
telnet type login sessions on one physical radio channel, using a
standard, albeit high speed (38.4Kb?) serial line between TNC and
computer.

Does KA9Q do this?  Are other possible sources PD?  I need to have
source code available.  I (read: my employer) would be interested in
discussing commercial licensing at some future point.  For now,
though, folks, I'd just like to know what I'm talking about.

Can you help?

Email ONLY, please.  The .sig path should work just fine.

Tnx,
-- jra
KA1FJX
--
Jay R. Ashworth ---+-- Suncoast Television Productions--+ ...!uunet!codas!
10974 111th St. N. |   producers of Suncoast Magazine   |  !usfvax2!jc3b21!jra
Seminole FL 34648  +------------------------------------------------+---------
(813) 397-1859 ----+-- Premiering on Vision Cable Ch. 24 in July ---+ :-) !$

Robert Heinlein, 1901-1988, alas, not as long-lived as Lazarus Long.  R. I. P.
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 88 19:25 EDT
From:      PMDF Mail Server <Postmaster%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
The message could not be delivered to:

Addressee: RILEY
Reason:
  %MAIL-E-NOSUCHUSR, no such user RILEY at node

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

Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 19:21 EDT
Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6420 for RILEY@BKNLVMS;
 Wed,  1 Jun 88 18:40 EDT
Received: by OHSTVMA (Mailer X1.25) id 6412; Wed, 01 Jun 88 18:36:58 EDT
Date: Wed, 1 Jun 88 07:09:14 GMT
From: "Theodore W. Manos" <aocgl!tmanos@uunet.uu.NET>
Subject: Re: non-*NIX implementations
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@OHSTVMA.BITNET>
To: jeff davis <DAVIS@BKNLVMS.BITNET>, 'Ralph Droms' <DROMS@BKNLVMS.BITNET>,
 JERRY MEAD <MEAD@BKNLVMS.BITNET>, "CARL I. NEWMAN" <NEWMAN@BKNLVMS.BITNET>,
 CHRIS RILEY <RILEY@BKNLVMS.BITNET>, "TIMOTHY M. SCHREYER"
 <SCHREYER@BKNLVMS.BITNET>
Reply-to: TCP-IP@SRI-NIC.ARPA
Comments:     Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa
X-To:         tcp-ip@sri-nic.arpa

Ya Mike, what are you looking for?  VM/CMS?  VMS?  MS/DOS?  Macintosh?  MPE?
There's stuff all over the place.

-Ted
---------
Ted Manos   tmanos@aocgl.{COM,UUCP,UU.NET}  or ...!{uunet,mcdchg}!aocgl!tmanos
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 88 19:30 EDT
From:      PMDF Mail Server <Postmaster%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
The message could not be delivered to:

Addressee: NEWMAN
Reason:
  %MAIL-E-NOSUCHUSR, no such user NEWMAN at node

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

Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 19:26 EDT
Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 6419 for NEWMAN@BKNLVMS;
 Wed,  1 Jun 88 18:40 EDT
Received: by OHSTVMA (Mailer X1.25) id 6412; Wed, 01 Jun 88 18:36:57 EDT
Date: Wed, 1 Jun 88 07:09:14 GMT
From: "Theodore W. Manos" <aocgl!tmanos@uunet.uu.NET>
Subject: Re: non-*NIX implementations
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@OHSTVMA.BITNET>
To: jeff davis <DAVIS@BKNLVMS.BITNET>, 'Ralph Droms' <DROMS@BKNLVMS.BITNET>,
 JERRY MEAD <MEAD@BKNLVMS.BITNET>, "CARL I. NEWMAN" <NEWMAN@BKNLVMS.BITNET>,
 CHRIS RILEY <RILEY@BKNLVMS.BITNET>, "TIMOTHY M. SCHREYER"
 <SCHREYER@BKNLVMS.BITNET>
Reply-to: TCP-IP@SRI-NIC.ARPA
Comments:     Warning -- original Sender: tag was tcp-ip-request@sri-nic.arpa
X-To:         tcp-ip@sri-nic.arpa

Ya Mike, what are you looking for?  VM/CMS?  VMS?  MS/DOS?  Macintosh?  MPE?
There's stuff all over the place.

-Ted
---------
Ted Manos   tmanos@aocgl.{COM,UUCP,UU.NET}  or ...!{uunet,mcdchg}!aocgl!tmanos
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 88 19:45 EDT
From:      PMDF Mail Server <Postmaster%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
The message could not be delivered to:

Addressee: SCHREYER
Reason:
  %MAIL-E-NOSUCHUSR, no such user SCHREYER at node

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

Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 19:40 EDT
Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 8645 for
 SCHREYER@BKNLVMS; Wed,  1 Jun 88 19:36 EDT
Received: by OHSTVMA (Mailer X1.25) id 8634; Wed, 01 Jun 88 19:31:40 EDT
Date: Wed, 1 Jun 88 12:42:55 CDT
From: John Lee <JLEE@STL-HOST1.ARPA>
Subject: WHOIS prog. for 5000/80
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@OHSTVMA.BITNET>
To: jeff davis <DAVIS@BKNLVMS.BITNET>, 'Ralph Droms' <DROMS@BKNLVMS.BITNET>,
 JERRY MEAD <MEAD@BKNLVMS.BITNET>, "CARL I. NEWMAN" <NEWMAN@BKNLVMS.BITNET>,
 CHRIS RILEY <RILEY@BKNLVMS.BITNET>, "TIMOTHY M. SCHREYER"
 <SCHREYER@BKNLVMS.BITNET>
Reply-to: TCP-IP@SRI-NIC.ARPA
X-To:         tcp-ip@SRI-NIC.ARPA

Ladies and Gentlemen:

I am the host administrator of an Unisys (Sperry) 5000/80 running
release 5.2 of UNIX with release 2.0 of the DDN software.  I am
looking for someone who has a version of "WHOIS" running on their
5000/80.  I would greatly appreciate getting the source code of that
program.  Can anyone help?  Thanks for your time.

John lee
Information Systems Command
4300 Goodfellow
St. Louis, Mo. 63120
mailbox: jlee@AVSCOM.ARPA
phone: (314) 263-3137 autovon: 693-3137
-------
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 88 19:53 EDT
From:      PMDF Mail Server <Postmaster%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
The message could not be delivered to:

Addressee: RILEY
Reason:
  %MAIL-E-NOSUCHUSR, no such user RILEY at node

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

Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 19:49 EDT
Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 8640 for RILEY@BKNLVMS;
 Wed,  1 Jun 88 19:36 EDT
Received: by OHSTVMA (Mailer X1.25) id 8634; Wed, 01 Jun 88 19:31:40 EDT
Date: Wed, 1 Jun 88 12:42:55 CDT
From: John Lee <JLEE@STL-HOST1.ARPA>
Subject: WHOIS prog. for 5000/80
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@OHSTVMA.BITNET>
To: jeff davis <DAVIS@BKNLVMS.BITNET>, 'Ralph Droms' <DROMS@BKNLVMS.BITNET>,
 JERRY MEAD <MEAD@BKNLVMS.BITNET>, "CARL I. NEWMAN" <NEWMAN@BKNLVMS.BITNET>,
 CHRIS RILEY <RILEY@BKNLVMS.BITNET>, "TIMOTHY M. SCHREYER"
 <SCHREYER@BKNLVMS.BITNET>
Reply-to: TCP-IP@SRI-NIC.ARPA
X-To:         tcp-ip@SRI-NIC.ARPA

Ladies and Gentlemen:

I am the host administrator of an Unisys (Sperry) 5000/80 running
release 5.2 of UNIX with release 2.0 of the DDN software.  I am
looking for someone who has a version of "WHOIS" running on their
5000/80.  I would greatly appreciate getting the source code of that
program.  Can anyone help?  Thanks for your time.

John lee
Information Systems Command
4300 Goodfellow
St. Louis, Mo. 63120
mailbox: jlee@AVSCOM.ARPA
phone: (314) 263-3137 autovon: 693-3137
-------
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 88 19:59 EDT
From:      PMDF Mail Server <Postmaster%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
The message could not be delivered to:

Addressee: NEWMAN
Reason:
  %MAIL-E-NOSUCHUSR, no such user NEWMAN at node

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

Received: from JNET-DAEMON by BKNLVMS.BITNET; Wed, 1 Jun 88 19:54 EDT
Received: From OHSTVMA(MAILER) by BKNLVMS with Jnet id 8639 for NEWMAN@BKNLVMS;
 Wed,  1 Jun 88 19:36 EDT
Received: by OHSTVMA (Mailer X1.25) id 8634; Wed, 01 Jun 88 19:31:40 EDT
Date: Wed, 1 Jun 88 12:42:55 CDT
From: John Lee <JLEE@STL-HOST1.ARPA>
Subject: WHOIS prog. for 5000/80
Sender: ARPA TCP-IP Discussion Redistribution <TCPIP-L@OHSTVMA.BITNET>
To: jeff davis <DAVIS@BKNLVMS.BITNET>, 'Ralph Droms' <DROMS@BKNLVMS.BITNET>,
 JERRY MEAD <MEAD@BKNLVMS.BITNET>, "CARL I. NEWMAN" <NEWMAN@BKNLVMS.BITNET>,
 CHRIS RILEY <RILEY@BKNLVMS.BITNET>, "TIMOTHY M. SCHREYER"
 <SCHREYER@BKNLVMS.BITNET>
Reply-to: TCP-IP@SRI-NIC.ARPA
X-To:         tcp-ip@SRI-NIC.ARPA

Ladies and Gentlemen:

I am the host administrator of an Unisys (Sperry) 5000/80 running
release 5.2 of UNIX with release 2.0 of the DDN software.  I am
looking for someone who has a version of "WHOIS" running on their
5000/80.  I would greatly appreciate getting the source code of that
program.  Can anyone help?  Thanks for your time.

John lee
Information Systems Command
4300 Goodfellow
St. Louis, Mo. 63120
mailbox: jlee@AVSCOM.ARPA
phone: (314) 263-3137 autovon: 693-3137
-------
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 88 17:36:58 GMT
From:      JLEE@STL-HOST1.ARPA (John Lee)
To:        comp.protocols.tcp-ip
Subject:   whois prog. for 5000/80

Ladies/Gentlemen:

I am the host administrator of an Unisys (Sperry) 5000/80 running
UNIX 5.2.  We are running release 2.0 of DDN software.  I am looking
for someone who has the "whois" program running on their 5000/80.
If so, I would like to get the program (source if possible).  Is
there anyone who can help?  My mailbox is jlee@AVSCOM.ARPA.  Thanks
for you time.

John Lee
Information Systems Command
4300 Goodfellow
St. Louis, Mo. 63120

mailbox address : jlee@AVSCOM.ARPA
-------

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 88 17:42:55 GMT
From:      JLEE@STL-HOST1.ARPA (John Lee)
To:        comp.protocols.tcp-ip
Subject:   WHOIS prog. for 5000/80

Ladies and Gentlemen:

I am the host administrator of an Unisys (Sperry) 5000/80 running
release 5.2 of UNIX with release 2.0 of the DDN software.  I am
looking for someone who has a version of "WHOIS" running on their
5000/80.  I would greatly appreciate getting the source code of that
program.  Can anyone help?  Thanks for your time.

John lee
Information Systems Command
4300 Goodfellow
St. Louis, Mo. 63120
mailbox: jlee@AVSCOM.ARPA
phone: (314) 263-3137 autovon: 693-3137
-------

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 88 19:00:48 GMT
From:      chuck@excelan.UUCP (Chuck Kollars)
To:        comp.protocols.tcp-ip
Subject:   Re: Third TCP-IP Book?

In article <925@actnyc.UUCP> gcf@actnyc.UUCP (Gordon Fitch) writes:
>I'd like to get the full titles, etc., of the [TCP/IP] books ...

	An Introduction to TCP/IP
	by John Davidson
	Springer-Verlag, 1988  -  ISBN# 0-387-96651-X  (also 3-540-96651-X)
	paperback, over 100 pages  -  suggested retail price $24.95

	Handbook of Computer Communications Standards
	Volume 3, Department of Defense (DOD) Protocol Standards
	by William Stallings
	Macmillan, 1988  -  ISBN# 0-02-948072-8
	hardbound, over 200 pages  -  suggested retail price $34.95

	Internetworking With TCP/IP
	Principles, Protocols, and Architecture
	by Douglas Comer
	Prentice Hall, 1988  -  ISBN# 0-13-470154-2
	hardbound, almost 400 pages  -  suggested retail price $36.00
-- 
Chuck Kollars,  Excelan, Inc.	mtxinu!excelan!chuck@ucbvax.Berkeley.COM
(chuck@excelan.UUCP)		...!{mtxinu,leadsv,cae780}!excelan!chuck

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 88 19:06:00 GMT
From:      AIVANO@VENUS.YCC.YALE.EDU
To:        comp.protocols.tcp-ip
Subject:   Moderated Newsgroup Posting

Path: venus!aivano
From: aivano@venus.ycc.yale.edu
Newsgroups: mail.tcp-ip
Subject: Public Domain TN3270
Message-ID: <27@venus.ycc.yale.edu>
Date: 1 Jun 88 14:05:48 GMT
Organisation: VMS NEWS V4.0
Lines: 11

Is there a public domain TN3270 program that runs under VMS and can
interface with Wollongong's TCP/IP?  We would prefer to have source code
so that we could write our own interface, but could live with a
documented executable that includes an interface to the Wollongong
TCP/IP.

Please send replies directly to me,
Sandy Aivano
Yale Computer Center
AIVANO@YALEVMS (BITNET)
AIVANO@YALEVMS.YCC.YALE.EDU (ARPA)

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 88 19:55:34 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        rec.ham-radio.packet,comp.protocols.tcp-ip
Subject:   Re: SLIP Info please?

I don't think I've seen a formal description of SLIP, but it is very
simple.  It is just a framing technique suitable for carrying IP
datagrams (or whatever you want) on asynchronous links.

Four special characters are defined. They are as follows:

<Frame End>		C0 hex
<Frame Esc>		DB
<Transposed Frame End>	DC
<Transposed Frame Esc>	DD

Transmitter Operation

The transmitter sends the frame a byte at a time, ending it with the
<Frame End> character. If a <Frame End> character occurs in the body of
the frame, it is replaced by the two character sequence <Frame Esc>,
<Transposed Frame End>. Similarly, if a <Frame Esc> character occurs in
the body of the frame, it is replaced by the two byte sequence <Frame
Esc>, <Transposed Frame Esc>.

Receiver Operation

The receiver appends incoming bytes to a reassembly buffer, passing 
whatever has been accumulated up to the next layer when it sees a <Frame
End> character. (The <Frame End> itself is not added to the buffer). The
receiver maintains a one-bit "escaped" flag that is set whenever it sees
a <Frame Esc> character.  (The <Frame Esc> character itself is NOT added
to the reassembly buffer). If the receiver then sees either a
<Transposed Frame End> or a <Transposed Frame Esc> while in "escaped"
mode, it is translated to a <Frame End> or a <Frame Esc>, respectively,
and adds it to the reassembly buffer. Regardless of the character
received while in escaped mode, the "escaped" flag is cleared. If the
<Transposed Frame End> or <Transposed Frame Esc> characters are received
while NOT in "escaped" mode, no special action is necessary; they are
added to the reassembly buffer unchanged.

Note that the <Frame End> character is *never* sent over the line except
as an actual end-of-frame indication.

The original SLIP put <Frame End> characters only at the end of each
frame.  I.e., a series of back-to-back frames would be separated by only
a single <Frame End>. I have made a minor, backward compatible change to
the protocol that puts a <Frame End> in front of each frame as well.
This adds a very small bit of overhead (back-to-back frames are now
separated by two <Frame End> characters) but it improves performance
over noisy links by forcing the receiver into a known state at the
beginning of each new frame.

When used to send IP datagrams over phone lines, the datagrams are
encapsulated directly in frames formatted as described here; no
additional header is carried. There has been considerable discussion
about the need for such a header, but nothing has actually come into
use, as far as I know.

I use SLIP in a different way between a system running my TCP/IP
software and a KISS TNC. There I use SLIP style framing to carry AX.25
frames and control messages between the TNC and host, and there is a
one-byte "type" field at the beginning of each frame. For details, see
the paper by K3MC and myself in last year's ARRL Computer Networking
Conference proceedings. (The same article also described SLIP in
detail).

Phil

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 88 21:23:40 GMT
From:      HEILNER_K@VAXC.STEVENS-TECH.EDU
To:        comp.protocols.tcp-ip
Subject:   ISO Documents


Hi

Does anyone have the address for purchasing documents like ISO 8348. I am 
particularly interested in finding documents that explain the structure of
the network address as defined by ISO.


Thanks 

Keith Heilner
Stevens Institute
Network Coordinator
Heilner_k@sitvxc
Heilner_k@vaxc.stevens-tech.edu
------------

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 88 22:01:10 GMT
From:      amdahl!pacbell!david@ames.arc.nasa.gov  (David St.Pierre)
To:        tcp-ip@sri-nic.arpa
Subject:   TCP/IP in MVS?
I'm trying to determine whether or not there are any commercial
products which support TCP/IP on MVS, specifically for the purposes of
FTP. We need to transfer a lot of files around and sneaker-net just
isn't cutting it.

I've talked to one vendor who may have a product out this summer.
Other than that, I'm completely at a loss as to what's available.

What kind of hardware is needed? What's required on the MVS side? How
is security handled (RACF, ACF2)?

Any leads would be appreciated. Please E-mail them to me. Thanks.
-- 
David St. Pierre 415/823-6800 {att,bellcore,sun,ames,pyramid}!pacbell!david
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 88 00:25:57 GMT
From:      wiltzius@lll-lcc.aRpA (Dave P. Wiltzius)
To:        comp.protocols.tcp-ip
Subject:   UDP reserved ports


I believe this was discussed here a while back, but I would
like to know how daemons (such as TFTPD or FTPD) get their
reserved UDP or TCP port (as specified in RFC 1010 if I recall
correctly).  That is, the port for TFTP is 69 (dex) as per
RFC 1010.  The TFTP client therefore sends packets to the
destination host with UDP port number 69 - which the TFTP
daemon on that host should subsequently receive since it
listens on UDP port 69.

How does it acquire UDP port 69?  Directions to appropriate
BSD code would be most welcome.

Thank you.
  Dave (wiltzius@lll-lcc.llnl.gov)

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 88 02:36:48 GMT
From:      bzs@bu-cs.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP reserved ports


>How does it acquire UDP port 69?  Directions to appropriate
>BSD code would be most welcome.
>
>Thank you.
>  Dave (wiltzius@lll-lcc.llnl.gov)

See the bind and recvfrom manual pages.

	-Barry Shein, Boston University

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jun 88 11:53 CST
From:      Michael Califf <CALIFFM%BAYLOR.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   RE: TCP/IP in MVS?
Here at Baylor we are using a product from Advintech inc. on our
MVS 4381.  It is a combined hardware/software product which uses
a custom channel-attach box to interface to the ether/DDN and
includes SMTP (with a mailer) FTP and TELNET (nvt).  This is a
new company and a new product so there are still a few bugs,
but they are working on them.  If you want an address/phone
number please send me a note or call.

Mike Califf
Communications Programming Coordinator
Baylor University
CALIFFM@BAYLOR.BITNET
(817) 755-2711

I have no connection with ACVINTECH other than being an employee
of a moderately satisfied customer.  My opinions are my own and
rarely reflect those of my employers.

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 88 06:26:44 GMT
From:      MKL@SRI-NIC.ARPA (Mark Lottor)
To:        comp.protocols.tcp-ip
Subject:   Mail Loop

Submissions to the TCP-IP list will now be manually redistributed
until the person responsible for the mail loop sends me a personal
letter explaining that it is fixed.  The bogus mail is from:

From: PMDF Mail Server <Postmaster%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>

-------

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 88 12:10:22 GMT
From:      steve@pdn.UUCP (Steve Fowler)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO Documents


In article <8851162341.21a0028a.HEILNER_K> you write:
>Does anyone have the address for purchasing documents like ISO 8348. I am 
>particularly interested in finding documents that explain the structure of
>the network address as defined by ISO.
>
>Keith Heilner
>Stevens Institute
>Network Coordinator
>Heilner_k@sitvxc
>Heilner_k@vaxc.stevens-tech.edu

Keith,

The document you are looking for can be purchased from the following company:

	OMNICOM, INC.
	115 Park Street, S.E.
	Vienna, VA  22180
	TEL: (703) 281-1135
	FAX: (703) 281-1505
	TLX: 279678 OMNI UR
	ORDER#: 1-800-OMNICOM (666-4266)

I quote from their order form:

"The American National Standards Institute (ANSI) has granted to Omnicom the 
right to distribute ISO/IEC JTC 1 (Information Processing Systems) working
papers, draft proposals, draft international standards, and internmational 
standards currently available for Open Systems Interconnection and Data
Commuinications.  Topics of interest ionclude the seven layers of OSI,
OSI Management, Formal Description Languages, Conformance Testing, Database
Languages, Computer Graphics, Text and Office Systems, The Directory, and
Remote Database Operations."

Omnicom also distributes the CCITT "red" and "green" books.

I hope that this information helps you.


-- 
Steve Fowler W(813) 530-8708                	Paradyne Corporation   | \ _ / 
"I can't even be held responsible for		Mail Stop LF-207       | ~o.O~
my own opinions much less my employer's"	8550 Ulmerton Rd.,     | (_|_)
..!uunet!pdn!steve				Largo, FL 34641        | / U

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 88 17:06:52 GMT
From:      indra@amdcad.AMD.COM (Indra K. Singhal)
To:        comp.protocols.tcp-ip
Subject:   Convert /etc/hosts to RR format pgm anyone?

Has anyone put together a program/shell script that converts 
/etc/hosts to the standard RR format as specified in the RFCs listed?

Thought I'd ask before I get a coleague to spend time reinventing
it. Thanks !!

-- 
Indra K. Singhal                      |                                |
{ucbvax,decwrl,allegra}!amdcad!indra  |      This space for rent !     |
amdcad!indra@decwrl.dec.com           |                                |
(408) 749-5445(w)                     |                                | 

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 88 19:52:31 GMT
From:      zu!kurt@hc.dspo.gov  (Kurt Zeilenga)
To:        tcp-ip@sri-nic.arpa
Subject:   TCP/IP for PDP-11 running TSX (RT11)
We have a system here in need of a cheap, basic TCP/IP
implementation.  It should support at least telnet and FTP.
Here is the description I was given of the system:

>My machine is a PDP-11/23.  The Ethernet card is a DEQNA. My operating
>system is TSX-Plus Version 5.1B, which is written by S&H Enterprises.
>TSX is based on DEC's RT11, inc this case Version 5.  TSX uses all of the
>RT11 filesystem and I/O handlers, but replaces the kernel with a
>multitasking multiuser real-time kernel.

Any pointers, etc., would be greatly appreciated.

	-- Kurt
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 88 21:08:08 GMT
From:      MKL@SRI-NIC.ARPA (Mark Lottor)
To:        comp.protocols.tcp-ip
Subject:   a bunch of messages

Received: from DOCKMASTER.ARPA by SRI-NIC.ARPA with TCP; Thu, 2 Jun 88 05:47:11 PDT
Date:  Thu, 2 Jun 88 08:45 EDT
From:  Fitch@DOCKMASTER.ARPA
Subject:  UDP Example Sources
To:  tcp-ip@SRI-NIC.ARPA
Message-ID:  <880602124550.014174@DOCKMASTER.ARPA>

I am looking for a suite of examples using UDP, ranging from something
simple (say an echo server) to something more complex (say TFTP).  Can
someone point me to public domain, anonymous FTP-able, sources?  In
particular, I am looking for examples using the Berkeley socket
interface to UDP.

--Jack Fitch (Fitch@dockmaster.arpa) include <std_disclaims.h>



----------------------------------------------------------------------
Received: from uxc.cso.uiuc.edu by SRI-NIC.ARPA with TCP; Thu, 2 Jun 88 09:13:15 PDT
Received: by uxc.cso.uiuc.edu (5.51/9.7)
	id AA23522; Thu, 2 Jun 88 10:28:59 CDT
Date: Thu, 2 Jun 88 10:28:59 CDT
From: kline@uxc.cso.uiuc.edu (Charley Kline)
Message-Id: <8806021528.AA23522@uxc.cso.uiuc.edu>
To: tcp-ip@sri-nic.arpa
Subject: Re:   non-*NIX implementations

We run TCP implementations on Unix systems as well as VMS, Macintosh, 
MSDOS, Cray CTSS, and VM/SP. What did you want to know?

-----
Charley Kline,  University of Illinois Computing Services
kline@tuna.cso.uiuc.edu
{ihnp4,uunet,pur-ee,convex}!uiucuxc!kline

"Birth.   School.   Work.   Death."


----------------------------------------------------------------------
Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP;
  Thu, 2 Jun 88 09:41:24 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
	id AA16608; Thu, 2 Jun 88 08:32:10 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 1 Jun 88 06:54:36 GMT
From: mcvax!enea!erix!per@uunet.uu.net  (Per Hedeland)
Organization: Ericsson Telecom, Stockholm, Sweden
Subject: Re: Subnetting
Message-Id: <1624@erix.UUCP>
References: <1607@erix.UUCP>
Sender: tcp-ip-request@sri-nic.arpa
To: tcp-ip@sri-nic.arpa


While it may be a bit late, I thought I should post a short summary of the
information I got in response to my query a few weeks back - it did generate
some discussion, after all. If you recall, the issue was how to use subnetting
on a network structure with a big backbone net and many small ones hanging
off of it. I think the below is the essence of what I found out; I also have
a pile of mail for those particularly interested.

- Unequal-sized subnets, whether or not a Good Thing, is not currently
  implemented in any generally accepted way (and thus of little interest to
  us).

- Partitioned subnets (i.e. subnets of a given net interconnected only by some
  other net) are out.

- One can have several logical subnets on the same wire (i.e. the backbone in
  our case), thus effectively increasing the address space, at the expense of
  some manual "routing" (i.e. gateways have to be explicitly told that the
  different subnets can be accessed via the same interface - hosts on such
  a wire can be "fooled" into believing that it's all one (bigger) subnet).

We will probably go for the latter method, with a long-term goal of splitting
our backbone by using dedicated routers.

Thanks to all who offered help and advice!
---Per Hedeland



----------------------------------------------------------------------
Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu, 2 Jun 88 10:28:56 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
	id AA18222; Thu, 2 Jun 88 10:04:56 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 1 Jun 88 19:00:48 GMT
From: amdahl!pyramid!leadsv!excelan!chuck@ames.arc.nasa.gov  (Chuck Kollars)
Organization: Excelan Inc., San Jose, CA
Subject: Re: Third TCP-IP Book?
Message-Id: <360@lalk.excelan.UUCP>
References: <8805170601.AA21125@Larry.McRCIM.McGill.EDU>, <12399598897.40.LYNCH@A.ISI.EDU>, <925@actnyc.UUCP>
Sender: tcp-ip-request@sri-nic.arpa
To: tcp-ip@sri-nic.arpa

In article <925@actnyc.UUCP> gcf@actnyc.UUCP (Gordon Fitch) writes:
>I'd like to get the full titles, etc., of the [TCP/IP] books ...

	An Introduction to TCP/IP
	by John Davidson
	Springer-Verlag, 1988  -  ISBN# 0-387-96651-X  (also 3-540-96651-X)
	paperback, over 100 pages  -  suggested retail price $24.95

	Handbook of Computer Communications Standards
	Volume 3, Department of Defense (DOD) Protocol Standards
	by William Stallings
	Macmillan, 1988  -  ISBN# 0-02-948072-8
	hardbound, over 200 pages  -  suggested retail price $34.95

	Internetworking With TCP/IP
	Principles, Protocols, and Architecture
	by Douglas Comer
	Prentice Hall, 1988  -  ISBN# 0-13-470154-2
	hardbound, almost 400 pages  -  suggested retail price $36.00
-- 
Chuck Kollars,  Excelan, Inc.	mtxinu!excelan!chuck@ucbvax.Berkeley.COM
(chuck@excelan.UUCP)		...!{mtxinu,leadsv,cae780}!excelan!chuck




----------------------------------------------------------------------
Received: from acc.arpa by SRI-NIC.ARPA with TCP; Thu, 2 Jun 88 10:47:19 PDT
Date: 2 Jun 88 10:31:00 PST
From: <art@acc.arpa>
Subject: RE: ISO Documents
To: "heilner_k" <heilner_k@vaxc.stevens-tech.edu>
cc: tcp-ip@sri-nic.arpa
Reply-To: <art@acc.arpa>


>Does anyone have the address for purchasing documents like ISO 8348. I am 
>particularly interested in finding documents that explain the structure of
>the network address as defined by ISO.

Two places that we use are:

	OMNICOM, Inc.
	115 Park Street S.E.
	Vienna, VA  22180
	(703) 281-1135

	AlphaGraphics
	10215 N. 35th Ave.
	Phoenix, AZ  85051
	(602) 863-0999

Both try to obtain up-to-date copies of the standards documents and offer
document duplication services.  I believe both will take phone orders on
major credit cards.  OMNICOM also provides seminars on ISO protocols, etc.

						Art Berggreen
						art@acc.arpa

------



----------------------------------------------------------------------
Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu, 2 Jun 88 12:25:12 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
	id AA19084; Thu, 2 Jun 88 10:44:07 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 2 Jun 88 17:06:52 GMT
From: amdcad!indra@ucbvax.Berkeley.EDU  (Indra K. Singhal)
Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca.
Subject: Convert /etc/hosts to RR format pgm anyone?
Message-Id: <21877@amdcad.AMD.COM>
Sender: tcp-ip-request@sri-nic.arpa
To: tcp-ip@sri-nic.arpa

Has anyone put together a program/shell script that converts 
/etc/hosts to the standard RR format as specified in the RFCs listed?

Thought I'd ask before I get a coleague to spend time reinventing
it. Thanks !!

-- 
Indra K. Singhal                      |                                |
{ucbvax,decwrl,allegra}!amdcad!indra  |      This space for rent !     |
amdcad!indra@decwrl.dec.com           |                                |
(408) 749-5445(w)                     |                                | 
-------

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 88 22:59:43 GMT
From:      symchych@SKL-CRC.ARPA (Tim Symchych)
To:        comp.protocols.tcp-ip
Subject:   Re: Linking LAN's via Public X.25

Perhaps another view of IP over X.25 might help.  While the original
question was asked about Sun X.25, there are a number of networks within the
ARPA/Internet that use IP over X.25.

The experience that Phil Karn described at Bellcore does not describe
our experience in establishing the DRENET and XDRENET here in Canada.
There is no doubt in my mind that some implementations of packet
switching using CCITT X.25 are poor.  We did some testing of various
networks about two years ago including ARPANET (1822 Links), Telenet
in the USA, SATNET, and the public packet switching networks in the
UK and Canada (Datapac).  Packets were timed in some great loops, and
by network segment to allow us to determine level of service over the
various segments.  Generally, the packets through Telenet and SATNET
suffered the most delay. The X.75 gateways didn't seem to work all that
well then either.

I'm not sure that X.25 was designed for slow speed terminal multiplexing.
NO packet switching network works well at that task.

In our own case, use of TCP/IP over X.25 has been shown effective from
both points of view: cost and throughput.  In Canada, we have at least
one first rate X.25 packet switching network.  Through eight years
of using Datapac for applications, including five years of TCP/IP over
X.25, we have found no problems in service or reliability.  By the way,
I don't work for any of the Bell franchises, nor do I own any of their
stock.  I just pay the phone bill.

We have several hosts and gateways that connect LANs using X.25. I
don't agree that X.25 is overly complex, or managing virtual circuits
is a big problem. Our gateways and hosts usually do the work in software
on board level products.  We did some preliminary testing with SunLink
using our hosts and one of their software implementations.  Everything
worked but the Sun stuff has some minor rough edges.  For instance,
the Sun would only allow one virtual circuit between two hosts even
thought our side would allow one per user process. Imagine sharing
your TELNET session with an FTP with each IP packet waiting it turn in
in the X.25 queue.  TELNET over X.25 is bad, but Sun made it worse.  I
hope they worked on that "kludge".

Our tariff structure for communication services is almost the reverse
to that in the U.S.  Our leased lines cost us dearly, but out packet
switching cost much less.  If you look at our telco infrastructure, its
easy to see why.  Our population is spread across the country, and
leased lines are nearly always new services.

In the way of cost and performance, we have this kind of experience:

Rental of 9600 bps X.25 modem with 20 virtual circuits is $390.00 U.S. per
month.
Traffic charges range from $35.00 to $300.00 U.S. per month per X.25 interface
depending on usage and distance.  The later is for about 50MB per month
to a site 1500 miles away using the Datapac cost formula.
On most of our X.25 legs, we get between 50 and 75 per cent of the of the
9600 bps.  But this does depend a great deal on the HOST implementation
of TCP/IP. In contrast, our 9600 bps HDH line gives us about 80 to 85
per cent of the line speed. Our 56 kbps line gives about 20 to 30 percent
of the line speed, but we are not sure that we have hosts at either
end to drive it faster.
To send a 10 MB file across the country, it would cost about $75.00 U.S..
Thats about the same as it would cost to run the data on to a mag new tape
and send it FEDEX.

Some of our sites will be running 19.2 bps X.25 service which will double
the monthly modem cost, and increase throughput but will be limited by 
the TCP/IP on the hosts.
We expect that these 19.2 links will get us about 12000 bps or just about
what we get out of our very expensive 56k bps line between our core gateway
and the U. of Rochester. When our core gateway was replaced in Feb/88 with
a Butterfly, the measured throughput went up slightly even though the HDH
interface was replaced with an X.25 interface. I've tried to figure that one
out.

I will be the first to agree that our needs and network structure is
different than Bellcore.  However, I view X.25 packet switches as a low cost
backbone that will allow us to operate until we have sufficient traffic
levels to support leased lines.

If there is a target needing a thumper, it sounds like the implementation
of X.25 in Telenet will do. When it comes to bad implementations of TCP/IP,
the cry is "burn them at the stake".  There are good and bad X.25
implementations, and I recommend burning where it is due.

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1988 1131-PDT (Friday)
From:      Charles Spurgeon <spurgeon@jessica.Stanford.EDU>
To:        tcp-ip@sri-nic.arpa
Cc:        
Subject:   Network books, TCP/IP and Ethernet
The following is an annotated list of books that I've found useful while
designing, building, and operating networks at Stanford University over the
last several years.  The list reflects the experience of building networks
primarily based on TCP/IP protocols and Ethernet technology.  

This message is long.  I just set out to list some useful books with
complete access information, and it got longer and longer...

   -Charles Spurgeon
    (spurgeon@jessica.stanford.edu)
    Networking and Communications Systems, Stanford University.
    June 3, 1988

-- Introductory --

1.  "Local Area Networks", by John E. McNamara, 1985, 165pps with index and
glossary. $29.00  Published by Digital Press, ISBN 0-932376-79-7.  Digital
Press part number for ordering is EY-00051-DP.  Digital Press phone is
1-800-343-8321.

This is a good general introduction to the concepts and technologies of
LANs.  As stated in the preface: 

" This book is intended for students, computer system managers,
telecommunications managers, and others who want to become more familiar
with local area networks.  Since product offerings in this area are
constantly changing, a deliberate attempt has been made to emphasize the
general principles, operating characteristics, and problem areas of local
area network hardware, rather than cite specific product examples." 

Of special note is the chapter on "Administrative considerations for large
networks" which is largely taken from David Clark's 1983 "M.I.T. Campus
Network Implementation Planning Document".   This chapter mentions many of
the problems of supporting large campus area networks with special reference
to the issue of multiple protocol support on campus backbone networks.


-- Two books by Douglas Comer --

Douglas Comer has written two books of special interest to the networker.
His books are comprehensive and he has an excellent writing style, making
these the best books I've seen on the TCP/IP protocols.

2. "Internetworking With TCP/IP, Principles, Protocols, and Architecture".  By
Douglas E. Comer.  1988, 382pps with index and glossary.  Prentice-Hall,
Inc., New Jersey, ISBN 0-13-470154-2.  $36.00. (Stanford Bookstore price.)

As stated in the preface:

"For professionals, the book provides a comprehensive introduction to TCP/IP
technology and the architecture of the Internet.  Although it is not
intended to replace protocol standards, the book is a good starting point
for learning about internetworking because it gives a uniform overview that
emphasizes principles.  Moreover, it gives the reader perspective that can
be extremely difficult to obtain from individual protocol documents."

"The book is organized into four main parts.  Chapters 1 and 2 form an
introduction that provides an overview and discusses existing technologies.
In particular, Chapter 2 reviews physical network hardware.  The intention
is to provide basic intuition about what is possible, not to spend
inordinate time on hardware details.  Chapters 3-12 describe the TCP/IP
Internet from the viewpoint of a single host, showing the basic services
available and the protocols a host uses to access them.  They cover the
basics of Internet addressing and routing as well as the notion of protocol
layering.  Chapters 13-16 describe the architecture of the Internet when
viewed globally.  They explore the core gateway system and the protocols
gateways use to exchange routing information.  Finally, Chapters 17-19
discuss application level services available in the Internet.  They present
the client-server model of interaction and give several examples of how one
can organize client and server software.  The last section discusses
electronic mail and the domain name system, two topics that are extremely
popular."

I particularly like the real-world orientation of this book.  For instance,
there is an appendix on "4.3 BSD UNIX Interface to Internet Protocols" that
describes Berkeley sockets and presents example client and server programs
for a network whois service.  There's another appendix on "Hints And
Suggestions For Implementors" full of useful tips for network programmers.
And there's a nice appendix called "A Guide To RFCs" which explains the
Requests For Comments completely and with due regard for the early folklore
and development of the ARPAnet.  A guide to the first one thousand RFCs,
extracted from RFC1000, is presented as well as electronic and snail mail
addresses for getting your own copies of the RFCs.

3. "Operating System Design - Volume II, Internetworking with Xinu".  By
Douglas Comer.  1987, 5667pps with index.  Published by Prentice-Hall, Inc.,
New Jersey, ISBN 0-13-637414-X.  $39.33. (Stanford Bookstore price.)

As stated in the preface:

"Chapters 1-11 comprise a self-contained unit that covers the basics of
internet communication.  Each of the eleven chapters explores one component
of internet protocol software, motivating and explaining how that component
fits into the overall system design.  The unit starts with a detailed
examination of one network technology, the Ethernet, and moves on to
consider the internet concept, address resolution, internet datagrams,
routing, control messages, user datagrams, and datagram demultiplexing.
Later chapters build on the basic communication system, examining
client-server interaction, and remote file access, as well as a user
interface and commands that manipulate both local and remote files."

"Written as a continuation of 'Operating System Design - The XINU Approach'
(Comer [1984]), this text starts where the earlier one ends.  The two
volumes were written to support a two-semester course in systems design that
encompasses operating systems and networks... ."

This book is based on the XINU operating system software which is available
from Purdue University as described in the book.  XINU was written to give
students the experience of studying a UNIX-like operating system whose
source code was available for modification.  Lots of software examples in
every chapter make this an especially useful text for aspiring network
programmers.  It's also good resource for those just curious as to what
network software looks like and how it fits together.

-- Three books by William Stallings  --

William Stallings has published a series of three books that can be helpful
in hacking one's way through the jargon laden jungles of network standards -
especially the OSI and IEEE standards.  

4. "Volume 1. Handbook of Computer Communications Standards, The Open Systems
Interconnection (OSI) Model and OSI-Related Standards". By William Stallings.
1987, 322pps with index. Macmillan Publishing Co., NY, ISBN 0-02-948071-X.
$34.95.

The first volume sets the stage by explaining the OSI standards effort and
the organization of the OSI standards process.  The OSI reference model is
then presented, and each layer is discussed in depth with lots of detail.
OSI is a moving target, and some of the material here is no doubt already
dated, but it's still a good explanation of the whole OSI world.

5. "Volume 2. Handbook of Computer Communications Standards, Local Network
Standards".  By William Stallings. 1987, 244pps with index.  Macmillan
Publishing Co,, NY, ISBN 0-02-948070-1.  $34.95.

This book covers the IEEE 802 series of standards and the emerging FDDI
standard.  The material described here makes it possible to decipher the
802.3 standard.  After a brief introduction covering network topologies and
media, Stallings explains the standardization efforts, including the
structure of the standards committees and how the various standards agencies
interact.

Next the IEEE 802 standards structure is described, with the various
subsets explained.  Chapter 4 describes the 802.3 standard including
variants such as 10BASE2.  Also included is a brief description of the major
differences between 802.3 and DIX Ethernet.  An appendix provides a short
introduction to the OSI reference model, so that you don't need volume 1 to
figure out volume 2.

6. "Volume 3. Handbook of Computer Communications Standards, Department of
Defense (DOD) Protocol Standards".  By William Stallings, Paul Mockapetris,
Sue McLeod and Tony Michel, 1988, 206pps with index. Macmillan Publishing
Co., NY, ISBN 0-02-948072-8.  $34.95.

This volume is a guide to the TCP/IP protocol suite.  As stated in the
preface:

"...Volume 3, covers the five military standard protocols that have been
issued by the DOD.  The book begins by introducing the four layer
communications architecture that is the framework within which these
standards fit.  Following the introduction of this architecture, a chapter
is devoted to each of the standards."

"In contrast with the other books in this series, several of the chapters of
this book were written by contributors.  Each contributor is intimately
familiar with the topic under discussion: biographies of the main author and
the contributing authors are found at the end of the book."

The chapters on IP and TCP appear to have been written by Stallings.  The
chapter on FTP is by Tony Michel, the SMTP chapter by Paul Mockapetris and
the Telnet chapter by Sue McLeod.  The chapters are good descriptions of the
various protocols.  On the other hand, I prefer Douglas Comer's book, for
reasons given above.


-- Ethernet Standards --

The next several items deal with the various Ethernet standards in use
today.

7. "Ethernet Local Area Network Specification Version 2.0. November, 1982".
103pps, $32.00.  DEC Part Number: AA-K759B-TK.  Available from DEC-Direct by
calling 1-800-344-4825.

This is version 2 of the original ten megabit Ethernet specification.  The
newer 802.3 standard supersedes the DEC-Intel-Xerox (DIX) spec listed here,
but most TCP/IP implementations are still based on this DIX specification.

Since this specification is not based on the OSI model it is relatively
jargon free and reads like something close to English, making it a much more
approachable document than the IEEE standards.  

8. "Carrier Sense Multiple Access with Collision Detection, ANSI/IEEE Std
802.3, 1985, ISO/DIS 8802/3".  ISBN 0-471-82749-5.  Available from, IEEE
Service Center, 445 Hoes Lane, Piscataway, New Jersey 08854, or by calling
1-201-981-0060, or from technical bookstores (see below).

The new Ethernet specifications.  Much has changed.  Much stayed the same.
Vendors like to gloss over the differences (it's a lot easier than trying to
describe them!) and you're on your own trying to figure out how it all
works.

This standard was written to comply with the OSI model.  As a result, it
contains much more jargon and can be much less understandable at first.  An
explanatory guide like Stalling's volume 2 is a requirement to help the
newcomer to OSI make any sense of it all.

9. "Supplements to Carrier Sense Multiple Access with Collision Detection,
ANSI/IEEE Std 802.3a,b,c,and e-1988".  ISBN 0-471-61153-0  Same access as
above. 

A set of additions to the 1985 802.3 standard, including the thin Ethernet
standard (Type 10BASE2).  Also included is the broadband standard (Type
10BROAD36) and a revision of section 9 of the 1985 standard on repeaters.


-- Ethernet hardware information --

None of the Ethernet standards docs are very useful when it comes to
actually building, testing, and operating an Ethernet.  For that you need
information about what topologies are allowed, how Ethernet equipment is
configured, how to attach connectors and all the rest.  While there isn't a
good general book available on Ethernet design and construction, the
following manual can help.

10. "LAN Cable and Accessories Installation Manual", January 1986, published
by Hewlett-Packard Co..  HP Part No. 5955-7680.  $45.00.  Order from H.P.
Direct at 1-800-538-8787.

This manual is somewhat dated and contains instructions for installing thick
cable transceivers that are obsolete, for instance.  On the other hand, the
network configuration information is useful and the guidelines for
routing cables and grounding issues are informative.  My major disagreement
with H.P.'s grounding instructions is that they allow metallic cable between
building frames if H.P.'s surge arrestors are installed.  Given the
ease of using fiber optic repeaters, and the dangers inherent in metallic
network cables that travel between building frames, there seems little
excuse for not using fiber in these situations.

In any event, the manual really shines when it comes to complete
descriptions of thick cable and thin cable wire strippers and connector
crimpers.  The H.P. manual has diagrams showing how to strip each kind of
cable and how to crimp on N connectors and BNC connectors.

There's a short section on verifying the cables you've built, and a longer
section on how to use a Time Domain Reflectometer to test networks.  Another
useful section is the one on how to open up a crimp tool that has been
closed on something you didn't want to crimp (like your finger!).  Don't
laugh - this section came in handy the other day when a student used a crimp
tool with a 75 ohm UHF crimp die in it to crimp a 50 ohm N connector.  The
instructions in the H.P. manual allowed us to get the mauled N connector out
without dismantling the whole tool and ruining the precision adjustments.


-- Access --

Aside from various phone numbers listed above, the following book stores can
be of service:

Computer Literacy Bookshop, 2590 North First St., San Jose, CA 95131.  Phone
408-435-1118 for mail orders.  A good source for computer and electronics
books of all kinds.  They carry the IEEE network standards, and can probably
supply most of the books listed above.

Jim Joyce's UNIX Bookstore, 47 Potomac St., San Francisco, CA 94117.  Phone
415-626-7581 for mail orders.  A handy resource for UNIX-related books of
all kinds, including the Douglas Comer books.

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Fri 3 Jun 88 14:53:09-EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        symchych@skl-crc.arpa
Cc:        thumper!karn@faline.bellcore.com, tcp-ip@sri-nic.arpa, lynch@A.ISI.EDU
Subject:   Re: Linking LAN's via Public X.25

Tim,  Thanks for the explanation of how X.25 works in Canada.  Different 
"administrations" charge differently for the "same services" for their
local reasons.  That's just the way the world works.  Doesn't seem
to be a way to optomize an architecture to account for all possible 
larcenies or charities.

But,  I was amazed to see you describe the low throughput on some of your
slow links (anything under T1 is "slow" in my book).  How can there
be implementation sout there that cannot keep a 9600 baud link running full
tilt???

Reason I ask is that your wording left me feeling that the host implementations
were somehow anemic.  I would hop that they just had poor data link drivers
that can be fixed rapidly.  Or are they mainly suffering from the lack of
Van Jacobson's fixes?

Dan
-------
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 88 13:17:23 GMT
From:      doug@MSC2.TN.CORNELL.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP for PDP-11 running TSX (RT11)

Process Software in in Mass. has FTP for RT and TSX, TELNET for RT, and I 
believe they are working on TELNET for TSX.  Their product is NOT a general
TCP/IP implementation, but a series of applications.  The FTP is a very
basic vanilla FTP, but the TSX version uses DEC command-line syntax instead
of interactive Unix-style syntax.  The result of this is that they open
and close the connection for EACH file that gets transferred.  Also missing
is wildcarding (MPUT/MGET), CWD, and DIR functionality.  I have written to
them requesting that they add the above.  It is, however, a basic
implementation that works.
They can be reached at:
	Process Software
	35 Montague Road
	PO Box 746
	Amherst, MA  01004
	(413) 549-6994

- Doug Neuhauser, Materials Science Center, Cornell University
(doug@msc2.tn.cornell.edu)

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 88 13:32:04 GMT
From:      doug@ICASE.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Sun File server

My apologies if this is posted to the wrong discussion group.

We have just upgraded our server from a 3/180 to a 3/280, and have
seen a DECREASE in performance. We run Sun OS 3.5. The number of diskless
clients in both cases is the same. The e-net collision rate is much
higher with the new server, which may account for some of the decrease.

But I just received my copy of the May Sun STB, which has an article
describing how the cache works on a Sun 3/200 series machine. On page
826, there is a statement to the effect that if the cache hit rate is
effectively zero, then performance of a 3/280 system will be less than
a 3/280. As a server, handling lots of random client requests, I would
think that the cache hit rate would be very low.

Has anyone observed similar phenomenon? I will summarize to the net.

Doug Peterson
Systems Manager
ICASE
Mail Stop 132C
NASA Langley Research Center
Hampton, VA 23665-5225
(804) 865-4090




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

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 88 14:40:49 GMT
From:      jon@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Linking LAN's via Public X.25



 >Perhaps another view of IP over X.25 might help.  While the original
 >question was asked about Sun X.25, there are a number of networks within the
 >ARPA/Internet that use IP over X.25.

another e.g. of IP over X.25 is the UK Academic link to the US,
which has run over IPSS for some years, as leased lines were
rather expensive for the amount of traffic we used to have, and
since the SATNET was mainly reserved for research use.

A lot of interesting work was done on accounting and access
control so that we could forward bills for the IPSS usage to
the UK source of any IP packets on a sensible basis.

Useful reading...

%A R. H. Cole
%T User Experience and Evaluation of International X.25 Services
%J Proc. Telecoms Today Conf.
%I Online
%C London
%D March 1984
%P 107-118
%K X.25 performance

jon

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 88 14:49:46 GMT
From:      virchaux@CLSEPF51.BITNET (J.Virchaux EPFL-SIG)
To:        comp.protocols.tcp-ip
Subject:   Query : TCP/IP on TSX+

I'm looking for an implementation of TCP/IP on TSX+.

We should like to FTP files from a PDP running TSX+ operating system
to a VAX through an Ethernet link. Is such software (and hardware if
not DEQNA) available ?

Please, do not answer to the list as I'm not a member. Reply to :

        VIRCHAUX@CLSEPF51.BITNET
        Virchaux@Eldp.Epfl.CH             (Arpa, Cs.Net, X.400)
        PSI%022846911008::ELDP::VIRCHAUX  (PSI-Mail)

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Fri, 03 Jun 88 15:40:49 +0100
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Linking LAN's via Public X.25


 >Perhaps another view of IP over X.25 might help.  While the original
 >question was asked about Sun X.25, there are a number of networks within the
 >ARPA/Internet that use IP over X.25.

another e.g. of IP over X.25 is the UK Academic link to the US,
which has run over IPSS for some years, as leased lines were
rather expensive for the amount of traffic we used to have, and
since the SATNET was mainly reserved for research use.

A lot of interesting work was done on accounting and access
control so that we could forward bills for the IPSS usage to
the UK source of any IP packets on a sensible basis.

Useful reading...

%A R. H. Cole
%T User Experience and Evaluation of International X.25 Services
%J Proc. Telecoms Today Conf.
%I Online
%C London
%D March 1984
%P 107-118
%K X.25 performance

jon
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 88 18:31:00 GMT
From:      spurgeon@JESSICA.STANFORD.EDU (Charles Spurgeon)
To:        comp.protocols.tcp-ip
Subject:   Network books, TCP/IP and Ethernet

The following is an annotated list of books that I've found useful while
designing, building, and operating networks at Stanford University over the
last several years.  The list reflects the experience of building networks
primarily based on TCP/IP protocols and Ethernet technology.  

This message is long.  I just set out to list some useful books with
complete access information, and it got longer and longer...

   -Charles Spurgeon
    (spurgeon@jessica.stanford.edu)
    Networking and Communications Systems, Stanford University.
    June 3, 1988

-- Introductory --

1.  "Local Area Networks", by John E. McNamara, 1985, 165pps with index and
glossary. $29.00  Published by Digital Press, ISBN 0-932376-79-7.  Digital
Press part number for ordering is EY-00051-DP.  Digital Press phone is
1-800-343-8321.

This is a good general introduction to the concepts and technologies of
LANs.  As stated in the preface: 

" This book is intended for students, computer system managers,
telecommunications managers, and others who want to become more familiar
with local area networks.  Since product offerings in this area are
constantly changing, a deliberate attempt has been made to emphasize the
general principles, operating characteristics, and problem areas of local
area network hardware, rather than cite specific product examples." 

Of special note is the chapter on "Administrative considerations for large
networks" which is largely taken from David Clark's 1983 "M.I.T. Campus
Network Implementation Planning Document".   This chapter mentions many of
the problems of supporting large campus area networks with special reference
to the issue of multiple protocol support on campus backbone networks.


-- Two books by Douglas Comer --

Douglas Comer has written two books of special interest to the networker.
His books are comprehensive and he has an excellent writing style, making
these the best books I've seen on the TCP/IP protocols.

2. "Internetworking With TCP/IP, Principles, Protocols, and Architecture".  By
Douglas E. Comer.  1988, 382pps with index and glossary.  Prentice-Hall,
Inc., New Jersey, ISBN 0-13-470154-2.  $36.00. (Stanford Bookstore price.)

As stated in the preface:

"For professionals, the book provides a comprehensive introduction to TCP/IP
technology and the architecture of the Internet.  Although it is not
intended to replace protocol standards, the book is a good starting point
for learning about internetworking because it gives a uniform overview that
emphasizes principles.  Moreover, it gives the reader perspective that can
be extremely difficult to obtain from individual protocol documents."

"The book is organized into four main parts.  Chapters 1 and 2 form an
introduction that provides an overview and discusses existing technologies.
In particular, Chapter 2 reviews physical network hardware.  The intention
is to provide basic intuition about what is possible, not to spend
inordinate time on hardware details.  Chapters 3-12 describe the TCP/IP
Internet from the viewpoint of a single host, showing the basic services
available and the protocols a host uses to access them.  They cover the
basics of Internet addressing and routing as well as the notion of protocol
layering.  Chapters 13-16 describe the architecture of the Internet when
viewed globally.  They explore the core gateway system and the protocols
gateways use to exchange routing information.  Finally, Chapters 17-19
discuss application level services available in the Internet.  They present
the client-server model of interaction and give several examples of how one
can organize client and server software.  The last section discusses
electronic mail and the domain name system, two topics that are extremely
popular."

I particularly like the real-world orientation of this book.  For instance,
there is an appendix on "4.3 BSD UNIX Interface to Internet Protocols" that
describes Berkeley sockets and presents example client and server programs
for a network whois service.  There's another appendix on "Hints And
Suggestions For Implementors" full of useful tips for network programmers.
And there's a nice appendix called "A Guide To RFCs" which explains the
Requests For Comments completely and with due regard for the early folklore
and development of the ARPAnet.  A guide to the first one thousand RFCs,
extracted from RFC1000, is presented as well as electronic and snail mail
addresses for getting your own copies of the RFCs.

3. "Operating System Design - Volume II, Internetworking with Xinu".  By
Douglas Comer.  1987, 5667pps with index.  Published by Prentice-Hall, Inc.,
New Jersey, ISBN 0-13-637414-X.  $39.33. (Stanford Bookstore price.)

As stated in the preface:

"Chapters 1-11 comprise a self-contained unit that covers the basics of
internet communication.  Each of the eleven chapters explores one component
of internet protocol software, motivating and explaining how that component
fits into the overall system design.  The unit starts with a detailed
examination of one network technology, the Ethernet, and moves on to
consider the internet concept, address resolution, internet datagrams,
routing, control messages, user datagrams, and datagram demultiplexing.
Later chapters build on the basic communication system, examining
client-server interaction, and remote file access, as well as a user
interface and commands that manipulate both local and remote files."

"Written as a continuation of 'Operating System Design - The XINU Approach'
(Comer [1984]), this text starts where the earlier one ends.  The two
volumes were written to support a two-semester course in systems design that
encompasses operating systems and networks... ."

This book is based on the XINU operating system software which is available
from Purdue University as described in the book.  XINU was written to give
students the experience of studying a UNIX-like operating system whose
source code was available for modification.  Lots of software examples in
every chapter make this an especially useful text for aspiring network
programmers.  It's also good resource for those just curious as to what
network software looks like and how it fits together.

-- Three books by William Stallings  --

William Stallings has published a series of three books that can be helpful
in hacking one's way through the jargon laden jungles of network standards -
especially the OSI and IEEE standards.  

4. "Volume 1. Handbook of Computer Communications Standards, The Open Systems
Interconnection (OSI) Model and OSI-Related Standards". By William Stallings.
1987, 322pps with index. Macmillan Publishing Co., NY, ISBN 0-02-948071-X.
$34.95.

The first volume sets the stage by explaining the OSI standards effort and
the organization of the OSI standards process.  The OSI reference model is
then presented, and each layer is discussed in depth with lots of detail.
OSI is a moving target, and some of the material here is no doubt already
dated, but it's still a good explanation of the whole OSI world.

5. "Volume 2. Handbook of Computer Communications Standards, Local Network
Standards".  By William Stallings. 1987, 244pps with index.  Macmillan
Publishing Co,, NY, ISBN 0-02-948070-1.  $34.95.

This book covers the IEEE 802 series of standards and the emerging FDDI
standard.  The material described here makes it possible to decipher the
802.3 standard.  After a brief introduction covering network topologies and
media, Stallings explains the standardization efforts, including the
structure of the standards committees and how the various standards agencies
interact.

Next the IEEE 802 standards structure is described, with the various
subsets explained.  Chapter 4 describes the 802.3 standard including
variants such as 10BASE2.  Also included is a brief description of the major
differences between 802.3 and DIX Ethernet.  An appendix provides a short
introduction to the OSI reference model, so that you don't need volume 1 to
figure out volume 2.

6. "Volume 3. Handbook of Computer Communications Standards, Department of
Defense (DOD) Protocol Standards".  By William Stallings, Paul Mockapetris,
Sue McLeod and Tony Michel, 1988, 206pps with index. Macmillan Publishing
Co., NY, ISBN 0-02-948072-8.  $34.95.

This volume is a guide to the TCP/IP protocol suite.  As stated in the
preface:

"...Volume 3, covers the five military standard protocols that have been
issued by the DOD.  The book begins by introducing the four layer
communications architecture that is the framework within which these
standards fit.  Following the introduction of this architecture, a chapter
is devoted to each of the standards."

"In contrast with the other books in this series, several of the chapters of
this book were written by contributors.  Each contributor is intimately
familiar with the topic under discussion: biographies of the main author and
the contributing authors are found at the end of the book."

The chapters on IP and TCP appear to have been written by Stallings.  The
chapter on FTP is by Tony Michel, the SMTP chapter by Paul Mockapetris and
the Telnet chapter by Sue McLeod.  The chapters are good descriptions of the
various protocols.  On the other hand, I prefer Douglas Comer's book, for
reasons given above.


-- Ethernet Standards --

The next several items deal with the various Ethernet standards in use
today.

7. "Ethernet Local Area Network Specification Version 2.0. November, 1982".
103pps, $32.00.  DEC Part Number: AA-K759B-TK.  Available from DEC-Direct by
calling 1-800-344-4825.

This is version 2 of the original ten megabit Ethernet specification.  The
newer 802.3 standard supersedes the DEC-Intel-Xerox (DIX) spec listed here,
but most TCP/IP implementations are still based on this DIX specification.

Since this specification is not based on the OSI model it is relatively
jargon free and reads like something close to English, making it a much more
approachable document than the IEEE standards.  

8. "Carrier Sense Multiple Access with Collision Detection, ANSI/IEEE Std
802.3, 1985, ISO/DIS 8802/3".  ISBN 0-471-82749-5.  Available from, IEEE
Service Center, 445 Hoes Lane, Piscataway, New Jersey 08854, or by calling
1-201-981-0060, or from technical bookstores (see below).

The new Ethernet specifications.  Much has changed.  Much stayed the same.
Vendors like to gloss over the differences (it's a lot easier than trying to
describe them!) and you're on your own trying to figure out how it all
works.

This standard was written to comply with the OSI model.  As a result, it
contains much more jargon and can be much less understandable at first.  An
explanatory guide like Stalling's volume 2 is a requirement to help the
newcomer to OSI make any sense of it all.

9. "Supplements to Carrier Sense Multiple Access with Collision Detection,
ANSI/IEEE Std 802.3a,b,c,and e-1988".  ISBN 0-471-61153-0  Same access as
above. 

A set of additions to the 1985 802.3 standard, including the thin Ethernet
standard (Type 10BASE2).  Also included is the broadband standard (Type
10BROAD36) and a revision of section 9 of the 1985 standard on repeaters.


-- Ethernet hardware information --

None of the Ethernet standards docs are very useful when it comes to
actually building, testing, and operating an Ethernet.  For that you need
information about what topologies are allowed, how Ethernet equipment is
configured, how to attach connectors and all the rest.  While there isn't a
good general book available on Ethernet design and construction, the
following manual can help.

10. "LAN Cable and Accessories Installation Manual", January 1986, published
by Hewlett-Packard Co..  HP Part No. 5955-7680.  $45.00.  Order from H.P.
Direct at 1-800-538-8787.

This manual is somewhat dated and contains instructions for installing thick
cable transceivers that are obsolete, for instance.  On the other hand, the
network configuration information is useful and the guidelines for
routing cables and grounding issues are informative.  My major disagreement
with H.P.'s grounding instructions is that they allow metallic cable between
building frames if H.P.'s surge arrestors are installed.  Given the
ease of using fiber optic repeaters, and the dangers inherent in metallic
network cables that travel between building frames, there seems little
excuse for not using fiber in these situations.

In any event, the manual really shines when it comes to complete
descriptions of thick cable and thin cable wire strippers and connector
crimpers.  The H.P. manual has diagrams showing how to strip each kind of
cable and how to crimp on N connectors and BNC connectors.

There's a short section on verifying the cables you've built, and a longer
section on how to use a Time Domain Reflectometer to test networks.  Another
useful section is the one on how to open up a crimp tool that has been
closed on something you didn't want to crimp (like your finger!).  Don't
laugh - this section came in handy the other day when a student used a crimp
tool with a 75 ohm UHF crimp die in it to crimp a 50 ohm N connector.  The
instructions in the H.P. manual allowed us to get the mauled N connector out
without dismantling the whole tool and ruining the precision adjustments.


-- Access --

Aside from various phone numbers listed above, the following book stores can
be of service:

Computer Literacy Bookshop, 2590 North First St., San Jose, CA 95131.  Phone
408-435-1118 for mail orders.  A good source for computer and electronics
books of all kinds.  They carry the IEEE network standards, and can probably
supply most of the books listed above.

Jim Joyce's UNIX Bookstore, 47 Potomac St., San Francisco, CA 94117.  Phone
415-626-7581 for mail orders.  A handy resource for UNIX-related books of
all kinds, including the Douglas Comer books.

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jun 88 00:30 EST
From:      PMDF Mail Server <Postmaster@GRAD.CIS.TEMPLE.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Undeliverable mail
Your message could not be delivered to: 

    STAFFORD

Your message has been enqueued and undeliverable for 6 days.
The mail system will continue to try to deliver your message
for an additional 6 days.

The beginning of your message follows: 

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 88 19:54:59 GMT
From:      symchych@SKL-CRC.ARPA (Tim Symchych)
To:        comp.protocols.tcp-ip
Subject:   Re: Linking LAN's via Public X.25

Dan:
Yes, there are still versions of IP around in hosts that
do not perform well.  Regardless of some of the fine work
that has been done in end-to-end performance, we still
use what comes off the shelf, and if the vendors don't
put it out in the product, then we don't have it.  Most of our sites
have no interest in "patch and run" systems for their users.
Many people on this mailing list have covered this problem,
including the problems of mixing speeds on segments of the
path that traverse ethernet, leased lines and non-IP packet
switched nets. Except for ethernet LANS, all our links between
hosts use combinations of different link types.  I guess that
in our case, X.25 is the least of our problems.
Something I forgot to mention is that in our PDN connections
at 9600, we use 256 byte packets with a window size of up to
7 packets. I also received some hints on the 56 kbps X.25
line to our Butterfly from Dave Capshaw at Lockheed.  Seems
that some tuning may be possible between the PSN and the
Butterfly.
regards
tim

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 88 23:33:08 GMT
From:      jdc@naucse.UUCP (John Campbell)
To:        comp.misc,comp.protocols.tcp-ip,comp.os.vms
Subject:   cmu tcp-ip

I know that CMU's TCP/IP has been out for a while.  I would like
to hear from anyone who has used this implementation.  In particular,
I am interested in sites that have used TCP/IP terminal servers
with CMU TCP/IP on VMS.  I would like to say that this is a cost-effective
way to get out of LAT and away from DECServers.  Any comments?

Please mail directly to me.  Some of these groups I don't follow.  I
will summarize responses if there is any interest.

Also--if you know other VMS TCP/IP vendors and cost/quality information
send it along as well.  I'll include anything I get that pretains to
the above in my summary.

Thanks.
-- 
	John Campbell               ...!arizona!naucse!jdc

	unix?  Sure send me a dozen, all different colors.

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jun 88 07:01:42 CDT
From:      lhl@cs.wisc.edu (L.H. Landweber)
To:        tcp-ip@sri-nic.arpa
Subject:   SIGCOMM '88 Program
All,

Enclosed is the advance program and registration form for the 1988 ACM
SIGCOMM symposium.  SIGCOMM is THE ACM symposium on computer
communications.  This year we have a very strong technical program,
consisting of three days of conference papers, plus one tutorial day.

For more information about hotels and on-campus accommodations, please
contact Stanford University directly (415/723-3126).
Please note that VERY limited on-campus accommodations are available.

To expedite the registration process, you can send print outs of the
attached forms with payment.

Sincerely,

JJ Garcia-Luna
General Chair, SIGCOMM 88

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

			    ACM SIGCOMM 88 SYMPOSIUM
 			        ADVANCE PROGRAM
		 Communications Architectures and Protocols
			      August 16-19, 1988
		  Stanford University, Stanford, California


				  SYMPOSIUM
			      August 17-19, 1988


				August 17, 1988

9:00 - 10:00
Session 1: Keynote Session
	General Chair: J.J. Garcia-Luna-Aceves, SRI International, USA
	Program Chair: L. Landweber, University of Wisconsin, USA
	Student Paper Award: J.J. Garcia-Luna-Aceves, SRI International, USA 
	Keynote Address: Donald Nielson, SRI International, USA

10:30 - 12:00
Session 2: Local/Metropolitan Area Internets 
Chair: D. Anderson, Unviversity of California, Berkeley, USA

     Topological Analysis of Local-Area Internetworks
     (G. Trewitt, Stanford University) --- Student Paper
     Dynamic Resource Allocation in a Metropolitan Area Network
     (K. Maly, C. Overstreet, Old Dominion Univ.; 
     X. Qui, China State Shipbuilding Corporation, Peoples Republic
     of China; and D. Tang, Chengdu University of Science &
     Technology, Peoples Republic of China)
     Optical Interconnection Using ShuffleNet Multihop Networks in
     Multi-Connected Ring Topologies  
     (M.J. Karol, AT&T Bell Laboratories, USA)

1:15 - 2:45
Session 3: Routing 
Chair: L. Chapin, Data General Corporation, USA

    Landmark Routing:  Distributed Name-Based Routing for Very 
    Large Networks 
    (P.F. Tsuchiya, Mitre, USA)
    Pitfalls of a Certain Class of Distributed Routing Algorithms	
    (R. Perlman and G. Varghese, DEC, USA)
    Multicast Routing in Internetworks and Extended LANs
    (S.E. Deering, Stanford University, USA) --- Student Paper

3:15 - 5:15
Session 4: Transport Level and Operating System Issues 
Chair: S. Lam, University of Texas at Austin, USA

     Design of an x-Kernel 
     (N. Hutchinson and L. Peterson, Univ. of Arizona, USA)
     Exploiting Recursion to Simplify RPC Communication Architectures
     (D.R. Cheriton, Stanford University, USA)
     Service Specification and Protocol Construction for the Transport Layer 
     (S.L. Murphy and A.U. Shankar, Univ. of Maryland at College Park, USA)
     A Network Management Language for OSI Networks
     (U. Warrier, A. Relan, Unisys Corporation, USA; 
     O. Berry, IBM Science and Technology, Israel; 
     and J. Bannister, The Aerospace Corporation, USA)

7:00 pm - on
Banquet


				August 18, 1988

8:30 - 10:00
Session 5: Lessons of the Internet 
Chair: J. Mogul, Digital Equipment Corporation, USA

    Some thoughts on the DARPA Internet Architecture 
    (David Clark, MIT, USA)
    The Fuzzball 
    (D.L. Mills, University of Delaware, USA)
    Development of the Domain Name System 
    (Paul Mockapetris, USC Information Sciences Institute, USA)

10:30 - 12:00
Session 6: Local Area Network Architecture 
Chair: R. Cheung, Hewlett-Packard, USA

     Optimizing Bulk Data Transfer Performance: The Packet Train Model
     (C. Song and L.H. Landweber, University of Wisconsin, USA)
     --- Student paper
     A Mesh/Token Ring Hybrid-Architecture LAN 
     (C. Kang, The American University, USA;
     and J. Herzog, Oregon State University, USA)
     Tree LANs with Collision Avoidance: Protocol, Switch Architecture,
     and Simulated Performance
     (T. Suda, S. Morris, and T. Nguyen, 
     University of California, Irvine, USA)

1:15 - 2:45
Session 7: Very High Speed Networking 
Chair: D. Farber, University of Pennsylvania, USA

    An Analysis of Memnet - An Experiment in High Speed Memory Mapped
    Local Networking (G. Delp, A. Sethi, University of Delaware, USA;
    and D. Farber, University of Pennsylvania, USA)
    --- Student paper
    The VMP Network Adapter Board (NAB): High-Performance Network
    Communication for Multiprocessors 
    (H. Kanakia and D. Cheriton, Stanford University, USA) --- Student paper
    Fast Circuit Switching in Fiber Optic Networks
    (I. Chlamtac, A. Ganz, and G. Karmi, University of Massachusetts, USA)

3:15 - 5:15
Session 8. Measurement and Management 
Chair: V. Cerf, Corporation for National Research Initiatives, USA

     A Pseudo-Machine for Packet Monitoring and Statistics
     (R.T. Braden,  USC Information Sciences Institute, USA)
     Knowledge-Based Monitoring and Control: An Approach to
     Understanding the Behavior of TCP/IP Network Protocols
     (B.L. Hitson, Stanford University, USA) --- Student paper
     Measured Capacity of an Ethernet
     (D.R. Boggs, J.C. Mogul, and C.A. Kent, DEC, USA)
     Distributed Testing and Measurement across the Atlantic Packet
     Satellite Network (SATNET)
     (K. Seo, BBN, USA; J. Crowcroft, UCL, England; 
     P. Spilling, Norwegian Telecommunications Administration, Norway;
     J. Laws, Royal Signals and Radar Establishment, Englanand;
     and  C. Topolcic, BBN, USA)

5:30 - 7:00
Reception

				August 19, 1988

8:30 - 10:00
Session 9: Communication Protocol Design and Testing 
Chair: D. Mills, University of Delaware, USA

    A Multicast Transport Protocol 
    (J. Crowcroft and K. Paliwoda, University College London, England)
    Experience with Test Generation for Real Protocols
    (D. Sidhu and T. Leung, Iowa State University, USA)
    Performance Models for Noahnet
    (G.M. Parulkar, A.S. Sethi, D.J. Farber, University of Pennsylvania, USA)

10:30 - 12:00
Session 10: Broadcast Issues 
Chair: D. Sidhu, Iowa State University, USA

     A High Performance Broadcast File Transfer Protocol
     (J.S.J. Daka, A.G. Waters, University of Essex, England)
     Specification and Verification of Collision-Free Broadcast Networks 
     (P. Jain and S.S. Lam, University of Texas, Austin, USA)-- Student Paper
     Delivery and Discrimination: The Seine Protocol
     (M. Gouda, University of Texas at Austin, USA;
     N. Maxemchuk, U. Mukherji, and K. Sabnani,
     AT&T Bell Laboratories, USA)

1:15 - 2:45
Session 11: Congestion and Topology Control 
Chair: J.J. Garcia-Luna-Aceves, SRI International

     An Explicit Binary Feedback Scheme for Congestion Avoidance in
     Computer Networks with a Connectionless Network Layer
     (K.K. Ramakrishnan and  R. Jain, DEC, USA)
     Congestion Avoidance and Control 
     (Van Jacobson, Lawrence Berkeley Laboratory, USA)
     A Protocol to Maintain a Minimum Spanning Tree in a Dynamic Topology
     (C. Cheng, I. Cimet, P. Kumar, Northwestern Univ., USA)


3:00 - 5:00
Session 12: Panel on Internet Engineering
Chair: P. Gross, Mitre, USA
Panelsists to be announced

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



				   TUTORIALS
				August 16, 1988
				9:00 am - 5:00 pm

	            1. INTEGRATED SERVICES DATA NETWORKS:
			  NARROWBAND AND BROADBAND
			      (Mario Gerla, UCLA)


				   Abstract

ISDN is one of the newest " buzzwords " in the communications arena.
The concept is extremely appealing: by integrating various services (
voice, data, video etc.) in a common network we will be able to achieve
lower operating costs, higher efficiency, better
availability/maintainability and higher flexibility in the introduction
of new services.This concept is now becoming a reality, and both users
and service providers are taking into account the potential of ISDN's
in formulating their plans.

This seminar will review the evolution of the ISDN concept during the
past few years,will discuss the standard recommendations, will compare
implemen- tation alernatives and finally will report on recent field
trials.  In organizing this seminar , the attempt was to maintain a
good balance between design principles, standard recommendations and
actual network implementations.


		                Outline

	- Why integrated services
	- Narrowband and Broadband ISDN's
	- Standard recommendations
	- ISDN backbone implementation alternatives
	   ( Packet/Circuit/Hybrid switching)
	- ISDN routing and flow control
	- Service integration in MAN's and LAN's
	- Field trials
	- Future trends

                              Biography

Professor Mario Gerla received the PhD degree in engineering from the
University of California, Los Angeles (UCLA), in 1973.  From 1973 to
1976, he was Network Planning Manager at Network Analysis Corporation.
>From 1976 to 1977, he was with Tran Telecommunications, Los Angeles,
where he participated in the development of integrated packet and
circuit networks.  In 1977, he joined UCLA and is now a Professor in
the Department of Computer Science.  His research interests include the
design and control of distributed computer communications systems and
networks, and the development of high-speed local area networks.
 

   		2. MULTI-HOP TOPOLOGIES, BRIDGES AND ROUTERS
			   (Radia Perlman, DEC)

			         Abstract

A Local Area Network (LAN) allows direct communication between any
stations directly connected to the LAN.  Route computation and
forwarding nodes are not necessary.  However, technology and
performance constrains the topology, distance, and number of stations
of a single LAN.  Thus a network usually needs to grow beyond the
limits of a single LAN.  One method of interconnecting LANs is through
"Bridges".  Two different schemes for interconnecting LANs are being
standardized by two different subcommittees of the IEEE 802 committee,
which is standardizing LANs.  These two schemes are "spanning
tree/transparent" bridges, and "source routing" bridges.  Another
method of creating a network with multiple links is through "routers".
These too are being standardized by various committees.  "Routers"
perform the "Network Layer Protocol" as defined by the ISO reference
model.

This tutorial will briefly review the ISO reference model.  It will
explain the two bridge schemes, and contrast their functionality and
performance.  It will explain the functionality of the Network Layer,
and explain design alternatives for meeting this functionality.  The
emphasis will be placed on the design of a "connectionless" style of
Network Layer.  No background other than intellectual curiosity is
required.  Emphasis is on protocol concepts rather than specifics of
the schemes, or mathematical analysis.

                               Outline

     o   ISO Reference Model Review (20 minutes)
     o   LAN review -- CSMA/CD, token ring, token bus (15 minutes)
     o   Bridges -- Spanning Tree, Source Routing, Comparisons (1 1/2
         hours)
     o   Network Layer functionality -- connection oriented vs
         connectionless, routing, fragmentation and reassembly,
         autoconfigurability, addressing (45 minutes)
     o   Routing Algorithms -- "Distance Vector" vs "Link State" (2
         hours)
     o   Depending on time and interest, remaining time can be spent
         exploring the design implications of:
         -   interoperability of spanning tree and source routing
             bridges
         -   Network Layer autoconfigurability
         -   Design implications of hierarchical networks; subnetwork
             partition problem, subnetwork autonomy

                              Biography

Radia Perlman is a consulting engineer at Digital Equipment
Corporation.  She designed the spanning tree algorithm used by
Digital's bridges and adopted for use by both bridge standards
(transparent bridges and source routing bridges).  She also was
responsible for the design and specification of the Network Layer in
Digital's Network Architecture, aspects of which have been adopted by
ISO for use in the standard connectionless Network Layer.

She has taught as adjunct faculty at the graduate schools of Wang
Institute and University of Lowell, and at the Wang Summer Institute.
She received the B.S.  and M.S.  degrees in mathematics at MIT, and is
currently pursuing a Ph.D.  degree in Computer Science at MIT. 


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

                        TUTORIAL AND SYMPOSIUM REGISTRATION


Please check applicable fees:


					ADVANCE			REGULAR
				     (before 7/25/88)

	TUTORIAL 1:
____	ACM members			$200			$250
____	Non-members			 250			 300
____	Full-time students**		 100 			 150

	TUTORIAL 2:
____	ACM members			$200			$250
____	Non-members			 250			 300
____	Full-time students**		 100 			 150

	SYMPOSIUM*:
____	ACM members			$200			$250
____	Non-members			 250			 300
____	Full-time students**		 100			 150


* Reception and banquet fees will be included in the recidence hall
  registration package.

** Student registration must be accompanied by a copy of valid full-time
   student ID. Must be ACM member.

TOTAL PAYMENT MUST BE INCLUDED IN US$.  $____________.

Advance registration payment must be received by July 25, 1988.  After
that date, please wait to register at the Symposium itself.  Make
checks payable in US$ to ACM SIGCOMM.  There will be a $10.00 Surcharge
on foreign banks.

Please return tutorial and symposium registration form and complete
payment to: Dr.  J.J.  Garcia-Luna-Aceves, SRI International, 333
Ravenswood Ave., Menlo Park, CA 94025, USA; tel: (415) 859-5647;
e-mail: garcia@sri.com.


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

	                   APPLICATION FOR RESIDENCE HALLS


Room and meal payments are due upon arrival.  DO NOT PAY IN ADVANCE.
All payments must be in $US dollars, and made in cash, traveler's
checks, or personal checks from a U.S. Bank  made payable to
Stanford University.

A VERY LIMITED number of rooms in Stanford University are available on
a first-come, first-served basis.  Complete this form and return it, no
later than July 25, 1988, to Dr. J.J. Garcia-Luna-Aceves, SRI International, 
Menlo Park, CA 94035; Tel: (415) 859-5647; e-mail: garcia@sri.com.


RATES:

PLAN I - Room for 4 nights (Mon., Tue., Wed., and Thurs.) and 10 meals
from Tue. breakfast thru Fri. lunch (omitting Wed. Dinner).

	Single room - $102.00,    shared room - $76.00
	      meals     95.00           meals - $95.50
		       -------			-------
		      $197.50                  $171.50 per person


PLAN II - Room for 3 nights (Tues., Wed., Thurs.) and 7 meals
(breakfast and lunch on Wed., Thurs., Fri., and dinner on Thursday.

	Single room -  $76.50,    shared room - $57.00
	      meals     65.00           meals - $65.50
		       -------			-------
		      $141.50                  $122.50 per person

EXTRA NIGHT'S STAY: single room - $25.50, shared room - $19.00 per person.

CHILDREN: 10 yrs.  old and under are charged half rate for housing and
meal package. 


RESIDENCE HALL REQUIREMENTS:

Name: ____________________________________________________________
	Last				First		Middle

Address: _________________________________________________________
	 _________________________________________________________
	 _________________________________________________________

____ Plan I,  ____ Plan II
____ Single,  ____ Double
____ Female,  ____ Male
____ Smoking, ____ Nonsmoking

Preferred rommate: ________________________________________________
Date and time of arrival: _________________________________________
Date and time of departure: _______________________________________


_________________________________________________________________________

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jun 88 15:12
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@relay.MOD.UK>
To:        tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa>
Cc:        
Subject:   Re: Linking LAN's via Public X.25
 
>Perhaps another view of IP over X.25 might help.  While the original
>question was asked about Sun X.25, there are a number of networks within the
>ARPA/Internet that use IP over X.25.
 
Yet another view. The RSRE Internet Lab connects to two other European
Internet sites (one in Holland and one in Germany) and others internal
to the UK running IP over X.25. Quality of service is good and at
current traffic levels is much cheaper than international/national leased
circuits. The software has been developed to pay attention to the fact
that real money is being spent e.g. virtual circuits close if IP traffic
stops, and of course accounting and access control are well developed.
 
If national X.25 provision by US carriers is seen as less than adequate,
by US users, maybe its because they (the carriers) do not see it as a
viable commercial market to make a big investment in given the existing
'free' networks like Arpanet, Milnet, NSFnet etc. YES I DO KNOW that
they are not really free - that Government, Academic institutions and
companies make payments. But in many cases the users at the keyboard
are unaware and uncaring of the costs (judged by many of the remarks
in this forum some months ago).
 
John
 
 
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 88 13:48:35 GMT
From:      guru@flora.wustl.EDU (Gurudatta Parulkar)
To:        comp.protocols.tcp-ip
Subject:   A couple of questions

Has anybody successfully installed Van Jacobson's tcp/ip on a 
binary only sun 3/50 ? Please let me know. I need some help.

Are there any good references on operating large campus networks which
talk about administrative as well as technical issues ? I have 
accumulated a lot of info from this and other bboards, but want
to check if there are any comprehensive papers on the subject.

Thanks in advance.

-guru

Dr. Guru Parulkar
Asst Professor             guru@flora.wustl.edu
Dept of Computer Science   parulkar@udel.edu 
Washington University      wucs1!guru@uunet.uu.net
St. Louis MO 63130 
(314) 889-4621

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 88 13:48:35 GMT
From:      @hplabs.hp.com  (Gurudatta Parulkar)
To:        tcp-ip@sri-nic.arpa
Subject:   A couple of questions
Has anybody successfully installed Van Jacobson's tcp/ip on a 
binary only sun 3/50 ? Please let me know. I need some help.

Are there any good references on operating large campus networks which
talk about administrative as well as technical issues ? I have 
accumulated a lot of info from this and other bboards, but want
to check if there are any comprehensive papers on the subject.

Thanks in advance.

-guru

Dr. Guru Parulkar
Asst Professor             guru@Dept of Computer Science   parulkar@udel.edu 
Washington University      wucs1!guru@uunet.uu.net
St. Louis MO 63130 
(314) 889-4621


#! rnews 1443e wind th: ucb
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 88 18:09:46 GMT
From:      MRC@PANDA.PANDA.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Linking LAN's via Public X.25

Dan -

     I'm responsible for one of the TCP/IP implementations used on a
9600 baud link in Canada.  The system is a DEC-2065 running a TOPS-20
with a heavily modified TCP.  It has two IP interfaces; a NIA20 to the
local Ethernet and an AN20 to a C/30 PSN using 1822.

     This TCP lacks RFNM counting which is a serious deficiency, but
in the case of this link it doesn't really matter all that much since
(at least the last I read) there is only one place for the 1822-grams
to go to.  If you're RFNM blocked to the friendly not-so-local gateway,
you can't do anything anyway.

     What makes the burden worse, this machine is the only path between
the local Ethernet (which talks TCP/IP and DECnet) and the rest of the
world.  It has a rudimentary EGP-speaker that babbles updates to Friend
Gateway.

     I've seen no indication of a bottleneck at the DEC-20.  Instead,
it seems to be more that the DEC-20 (and the Symbolics Lisp machines
behind it on the Ethernet) are communicating almost exclusively with
the Internet in the US, across two gateways over a long long wire.
There isn't all that much traffic to begin with, so any latency in a
connection can easily stop the line...because there is no other traffic!

-- Mark --
-------

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 88 22:12:00 GMT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re: Linking LAN's via Public X.25


 
>Perhaps another view of IP over X.25 might help.  While the original
>question was asked about Sun X.25, there are a number of networks within the
>ARPA/Internet that use IP over X.25.
 
Yet another view. The RSRE Internet Lab connects to two other European
Internet sites (one in Holland and one in Germany) and others internal
to the UK running IP over X.25. Quality of service is good and at
current traffic levels is much cheaper than international/national leased
circuits. The software has been developed to pay attention to the fact
that real money is being spent e.g. virtual circuits close if IP traffic
stops, and of course accounting and access control are well developed.
 
If national X.25 provision by US carriers is seen as less than adequate,
by US users, maybe its because they (the carriers) do not see it as a
viable commercial market to make a big investment in given the existing
'free' networks like Arpanet, Milnet, NSFnet etc. YES I DO KNOW that
they are not really free - that Government, Academic institutions and
companies make payments. But in many cases the users at the keyboard
are unaware and uncaring of the costs (judged by many of the remarks
in this forum some months ago).
 
John
 
 

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 88 05:25:19 GMT
From:      roode@orc.olivetti.COM (David Roode)
To:        comp.protocols.tcp-ip
Subject:   Re: Linking LAN's via Public X.25

There's no question that X.25 packet switching is a service built on
top of point-to-point data circuit (leased line) capability.  The
tariffs in the U.S treat this as a 'value added' service and prohibit
the basic operating companies from competing in the national market.
The Public Data Networks offering packet services have to pay the same
leased line rates as an end-user, both for backbone circuits and for
ties between their switch locations and customer premises.
At the same time, the charges for leased line service are obviously
much cheaper in the U.S. than they are elsewhere.  (It calls for a
judgement, but it seems likely that much in excess of costs is
recovered in the charges for leased line service in Europe.)

As a result, it may be illogical to 'blame' the U.S. Public Data Nets
for their charges.  European PTT's may subsidize their X.25 offerings.
U.S. PDN's see reduced usage volume due to reasonable competition from
leased lines. The main service a PDN provides is the sharing of data
circuits.  So, in the U.S. a smaller fraction of uses see an economic
incentive to share costs by making use of a PDN.  (It takes a smaller
volume of usage to cost justify switching to a leased line in the
U.S.)  The operating efficiency of the U.S. PDN's may be the same or
even higher than the European PTT's in providing PDN service.

It appears the hierarchy in terms of increasing cost for a 2400 baud
data flow is something like:

	leased lines at U.S. typical rates
	Public Data nets at European rates
	Public Data nets at U.S. rates
	leased lines at European rates

For 300 baud data flow, it is something like:

	Public Data nets at European rates
	Public Data nets at U.S. rates
	leased lines at U.S. typical rates
	leased lines at European rates

For 9600 baud data flow, sequence might be:

				    -or-
	leased lines/ U.S. rates	leased lines/ U.S. rates
	Public Data nets/ U.S. rates	Public Data nets/ U.S. rates
	Public Data nets/ Europe rates	leased lines/Europe rates
	leased lines/Europe rates	Public Data nets/ Europe rates

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Sun, 05 Jun 88 12:40:10 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        guru@flora.wustl.edu
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: a couple of questions

Installing Van Jacobson's TCP on a SUN 3/50 is quite simple.  There is
a special Makefile.sun that makes it easy to generate *.o files you
can stick in /sys/OBJ.  It also works wonderfully -- my TCP connections
have been noticeably happier.

Installing the entire Berkeley distribution (with the IP fixes, etc) is
quite difficult -- it requires porting the software to the SUN.

Craig
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Jun 88 20:38:52 PDT
From:      nowicki@Sun.COM (Bill Nowicki)
To:        guru@flora.wustl.EDU
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  A couple of questions
	From: guru@flora.wustl.EDU (Gurudatta Parulkar)
	Date: 4 Jun 88 13:48:35 GMT

	Has anybody successfully installed Van Jacobson's tcp/ip on a 
 	binary only sun 3/50 ? 

Yes. Several thousand have.  It is in the current software release, 
SunOS 4.0.

	- Bill Nowicki
	  Sun Microsystems
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 88 16:40:10 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: a couple of questions


Installing Van Jacobson's TCP on a SUN 3/50 is quite simple.  There is
a special Makefile.sun that makes it easy to generate *.o files you
can stick in /sys/OBJ.  It also works wonderfully -- my TCP connections
have been noticeably happier.

Installing the entire Berkeley distribution (with the IP fixes, etc) is
quite difficult -- it requires porting the software to the SUN.

Craig

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 88 21:02:42 GMT
From:      melohn@SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: A couple of questions

In article <8806041348.AA06264@lora.wustl.edu> guru@wra.wustl.EDU (Gurudatta Parulkar) writes:
>Has anybody successfully installed Van Jacobson's tcp/ip on a 
>binary only sun 3/50 ? Please let me know. I need some help.

Van's XTCP work is included in SunOS 4.0, which should be available
now at a Sun sales office near you.

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 88 09:13:53 GMT
From:      mcgill-vision!mouse@BLOOM-BEACON.MIT.EDU  (der Mouse)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: FTP server question
In article <8805261929.AA04199@RHEA.CAM.UNISYS.COM>, jonab@CAM.UNISYS.COM (Jonathan P. Biggar) writes:
>> The TCP URGENT mechanism uses a pointer; I do not think that there
>> is any specification which says that packet boundaries are
>> significant with respect to URGENTs.
> Not so!  RFC 793 states:
>	If there is urgent data [...].  *****Note that data following
>	the urgent pointer (non-urgent data) cannot be delivered to the
>	user in the same buffer with preceeding urgent data unless the
>	boundary is clearly marked for the user.*****

What does this have to do with packet boundaries?  Jonab said "packet",
not "user buffer".

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 88 09:37:43 GMT
From:      mcgill-vision!mouse@bloom-beacon.mit.edu  (der Mouse)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Convert /etc/hosts to RR format pgm anyone?
In article <21877@amdcad.AMD.COM>, indra@amdcad.AMD.COM (Indra K. Singhal) writes:
> Has anyone put together a program/shell script that converts
> /etc/hosts to the standard RR format as specified in the RFCs listed?

You probably don't want to do this as simply as you think.  Why?

- /etc/hosts generally doesn't have domain-style addresses in it
- You'll need in-addr.arpa records too
- You probably want to put each domain into a file of its own, with SOA
   and NS records and suchlike....

If you really do want to just convert /etc/hosts to a bunch of A
records, it's hardly complicated....

< /etc/hosts sed -e 's/#.*//' \
| awk '{ for (i=2;i<=NF;i++) printf("%s\tin\ta\t%s\n",$i,$1); }' \
> wherever-you-want-the-RRs

(The resulting RRs should be loaded with a $ORIGIN of ., of course.)

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 88 10:22:43 GMT
From:      richier@imag.imag.fr (Jean-Luc Richier)
To:        comp.protocols.tcp-ip
Subject:   gateways and more-than-one-IP-net on one ethernet

I have a problem with the 4.3 version of TCP-IP, when I use both gateways and
multiple nets on one ethernet.

Description:
    I have a ethernet LAN which contains 2 IP networks (In fact, it consists of
    two ethernet networks, interconnected with Level 2 Bridges).
    There is also a gateway on the LAN, which provides acess to a third network.

    The structure is as follows (with arbitrary IP numbers):

	etherLAN  IP-net-A(192.0.0.xx)  IP-net-B(192.0.1.yy)
      --------------------------+---------------------------------
				| Gateway (addr 192.0.0.1, dstaddr 192.0.2.1)
				|
				| Gateway (addr 192.0.2.2, dstaddr 192.0.0.2)
      --------------------------+---------------------------------
		etherLAN  IP-net-C(192.0.2.xx)

  The machines on IP-net-A use the route commands:
	route add network IP-net-B <name of the machine> 0
	route add network IP-net-C 192.0.0.1 1
  The machines on IP-net-B use the route command:
	route add network IP-net-A <name of the machine> 0

  The problem is that I cannot access the net IP-net-C from machines on
  the net IP-net-B: The route command
	route add network IP-net-C 192.0.0.1 1
   is refused, with the message "network is unreachable"

I have been unable to solve this problem with route, routed, or even by
using the "arp -s" command (trying to use proxy arp).

About 6 months ago, some persons in netland (in comp.protocols.tcp-ip)
suggested the idea of declaring more than one ethernet interface, in
order to solve the problem of more than one net on a LAN, each with
subnet and non standard broadcast addresses. I have been unable
to implement this solution (on Vax or Sun, these interfaces do not
configure, and therefore ifconfig does not work).

Is there any solution? I can think of many, but they all ask for modifications
in the kernel source. I hope that there is simpler solutions.

------------
Jean-Luc Richier
richier@imag.imag.fr or richier@imag.UUCP or uunet.uu.net!imag!richier

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 88 13:18:29 GMT
From:      wingo@ncrcae.Columbia.NCR.COM (Dave Wingo)
To:        comp.protocols.tcp-ip
Subject:   rlogin to self with host name not loopback

I have a question concerning tcp/ip rlogin and/or telnet. If you are trying
to rlogin/telnet to yourself using your own host name and not the loopback
interface should the traffic generated be kept internal to your host or
must it go out on the net. Is there a standard defining this situation or
is it just an implementation detail.

Thanks in advance.....

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Mon, 06 Jun 88 20:11:25 -0400
From:      Edward F. Beadel Jr. <beadel@oswego.oswego.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP/IP for PDP-11 running TSX (RT11)
In regard to Kurt Zeilenga's (kurt@hc.dspo.gov) question about TCP/IP
for RT-11. The following message is from the info-pdp11 mailing list.

-ed
***********************************************************************
Edward F. Beadel, Jr., Assistant Director
Instructional Computing Center          
SUNY College at Oswego                 beadel@oswego.Oswego.EDU
Oswego, NY  13126 (315)-341-3055       
***********************************************************************

------- Forwarded Message

>From rna!dan%cmcl2.NYU.EDU@cmcl2.NYU.EDU  Fri Jun  3 22:24:41 1988
Date: Fri, 3 Jun 88 20:27:03 EDT
>From: rna!dan@cmcl2.NYU.EDU (Dan Ts'o)
Message-Id: <8806040027.AA22899@rna>
To: cmcl2!oswego.oswego.edu!beadel@cmcl2.NYU.EDU, info-pdp11@sei.cmu.edu
Subject: Re:  RT-11 question from the TCP-IP mail

	You can always get the Process Software telnet and ftp for RT-11.
I think they want about $1000 for it.

				Cheers,
				Dan Ts'o		212-570-7671
				Dept. Neurobiology	dan@rna.rockefeller.edu
				Rockefeller Univ.	...cmcl2!rna!dan
				1230 York Ave.		rna!dan@nyu.edu
				NY, NY 10021		tso@rockefeller.edu

------- End of Forwarded Message

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 88 13:31:35 GMT
From:      wingo@ncrcae.Columbia.NCR.COM (Dave Wingo)
To:        comp.protocols.tcp-ip
Subject:   streams based vs character based tcp/ip on UNIX

Has anyone compared the character based tcp/ip vs the streams based tcp/ip
for UNIX. Does one out perform the other? Is one larger than the other?

Thanks for your comments and responses in advance.

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 88 18:53:11 GMT
From:      phil@amdcad.AMD.COM (Phil Ngai)
To:        comp.periphs,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Wanted: Delni

In article <5398@coherent.com> celeste@coherent.com (Celeste C. Stokely) writes:
>Save yourself a lot of grief and don't buy a Delni. They seems to suffer
>from some of the worst quality control problems I've ever seen. If you get
>a good one, they're great, but it's hard to get a good Delni.

Could you go into more detail on this? How can you tell if your DELNI is bad?

We have used a lot of Cabletron equipment and are very happy with them also.
Mostly transceivers. We started using DELNIs before Cabletron was around
and for lack of any problems directly attributed to them stuck with them.

By coincidence, we are seeing problems in a new building and I wonder if
the DELNIs are the culprit.
-- 

I speak for myself, not the company.
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 88 19:22:24 GMT
From:      dunigan@MSR.EPM.ORNL.GOV (Tom Dunigan 576-2522)
To:        comp.protocols.tcp-ip
Subject:   seeking info on security features of tcp/ip

We are gathering information for a CS reading course on aspects 
of network security supported by TCP/IP -- from the data layer to the
application layer.  We would very interested in any information
on current research, publications, RFC's, etc. relating to network
security with respect to TCP/IP.  Does anyone use the security options
of IP?

	     thanks
	      Tom Dunigan
	      dunigan@msr.epm.ornl.gov

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 88 20:38:00 GMT
From:      mishkin@apollo.uucp (Nathaniel Mishkin)
To:        comp.protocols.tcp-ip
Subject:   XNS over non-Ethernet

OK, I *know* this isn't an IP questions, but there's no XNS mailing list
/ news group that I know of and I'm sure some reader of this group must
know the answer, so...

Has anyone ever run XNS over a data link that was addressed differently
from Ethernet?  If so, what did they do?  ARP?

Thanks.

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 88 21:59:22 GMT
From:      hunaid@stanford.CRAY.COM (Hunaid Engineer)
To:        comp.protocols.tcp-ip
Subject:   IP security

I will working on putting some sort of IP security to our TCP/IP
code. Any ideas or examples.

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 88 00:19:04 GMT
From:      wiltzius@lll-lcc.aRpA (Dave P. Wiltzius)
To:        comp.protocols.tcp-ip
Subject:   More IP Security


We at LLNL would like to use the IP security option.  See the
plea for help below.  Also talked with people at LANL (sorry,
the former is Lawrence Livermore Nat'l Lab and the latter is
Los Alamos Nat'l Lab) and Sandia Labs.  Apparently all three
labs are ready to migrate to TCP/IP to some degree.  All three,
I think it is safe to say, will need one or both of the
IP security options (LLNL apparently will need both).

I would recommend getting familiar with RFC 1038 even though
it is a draft since (at least a few) vendors are already
complying with it.

RFC 1038 specifies the use of the IP Basic security option and
defines the IP Extended security option.  I know of a few vendors
of IP routers that intend to comply with RFC 1038 and one vendor
of TCP/IP products for hosts (TWG) that intends to comply with
it.

Anyone know what kind of support for RFC 1038 can be expected from
DEC (Ultrix in particular), SUN and others (Ardent, Silicon Graphics,
etc)?  The local sales folks want to help but . . .

Thanks.
  Dave (wiltzius@lll-lcc.llnl.gov)

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jun 88 10:52:51 PDT
From:      braden@venera.isi.edu
To:        tcp-ip@sri-nic.arpa
Cc:        braden@venera.isi.edu, ietf-hosts@nnsc.nsf.net
Subject:   FTP Logical Byte Sizes

Some time ago there was a discussion on this list about the use of the
TYPE L <logical byte size> command in FTP, but I don't recall the details.
I would appreciate hearing from anyone who does remember the discussion;
I vaguely remember that a question from Mark Crispin started it off.

Any wisdom you can recall or invent will find its way into the
"Requirements for Internet Hosts" RFC that is being drafted by an
IETF Working Group.  Do you have an application that requires some
use of TYPE L?

Thanks.

  Bob Braden
  
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 88 04:34:02 GMT
From:      peter%infidel@LANL.GOV (Peter Ford)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: Delni

We have a cabletron DELNI clone which is better than the old DELNIs 
since it is loaded with lights which have helped in network debugging.
I have found both DELNIs and Cabletron clones to be equally
reliable (haven't seen either fail yet), but I am serious about those lights,
I would buy a Cabletron MT-800 every time.

Some of us still like those blinking lights on our gear and hope
that they come back in style on all equipment.  

Peter Ford
Center for Nonlinear Studies
peter@lanl.gov

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Tue, 07 Jun 88 13:52:25 -0500
From:      Gurudatta Parulkar <guru@flora.wustl.edu>
To:        nowicki@sun.com (Bill Nowicki)
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: A couple of questions

    	From: guru@flora.wustl.EDU (Gurudatta Parulkar)
    	Date: 4 Jun 88 13:48:35 GMT

    	Has anybody successfully installed Van Jacobson's tcp/ip on a 
     	binary only sun 3/50 ? 

>    Yes. Several thousand have.  It is in the current software release, 
>    SunOS 4.0.

Very true except several thousands like us haven't yet received the
SunOS 4.0! And I am interested in having the Van Jacobsen's "source"
code for TCP AND IP on my otherwise binary only Sun 3/50. As Craig
pointed out TCP is not a problem, but IP part has to be actually
ported to sun. I guess the revised question should be 

has anybody successfully ported the IP part of Van Jacobsen's code to
sun 3/50 and is willing to let others use the revised source code ? 

I hope this makes some sense.

-guru             guru@flora.wustl.edu or parulkar@udel.edu



-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Tue 7 Jun 88 17:36:02-PDT
From:      Vince Fuller <VAF@Score.Stanford.EDU>
To:        braden@VENERA.ISI.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, ietf-hosts@NNSC.NSF.NET
Subject:   Re: FTP Logical Byte Sizes
The TOPS-20 FTP software uses TYPE L 36 when transferring files between TOPS-20
machines (and TOPS-10's/TENEX's, for that matter...). I believe the bit-packing
is done essentially identically to TYPE I for 36-bit words. The TOPS-20 FTP
software also supports other, arbitrary file byte sizes using TYPE L xx and
sets the file byte size on the target machine accordingly.

	Vince Fuller,
	Stanford Networking Systems
	(formerly CMU TOPS-20/networking hacker)
-------
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 88 11:55:27 GMT
From:      osu-cis!att!oucsace!oucs!wright!jsloan@tut.cis.ohio-state.edu  (John Sloan)
To:        tcp-ip@sri-nic.arpa
Subject:   Experience with Xyplex Terminal Servers?
Our main campus computer center is evaluating a terminal server
manufactured by Xyplex that speaks both TCP/IP and DECnet. We in
Computer Science have never heard of this beast, having settled on
Encore Annexen, and are interested in anyone's comments regarding how
well the Xyplex works, long term reliability, ease of configuration and
management, caveats, etc. Email, and if there's any interest, I'll be
glad to summarize and post.

Thanks much.

-- John Sloan
   CSNET: jsloan@SPOTS.Wright.Edu
-- 
John Sloan, The SPOTS Group    Wright State University Research Building
CSNET: jsloan@SPOTS.Wright.Edu  3171 Research Blvd., Kettering, OH 45420
UUCP:  ...!wright!jsloan                +1-513-259-1384  +1-513-873-2491
Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Tue 7 Jun 88 16:57:03-EDT
From:      Ken Rossman <sy.Ken@CU20B.CC.COLUMBIA.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Wanted: Delni [blinking lights]
I'll put in a "third" on that one.  I miss those little status lights.
It's a shame that pricing competition has gotten vendors to a point where
they feel they need to shave off a few bucks by tossing out "needless"
status lights in favor of some remote "console" (maybe, if that)...
-------
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 88 13:29:00 GMT
From:      necntc!dandelion!ulowell!apollo!mishkin@ames.arc.nasa.gov  (Nathaniel Mishkin)
To:        tcp-ip@sri-nic.arpa
Subject:   Point-to-Point links
I wonder whether someone would be so kind as to tell me the revealed
truth about the assignment of IP network numbers to point-to-point links
(like SLIP).  From what I can tell from munging around 4.3bsd, it seems
that not everyone (e.g. 4.3bsd) assigns a separate IP network number
to the link itself.  I thought it was always the right thing (if a waste)
to assign the link a network number.  Can someone tell me how to think
about this?  Thanks.
-- 
                    -- Nat Mishkin
                       Apollo Computer Inc., Chelmsford, MA
                       {decvax,mit-eddie,umix}!apollo!mishkin
                       apollo!mishkin@mit-eddie.arpa
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 88 13:33:00 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: Delni [blinking lights]

In article <8806070434.AA09530@infidel.lanl.gov.ARPA> peter%infidel@LANL.GOV (Peter Ford) writes:
>Some of us still like those blinking lights on our gear and hope
>that they come back in style on all equipment.  
>
	I heartily second that.  One of the interesting things I note
on the new unshielded twisted pair Ethernet gear from Cabletron is a
"Link OK" status light.  I was delighted to hear that Cabletron (and
possibly others) are using a 1 MHz idle "tone" on the circuit to
indicate "continuity" in the link.  This is much better than a simple
power light and should help find swapped pairs and dead circuits.  I
understand that the 802.3 committee is considering standardizing a
"Link OK" idle signal (on UTP and fiber[?]).  I hope they do.

	Never underestimate the power of a little LED.

	Kent England, Boston U

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 88 16:50:23 GMT
From:      kwe@bu-cs.bu.edu  (kwe@bu-it.bu.edu (Kent W. England))
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Point-to-Point links
In article <3c8494c7.13422@apollo.uucp> 
mishkin@apollo.UUCP (Nathaniel Mishkin) writes:
>I wonder whether someone would be so kind as to tell me the revealed
>truth about the assignment of IP network numbers to point-to-point links
>(like SLIP).  

	Here's an example from Proteon.  Proteon added the feature of
NOT using IP subnets on serial links to Rel 7.4 (circa last summer).
Prior to 7.4 you HAD to use a subnet.  What do you give up?  Here's
what Proteon said in the 7.4 release notes:

	o  can't ping the interface
	o  cannot run EGP over the interface
	o  cannot boot from that interface (serial line boot added rel 8.0)

	The problem with omitting an IP subnetted address from a
serial interface has to do with identifying that interface.  Proteon
says that "for routing decisions, such a serial line [no IP addr] is
considered to be a part of each subnetted network present in the
gateway." 

	Of course, the big lose with IP addresses is "wasting" all
those two node subnets.

	Use addresses for finer control.  Don't use them if you don't
have subnets to "waste".  However, you should design the option in for
your customers.

	Kent England, Boston U
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Wed, 08 Jun 88 01:50:05 -0400
From:      Buz Owen <ado@VAX.BBN.COM>
To:        "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
Cc:        braden@VENERA.ISI.EDU, ietf-hosts@NNSC.NSF.NET, tcp-ip@SRI-NIC.ARPA, ado@bbn.com
Subject:   Re: FTP Logical Byte Sizes
In addition to being useful with 36 bit pdp10 and related machines, local byte
size 8 is useful with the BBN C/70, which has a 20 bit word and a 10 bit byte
size.  While a discussion of choices of reasonable machine word sizes, and
important or unimportant machine architectures would be inappropriate (and
boring, or maybe annoying) on this list, type L 8 is useful to tell the C/70 to
send just the low 8 bits of each byte, a common type of file on the C/70 --
what you normally get as output from a C program that writes an 8 bit binary
file -- or store such a file.  Using Image mode instead, you get the unused
zero bits sent through the net, wasting network bandwidth and machine cycles,
as the C/70 laboriously repacks bits into 8 bit bytes -- and then have to
run a program to strip the bits out at the other end.

So for both the C/70 and pdp10 type architectures, type L 8 tells the machine
to skip over unused bit positions -- the pdp10 put these bits at the end of
each word, the C/70 puts them in the high order position of each byte.  Thus
local byte size is important if you want to assure compatibility with possible
"odd" machines in the future, or with existing ones you know you need to
communicate with already.

User and server FTP's for 8 bit machines sometimes do not initially implement
even type L 8 because the author knew that there was no special local
interpretation of for it, i.e. that it would be treated the same as image, and
therefore deemed it unnecessary.  But it eventually has to be added in order to
talk to odd machines which do place an interesting -- i.e.  different than
image -- interpretation on it at the other end.  To be general, at least any
local byte size that seems equivalent to type image ought to be accepted by the
server and settable by the user process, and then treated identically to type
Image -- this costs almost nothing in the implementation.  As far as I know,
only a few cases really seem to be needed.

On an 8 bit machine, multiples of 8 seem like they might be equivalent to
image, but then since the spec does not say a particular local byte type means,
it being a local matter, it is hard to rule out that you might someday need to
talk to a machine that needs to be told "type L 5".  What should this mean on a
an 8 bit machine?  The user ftp "quote" command is a reasonable hedge against
this unlikely case except that some user ftp processes withhold the type
command and send it just before the "stor" or "retr" command.

Buz
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 88 19:31:12 GMT
From:      amdcad!phil@ucbvax.Berkeley.EDU  (Phil Ngai)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Wanted: Delni [blinking lights]
In article <23179@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes:
>understand that the 802.3 committee is considering standardizing a
>"Link OK" idle signal (on UTP and fiber[?]).  I hope they do.
>
>	Never underestimate the power of a little LED.

I asked the DEC salesman about having LEDs like Cabletron does
on their transceivers. He thought it was a silly idea.

We don't buy H4005s anymore. We buy Cabletron transceivers.

Thank goodness for the free market system.
-- 

I speak for myself, not the company.
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 88 20:57:36 GMT
From:      sun.soe.clarkson.edu!nelson@tcgould.tn.cornell.edu  (Russ Nelson)
To:        tcp-ip@sri-nic.arpa
Subject:   RIP vs. HELLO
Reading Comer's book, _Internetworking with TCP/IP_, I get the
impression that RIP is a second son of the Internet protocol suite.  I
also found out why I couldn't find any documentation on the "RIP
Protocol".  Is there a move to HELLO afoot?  *Should* there be a move
to HELLO?

Also, reading the RFC for BOOTP, I get the impression that RARP is
obsoleted by BOOTP.  There is no contact address given in the RFC,
so I ask here...

Also also, Comer's book is very handy for figuring out how a packet
gets from host A to host B.  Tannenbaum's _Computer Networks_ is a good
tutorial on networks in general, but Comer's book gives you a chance
to decode Dave Mills' postings :-)
-- 
signed char *reply-to-russ(int network) {	/* Why can't BITNET go	*/
if(network == BITNET) return "NELSON@CLUTX";	/* domainish?		*/
else return "nelson@clutx.clarkson.edu"; }
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 88 22:38:00 GMT
From:      WANCHO@SIMTEL20.ARPA ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   FTP Logical Byte Sizes

Bob,

There still is a definite need for TYPE L <bytesize>, in particular,
TYPE L 8, TYPE L 32, and TYPE L 36.  Most important is TYPE L 8
because it is the only way to correctly transfer our 8-bit binary
files to a non-PDP10 host.  It would be short-sighted to assume
transfers of 8-bit binary data even between hosts of the same word
length would be correct using TYPE IMAGE or TYPE L nn as the byte
order within the word may not be the same.  Similar cases can be made
to be able to specify other possible bytesizes.

--Frank

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 88 23:20:47 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP Logical Byte Sizes

Frank,

I must admit I never thought about byte order.  Are there actually any
FTP's for little-endian machines that would send "swapped" bytes, ie,
not in byte order but in halfword or word order for those machines??

Bob Braden

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jun 88 09:26:40 PDT
From:      hjs@lindy.Stanford.EDU (Harry Saal)
To:        tcp-ip@sri-nic.ARPA, urbaniak@g.bbn.com
Subject:   More Ethertypes

Thank you for the list of Ethertypes and manufacturer ids you have
accumulated. It is valuable, since Xerox refuses to divulge their list
since it is "confidential", and they never chose to ask companies
their permission to "disclose" the existence of an assigned Ethertype.

Here are several more entries to add to your list:

0200  PUP     **** this conflicts with IEEE 802.3/802.2 style network
0201  PUP Address Recog Protocol  ***** ditto

0888 Xyplex
0BAD Banyan Systems
8080 Vitalink
8137 Novell
9001 Bridge (bridge management)
9002 Bridge (terminal server)
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 88 02:38:57 GMT
From:      tpmsph@ecsvax.UUCP (Thomas P. Morris)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   CMU TCP-IP for VMS 5.0?

Is there or will there be available any time REAL SOON
NOW, a version of the CMU TCP-IP package for VMS which
will be compatible with VMS 5.0? We're getting ready
to install and make available the CMU TCP-IP 6.0/6.2
release on our VAXcluster. We're not particularly 
thrilled at the prospect of having our user population
become dependent upon this package for TELNET and FTP,
if the ACP and IPDRIVER code "breaks" under VMS 5.0,
which we expect to have in hand and install in the next
month and a half.

VMS 5.0 changes some of the device driver and system
data structure synchronization techniques, so I know 
that changes will be required to the ACP and the 
IPDRIVER. We don't have all the tools necessary to 
rebuild these images on our local systems.

So, has anyone tackled this problem yet? Will there
be a new release from CMU?

Thanx in advance.

-----------------------------------------------------------------------------
Tom Morris                                 BITNET: TOM@UNCSPHVX
UNC School of Public Health                UUCP  : ...!mcnc!ecsvax!tpmsph
-----------------------------------------------------------------------------
-- 
-----------------------------------------------------------------------------
Tom Morris                                 BITNET: TOM@UNCSPHVX
UNC School of Public Health                UUCP  : ...!mcnc!ecsvax!tpmsph
-----------------------------------------------------------------------------

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 88 10:35:00 PDT
From:      Mike Anello <mja@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   RE: streams based vs character based tcp/ip on UNIX


We have seen a 40% increase in performance on our streams based tcp/ip
over our character based tcp/ip. The size 
I don't have the information about the size of our character product handy,
but our streams product kernel is approx 70k. Hope this is useful.

Mike Anello
Manager, Streams Development
Wollongong - Palo Alto


-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 88 05:50:05 GMT
From:      ado@VAX.BBN.COM (Buz Owen)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP Logical Byte Sizes

In addition to being useful with 36 bit pdp10 and related machines, local byte
size 8 is useful with the BBN C/70, which has a 20 bit word and a 10 bit byte
size.  While a discussion of choices of reasonable machine word sizes, and
important or unimportant machine architectures would be inappropriate (and
boring, or maybe annoying) on this list, type L 8 is useful to tell the C/70 to
send just the low 8 bits of each byte, a common type of file on the C/70 --
what you normally get as output from a C program that writes an 8 bit binary
file -- or store such a file.  Using Image mode instead, you get the unused
zero bits sent through the net, wasting network bandwidth and machine cycles,
as the C/70 laboriously repacks bits into 8 bit bytes -- and then have to
run a program to strip the bits out at the other end.

So for both the C/70 and pdp10 type architectures, type L 8 tells the machine
to skip over unused bit positions -- the pdp10 put these bits at the end of
each word, the C/70 puts them in the high order position of each byte.  Thus
local byte size is important if you want to assure compatibility with possible
"odd" machines in the future, or with existing ones you know you need to
communicate with already.

User and server FTP's for 8 bit machines sometimes do not initially implement
even type L 8 because the author knew that there was no special local
interpretation of for it, i.e. that it would be treated the same as image, and
therefore deemed it unnecessary.  But it eventually has to be added in order to
talk to odd machines which do place an interesting -- i.e.  different than
image -- interpretation on it at the other end.  To be general, at least any
local byte size that seems equivalent to type image ought to be accepted by the
server and settable by the user process, and then treated identically to type
Image -- this costs almost nothing in the implementation.  As far as I know,
only a few cases really seem to be needed.

On an 8 bit machine, multiples of 8 seem like they might be equivalent to
image, but then since the spec does not say a particular local byte type means,
it being a local matter, it is hard to rule out that you might someday need to
talk to a machine that needs to be told "type L 5".  What should this mean on a
an 8 bit machine?  The user ftp "quote" command is a reasonable hedge against
this unlikely case except that some user ftp processes withhold the type
command and send it just before the "stor" or "retr" command.

Buz

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1988 1603-EDT
From:      hsw@TYCHO.ARPA  (Howard Weiss)
To:        tcp-ip at sri-nic.arpa, info-vax at kl.sri.com
Cc:        hsw
Subject:   DDN support for CMU-TEK TCP/IP

Does anyone know of any work that has been done to support a DDN interface
in the CMU-TEK TCP/IP package?  As delivered, the code supports Ethernet
but I would like to know if anyone has support for interfaces such as
the ACC LH/DH or the ACC 6250 in order to accomplish a direct connection
to a DDN-like network without first going through a gateway.

Howard Weiss

Internet: hsw@tycho.arpa
-------

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 88 16:26:40 GMT
From:      hjs@LINDY.STANFORD.EDU (Harry Saal)
To:        comp.protocols.tcp-ip
Subject:   More Ethertypes


Thank you for the list of Ethertypes and manufacturer ids you have
accumulated. It is valuable, since Xerox refuses to divulge their list
since it is "confidential", and they never chose to ask companies
their permission to "disclose" the existence of an assigned Ethertype.

Here are several more entries to add to your list:

0200  PUP     **** this conflicts with IEEE 802.3/802.2 style network
0201  PUP Address Recog Protocol  ***** ditto

0888 Xyplex
0BAD Banyan Systems
8080 Vitalink
8137 Novell
9001 Bridge (bridge management)
9002 Bridge (terminal server)

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 88 16:59:14 GMT
From:      mhorne@tekfdi.TEK.COM (Michael T. Horne)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   3c501/503 programming info...

I'm trying to locate programming information about the 3COM 3c503 and
3c501 ethernet boards for the PC.  Doesn anyone have such information?
I'm looking for documentation, schematics, programming info, etc.

Apparently the 3c503 info is "available" for $1000 from 3COM (gosh, what
a wonderful way to get people to want to support your hardware product).
Can anyone fill me in on this?

Mike

-- 
Michael Horne - KA7AXD      |  UUCP: tektronix!tekfdi!honda!mhorne
FDI Div, Tektronix, Inc.    |  INTERNET: mhorne%honda.fdi.tek.com@relay.cs.net
Phone: (503) 627-1878       |  AMPRNET: ka7axd@tek.ka7axd.ampr.org

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 88 17:35:00 GMT
From:      mja@TWG.COM (Mike Anello)
To:        comp.protocols.tcp-ip
Subject:   RE: streams based vs character based tcp/ip on UNIX



We have seen a 40% increase in performance on our streams based tcp/ip
over our character based tcp/ip. The size 
I don't have the information about the size of our character product handy,
but our streams product kernel is approx 70k. Hope this is useful.

Mike Anello
Manager, Streams Development
Wollongong - Palo Alto

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 88 18:13:27 GMT
From:      martinea@SKL-CRC.ARPA (Mike Martineau)
To:        comp.protocols.tcp-ip
Subject:   PC Network Information


I am looking for technical information on various PC networking
schemes (PC-LAN, 3-Com 3+, Novell, etc).  Can anyone point me
to appropriate articles, books, technical contacts, etc.

Thanks in advance.

M.P. Martineau
Software Kinetics Ltd.

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 88 20:03:00 GMT
From:      hsw@TYCHO.ARPA (Howard Weiss)
To:        comp.protocols.tcp-ip
Subject:   DDN support for CMU-TEK TCP/IP


Does anyone know of any work that has been done to support a DDN interface
in the CMU-TEK TCP/IP package?  As delivered, the code supports Ethernet
but I would like to know if anyone has support for interfaces such as
the ACC LH/DH or the ACC 6250 in order to accomplish a direct connection
to a DDN-like network without first going through a gateway.

Howard Weiss

Internet: hsw@tycho.arpa
-------

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 88 23:07:31 GMT
From:      mikep@lakesys.UUCP (Mike Pluta)
To:        comp.protocols.tcp-ip
Subject:   help, questions


I'm beginning the process of research into a TCP/IP implementation under the
Pick o/s.  Pick is primarily a database, and is nowhere near Unix in terms of
internal structure; also, 'C' is not available for Pick- all systems coding
is done (or rather would be done) in the Pick o/s meta assembler.

What I am basically after, are insights into the implementation of TCP/IP
under non-Unix like o/s', and without the use of 'C'.

Further, what implementation and research references should I gather- I have 
access to the 'net' and have read through the Comer book.

Any insights?  suggestions?  encouragements?  

Michael J Pluta
Director of New Product Development
Tri-Sys Computer Corp, Inc.
-- 
Michael J Pluta (mikep@lakesys.UUCP) c/o   | {ihnp4,uwvax}!
Tri-Sys Computer Corp., Inc.               | uwmcsd1!lakesys!
207 East Buffalo Street, Suite 600         | mikep
Milwaukee, WI  53202                       |

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 88 23:18:11 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: RIP vs. HELLO

In article <1041@sun.soe.clarkson.edu>
nelson@sun.soe.clarkson.edu (Russ Nelson) writes:
>Reading Comer's book, _Internetworking with TCP/IP_, I get the
>impression that RIP is a second son of the Internet protocol suite.  I
>also found out why I couldn't find any documentation on the "RIP
>Protocol".  Is there a move to HELLO afoot?  *Should* there be a move
>to HELLO?
>
	You can read all about RIP in IDEA0004-01.  As soon as Hedrick
gets it published as an RFC, we can all take our respective vendors to
task for any noncompliance, if there are still any implementations out
there that haven't done split horizon, holddowns, etc.

	HELLO seems to be becoming an orphan with the emergence this
summer of the "new NSFnet backbone".  Are there any other
implementations running, besides the "old NSFnet backbone"?  What
happens to the fuzzballs?  Should we start a networking corner at the
Boston Computer Museum?  Or do they all revert to Mills' possession?
:-)  

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 88 10:25:00 PDT
From:      Mike Anello <mja@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   RE: streams based tcpip vs character based tcpip

>Mike - Being unwilling to show my ignorance to the whole tcp-ip list,
>I will ask you: what is the difference between streams vs character ?
>Does it have to do with System V vs 4.3 bsd ?  Regards - Craig

The difference is that streams based tcpip is built with stream drivers and
modules where character based tcpip is built with UNIX V or BSD character device
drivers. Two different technologies.

Mike

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Jun 88 12:29:01 PDT
From:      cire@clash.cisco.com
To:        Frank Kastenholz <KASTEN@mitvma.mit.edu>
Cc:        der Mouse <mcgill-vision!mouse@bloom-beacon.mit.edu>, tcp-ip@sri-nic.arpa, cire@clash.cisco.com
Subject:   Re: Convert /etc/hosts to RR format pgm anyone?
>> Date:         Thu, 09 Jun 88 09:33:04 EDT
>> From: Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
>> Subject:      Re: Convert /etc/hosts to RR format pgm anyone?
>> To: der Mouse <mcgill-vision!mouse@bloom-beacon.mit.edu>
>> Cc: tcp-ip@sri-nic.arpa
>> 

Good start!    I've added some corrections to the heirarchy.
It strikes me that this kind of info would be reasonable in an intro
of some kind to IP.

>> This sounds to me like there is some confusion over the meaning of
>> some of the terms used (which, to the best of my limited knowledge,
>> have never been fully codified - perhaps an addendum to the Assigned
>> Numbers RFC is in order - "Assigned Abbreviations and Terms and Their
>> Meanings").
>> 

I'd recommend Douglas Comer's book 'Internetworking with TCP/IP, Principals,
Protocols, and Architecture' or Andrew Tanenbaum's book 'Computer Networks'.
Both include a glossary at the back with very succinct definitions of most
everything you mention below.

>> As I understand things the "hierarchy" of terms in use in the Internet
>> protocols (among others) are:
>> 

Here is perhaps a better set of definitions:  (some of these are essentially
pulled from Comer's book).

FRAME - The unit of information encapsulated for transmission on physical
	media or network.
	
FRAGMENT - a unit that the IP layer breaks a DATAGRAM into if necessary
	   for transmission across networks that can not handle the size
	   of the entire DATAGRAM.   A FRAGMENT has essentially the same
	   IP header as the original DATAGRAM.

DATAGRAM - The basic unit of information dealt with by the IP layer.  This
	   is what is sent across the TCP/IP Internet.  It may be broken
	   into FRAGMENTS if a network can not handle the DATAGRAM's size.

SEGMENT - the basic unit that TCP deals with.  A segment consists of a block
	  of bytes that arrive or are sent at one time.  These bytes make up
	  part of stream of bytes.  Information in the segment identifies
	  where in the stream these bytes exist.  A segment will be
	  passed to the IP layer as one or more DATAGRAMS for transmission
	  by that layer.

PACKET - the basic unit of information sent across a packet-switching network.
	 It's exact meaning is dependent upon the context.

BUFFER - an implementation detail that is used for passing blocks of information
	 including DATAGRAMS to the layers for processing.

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Jun 88 09:33:04 EDT
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        der Mouse <mcgill-vision!mouse@bloom-beacon.mit.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Convert /etc/hosts to RR format pgm anyone?


In article <8805261929.AA04199@RHEA.CAM.UNISYS.COM>, jonab@CAM.UNISYS.COM
(Jonathan P. Biggar) writes:
>>> The TCP URGENT mechanism uses a pointer; I do not think that there
>>> is any specification which says that packet boundaries are
>>> significant with respect to URGENTs.
>> Not so!  RFC 793 states:
>>    If there is urgent data [...].  *****Note that data following
>>    the urgent pointer (non-urgent data) cannot be delivered to the
>>    user in the same buffer with preceeding urgent data unless the
>>    boundary is clearly marked for the user.*****
>
>What does this have to do with packet boundaries?  Jonab said "packet",
>not "user buffer".

This sounds to me like there is some confusion over the meaning of
some of the terms used (which, to the best of my limited knowledge,
have never been fully codified - perhaps an addendum to the Assigned
Numbers RFC is in order - "Assigned Abbreviations and Terms and Their
Meanings").

As I understand things the "hierarchy" of terms in use in the Internet
protocols (among others) are:

FRAME - lowest level of bits/bytes. One speaks of Ethernet Frames, etc
        A FRAME has ONE data link header (e.g. Ethernet header).

FRAGMENT - the thing that IP spits out to the data link driver. Each
           FRAGMENT has ONE IP header. A FRAGMENT may be split into
           multiple FRAMES by the lower layers.

SEGMENT - the thing that TCP spits into IP. Each SEGMENT has one TCP
          header. It may be broken into FRAGMENTS by IP.

Noe things get a little weird.....

DATAGRAM - this is also the 'larger' thing that IP tries to send. A
           DATAGRAM USUALLY has a one to one relationship with a SEGMENT.
           It may be broken up (fragmented) into a number of FRAGMENTS
           by IP before being sent through the data link.

           A DATAGRAM is ALSO what UDP and other "datagram" oriented
           protocols may give to IP for transmission.


PACKET - a generic term that can mean anything at any time - usually its
         meaning is derived from the context, other times by a prefix
         (such as IP PACKET), other times .....

BUFFER - what is passed to TCP/UDP for transmission. Usually. Of course,
         a device driver reads stuff out of the I/O interface into a
         buffer....


These are terms that I use, based on "common usage, the literature, etc"

Frank Kastenholz.
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 88 05:57:29 GMT
From:      lyndon@ncc.Nexus.CA (Lyndon Nerenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: Delni

In article <8806070434.AA09530@infidel.lanl.gov.ARPA> peter%infidel@LANL.GOV (Peter Ford) writes:
>We have a cabletron DELNI clone which is better than the old DELNIs 
>since it is loaded with lights which have helped in network debugging.

[ ... ]

>Some of us still like those blinking lights on our gear and hope
>that they come back in style on all equipment.  

Great! My question is: Do you have the rack mounting kit for
the DELNI? Some of us like the lights mounted in the rack where
everyone can see them.

[ Yes, this is a serious question. I'm getting sick of tripping over
  the bundle of cables... ]
-- 
{alberta,utzoo,uunet}!ncc!lyndon  lyndon@Nexus.CA

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 88 13:33:04 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: Convert /etc/hosts to RR format pgm anyone?



In article <8805261929.AA04199@RHEA.CAM.UNISYS.COM>, jonab@CAM.UNISYS.COM
(Jonathan P. Biggar) writes:
>>> The TCP URGENT mechanism uses a pointer; I do not think that there
>>> is any specification which says that packet boundaries are
>>> significant with respect to URGENTs.
>> Not so!  RFC 793 states:
>>    If there is urgent data [...].  *****Note that data following
>>    the urgent pointer (non-urgent data) cannot be delivered to the
>>    user in the same buffer with preceeding urgent data unless the
>>    boundary is clearly marked for the user.*****
>
>What does this have to do with packet boundaries?  Jonab said "packet",
>not "user buffer".

This sounds to me like there is some confusion over the meaning of
some of the terms used (which, to the best of my limited knowledge,
have never been fully codified - perhaps an addendum to the Assigned
Numbers RFC is in order - "Assigned Abbreviations and Terms and Their
Meanings").

As I understand things the "hierarchy" of terms in use in the Internet
protocols (among others) are:

FRAME - lowest level of bits/bytes. One speaks of Ethernet Frames, etc
        A FRAME has ONE data link header (e.g. Ethernet header).

FRAGMENT - the thing that IP spits out to the data link driver. Each
           FRAGMENT has ONE IP header. A FRAGMENT may be split into
           multiple FRAMES by the lower layers.

SEGMENT - the thing that TCP spits into IP. Each SEGMENT has one TCP
          header. It may be broken into FRAGMENTS by IP.

Noe things get a little weird.....

DATAGRAM - this is also the 'larger' thing that IP tries to send. A
           DATAGRAM USUALLY has a one to one relationship with a SEGMENT.
           It may be broken up (fragmented) into a number of FRAGMENTS
           by IP before being sent through the data link.

           A DATAGRAM is ALSO what UDP and other "datagram" oriented
           protocols may give to IP for transmission.


PACKET - a generic term that can mean anything at any time - usually its
         meaning is derived from the context, other times by a prefix
         (such as IP PACKET), other times .....

BUFFER - what is passed to TCP/UDP for transmission. Usually. Of course,
         a device driver reads stuff out of the I/O interface into a
         buffer....


These are terms that I use, based on "common usage, the literature, etc"

Frank Kastenholz.

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 88 15:24:55 GMT
From:      HEILNER_K@VAXC.STEVENS-TECH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted DELNIs

We have a large(50) DELNI population. It would be nice if DEC would put some
LEDs on the DELNI and the DEMPR. As for the reliability of the DELNI, I have
had only good experiences with the product. Our experience has been when a
DELNI fails it tends to fail a port at a time as opposed to the whole unit
going down at one time.



Keith Heilner
Network Coordinator
Stevens Institute
Heilner_k@sitvxb
Heilner_k@vaxb.stevens-tech.edu
------------

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 88 15:40:59 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Point-to-Point links


	
		Here's an example from Proteon.  Proteon added the feature of
	NOT using IP subnets on serial links to Rel 7.4 (circa last summer).
	Prior to 7.4 you HAD to use a subnet.  What do you give up?  Here's
	what Proteon said in the 7.4 release notes:
	
		o  can't ping the interface
		o  cannot run EGP over the interface
		o  cannot boot from that interface (serial line boot added rel 8.0)
	
		The problem with omitting an IP subnetted address from a
	serial interface has to do with identifying that interface.  Proteon
	says that "for routing decisions, such a serial line [no IP addr] is
	considered to be a part of each subnetted network present in the
	gateway." 
	
		Of course, the big lose with IP addresses is "wasting" all
	those two node subnets.
	
		Use addresses for finer control.  Don't use them if you don't
	have subnets to "waste".  However, you should design the option in for
	your customers.
	
		Kent England, Boston U
	
	
I would have thought that the Network Monitoring protocol used to 
monitor and control the gateway would require, or at least want, an
IP address for every gateway interface.  What does Proteon do about this
problem... or is it just a customer's problem?

Bob Braden

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 88 17:25:00 GMT
From:      mja@TWG.COM (Mike Anello)
To:        comp.protocols.tcp-ip
Subject:   RE: streams based tcpip vs character based tcpip


>Mike - Being unwilling to show my ignorance to the whole tcp-ip list,
>I will ask you: what is the difference between streams vs character ?
>Does it have to do with System V vs 4.3 bsd ?  Regards - Craig

The difference is that streams based tcpip is built with stream drivers and
modules where character based tcpip is built with UNIX V or BSD character device
drivers. Two different technologies.

Mike

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 88 19:29:01 GMT
From:      cire@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Convert /etc/hosts to RR format pgm anyone?

>> Date:         Thu, 09 Jun 88 09:33:04 EDT
>> From: Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
>> Subject:      Re: Convert /etc/hosts to RR format pgm anyone?
>> To: der Mouse <mcgill-vision!mouse@bloom-beacon.mit.edu>
>> Cc: tcp-ip@sri-nic.arpa
>> 

Good start!    I've added some corrections to the heirarchy.
It strikes me that this kind of info would be reasonable in an intro
of some kind to IP.

>> This sounds to me like there is some confusion over the meaning of
>> some of the terms used (which, to the best of my limited knowledge,
>> have never been fully codified - perhaps an addendum to the Assigned
>> Numbers RFC is in order - "Assigned Abbreviations and Terms and Their
>> Meanings").
>> 

I'd recommend Douglas Comer's book 'Internetworking with TCP/IP, Principals,
Protocols, and Architecture' or Andrew Tanenbaum's book 'Computer Networks'.
Both include a glossary at the back with very succinct definitions of most
everything you mention below.

>> As I understand things the "hierarchy" of terms in use in the Internet
>> protocols (among others) are:
>> 

Here is perhaps a better set of definitions:  (some of these are essentially
pulled from Comer's book).

FRAME - The unit of information encapsulated for transmission on physical
	media or network.
	
FRAGMENT - a unit that the IP layer breaks a DATAGRAM into if necessary
	   for transmission across networks that can not handle the size
	   of the entire DATAGRAM.   A FRAGMENT has essentially the same
	   IP header as the original DATAGRAM.

DATAGRAM - The basic unit of information dealt with by the IP layer.  This
	   is what is sent across the TCP/IP Internet.  It may be broken
	   into FRAGMENTS if a network can not handle the DATAGRAM's size.

SEGMENT - the basic unit that TCP deals with.  A segment consists of a block
	  of bytes that arrive or are sent at one time.  These bytes make up
	  part of stream of bytes.  Information in the segment identifies
	  where in the stream these bytes exist.  A segment will be
	  passed to the IP layer as one or more DATAGRAMS for transmission
	  by that layer.

PACKET - the basic unit of information sent across a packet-switching network.
	 It's exact meaning is dependent upon the context.

BUFFER - an implementation detail that is used for passing blocks of information
	 including DATAGRAMS to the layers for processing.

-c
cire|eric

Eric B. Decker
cisco Systems
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 88 20:13:53 GMT
From:      jerry@oliveb.olivetti.com (Jerry Aguirre)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: Delni

In article <10269@ncc.Nexus.CA> lyndon@ncc.UUCP (Lyndon Nerenberg) writes:
>In article <8806070434.AA09530@infidel.lanl.gov.ARPA> peter%infidel@LANL.GOV (Peter Ford) writes:
>>We have a cabletron DELNI clone which is better than the old DELNIs 
>>since it is loaded with lights which have helped in network debugging.
>
>Great! My question is: Do you have the rack mounting kit for
>the DELNI? Some of us like the lights mounted in the rack where
>everyone can see them.

When our DEC DELNI arrived I tried to mount it in a rack along with the
DEC LAT terminal servers.  They both come in a plastic case intended for
setting on a table or such.  To rack mount them you remove the plastic
case and inside there is a metal case that will fit into a rack.  (We
still have those empty plastic cases taking up room on a shelf.)

The LAT units installed with no problems but when I went to do the same
for the DELNI the brackets didn't line up with anything.  A little
investigation showed that the brackets included with the DELNI were the
ones for a LAT.  I thought this was just a fluke but others on the net
have complained that this always happens.  There is some screwup with
the part number so that even if you order the part for the DELNI you get
the bracket for the LAT.  According to one source the only way to get
the right part is to order the DELNI in one of DECs wiring cabinets.
Meanwhile our DELNI lays on the bottom of the rack.

The Cabletron MT-800 has a rack mount option (RMK-1000) that lists for
$75.  It is a little bulky for my tastes.  It is actually a shelf that
the MT-800 bolts to, but it works well and looks nice from the front.
(You want to be able to see those blinky lights.)

The MT-800 also comes (standard) with a bracket in the back that you can
tie-wrap all the cables to, including the power cord.  Those of you
familiar with transceiver connections and their slide-lock fasteners
will understand the importance of strain-relief.  The bracket and
tie-wrap combination is so effective that you can move the other end of
the cable arround and it wont pull out of the MT-800 even if the
slide-lock isn't fastened.

The Cabletron MR-9000 thin ethernet multiport repeater (DEMPR clone) has
the same chassis as the MT-800 and uses the same rack mount kit.  The
same strain relief bracket is included but I have not found it necessary
for BNC connections.  It does help for the power cord and transceiver
connection.

Cabletron has always shiped my orders very fast, usually in a couple of
days after we generate the PO.

Now for the bad news.  I had one of the MR-9000s fail.  No big deal, it
had been running for 6 months and I expect some failures.  (Actually I
also had a transceiver on a different floor fail at or about the same
time.  I suspect some kind of electrical spike.)  But I didn't find
Cabletron very responsive; it took several days and many phone calls to
get me the RMA number and the repair took over a week.  To be honest I
wasn't really pushing or screaming for immediate help.  I had borrowed
another unit and my network was working again the same day.  Perhaps if
I had told them I was off the air they would have arranged a loaner.
What was disturbing was that I have written a PO and received a new unit
from them in half the time it took to get an in-warranty repair.  I
finally decided to just order a spare unit.

				Jerry Aguirre

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 88 21:53:54 GMT
From:      VAF@SCORE.STANFORD.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re: DDN support for CMU-TEK TCP/IP

You might want to re-send your query to the CMU-TEK-TCP mailing list, which is
reachable as "CMU-TEK-TCP@C.CS.CMU.EDU". This list is mostly made up of users
of the CMU-TEK package but is also read by the CMU-TEK maintainers.

	Vince Fuller,
	Stanford Networking
	(former implementor of CMU-TEK-TCP)

P.S. To partially answer your question - no such interface was ever written
     at CMU while I was working on the project and I suspect that it still true
     today. It is possible, however, that someone outside of CMU has done some
     work on this (I seem to remember reading something about it, in fact).
-------

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 88 22:11:06 GMT
From:      morrison@eecs.nwu.edu (Vance Morrison )
To:        comp.protocols.tcp-ip
Subject:   SLIP or TCP/X.25 for VMS????


Hello, I need some help

We are trying to connect two VAXes runing VMS to our campus TCP/IP internet.
Unfortuately, These computers are not that physically close to each
other (> 500 ft) or to the rest of campus (> 3000 ft).  Luckily, 
the data needs of these people are quite modest (mail and a few telnet's
and FTP's), so we were thinking about X.25 or SLIP.

So my question to you is, does anyone know about TCP/IP software for
VMS that will interface to X.25 or a serial port (SLIP).   Does
CMU make such a thing??  Any help will be greatly appreciated.

					Vance Morrison
					Northwestern University
					morrison@accuvax.nwu.edu

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 88 00:45:00 GMT
From:      brezak@apollo.uucp (John Brezak)
To:        comp.protocols.tcp-ip
Subject:   Need rfc 877

Could someone email RFC 877 to me.

Thanx in advance...

-- 
============================================================================================
    John Brezak                   UUCP: {mit-erl,yale,uw-beaver}!apollo!brezak
    Apollo Computer Inc.                apollo!brezak@eddie.mit.edu
    Chelmsford, MA                Phone: (617) 256-6600

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 88 13:21:50 GMT
From:      timk@NCSA.UIUC.EDU (Tim Krauskopf)
To:        comp.protocols.tcp-ip
Subject:   Re: 3c501/503 programming info...


As I understand it, the $1000 ($999 actually) is for the 3Com 3L programming
library of drivers for all of their boards - forms a common calling interface
which is also compatible with NETBIOS and 3+, etc.  Needless to say, I didn't
come up with the $1000 - if you get past the sales critters there ARE
marketing and engineering people at 3Com with the real Engineering reference
specs for the hardware that you might get a copy of.

I hope someone at 3Com is listening, because not everyone has $1000 to throw
at one company when there are so many good competitors out there....


Tim Krauskopf                timk@ncsa.uiuc.edu (ARPA)

National Center for Supercomputing Applications (NCSA) 
University of Illinois, Urbana-Champaign

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 88 13:38:14 GMT
From:      dnwcv@dcatla.UUCP (William C. VerSteeg)
To:        comp.protocols.tcp-ip
Subject:   Vendor Support of Source Quench


I recently spoke with a vendor of host based TCP/IP software. I was trying
to determine the company's support of ICMP Source Quench. The package they
sell ignores ICMP Source Quench messages. It doesn't lower offerred 
traffic when receiving a source quench and doesn't send a source quench 
when its buffer space is running out. I requested a fix for this problem. 
We discussed some of the ongoing work in the field of congestion control
and its impact on the usability of source quench mechanisms. 

He informed me that the company had no plans to implement source quench support
due to the large number of implementations that also ignore source quench. 

This brings me to my point. How many of the currently popular
packages handle Source Quench in a reasonable fashion? 
Is it worth my efforts to chase this vendor and force him to conform to 
specifications or is it a mute point due to a general lack of conformance 
to the ICMP spec by most of the available packages? We definately require
a traffic limiting mechanism. I don't know if the  ongoing congestion control
work being done obviates the need for source quench support, but I doubt that
it does.


Bill VerSteeg

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 88 14:42:38 GMT
From:      nuchat!texhrc!cml@uunet.uu.net  (Chris Lonvick)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP/IP in MVS?
In article <353@pacbell.PacBell.COM>, david@pacbell.PacBell.COM (David St.Pierre) writes:
> I'm trying to determine whether or not there are any commercial
> products which support TCP/IP on MVS, specifically for the purposes of
> FTP....
> 

We looked at many solutions to link things to the MVS computers. At first we
were just concerned with our VAXen running VMS. We found FlexLINK, Interlink
and FlexComm. Contact IBM if you wish to look at any of these.

To actually get TCP/IP from an Ethernet talking to an MVS processor, you 
will have to either go with some solution that IBM has (bad option) or
with one of the third party solutions. The cadillac is the Sparticus
products (a division of Fibronics.) It was very expensive last time I 
looked at it. There is also another startup company (whose name I have
forgotten) and Mitek. We will be implementing the Mitek solution in the 
next few weeks. The telephone number for Fibronics is (617)-778-0700.
for Mitek, contact Tim Hogan at (214)-490-4090.

It sounds, though, that you just want file transfer. This may be accomplished
through several proprietary networks such as Network System's HYPERChannel.
This is also a very expensive solution. If you are just transferring text
files, I would recommend that you build your own solution. Take one of your
old XTs lying around and put an IRMA (or compatable) card in it along with
an Ethernet card. Buy an API (Application Programming Interface) to emulate
keystrokes through the IRMA software and make sure that your TCP/IP software
comes with an API. As far as I know, only Bridge Communications PCS/1 has
this capability. Set up user accounts on the MVS system and on some TCP/IP
node. Now comes the tricky part: write your program on the PC to first log
into the MVS system. Grab any files that are there and pull them down to the
PC. Close the connection (or not if you prefer). Open an FTP connecetion
to the TCP/IP node and push all the files to the directory there. Pull back
any files that you did not put there. Close you FTP connection and reopen
the MVS connection. Put files there that you pulled from the TCP node.
Go to step one and continue ad infinitum. If you want to get real fancy,
you could write front-ends for the MVS and TCp node to put headers on the files
and distribute them to final destinations. Now, to transfer files, just put
them in one directory on one machine and they will appear on the other machine.


Chris Lonvick
Texaco EPTD

Disclaimer: These opinions are my own and don't reflect the position of the
company.
-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 88 14:44:13 GMT
From:      goldstei@MITRE.ARPA (Steve Goldstein)
To:        comp.protocols.tcp-ip
Subject:   YANB--Yet Another Networking Book

Folks,

I hesitate to speak up among all you august authorities, but in all the
chatter back ond forth about references on communications books, I have
not noted mention of Stallings' Second Edition "Data and Communications":

William Stallings, Ph.D., "Data and Computer Communications--Second Edition"
Macmillan Publishing Company, New York, 1988; ISBN 0-02-415451-2;
653 pp.; $51.35 at the Univ of Colorado Book Store in March '88.

Seems to do a magnificent job of covering the various protocols in a balanced 
and comparative fashion.  MAY be a condensation of his three-volume set; but
as I haven't gone through the set, I really do not know.  At any rate, I
find this chock-full of the explanations I've been searching for and a most
useful extension beyond the world of TCP/IP.  Material is presented at an
introductory level for the first-time inquirer, and it is quite readily
understandable.  Still, there's considerable depth.  So, if you want a
good view of the world beyond Comer and can only have one additional book,
I'd vote for Stallings' Second Edition.

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 88 15:47:11 GMT
From:      gomberg@gateway.mitre.ORG (Dave Gomberg)
To:        comp.protocols.tcp-ip
Subject:   DCA R&D Planning

The MITRE Corporation is assisting the Defense Communications Agency (DCA)
in planning for Internet Research and Development (R&D) activities for the
FY90-FY92 period (i.e., October 1990-September 1992).  Although the focus
is more likely to be on D than R for DCA funded projects, there is interest
in R projects that might be pursued through other than DCA funding.  One of
the reasons D will dominate R is that DCA would like to fund projects that
will have an operational impact within a year or two of project completion.

We are seeking suggestions for R&D activities that can realistically be
pursued in the FY90-FY92 period.  Suggested activities may or may not be
ones in which you or your organization would like to participate.  By
replying to me directly (not to this list) you may be assured that your
ideas will not be revealed outside DCA until the Government issues an RFP
and that your unique inputs will be credited/acknowledged to DCA.

Although your suggestions may be informally presented, they should address
the following to the extent possible:

	- description of the Internet problem to be addressed and why it
	  is important

	- suggested approach to solving the problem

	- estimate of resources required (staff years over some period)

Note that the kinds of problems of interest are broad in scope.  Not only
are "network-centric" problems, such as congestion control of interest, but
problems normally thought of as host responsibilities are of interest also.

Some of you may recognize an intersection of this request and the IETF
Internet Problem/Description Form recently circulated by Phill Gross.  If
you have already responded to that, you need not duplicate the effort.  This
request is being sent to a wider audience and is narrower in focus.  Apologies
in advance to those of you who receive multiple copies of this message.

Thanks for your help and cooperation.

David A. Gomberg
The MITRE Corporation
7525 Colshire Drive
McLean, VA 22102
(703)-883-6322

gomberg@gateway.mitre.org

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 88 16:24:52 GMT
From:      Eugene.Hastings@MORGUL.PSC.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Experience with Xyplex Terminal Servers?

We had a demo of a Xyplex Terminal Server. It does IP, but it does not do
DECNET, but something similar to, but incompatible with DEC's LAT (Ethernet
terminal server transport, which requires physical ethernet connectivity).

They swore that they would be doing real LAT Real Soon Now, so we said "Call
us back when it does." They do require a host to download from, DEC-style,
even for the telnet code.

Gene

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 88 16:25:56 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  RIP vs. HELLO

Kent,

So far as I know, the Hellospeak (or whatever else it may be called)
routing scheme has been implemented in full only for the fuzzballs, about
two dozen of which are skulking about the Internet now. Partial implementations
have been done for the cisco router and gated daemon for Unix 4.3bsd. A lot
of work went into the design and refinement of Hellospeak in such rugged
environments as the present NSFNET Backbone, but as in many other cases like
this, the sheer weight of Unix ubiquity and availability of RIP will
undoubtably prevail. I would argue and expect many RIP implementors to
agree that neither Hellospeak nor RIP are suitable for use on an extended
WAN topoplogy and that link-state algorithms such as used in the new
NSFNET Backbone are more appropriate. As for enhancements to the traditional
Bellman-Ford algorithms, such as hold-down, split-horizon and so forth,
there is considerable disagreement within the RIP community as to whether and
how to do these things and I suspect agreement will never be reached. These
things and some other tricks have in fact been done for Hellospeak, but
have not been thoroughly documented and probably will not be replicated.

The NSFNET Backbone fuzzbunch belongs to NSF; however, by agreement Merit
& Co. is entitled to them should they choose to exercise that option. However,
I doubt very much IBM wants to get into the fuzzball maintenance business,
to say the least! Present plans are to pull down the serial lines at the
end of July, which will leave them isolated on their local Ethers.

Personally, I would like to see the fuzzies remain in place for use as
remote observation platforms and as time servers for the various regional
nets. It is not clear whether the regionals will agree to support this
(hardware maintenance) or not.

Dave

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 88 17:54:52 GMT
From:      holmes@wdl1.UUCP (Randy D. Holmes)
To:        comp.protocols.tcp-ip
Subject:   Multiple connects to ARPA



     I was wondering if someone might be able to inform me of any 
  issues which might arise from having two connections to the arpanet.
  Our network covers several geographic locations, with our arpa
  connection being on the east coast. We are looking at the possibility 
  of obtaining a second connection on the west coast. Is this a
  plan which is generally excepted? are the arpa routers capable
  of finding the easiest way in to our net? and how hard would be
  to set up our net to find the easiest way to an outside net. We
  are using several cisco gateways scattered about, with a direct line
  connecting our east coast site, and our west coast site. 
  Any insight would be appreciated.


Randy D. Holmes                   holmes1@Ford-wdl1.ARPA
Ford Aerospace Corporation
3939 Fabian Way
Palo Alto CA 94303
(415) 852-7125

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 88 19:58:49 GMT
From:      cca!mirror!rayssd!raybed2!linus!heart-of-gold!jc@husc6.harvard.edu  (John M Chambers)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Getting started
In article <192@execu.EXECU>, dewey@execu.EXECU (dewey henize) writes:
> Ok, I'm obviously the slow one here, but...  For some of us, this world of
> TCP/IP and networking is a bit tough to pick up.  I didn't have a chance
> to learn about it in college so its been strictly OJT.  Would anyone else
> out there who has been in this position be willing to send or post a good
> solid intro to mid level reading list?
> 
For a more specific request, I'd like to ask if anyone knows of a set of
prototype client/server programs for TCP and UDP.  There's no shortage of
reading matter on the subject, but I've yet to see anything that tells me
how to write the code correctly.  You'd think that, since this is something
that's supposed to make networking easy and painless for all of us, that
there'd be some examples of how it's done.  In reality, I (like everyone
I talk to) find it all black magic, and my programs just sorta work some
of the time, and other times fail in mysterious ways.  In particular, it
seems very hard to figure out how to pass messages correctly via UDP, though
it is supposed to be easy.

Note that I'm NOT looking for yet another theoretical explanation of why
TCP/UDP/IP are so wonderful.  I've got those.  I'm looking for examples
of correct code.  I don't got those.  "RTFM" isn't much help.  I've read
lotsa manuals, and frankly, they're all crummy.  (If you have an exception, 
I'd love to hear about it.)

Note also that I haven't said what machine(s) I'm running on.  If you really
want to know, I'll tell you (and it's a long list).  But it seems to me that
if these protocols are at all what they are hyped up to be, it shouldn't much
matter what sort of machines I have.  The protocols are supposed to be very
well standardized, aren't they?  Well, then, I oughta be able to use them
in exactly the same way on, say, a Sun and a MtXinu and a Xenix and a SysV
and a ... machine, shouldn't I?

Has this all perhaps been posted somewhere that I haven't seen?

[Boy, what a dreamer! ;-]


-- 
From:	John Chambers <mitre-bedford.arpa!heart-of-gold!jc>
From	...!linus!!heart-of-gold!jc (John Chambers)
Phone	617/217-7780
[Send flames; they keep it cool in this lab :-]
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 88 20:31:26 GMT
From:      lyndon@ncc.Nexus.CA (Lyndon Nerenberg)
To:        comp.protocols.tcp-ip
Subject:   DELNI Rack Mount Kits

In article <23399@oliveb.olivetti.com> jerry@oliveb.UUCP (Jerry Aguirre) writes:
>In article <10269@ncc.Nexus.CA> lyndon@ncc.UUCP (Lyndon Nerenberg) writes:
 
>When our DEC DELNI arrived I tried to mount it in a rack along with the
>DEC LAT terminal servers.  They both come in a plastic case intended for
>setting on a table or such.  To rack mount them you remove the plastic
>case and inside there is a metal case that will fit into a rack.  (We
>still have those empty plastic cases taking up room on a shelf.)
 
[ ... ]

>The LAT units installed with no problems but when I went to do the same
>for the DELNI the brackets didn't line up with anything.  A little
>investigation showed that the brackets included with the DELNI were the
>ones for a LAT.

I'm not sure if you're trying to imply that the mounting brackets are
part of the standard DELNI, or if you ordered them as an accessory
with the DELNI.

When we ordered our DELNI, a seperate part number was given for the
rack mounting kit (in the installation manual). When I called back
to order this kit, much confusion resulted. I finally received a
phone call from the distributor (about a week later) who said the
rack mounting kit was no longer available from DEC.

So... If I was to crack the DELNI open would I find the necessary
parts inside? If not, does anyone know if DEC still supplies these
brackets?

-- 
{alberta,utzoo,uunet}!ncc!lyndon  lyndon@Nexus.CA

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 88 22:15:07 GMT
From:      wiltzius@lll-lcc.aRpA (Dave P. Wiltzius)
To:        comp.protocols.tcp-ip
Subject:   IP Security


I posted a similar request to this, but received no replies
regarding DEC and SUN.

So, can anyone inform me of DEC's and SUN's plans for the
IP Security option?  Any plans to implement it as specified
in RFC 1038?  We have lots of Ultrix VAXes and seemly countless
SUNs and we would really like to use the IP Security option
soon.

Thanks much. (PS. Selden, tried to Email summary to you but
mailer failed.  Any other address to try?)
  Dave (wiltzius@lll-lcc.llnl.gov)

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 88 05:04:40 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Vendor Support of Source Quench

Bill,

At least the new Jacobson/Karels TCP does listen to source-quench and the
present NSFNET Backbone system does generate them. According to good-faith
info, the new NSFNET Backbone should generate source-quench in a repsonsible
way within the next few months. I would suggest you beat on your vendor
with this message. I should point out the present system is a far way from
optimally tuned and that ongoing research here at UDel shows this tuning
may not be easy; however, the handles are there and our experience shows
they do work.

Dave

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 88 13:40:00 GMT
From:      AI.CLIVE@MCC.COM (Clive Dawson)
To:        comp.protocols.tcp-ip
Subject:   Re: DELNI Rack Mount Kits

For years we have obtained our DELNI mounting kits from Radio
Shack.  They sell some sort of universal car stereo mounting kit
which works very well.

Clive
-------

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 88 02:05:54 GMT
From:      bob@rel.eds.com (Bob Leffler)
To:        comp.protocols.tcp-ip
Subject:   Re: DELNI Rack Mount Kits

In article <10286@ncc.Nexus.CA>, lyndon@ncc.Nexus.CA (Lyndon Nerenberg) writes:
> In article <23399@oliveb.olivetti.com> jerry@oliveb.UUCP (Jerry Aguirre) writes:
> >In article <10269@ncc.Nexus.CA> lyndon@ncc.UUCP (Lyndon Nerenberg) writes:
> I'm not sure if you're trying to imply that the mounting brackets are
> part of the standard DELNI, or if you ordered them as an accessory
> with the DELNI.
 ....
> phone call from the distributor (about a week later) who said the
> rack mounting kit was no longer available from DEC.
> 
> So... If I was to crack the DELNI open would I find the necessary
> parts inside? If not, does anyone know if DEC still supplies these
> brackets?

Last fall I installed about a dozen Dec DELNI's at my site.  What I was told
kinda amazed me.  DEC sells the brackets as an option in Europe for the 
standard 19" rack, but not in the US.  In the US, they only come with the
DEC cabinet/rack.

No, if you take off the plastic case, all you'll see is two holes in the
side of the DELNI to mount the missing "ears".

Fortunately since my customer site where this equipment is located, happens
to be an Engineering Test facility for an Automotive company, it was no
big deal for us to fabricate the parts ourselves.  I would have still
prefered to buy them from DEC.


-- 
Bob Leffler - EDS, GM Truck & Bus Account (313)456-5375
bob@rel.eds.com or {uunet!edsews, rutgers, umix}!rel!bob
Opinions expressed may not be those of my employer.

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 88 04:45:12 GMT
From:      mandrill!edguer@tut.cis.ohio-state.edu  (Aydin Edguer)
To:        tcp-ip@sri-nic.arpa
Subject:   network unreachable
I am trying to understand why certain sites are unreachable from my machine.
Background:
 I am currently at mandrill.ces.cwru.edu [129.22.16.1].  CASE.Edu used to be
 a CSNET site only, hooked up to relay-csnet via a leased line.  It has since
 become a part of the NSFnet with T-1(?) links to Pittsburgh and Columbus. 
 It was renamed CWRU.Edu.  Since joining the Internet I have enjoyed using
 {smtp,nntp,ftp} to obtain information and sources.  Recently, however, a
 number of sites which were reachable now return the message "network
 unreachable".  These sites include such places as purdue.edu, uunet.uu.net,
 and decwrl.dec.com.
Question(s):
 Why would sites which were reachable become unreachable like this?
 Is this due (perhaps) to the dismantling of the ARPAnet which I understand
 is taking place?
 What can I do to find out why they have become unreachable?
 What can I do to try to reach them now that my router has given up?

Aydin Edguer		INTERNET: edguer@mandrill.ces.cwru.edu
+1 216 368 3195	(w)	UUCP: {att,cbosgd,decvax,sun}!mandrill!edguer
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 88 05:16:41 GMT
From:      wash08!txr98@uunet.uu.net  (Timothy Reed)
To:        tcp-ip@sri-nic.arpa
Subject:   TCP-IP and UUCP
I just started up our tcp-ip net between our 11/785s OK, but uucp bombs
out when I try to start it up using the network.  My Ultrix doc is 
*horrible*, and does not touch on using uucp over ethernet.  My tcp-ip
on our NCR towers comes with a uucp daemon to facilitate this.  Is there
a similar tool for ultrix, or is there something I else I'm missing?
thanks...
Timothy Reed
ACS  ..uunet!wash08!txr98
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 88 15:21:52 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: APIs for PC TCP/IP packages, TCP/IP for MVS

In fact, most commercial TCP/IP packages for DOS can be purchased with an
Applications Programming Interface of some sort.  Our PC/TCP, Sun's PC/NFS,
Excelan's EXOS 8051, and NRC's all have libraries that emulate Berkeley
sockets, for Microsoft C.  I don't know details of Bridge's offering.  I
think each product supports all memory models, but I don't think anyone is
shipping code for 5.0 or 5.1 yet.  In addition, our Developer's Kit comes
with libraries that allow access to our native interface (interrupt-based,
with fairly rich asynchronous facilities - our NETBIOS was written with it),
as well as high-level libraries providing callable FTP, Telnet and Rlogin. 

Regarding the original question (TCP/IP for MVS), I believe that ACC offers
one, in addition to Spartacus.  Both provide FTP, Telnet (including TN3270)
and SMTP.  Both have UCLA MVS ancestry.  Both need hardware (a front-end) sold
by the vendor to actually provide the network connection.  Writing your own
FTP gateway on a PC would certainly be possible, particularly if it was batch
mode, but I'd be cautious about such a project, because the development would
take a while, and then there would be issues of reliability and maintenance...

James VanBokkelen
FTP Software Inc.

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 88 19:31:41 GMT
From:      narten@cs.purdue.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: network unreachable


In article  <2512@mandrill.CWRU.Edu> edguer@mandrill (Aydin Edguer) writes:
>I am trying to understand why certain sites are unreachable from my machine.
>Background:  [...recently joined NSFnet; prior connection via CSNET..]
 
>Question(s):
> Why would sites which were reachable become unreachable like this?
> Is this due (perhaps) to the dismantling of the ARPAnet which I understand
> is taking place?

No.  Both Purdue and decwrl are still reachable via the ARPANET.

> What can I do to find out why they have become unreachable?

The problem is broken routing tables, and I suspect NSFnet (or its
regionals).

We have been unable to reach net 128.146 (ohio-state) for a week, and
the same is apparently the case for 129.22.  Both of these nets are
reachable from NSFnet sites, but not from us.  Moreover, our butterfly
core gateway has routes for these nets that point to 10.4.0.14
(psc.psc.edu).  Since we can ping psc.psc.edu, I conclude that we are
correctly advertising routes to the core.  In other words, we (Purdue
and ARPANET) are managing routes correctly.

By implication, NSFnet is not correctly propagating all of the routes
it learns from the ARPANET. (Note that for the most part, we can reach
NSFnet sites; only a handful cause trouble.)

> What can I do to try to reach them now that my router has given up?

Contact your regional NOC (if there is one), and if that doesn't help,
call the NSFnet NOC.

The following information would be of help:

1) Do you have a route to get to Purdue (either explicit or default)?
For that matter, do you have routes to other sites that are on the
ARPANET?  Can you ping 10.0.0.37 (purdue's arpanet connection)? 

What about 10.4.0.14?  If both of us can ping a common gateway, but
not each other.......

2) Do you get ICMP unreachable messages when attempting to reach the
networks in question?  The best check for this is a 4.3 system with a
modified ping that prints the name of the gateway that generated the
ICMP message.

Alternatively, one can open TCP connection to the host in question.
For instance, "ftp 128.10.2.1" will abort with a "network unreachable"
error if ICMP unreachables are returned; "connection timed out" on the
other hand, indicates that packets are going into a black hole.  This
works on 4.3 BSD (running the latest tcp/ip code) and Sun OS systems.

-- 
Thomas Narten
narten@cs.purdue.edu or {ucbvax,decvax,ihnp4}!purdue!narten

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 88 22:08:44 GMT
From:      hrp@fermi.CRAY.COM (Hal Peterson)
To:        comp.protocols.tcp-ip
Subject:   Getting started (universal TCP/IP samples)

You ask for a universal sample client/server pair.  The trick is the
``universal'' part, in the face of zillions of hardware architectures,
implementation languages, and interfaces to the protocols and OS.  A
change in any ONE of those three parameters can cause enormous porting
headaches for any non-trivial program.  The best you can do is either
a vague and generic description of, say, the sequence of actions an
ULP must use to handshake with TCP (which you can find in the RFCs) or
a specific example that's reliably good for one kind of box running
one flavor of OS/protocol interface and is written on one source
language.  Neither of those is what you want.


Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN  55120
hrp%hall.CRAY.COM@umn-rei-uc.ARPA	ihnp4!cray!hrp	    (612) 681-3145

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 88 22:33:26 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re: Convert /etc/hosts to RR format pgm anyone? [unrelated]


	FRAME - lowest level of bits/bytes. One speaks of Ethernet Frames, etc
	        A FRAME has ONE data link header (e.g. Ethernet header).
	
	FRAGMENT - the thing that IP spits out to the data link driver. Each
	           FRAGMENT has ONE IP header. A FRAGMENT may be split into
	           multiple FRAMES by the lower layers.

Not quite.  A DATAGRAM becomes fragmented (in FRAGMENTS, of course) so that
each will fit into a FRAME.  The whole purpose of the MTU and fragmentation
is to avoid lower level fragmentation and reassembly.  The only exception to
this is X.25 where you have complete-packet-sequences (but since X.25
is reliable, and in order, this doesn't present a problem).  Under LAN
technologies (ARCNET, PRONET, Ethernet, Token Ring, etc) 1 FRAGMENT ==
1 FRAME.

	[ ... ]	

	DATAGRAM - this is also the 'larger' thing that IP tries to send. A
	           DATAGRAM USUALLY has a one to one relationship with a SEGMENT
	           It may be broken up (fragmented) into a number of FRAGMENTS
	           by IP before being sent through the data link.

Yes.

-Philip

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 88 22:43:15 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville)
To:        comp.protocols.tcp-ip
Subject:   RE: streams based tcpip vs character based tcpip


	The difference is that streams based tcpip is built with stream drivers
	and modules where character based tcpip is built with UNIX V or BSD
	character device drivers. Two different technologies.

Actually, BSD doesn't use character device drivers in the traditional
sense.  They use a different approach, with a network interface which
provides a dispatch table (somewhat like the character or block
device interface).

As I remember, the networking code for Version 6 UNIX did the standard
device model, but I forget the details.  (Their might be an RFC on it.)

-Philip

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jun 88 08:21 5
From:      "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Cisco terminal servers?
     Hello.

     I'm looking for information.  I'm told Cisco makes TELNET terminal 
servers.  This I didn't know.  Is it true?  Are they good (I know they 
make very good routers)?  Do they do the WHOLE standard and not just the 
mandatory parts (i.e. do they do things like Interrupt, Abort etc like
UNIX TELNET)?  What's the failure rate?  What are the common failure
modes?  Do they diagnose easily?  Can their parameters,  i.e. port
characteristics and IP characteristics, be changed from a central
location?  Does it burn up what gets plugged into it?  What's the
software complexity?  Is it ROM based, does it load from disk or is it
downlined?  How is Cisco at repair and support?  Anything else you can
think of would be helpful. 

     I'll summarize the results for the net if anyone wants it.

     Thanks much.

Chris Johnson
Northeastern University.
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 88 08:16:00 GMT
From:      JOHNSON@nuhub.acs.northeastern.EDU ("I am only an egg.")
To:        comp.protocols.tcp-ip
Subject:   Cisco terminal servers?


     Hello.

     I'm looking for information.  I'm told Cisco makes TELNET terminal 
servers.  This I didn't know.  Is it true?  Are they good (I know they 
make very good routers)?  Do they do the WHOLE standard and not just the 
mandatory parts (i.e. do they do things like Interrupt, Abort etc like
UNIX TELNET)?  What's the failure rate?  What are the common failure
modes?  Do they diagnose easily?  Can their parameters,  i.e. port
characteristics and IP characteristics, be changed from a central
location?  Does it burn up what gets plugged into it?  What's the
software complexity?  Is it ROM based, does it load from disk or is it
downlined?  How is Cisco at repair and support?  Anything else you can
think of would be helpful. 

     I'll summarize the results for the net if anyone wants it.

     Thanks much.

Chris Johnson
Northeastern University.

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 88 09:01:08 GMT
From:      chris@mimsy.umd.edu  (Chris Torek)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Getting started
In article <159@heart-of-gold> jc@heart-of-gold (John M Chambers) writes:
>... I'm looking for examples of correct code.
>Note also that I haven't said what machine(s) I'm running on.  If you really
>want to know, I'll tell you (and it's a long list).  But it seems to me that
>if these protocols are at all what they are hyped up to be, it shouldn't much
>matter what sort of machines I have. ...

This is sort of like saying, `I want to know how to install the fuel
filter, but I will not say what kind of car I have.'  One fuel filter
may fit quite a few cars, but the location of the appropriate hose is
different on each.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jun 88 14:33 EST
From:      BEAME@SSCvax.McMaster.CA
To:        tcp-ip@sri-nic.arpa
Subject:   Subnet to Subnet routing

After reading the documents regarding subnets, I still have one outstanding
question with the specifics of BSD/SUN routing from one subnet to another.

Is it possible to use the following numbering scheme and provide complete
inter-communication:

+-------+---------------- Class B Network -----------+--------+
        |                                            |
     +--+--+                                      +--+--+
     | SUN1|                                      | SUN2|
     +--+--+                                      +--+--+
        |                                            |
        |  +-----+                         +-----+   |
        +--+ SUN3|                         | SUN4+---+ (Class C Network)
        |  +-----+                         +-----+   |
        |                                            |
        . (Class C Network)                          .
        .                                            .
        .                                            .

Where SUN1 and SUN2 are on the same Class B network (0 subnet bits)
and SUN3 and SUN4 use the same Class C number, but with 4 bits used for
subnetting.

Will SUN1 route packets, from SUN3 destined to SUN4, to SUN2 when the
destination is the same Class C number except that the subnet bits are
different ?

- Carl Beame

  Beame@McMaster.CA
  Beame@McMaster.BitNet
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 88 12:25:51 GMT
From:      tom@TUT.CIS.OHIO-STATE.EDU (Tom Easterday)
To:        comp.protocols.tcp-ip
Subject:   network unreachable


  The problem that CWRU and Perdue is experiencing is due to two things.
  As of 6/7/88 the link between PSN 29 here at Ohio State and PSN 21 at
  Pittsburgh was deinstalled.  We switched over to our NSFnet link to PSC
  which is a string of Proteon gateways (one here, one in Cleveland, and
  one in Pittsburgh).  These gateways are running Proteon software rev
  7.4 which has a known bug when using default routes.  PSC is in the
  process (so I've been told) of installing rev 7.4b on these gateways 
  which will hopefully clear things up a bit.  I'm counting on it happening
  early this week.  When the Cleveland POP gateway is upgraded CWRU should
  see an improvement.  Maybe Gene Hastings at PSC would like to clarify
  things if something I've said here is incorrect.

Tom Easterday
The Ohio State University
Instruction and Research Computer Center
(614)292-4843
Email: tom@tut.cis.ohio-state.edu
    or tom@oscsuna.osc.ohio-state.edu

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 88 14:15:05 GMT
From:      karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
To:        comp.protocols.tcp-ip
Subject:   Re: network unreachable

narten@cs.purdue.EDU writes:
   edguer@mandrill writes:
   >[...Case Western can't get out to the Rest of the World...]
   > What can I do to find out why they have become unreachable?

   The problem is broken routing tables, and I suspect NSFnet (or its
   regionals).
   We have been unable to reach net 128.146 (ohio-state) for a week, and
   ...
   By implication, NSFnet is not correctly propagating all of the routes
   it learns from the ARPANET. (Note that for the most part, we can reach
   NSFnet sites; only a handful cause trouble.)

Case Western is behind the same gateway as Ohio State...

The problem is out-of-date software at the gateways in Columbus,
Cleveland, and Pittsburgh, from what the local folks managing the net
connections have told me, resulting in routing glitches in large
quantities and leaving us unable to find lots of places, e.g., I
haven't seen utexas.edu in 8 days.  The expectation/hope is that the
matter will be cleared up within another day or two - an update from
The Vendor is on the way.

What a mess,
--Karl

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 88 14:40:22 GMT
From:      Eugene.Hastings@MORGUL.PSC.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Networks unreachable

We have encountered a peculiar situation on a Proteon p4200 that has broken
connectivitiy for Ohio State, Case Western Reserve, and the Universith of
Michigan. The router in question is located in Cleveland and has T1 lines to
those institutions, and also to the routing stub where PSC-GW and companions
connect the ARPANET, NSFNET, PSCNET, and SURANET. Explicit RIP routes are
propagated, plus translated (from hello) NSFNET routes, plus default.  (Let
me remind all and sundry that the present gated does not announce routes
learned via EGP, but relies on the propagation of default.)

So far, so good. Default is propagated successfully to the affected schools,
but when data is sent to a net via default, the p4200 in Cleveland returns
net unreachable (in fact, if the Proteon console is queried for a route to
such a net, like MILNET, the response is "unable to route, reason none".
This reouter has been running v7.4 of Proteon's code for some time, and it
has only been very recently that it has failed. Proteon's response has been
to advise us to use a bugfix, v7.4b, which we have only just received.
No explanation of what may have happened to exercise this bug, or precisely
what bugs have been fixed has been offered. The new version should be
installed today.


Gene

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 88 17:25:40 GMT
From:      Eugene.Hastings@MORGUL.PSC.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Networks unreachable

Yea, verily, and after a restart, the Router In Question passes previously
barfed traffic. Thanks, and a tip of the bashed hat. Yet another reminder
that confession can be good for one's productivity, let alone one's soul.

Thanks again,
Gene
- - - - Begin forwarded message - - - -
Date: Mon, 13 Jun 88 08:25:13 PDT
From: dlw@violet.Berkeley.EDU (David Wasley)
Message-Id: <8806131525.AA24652@violet.berkeley.edu>
To: Eugene.Hastings@morgul.psc.edu
Subject: p4200 bug

We (actually Milo Medin) found what may be that bug when we installed 7.4
here, and Proteon generated 7.4b for us as a result. Basically, if the
box had an explicit route for a net, and it became unreachable (ie 16),
the box wouldn't take default but would claim the net was explicitly
unreachable.

There is a mailing list for p4200 users that Scott Brim started long ago:
p4200@devvax.tn.cornell.edu  --  some of those folks may have other
bug information re 7.4. We've been using 7.4b since January.

	David Wasley
	U C Berkeley

- - - - End forwarded message - - - -

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 88 18:52:03 GMT
From:      dmc@videovax.Tek.COM (Donald M. Craig)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Looking for comments on the 15-pin ethernet connector

I am looking for feedback on the quality and reliability of
the slide latch mechanism used on the DB-15 ethernet connectors.
I have used these myself for the past five years, and have
discovered a number of problems with them.  Additionally,
various nasty remarks about these connectors have surfaced
on the net from time to time.

The Society of Motion Picture and Television Engineers has a
standard known as RP-125 which specifies a parallel digital
television interface.  The connector for that interface is
a 25 pin D-type (DB-25) with a slide latch like the ethernet
connector.  The RP-125 standard is up for revision, and the
Tektronix representative submitted a note from me outlining
my experience and problems with the ethernet slide latch
connector.

Sun Microsystems also has a representative on the RP-125 committee.
He has asked the component engineer for connectors at Sun
if there was any data concerning the mechanical integrity of the
slide latch locking mechanism used in the ethernet connector.
Here is the response:

"I am the Component Engineer for connectors at Sun.  In regards to your
question concerning the Ethernet DB-15, these are used through out
industry by the millions, in many applications.  I am not aware of any
significant problems with mechanical integrity of the lock, or for that
matter with the connector in any aspect.  If the connector is properly
installed and handled in a semi-reasonable manner you should not have
any problems.  As far as Sun is concerned, usage of D-Sub connectors in
general, that is various sizes and configurations, will probably
increase.  When all things are considered it often turns out to be the
best way to go!  Hope this helps!!!"

In the face of this informal statement by Sun's component engineer,
I now need data about other people's experience with the DB-15 slide
latch ethernet connector.   Help save another standard from the same
fate!  Please send your comments email to:
	dmc@tv.tv.tek.com
		or
	tektronix!videovax!dmc

Thank you,

Don Craig
Tektronix Television Systems

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 88 18:54:55 GMT
From:      dheeraj@CHAKRA.CS.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   Pointers to performance studies on TCP/IP...

Hi,
	I am doing a performance analysis of TCP/IP by  instrumenting
the code and monitoring the selected connections. I am extremely interested
in knowing about the other performance studies done so far. Any pointers
to papers/journals/reports etcetera would be greatly appreciated.

If somebody is interested, I am working on SUN3.0 modified locally to
include 4.3BSD networking code.

thanks in advance,
-dheeraj

Dheeraj Sanghi					(301)-454-1516  (off)
Systems Design & Analysis Group			(301)-345-6024	(home)
Dept of CS, U of MD., College Pk. MD -20742	dheeraj@tove.umd.edu

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 88 19:33:00 GMT
From:      BEAME@SSCvax.McMaster.CA
To:        comp.protocols.tcp-ip
Subject:   Subnet to Subnet routing


After reading the documents regarding subnets, I still have one outstanding
question with the specifics of BSD/SUN routing from one subnet to another.

Is it possible to use the following numbering scheme and provide complete
inter-communication:

+-------+---------------- Class B Network -----------+--------+
        |                                            |
     +--+--+                                      +--+--+
     | SUN1|                                      | SUN2|
     +--+--+                                      +--+--+
        |                                            |
        |  +-----+                         +-----+   |
        +--+ SUN3|                         | SUN4+---+ (Class C Network)
        |  +-----+                         +-----+   |
        |                                            |
        . (Class C Network)                          .
        .                                            .
        .                                            .

Where SUN1 and SUN2 are on the same Class B network (0 subnet bits)
and SUN3 and SUN4 use the same Class C number, but with 4 bits used for
subnetting.

Will SUN1 route packets, from SUN3 destined to SUN4, to SUN2 when the
destination is the same Class C number except that the subnet bits are
different ?

- Carl Beame

  Beame@McMaster.CA
  Beame@McMaster.BitNet

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 88 21:53:31 GMT
From:      jsloan@wright.EDU (John Sloan)
To:        comp.protocols.tcp-ip
Subject:   Re: DELNI Rack Mount Kits

Are we all talking about the same thing? In my DECDirect catalog,
Winter/Spring 1988, on the same page as the DELNI (p. 113), P/N
H3126-00/FP, Rack Mount Brackets, $42. I've ordered these, installed
them on the DELNIs, and rack mounted them. Did one just last week.
What's the deal? Am I confused? Are they no longer available?
Should I be worried?

-- 
John Sloan, The SPOTS Group    Wright State University Research Building
CSNET: jsloan@SPOTS.Wright.Edu  3171 Research Blvd., Kettering, OH 45420
UUCP:  ...!wright!jsloan                +1-513-259-1384  +1-513-873-2491
Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 88 01:16:34 GMT
From:      lekash@ORVILLE.NAS.NASA.GOV (John Lekashman)
To:        comp.protocols.tcp-ip
Subject:   HYROUTE(TCP/IP gateway between HYPERchannel and ethernet)


     The bottom line is that any implementation of HYROUTE that limits
     you to a subset of the IP addresses that the vendor supports is
     broken.  (That is, if the vendor doesn't support subnets, then
     his HYROUTE program isn't broken because it doesn't work with
     subnets.  But if the vendor does support subnets, as the vendor
     should, and HYROUTE does not work with subnets, then the vendor's
     implementation is broken)

I bet this problem stems from the fact that the BSD distributed
in_lnaof() in the C-library does not return the subnetted net, only
the main network number.  (At least the version we have.  I think
I've gotten all bug fixes.)

So, the typical clever programmer just calls in_lnaof(addr) in
both the hyroute and the kernel, and loses cause they return
different things for user and kernel space.

I fixed this here some time ago by sticking in a in_mainlnaof()
in the hy driver, and calling that.  It returns only the class A,B,C
network.  It would be better to repair the c-library, but
it does not seem to be a trivial fix, and I didn't want to 
worry about breaking other things at this time.

I like the idea of hashing on the whole IP address better, but it
does mean a more difficult hashing algorithm, or else a really
big table.  I know those few rotates and adds don't much matter,
but they have to happen on every packet.

						john

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 88 14:26:32 GMT
From:      trewitt@MIASMA.STANFORD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: DELNI Rack Mount Kits

> Are we all talking about the same thing? In my DECDirect catalog,
> Winter/Spring 1988, on the same page as the DELNI (p. 113), P/N
> H3126-00/FP, Rack Mount Brackets, $42. I've ordered these, installed
> them on the DELNIs, and rack mounted them. Did one just last week.
> What's the deal? Am I confused? Are they no longer available?
> Should I be worried?

Here's some details on the kit that Clive Dawson mentioned earlier:

For a smaller part number (270-023) and a much smaller price ($2.99),
I think that the Radio Shack "Universal Mounting Bracket Set" is a much
better deal.  The only drawback is that you have to provide your own
#6-32 screws and washers.  Works great!  And, you have two other pairs
of brackets left over, just in case you need to mount a car stereo.

	- Glenn

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 88 14:42:09 GMT
From:      jps@wucs2.UUCP (James Sterbenz)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   TCP/IP on mainframes

I am interested in experiences involving the installation/operation
of official internet protocols (especially  TCP and IP) on large
mainframe systems.  I'd like to know how the protocols were installed
(division of processes, what code runs priviliged, etc.), how the
system architecture is utilized (is the communications link on a 
communications processor or an IOP), and how the implementation
performs.  I'm interested in this for the research issues pertaining to
high performance network-host architectures, rather than from the 
standpoint of finding a package to run on my system.

Either pointers to existing documentation (papers, tech reports) or 
private communications would be appreciated.  

In particular, I am looking for non-Unix, large system implementations,
such as on IBM sys/370 (303x, 308x, 3090) machines under MVS or VM,
Burroughs 6000/7000/A MCP, Univac 1100 EXEC, NCR 8500/8500 VRX, CDC
Cyber 700/800 NOS and NOS/VE, Honeywell DPS 8/80/90 GCOS and MULTICS
(yea I know Burroughs and Univac ane now Unisys, but it messes up the
"BUNCH"), and ICL 2900 VME.

 
I would guess that there are a number of these installations, especially IBM
(due to sheer numbers) and Univac (due to high government usage).


For example, in the IBM sys/370 MVS environment:
     - which parts of the protocols run as seperate tasks, and in what
       address spaces
     - how is inter adress space communication handeled: via SRB's or using
       CMS
     - what code runs user state, semi-priveleged, or supervisor state (key 0)
     - how are buffers allocated and passed (GETMAIN vs. GETCELL or CPOOL)  
     - what are performance factors: virtual storage (disk or extended),
       real storage utilization, SRM parameters (ICS, IPS), etc.
     - are links handeled as communications devices or I/O devices
     - if links are I/O devices, was IOS code modified and were new 
       channel programs written
     - if links are communications devices, was any existing VTAM
       (or God forbid, TCAM or BTAM  :-) code used (actually the effort
       might be worth the efficiency gained by using BTAM), or was a 
       'conventional' access method custom written
     - was existing NCP/SNA code utilized in a 3725 or 3705 box or was a 
       custom control program written
     - other issues are important, but this gives the flavor of what I'm
       looking for


If responses are e-mailed to me, I will summarize results and post.

-- 
James Sterbenz  Computer and Communications Research Center
                Washington University in St. Louis 314-726-4203
INTERNET:       jps@wucs1.wustl.edu
UUCP:           wucs1!jps@uunet.uu.net

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 88 15:02:23 GMT
From:      jas@proteon.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   Subnet to Subnet routing

Subnets of a given subnet must be contiguous.  The definition of
contiguous is that all subnets of the net are reachable via routes
internal to that network.  It's in RFC 950 and RFC 1009.

The whole point of subnets is to hide the internal structure of a
network from all other networks.  In your example, the Class C network
has been split, and is not contiguous, since traffic between the
subnets must cross the Class B network.  Since hosts on the Class B
network are routing to the Class C network on a network (not subnet)
basis, how will they know whether to send traffic for SUN3 via SUN1 or
SUN2? 

Looking at your configuration, subnet your Class B network, using from
4 to 8 subnet bits.  Make each Ethernet one subnet.  Subnetting Class
C networks is not typical.

If there are some hosts on the backbone Ethernet that don't know from
subnets, you may be able to fake them out using proxy ARP subnet
routing.  However, they had better age their ARP cache if they do
this.

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 88 15:28:03 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

dmc@videovax.Tek.COM (Donald M. Craig) writes:
> I am looking for feedback on the quality and reliability of
> the slide latch mechanism used on the DB-15 ethernet connectors.

	In a nutshell, they suck!  There is no doubt that the single most
common cause of problems in our entire network (19 Suns, a Vax, and maybe a
dozen Macintoshes and PCs) is loose ethernet tranciever cables, particularly
on the backs of Sun-3/50's which provide no mechanical support for the cable
at all.  On our rack-mount systems, we support the cables with cable ties to
various convenient supports.  On our deskside suns, we've constructed
assorted mechanical strain reliefs.  Some of our 3/50's seem to be OK with
just wedging the cable behind a desk but some are a constant cause of
trouble.  For the worse ones, we install a support bracked we've designed
which helps a little (it's just a plexiglass bar notched to fit on the card
extractor ears and with cutouts for the various cables and attachment points
for cable ties in the appropriate places).

> "I am the Component Engineer for connectors at Sun.  In regards to your
> question concerning the Ethernet DB-15 [...]  I am not aware of any
> significant problems with mechanical integrity of the lock, or for that
> matter with the connector in any aspect.

	I'm not given to public flamage, but this guy must have his head
firmly wedged in a dark place.  If he's not aware of any problems, it because
he hasn't been listening.  I've complained loudly about this on the net
before.  I've complained to Sun field service.  I've complained to Sun tech
support.  Clearly those complaints havn't gotten back to the right people.

	The stupid little stamped sheet metal clips are simply not strong
enough to secure a connector with a big fat, heavy, and fairly stiff
tranciever cable on it.  As long as the cable is secured so if can't move if
accidentally moved, it's OK.  For example, on the tranciever ends, we lash
the cable to the main ethernet trunk cable with 2 (or sometimes 3) wire ties
a few inches away.  But on systems which might move a little (like a deskside
Sun on wheels), or in situations where the cable might be disturbed (like
hanging off the back of a desk) forget it.

	What was wrong with good-old RS-232-style screws?  Or, if they really
wanted a tool-less installation, why not Macintosh-style knurled screws, or
maybe even centronics-style wire bails?  We recently got a 3-Com 3C503
ethernet card for an IBM-PC.  The connector is a bit different, with screw
holes instead of binding posts.  Unfortunately, to use the screw holes you
need a special adaptor bracket which I havn't been able to locate yet (OK, we
just got the thing; I havn't had a chance to look very hard).  It looks like
it might be a bit more secure.  Our Interlan ethernet board for the vax has a
slight variation on the slide connector which looks like it might be
marginally stronger (it has small extra ridges along the sides), but I doubt
it would still be strong enough if we weren't able to lash the cable to
various places in the vax's rack frame.

	I really don't know what the DIX guys had in mind when they designed
this connector.  Administering a network is hard enough without having to
worry about which $5 connector is falling out.
-- 
Roy Smith, System Administrator
Public Health Research Institute
455 First Avenue, New York, NY 10016
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 88 17:41:50 GMT
From:      cliff@se-sd.sandiego.NCR.COM (Cliff Bamford)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

The problem is that it's impossibly impractical to give that connector
"reasonable care" in the field. Regardless of type, connectors always 
seem to be just-barely-visible and just-barely-out-of-reach. The D-sub
requires good visibility (to tell which way the slider is slid) and
good tactile access to [un]couple. Since these conditions rarely obtain,
THE !#@$%&* CONNECTER DRIVES PEOPLE CRAZY.

Which is one of the reasons you see so many of them torn asunder, at
which point they become worse than useless. Except as mute testimony
to the limits of human patience.

-- 
cliff.bamford@sandiego.ncr.com  (619)693-5724  {ucsd,cbosgd}!ncr-sd!se-sd!cliff

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 88 17:58:28 GMT
From:      ron@topaz.rutgers.edu (Ron Natalie)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

Yep, by the way, we've gone and replaced the slide clips with the good old
RS-232 screws and threaded inserts on all the Ethernet cables of importance.

-Ron

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 1988 23:41-EDT
From:      KSEO@G.BBN.COM
To:        dheeraj@TOVE.UMD.EDU, dheeraj@CHAKRA.CS.UMD.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, satnet-task-force@VAX.BBN.COM
Subject:   Re:  Pointers to performance studies on TCP/IP...
Dheeraj,

The SATNET (Atlantic Packet Satellite Network) Measurement Taskforce
just completed some work analyzing TCP/IP performance over the SATNET.
As part of this effort, we developed an instrumented TCP/IP
implementation and a separate IP measurement tool.  For additional
information:
	a) Our experimental methodology, tools and results are
	   described in a paper to be presented at SIGCOMM 88
	   in August.  Send me your paper address if you'd like a 
	   copy.
	b) There will be 3 additional writeups describing the 
	   taskforce's work in more detail.  These will probably
	   be done by the end of the summer.  Let me know if you'd
	   like copies when they're complete.
	c) For specific details about the TCP and IP tools, please
	   contact:
		TCP tool: Jon Crowcroft (jon@cs.ucl.ac.uk) 
		IP tool:  Paal Spilling (paal@tor.nta.no) 

Let me know if you have further questions, 
Karen
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 88 19:54:09 GMT
From:      bzs@bu-cs.BU.EDU (Barry Shein)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector


I'll second Roy Smith's gripes about those slide-latch ethernet
connectors to quote Roy:

	"In a nutshell, they suck!"

Actually, if there were some negative pressure they might work...

We have around 100 Suns here and other assorted items (this lousy
slide-latch is not unique to Suns by any means, it's ubiquitous) and
they're always falling out, the worst catastrophes occur when they
fall out of centralized server machines, we've been out for hours and
hours while some poor operator tries to figure out what the problem is
(they're learning, we're all learning.)

Worse, much worse, it falls out of MY SUN all the time, like when I
swing my chair around to gulp coffee or some other critical maneuver
and brush the deskside tower, to get it to stay back in I have to
re-arch the cable at a precarious angle so it provides pressure
towards the plug.

Now *that's* unacceptable, the public be damned.

I'll also add a vote to the Mac-like knurled screws, that would be the
ticket.

	-Barry Shein, Boston University

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 88 20:41:12 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: the 15-pin ethernet connector slide lock

In article <23340@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
>
>I'll also add a vote to the Mac-like knurled screws, that would be the
>ticket.

	That would just about do it, but there are some little touches
that the hardware guys could do if they just thought about how the
equipment gets used.  Hardware engineers- you listening??

	Redesign the host side of the connection for better strain
relief.  We can handle the xcvr side with ty wraps alright.

	First, use a 90 degree angle on the cable into the connector.
Then provide a ty wrap mount an inch or so away from the connector
mounting point so we can tie the cable down and provide strain relief.
Barry will also be able to shove his deskside closer to the wall and
that will help.

	If you can't angle the cable put a standoff bar somewhere on
the back of the box so that when the unit IS shoved into the wall it
won't crush the cable/connector and pop it off.  Ideally, put a strain
relief point on the standoff bar so we can tie the cable down.  (Smart
guys will do both.)

	This would help a great deal even without a major session of
802.3 devoted to rehashing this.

	Kent England, also BU

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 88 21:02:30 GMT
From:      bae@ati.tis.llnl.gov (Hwa Jin Bae)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector


In general, I don't like DIX 15 pin adapter without any secure screws.
My Symmetric 375 comes with 9 pin output which can be interface to
regular transceiver with a 9 pin to 15 pin drop cable.  You can use
RS-232 like screw attachment with it, and it's so much nicer than SUN's
way of doing attachment.  But then again you can always use "Crazy Glue"
or something... 8-)

---

Hwa Jin Bae          | Standard excuses...not responsible.../dev/null...etc.
Control Data Corp.   | (415) 463 - 6865
4234 Hacienda Drive  | bae@tis.llnl.gov			   (Internet)
Pleasanton, CA 94566 | {ames,ihnp4,lll-crg}!lll-tis!bae    (UUCP)

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 88 23:13:34 GMT
From:      dewey@execu.UUCP (dewey henize)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

In article <5047@videovax.Tek.COM> dmc@videovax.Tek.COM (Donald M. Craig) writes:
>I am looking for feedback on the quality and reliability of
>the slide latch mechanism used on the DB-15 ethernet connectors.

[	Info on use of the info... }

>Sun Microsystems also has a representative on the RP-125 committee.
>He has asked the component engineer for connectors at Sun
>if there was any data concerning the mechanical integrity of the
>slide latch locking mechanism used in the ethernet connector.
>Here is the response:
>
>"I am the Component Engineer for connectors at Sun.  In regards to your
>question concerning the Ethernet DB-15, these are used through out
>industry by the millions, in many applications.  I am not aware of any
>significant problems with mechanical integrity of the lock, or for that
>matter with the connector in any aspect.  If the connector is properly
>installed and handled in a semi-reasonable manner you should not have
>any problems.  As far as Sun is concerned, usage of D-Sub connectors in
>general, that is various sizes and configurations, will probably
>increase.  When all things are considered it often turns out to be the
>best way to go!  Hope this helps!!!"
>
>In the face of this informal statement by Sun's component engineer,
>I now need data about other people's experience with the DB-15 slide
>latch ethernet connector.

Here at Execucom we have a slightly different term for this 'device'.  I
won't put it out on the net, however, since this probably isn't the place
to put adjectives regarding personal ancestory or public sexual habits.
Suffice it to say that if the person who designed the slide latch connector
were to come here and visit, his/her employer should only buy a one-way
ticket - we'd be able to ship what remains there were back in a shoebox!

Seriously, those things are a joke.  When each and every part is made to exact
and perfect spec, they seem to work ok (at least until you touch them in
some fashion).  The ones we got with at least 3 of our Suns and the cables
that we also got from Sun seem to be made to different specs entirely.  We
had to do a good bit of reverse engineering to get them to handle the normal
vibration of someone merely walking in the office (concrete floors).

Junk em.  Use screws.

Please, since you are protecting this 'Component Engineer', help him/her/it
:-) become aware of 'significant problems'.
 
-- 
===============================================================================
|      execu!dewey  Dewey Henize @ Execucom Systems Corp 512/346-3008         |
|    You don't think my employer APPROVES of these ideas, do you??  Sheesh!   |
=============================================================================== 

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 88 23:14:54 GMT
From:      jimk@iscuva.ISCS.COM (Jim Kendall)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: Delni

Jerry Aguirre writes:
>Now for the bad news.  I had one of the MR-9000s fail.... But I didn't find
>Cabletron very responsive; it took several days and many phone calls to
>get me the RMA number and the repair took over a week..... Perhaps if
>I had told them I was off the air they would have arranged a loaner.
>What was disturbing was that I have written a PO and received a new unit
>from them in half the time it took to get an in-warranty repair.

We detected a malfunction in one of our MR-9000s in that when the cable
segment was accidentally opened up a couple of hundred feet down the wire,
the fault and collision lights didn't come on........but the jam light 
flickered rapidly. This indication tells me that the faulty segment did
not automatically disconnect and that runt packets were being propagated
to all segments (including channel 9, the Ethernet segment). Needless to 
say, this loaded the network quite heavily. I disconnected the faulty
segment and, sure enough, the collision and fault lights lit and the
segment disconnected properly. I called Cabletron and told them about it
and they indicated that there was a PAL change made to later units (ours
was 8 months old, therefore we didn't have the PAL change) to fix a faulty
segment disconnect problem, BUT....he said that what I was describing didn't
sound like the problem the PAL change was intended to fix. He said that he 
would air freight me up a new one and that I should get it next Monday (this
was last week and Monday has obviously passed) along with an RMA # to ship
the old one back under. To date I've gotten neither.....and we need this
to fix our problem (we are in a developement situation where we are often
opening up segments, and it's imperative that the open segment disconnect
properly).

So, Jerry, I don't know about the "if I'd only told them I was down" 
arguement. While I've typically had good response from Cabletron, in this
particular instance it hasn't been.

Now just watch.......I'll hit the `S'end key and Receiving will call and
tell me to come get my MR-9000      ;^)

Cheers!

-- 
Jim Kendall                 ISC Systems Corp.          My boss is in full
jimk@iscuva.ISCS.COM        E. 22425 Appleway          agreement with all
uunet!iscuva!jimk           Liberty Lake, WA  99019    of my opinions....

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 88 23:18:33 GMT
From:      jimk@iscuva.ISCS.COM (Jim Kendall)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP


OHH!!! I forgot to ask..........

Has anyone got TCP/IP working on their eniac yet????


(That's a joke, son.......      :-)

Cheers!
-- 
Jim Kendall                 ISC Systems Corp.          My boss is in full
jimk@iscuva.ISCS.COM        E. 22425 Appleway          agreement with all
uunet!iscuva!jimk           Liberty Lake, WA  99019    of my opinions....

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 88 02:02:29 GMT
From:      root@sbcs.sunysb.edu (root)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

In article <3352@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes:
> dmc@videovax.Tek.COM (Donald M. Craig) writes:
> 
> > "I am the Component Engineer for connectors at Sun.  In regards to your
> > question concerning the Ethernet DB-15 [...]  I am not aware of any
> > significant problems with mechanical integrity of the lock, or for that
> > matter with the connector in any aspect.
> 
	To the "Component Engineer" at Sun:  I submit Sir, that you
	must not use your own product.  At Stony Brook we have ~100
	Suns of mixed types and I can attest that the metal slide lock
	causes us NO END of trouble.  

> 	What was wrong with good-old RS-232-style screws?  Or, if they really
> wanted a tool-less installation, why not Macintosh-style knurled screws, or
> maybe even centronics-style wire bails?  We recently got a 3-Com 3C503
	
	I would like to see a connector like the one used on the
	uVAX (?) console cable:  Long screw posts with a knob on
	the end that allows finger tightening of the screw.  I 
	understand that the slide is somehow a standard, but if 
	it "don't work" then fix the bloody thing.

> Roy Smith, System Administrator
> Public Health Research Institute
> 455 First Avenue, New York, NY 10016
> {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net

					Rick Spanbauer
					SUNY/Stony Brook

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jun 88 07:50 5
From:      "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Ethernet slide connectors
     Roy Smith, System Administrator for Public Health Research Institute
writes:

	"In a nutshell, they suck!"

     While I might have phrased it differently, I fully agree.  I have 
yet to get one of these silly, stupid slide style connectors to work.  I 
much prefer the other kind that are screwed in.

     We also use the idea of cable ties to secure the cables.  
Fortunately I can get away with this since all my wires are in very 
fixed places.  I had to scream at the communications people here to tie 
them up because they were constantly falling out just from fan 
vibration (and random air currents too I think).  In the earily days of
our Ethernet this was the cause of many a mysterious problem. 

     One of the things I ask vendors now is what style connector their 
hardware comes with.

Chris Johnson
Northeaster University.
-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jun 88 09:49:18 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        "Donald M. Craig" <tektronix!tekcrl!tekfdi!videovax!dmc@UCBVAX.Berkeley.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Looking for comments on the 15-pin ethernet connector

>     I am looking for feedback on the quality and reliability of
>     the slide latch mechanism used on the DB-15 ethernet connectors.

>     The Society of Motion Picture and Television Engineers has a
>     standard known as RP-125 which specifies a parallel digital
>     television interface.  The connector for that interface is
>     a 25 pin D-type (DB-25) with a slide latch like the ethernet
>     connector.  The RP-125 standard is up for revision, ...

So far, I have seen people flaming the slide latch, but no comment on the
Dtype connectors.  While using screws to replace the slide latch helps in some
cases, the main problem seems to be that the long, narrow connector with 2
rows of pins cannot withstand stress from a heavy or thick or stiff cable.
There should be some analysis of why you should not use cable that is an inch
in diameter to contain 18 individually shielded twisted pairs for your
rs422/rs449 and try to connect it with a DC-37.

The slide latch can only handle a little stress on the long dimension, and can
handle none on the narrow dimension.  The DB15 would be ok with a ribbon
cable, because the ribbon is both light and flexible, and a well fitted slide
latch would lock it in place, but then you would not even need a lock because
the friction of the connector would keep it it.

So, if SMPTE is going to do it right, they need to consider the mechanical
characteristics of the locking mechanism, as well as the ease of connection
and disconnection.

Mike

disclaimer:  My degree is E.E., not M.E., so I am relating experiences, not
properly qualified professional opinion.
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 88 03:41:00 GMT
From:      KSEO@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re:  Pointers to performance studies on TCP/IP...

Dheeraj,

The SATNET (Atlantic Packet Satellite Network) Measurement Taskforce
just completed some work analyzing TCP/IP performance over the SATNET.
As part of this effort, we developed an instrumented TCP/IP
implementation and a separate IP measurement tool.  For additional
information:
	a) Our experimental methodology, tools and results are
	   described in a paper to be presented at SIGCOMM 88
	   in August.  Send me your paper address if you'd like a 
	   copy.
	b) There will be 3 additional writeups describing the 
	   taskforce's work in more detail.  These will probably
	   be done by the end of the summer.  Let me know if you'd
	   like copies when they're complete.
	c) For specific details about the TCP and IP tools, please
	   contact:
		TCP tool: Jon Crowcroft (jon@cs.ucl.ac.uk) 
		IP tool:  Paal Spilling (paal@tor.nta.no) 

Let me know if you have further questions, 
Karen

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jun 88 9:32:49 EDT
From:      "Benjamin J. Woznick" <bjw@WILMA.BBN.COM>
To:        "Donald M. Craig" <tektronix!tekcrl!tekfdi!videovax!dmc@ucbvax.berkeley.edu>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Looking for comments on the 15-pin ethernet connector
I would like to second most of the comments that have been made
about the slide connector.  The problem with the ethernet is compounded
by the size and stiffness of the cable.  The only quibble I have
with the other comments is that *I* can't really tell which way the
slide wants to go even when I have it in full view.  This has to
be the worst human-engineered connector in the history of mankind.
	Ben Woznick
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 88 06:02:31 GMT
From:      robert@ATOM.HPL.HP.COM (Robert Michaels)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector


>	The stupid little stamped sheet metal clips are simply not strong
>enough to secure a connector with a big fat, heavy, and fairly stiff
>tranciever cable on it.  As long as the cable is secured so if can't move if
>accidentally moved, it's OK.  For example, on the tranciever ends, we lash
>the cable to the main ethernet trunk cable with 2 (or sometimes 3) wire ties
>a few inches away.  But on systems which might move a little (like a deskside
>Sun on wheels), or in situations where the cable might be disturbed (like
>hanging off the back of a desk) forget it.
>
>	What was wrong with good-old RS-232-style screws?  Or, if they really

To me the problem is that the little clips are "standard". I would be very
surprised if a vendor will have enough courage to promote something more
effective. To alleviate your problem you could try using a lighter weight
transceiver cable. For us most transceivers are within 5 meters of the host.
For short runs you don't need these really big fat cables. I think several
vendors build these short lightweight transceiver cables ( yes even HP does).

- Robert Michaels
  HP Labs

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 88 07:45:00 GMT
From:      JOHNSON@nuhub.acs.northeastern.EDU ("I am only an egg.")
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet slide connectors


     Roy Smith, System Administrator for Public Health Research Institute
writes:

	"In a nutshell, they suck!"

     While I might have phrased it differently, I fully agree.  I have 
yet to get one of these silly, stupid slide style connectors to work.  I 
much prefer the other kind that are screwed in.

     We also use the idea of cable ties to secure the cables.  
Fortunately I can get away with this since all my wires are in very 
fixed places.  I had to scream at the communications people here to tie 
them up because they were constantly falling out just from fan 
vibration (and random air currents too I think).  In the earily days of
our Ethernet this was the cause of many a mysterious problem. 

     One of the things I ask vendors now is what style connector their 
hardware comes with.

Chris Johnson
Northeaster University.

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 88 11:39:04 GMT
From:      cml@texhrc.UUCP (Chris Lonvick)
To:        comp.protocols.tcp-ip
Subject:   Re: DELNI Rack Mount Kits

>kinda amazed me.  DEC sells the brackets as an option in Europe for the 
> standard 19" rack, but not in the US.  In the US, they only come with the
 [...]
> to be an Engineering Test facility for an Automotive company, it was no
> big deal for us to fabricate the parts ourselves.  I would have still
> prefered to buy them from DEC. [???]
> 

I've been buying the ears from DEC for at least two years. If I had a machine
shop I would opt to manufacture them in-house since they could then be made
from gold and still cost less than what DEC charges. In the current 
DEC Direct catalog: H3126-00/FP Rack Mounting Brackets (rack 4 DELNI) $42.
This gives you 8 ears, some screws and a neat pictorial guide to correct
installation. Such a deal.

Chris Lonvick
Texaco EPTD

Usual Disclaimer: These views are mine, mine, all mine and you can't have any.

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 88 13:32:49 GMT
From:      bjw@WILMA.BBN.COM ("Benjamin J. Woznick")
To:        comp.protocols.tcp-ip
Subject:   Re:  Looking for comments on the 15-pin ethernet connector

I would like to second most of the comments that have been made
about the slide connector.  The problem with the ethernet is compounded
by the size and stiffness of the cable.  The only quibble I have
with the other comments is that *I* can't really tell which way the
slide wants to go even when I have it in full view.  This has to
be the worst human-engineered connector in the history of mankind.
	Ben Woznick

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 88 13:38:06 GMT
From:      schuetz@iravcl.ira.uka.de
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   tcp-connection on vaxen: vms4.7 <-> bsd4.3 (second attempt)

Hello again,

8 days ago I posted a very detailed letter (Reference <146@iravcl.ira.uka.de>.
Up to now I got no answers. Maybe there's trouble with BITNET from some sites
(delay up to 3 weeks) maybe no one knows the answer ...

I now want to know is there anybody who programmed with cmu-tek tcp/ip on VAXen
under VMS? Did you make a connection to a machine under bsd4.3 (esp. VAX, too)?
Did your program use two ports to communicate? Did you open the 1st port active
and the 2nd passive?

If you answer all questions with 'yes' please contact me. I want to hear of the
functions and parameters you use with '$qio'.

FYI: I'm using VAX-cluster (8700/8200 VMS4.7), VAX 11/750 (bsd4.3), IP_ACP(V6.2)

Please reply via e-mail to schuetz@ira.uka.de

Many thanks in advance
Regards, Elmar

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 88 13:49:18 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector


>     I am looking for feedback on the quality and reliability of
>     the slide latch mechanism used on the DB-15 ethernet connectors.
 
>     The Society of Motion Picture and Television Engineers has a
>     standard known as RP-125 which specifies a parallel digital
>     television interface.  The connector for that interface is
>     a 25 pin D-type (DB-25) with a slide latch like the ethernet
>     connector.  The RP-125 standard is up for revision, ...

So far, I have seen people flaming the slide latch, but no comment on the
Dtype connectors.  While using screws to replace the slide latch helps in some
cases, the main problem seems to be that the long, narrow connector with 2
rows of pins cannot withstand stress from a heavy or thick or stiff cable.
There should be some analysis of why you should not use cable that is an inch
in diameter to contain 18 individually shielded twisted pairs for your
rs422/rs449 and try to connect it with a DC-37.

The slide latch can only handle a little stress on the long dimension, and can
handle none on the narrow dimension.  The DB15 would be ok with a ribbon
cable, because the ribbon is both light and flexible, and a well fitted slide
latch would lock it in place, but then you would not even need a lock because
the friction of the connector would keep it it.

So, if SMPTE is going to do it right, they need to consider the mechanical
characteristics of the locking mechanism, as well as the ease of connection
and disconnection.

Mike

disclaimer:  My degree is E.E., not M.E., so I am relating experiences, not
properly qualified professional opinion.

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 88 14:15:52 GMT
From:      dlnash@ut-emx.UUCP (Donald L. Nash)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

In article <23340@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes:
> 
> We have around 100 Suns here and other assorted items (this lousy
> slide-latch is not unique to Suns by any means, it's ubiquitous) and
> they're always falling out, the worst catastrophes occur when they
 ^^^^^^^ ^^^^^^ ^^^^^^^ ^^^
> fall out of centralized server machines, we've been out for hours and
> hours while some poor operator tries to figure out what the problem is
> (they're learning, we're all learning.)
> 

It really gets interesting when the cable falls out just enough that
the transmit wire gets disconnected but the receive wire is still in
place.  Then you have a machine which can listen but not talk.  We had
this happen on a MicroVAX II and almost went into a panic thinking
the DEQNA had died.

> I'll also add a vote to the Mac-like knurled screws,

Me, too.


				Don Nash

UUCP:    ...!{allegra, seismo!ut-sally}!ut-emx!dlnash
ARPA:    dlnash@emx.utexas.edu
BITNET:  DLNASH@UTADNX, D.NASH@UTCHPC
THENET:  UTADNX::DLNASH, UTCHPC::D.NASH

UUU       UUU
 U         U                The University of Texas at Austin
 U     TTTTUTTTTTTTTT              Computation Center
 U     T   U TT     T
  U       U  TT            "The world is basically non-linear."
   UUUUUUU   TT
             TT 
            TTTT

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 88 17:41:54 GMT
From:      wesommer@athena.mit.edu (William Sommerfeld)
To:        comp.protocols.tcp-ip
Subject:   Re:  Looking for comments on the 15-pin ethernet connector

Actually, I would vote for something similar to what DEC uses for
serial console cables: screw connectors with knurled knobs which have
a slot for a screwdriver in them; this way, you don't _need_ a
screwdriver to connect or disconnect them, but if you have a
screwdriver, you can save some wear and tear on your fingers...

					- Bill

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 88 18:11:49 GMT
From:      tpmsph@ecsvax.UUCP (Thomas P. Morris)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector


In my limited experience with 3 hosts and 10 terminal servers and 2 DELNI's,
those $#%@%&^%$ slide latches on the ethernet db15s are a real problem.
As has been pointed out before, they are not built well enough to handle
the actual weight and strain of the bulky transceiver cable, and they
don't do their job as a result! Screws or knurled knobs or wire bails
a la IEEE488 or Centronics would be a welcome relief! For our DELNIS we
had to cobble together a custom strain-relief panel. For the servers
we ended up tie-wrapping the cables to the frame supports.


-----------------------------------------------------------------------------
Tom Morris                                 BITNET: TOM@UNCSPHVX
UNC School of Public Health                UUCP  : ...!mcnc!ecsvax!tpmsph
-----------------------------------------------------------------------------
-- 
-----------------------------------------------------------------------------
Tom Morris                                 BITNET: TOM@UNCSPHVX
UNC School of Public Health                UUCP  : ...!mcnc!ecsvax!tpmsph
-----------------------------------------------------------------------------

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jun 88 01:13
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@relay.MOD.UK>
To:        Jim Kendall <@nss:iscuva!jimk@uunet.uu.net>
Cc:        tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa>
Subject:   Re: TCP/IP
Jim,
 
'...eniac...'   Hmmmmm.... in the spirit of competition and keeping
the UK ahead of the game - I'll race down to the Science Museum London
and hack TCP/IP onto the Babbage m/c ...... now where did I put my
hacksaw (agreed a weak pun). Those of you strong on theory might like
to try it on the Turing m/c - US folks would rather go to Church and
Post a solution, or in these days of detente why not chain yourself
to A Markov.
 
Wales is a whisper away from here so don't be surprised if you hear
on the news come 21/22 June that Stonehenge, after Hoyle (Fred and
not the American maker of Rules quoted in a song), has been re-
programmed with Theological Cosmic Prayer/Inter-galatic Protocol.
 
John
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 02:10:23 GMT
From:      donegan@stanton.TCC.COM (Steven P. Donegan)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector


How many of you fools still swear at slide locks, experience massive down
time due to same? Well, less than a dollars worth of hardware and the guts
to mess with the 'standard' (read holy) connectors will buy you much peace
of mind. We convert ALL slide-lock cables and devices to SCREW-DOWN style.
Haven't lost a single server or transceiver due to our un-holy conversion to
a much more secure fastening method.
-- 
Steven P. Donegan
Sr. Telecommunications Analyst
Western Digital Corp.
donegan@stanton.TCC.COM

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 03:21:30 GMT
From:      evan@ndcheg.UUCP (Evan Bauman)
To:        comp.protocols.tcp-ip
Subject:   Re: Networks unreachable

In article <1988.6.13.14.27.28.Eugene.Hastings@morgul>, Eugene.Hastings@MORGUL.PSC.EDU writes:
> We have encountered a peculiar situation on a Proteon p4200 that has broken
> connectivitiy for Ohio State, Case Western Reserve, and the Universith of
> Michigan. The router in question is located in Cleveland and has T1 lines to
> those institutions, and also to the routing stub where PSC-GW and companions
> connect the ARPANET, NSFNET, PSCNET, and SURANET. Explicit RIP routes are
> propagated, plus translated (from hello) NSFNET routes, plus default.  (Let
> me remind all and sundry that the present gated does not announce routes
> learned via EGP, but relies on the propagation of default.)
> 
> So far, so good. Default is propagated successfully to the affected schools,
> but when data is sent to a net via default, the p4200 in Cleveland returns
> net unreachable (in fact, if the Proteon console is queried for a route to
> such a net, like MILNET, the response is "unable to route, reason none".
> This reouter has been running v7.4 of Proteon's code for some time, and it
> has only been very recently that it has failed. Proteon's response has been
> to advise us to use a bugfix, v7.4b, which we have only just received.
> No explanation of what may have happened to exercise this bug, or precisely
> what bugs have been fixed has been offered. The new version should be
> installed today.

Just wanted to throw my two cents in on the subject.

Although I'm posting from Notre Dame, I'm currently residing at the
University of Cincinnati.  They guys running the HPUX box here are new
to the news and nets and have compiled the news a la FASCIST.  So it's
time to telnet back home to post until they work out outbound news with
the upstream guys.  In any case, I believe that we here are part of the
Ohio network that is having its share of troubles.

We've been experiencing the same "network not reachable" messages here.
I've recently configured a set of Suns to work with a Proteon p4200,
and from my experience there, I can tell that the routing tables
on the HPUX here is correct.  In fact, there were times that I was able
to reach several sites that were not explicitly listed in the netstat -r
output.

Then sometime on Monday, net access was perfect.  I could reach every
site I could think of.  This would coincide with the announcement from
OSU that the new Proteon gateway software was installed.

On Monday night, the net failed again here in Cincinnati.  We got
mostly "network not reachable" messages, but for a while, the attempted
connection just timed out.  Suddenly, tonight it came back up; as witnessed
by my ability to post in Indiana while sitting at a desk in Ohio.

I don't mean to gripe.  Was just trying to let the guys in Columbus
know what's happening here and help with the diagnostics.

	Evan Bauman
	University of Notre Dame
	..!iuvax!ndcheg!evan  <-- will forward to proper U. Cin. address


-- 

---------------------------------------------------------------------------
This message has been sponsored by Powdermilk Biscuits in the big blue box.
---------------------------------------------------------------------------

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 08:13:00 GMT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP

Jim,
 
'...eniac...'   Hmmmmm.... in the spirit of competition and keeping
the UK ahead of the game - I'll race down to the Science Museum London
and hack TCP/IP onto the Babbage m/c ...... now where did I put my
hacksaw (agreed a weak pun). Those of you strong on theory might like
to try it on the Turing m/c - US folks would rather go to Church and
Post a solution, or in these days of detente why not chain yourself
to A Markov.
 
Wales is a whisper away from here so don't be surprised if you hear
on the news come 21/22 June that Stonehenge, after Hoyle (Fred and
not the American maker of Rules quoted in a song), has been re-
programmed with Theological Cosmic Prayer/Inter-galatic Protocol.
 
John

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 09:22:10 GMT
From:      steve@NOTE.NSF.GOV (Stephen Wolff)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP


128.91.2.22	eniac.seas.upenn.edu

<grin> 

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 11:31:38 GMT
From:      bob@rel.eds.com (Bob Leffler)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector


In article <5047@videovax.Tek.COM>, dmc@videovax.Tek.COM (Donald M. Craig) writes:
> Sun Microsystems also has a representative on the RP-125 committee.
> "I am the Component Engineer for connectors at Sun.  In regards to your
....

> significant problems with mechanical integrity of the lock, or for that
> matter with the connector in any aspect.  If the connector is properly
 ....
> In the face of this informal statement by Sun's component engineer,
> I now need data about other people's experience with the DB-15 slide

I can speak only from my own experience.  We have many workstations located
in the Engineer's cube at GM.  Most of them are connected via a transceiver
cable with the sliding connector that you are refering to in the previous
article.

We experienced at least one connector that was disconnected at least once
a week.  We would then have to dispatch somebody to the site, trouble
shoot the problem, then plug the connector back in.  Needless to say,
this is very labor intensive and expensive.  Almost all of our network
problems turn out to be transceiver cables that are unplugged.

I reported this problem to one of our vendors (Sun :-) ).  I stated that
in my environment, we would prefer a connector that could be fasten by
screws.  Local Sun Field service stated that they had received other
similar complaints from other customers and that they would pass the
suggestion back to their corporate office.

-- 
Bob Leffler - EDS, GM Truck & Bus Account (313)456-5375
bob@rel.eds.com or {uunet!edsews, rutgers, umix}!rel!bob
Opinions expressed may not be those of my employer.

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 13:03:16 GMT
From:      donegan@stanton.TCC.COM (Steven P. Donegan)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

In article <8806150602.AA11768@atom.hpl.hp.com>, robert@ATOM.HPL.HP.COM (Robert Michaels) writes:
> 
> >	The stupid little stamped sheet metal clips are simply not strong
> >enough to secure a connector with a big fat, heavy, and fairly stiff
> >tranciever cable on it.  As long as the cable is secured so if can't move if
> >accidentally moved, it's OK.  For example, on the tranciever ends, we lash
> >the cable to the main ethernet trunk cable with 2 (or sometimes 3) wire ties
> >a few inches away.  But on systems which might move a little (like a deskside
> >Sun on wheels), or in situations where the cable might be disturbed (like
> >hanging off the back of a desk) forget it.
> >
> >	What was wrong with good-old RS-232-style screws?  Or, if they really
> 
> To me the problem is that the little clips are "standard". I would be very
> surprised if a vendor will have enough courage to promote something more
> effective. To alleviate your problem you could try using a lighter weight
> 
> - Robert Michaels
>   HP Labs


Our experience has shown the vendors we deal with to be very flexible. TCL and
Bridge Communications have both agreed to sell us 'positive attachment' cables
and interfaces (on the server and the transceiver). I really liked Bridges
naming this option as 'positive attachment' :-)))

The original transceiver cables used a cast slide rather than a stamped sheet
metal slide - the casting was much thicker and did provide a somewhat firmer
connection.

Every cable, transceiver, server and multiport fan-out that we have used at
WD have been possible to convert to screw-downs. The hardest to convert so far
was the BICC multiport fan-out; this was due to their extreme use of shielding
and screws to hold the unit together - it takes about 20-30 minutes and a
large amount of patience to convert this unit. The results are worth the effort.


-- 
Steven P. Donegan
Sr. Telecommunications Analyst
Western Digital Corp.
donegan@stanton.TCC.COM

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 13:12:22 GMT
From:      andy@cs.hw.ac.UK
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

Robert Michaels at HP Labs wrote...

>To me the problem is that the little clips are "standard". I would be very
>surprised if a vendor will have enough courage to promote something more
>effective.

About 3 years back we at Spider Systems decided that slidelocks were
useless, and ever since have been fitting screwlocks instead to all our
terminal servers, bridges and stuff.  To let people attach to "standard"
drop cables we provide a free 1 metre drop cable with a screwlock plug on
one end, and a slidelock socket at the other.  We call this a "tail".

The point is that the slidelock part is then not at a strain position - it
is a cable joint well away from the "immovable object" which the back of
the box represents.  It is twisting and bending which breaks slidelocks,
not just pulling - slidelocks are fairly usable for in-line connections.

Of course for people who are near to their network - for example in a rack
with a DELNI, the length of the tail means you don't need another
drop cable at all.  Just to wrap it all up nicely, the screws have a knurled
plastic knob on top for finger tightening.

Of the thousands of products we have shipped, NOT ONE PERSON has reported
a connector problem, and as far as I know NO-ONE has not bought something
because we are "non-standard".  We do get a lot of compliments though...

Take heart, non-courageous HP - let good engineering win through!

	Andy Davis		(andy@spider.uucp)
	Technical Director	(andy@uk.co.spider)
	Spider Systems

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 13:33:21 GMT
From:      dnwcv@dcatla.UUCP (William C. VerSteeg)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector


The 15-pin ethernet connector with a sliding latch has been the point of
failure for more problems on my networks than all other problems combined.
The problems have gotten even worse recently. It seems that in search of the
extra buck, most companies are using thinner and weaker sheet metal on the
sliding lock. This bends and causes intermittent problems. Do yourself a 
vavor and don't propigate this abomination to another hardware set.

Standard Disclaimer

Bill VerSteeg
DCA

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 13:57:32 GMT
From:      tom@OSCSUNA.osc.ohio-state.edu (Thomas Easterday)
To:        comp.protocols.tcp-ip
Subject:   (none)


From MAILER-DAEMON Thu Jun 16 09:02:30 1988
Return-Path: <MAILER-DAEMON (Mail Delivery Subsystem)>
Received: by OSCSUNA.osc.ohio-state.edu (4.0/SMI-DDN)
	id AB23005; Thu, 16 Jun 88 08:51:25 EDT
Date: Thu, 16 Jun 88 08:51:25 EDT
From: MAILER-DAEMON (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8806161251.AB23005@OSCSUNA.osc.ohio-state.edu>
To: tom
Status: R

   ----- Transcript of session follows -----
421 Host ndcheg.uucp not found for mailer ddn.
550 evan@ndcheg.UUCP... Host unknown

   ----- Unsent message follows -----
Return-Path: <tom (Thomas Easterday)>
Received: by OSCSUNA.osc.ohio-state.edu (4.0/SMI-DDN)
	id AA22999; Thu, 16 Jun 88 08:51:25 EDT
Date: Thu, 16 Jun 88 08:51:25 EDT
From: tom (Thomas Easterday)
Message-Id: <8806161251.AA22999@OSCSUNA.osc.ohio-state.edu>
To: ndcheg!evan
Subject: Networks Unreachable


   The problem with the Univ. of Cinn. Monday night (until Wed 4:30pm ish) was
   unrelated to the router problem that was dicussed.  This problem was a 
   line problem which Cincinnati Bell repaired.

                       Tom

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 13:57:43 GMT
From:      tsa@edai.ed.ac.uk (Tom Alexander)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

From article <3352@phri.UUCP>, by roy@phri.UUCP (Roy Smith):
> dmc@videovax.Tek.COM (Donald M. Craig) writes:
>> I am looking for feedback on the quality and reliability of
>> the slide latch mechanism used on the DB-15 ethernet connectors.
> 
> 	In a nutshell, they suck!  There is no doubt that the single most
> common cause of problems in our entire network is loose ethernet tranciever
> cables, particularly on the backs of Sun's which provide no mechanical
> support for the cable at all.

I agree entirely with the above comment. These bent bits of tin, laughingly
described as retaining clips, are completely useless. They may work reasonably
well with light, flexible cables but they certainly do nothing when used with
the heavy, stiff transceiver drop cables.

>> "I am the Component Engineer for connectors at Sun.  In regards to your
>> question concerning the Ethernet DB-15 [...]  I am not aware of any
>> significant problems with mechanical integrity of the lock, or for that
>> matter with the connector in any aspect.
> 
> 	I'm not given to public flamage, but this guy must have his head
> firmly wedged in a dark place.  If he's not aware of any problems, it because
> he hasn't been listening.  I've complained loudly about this on the net
> before.  I've complained to Sun field service.  I've complained to Sun tech
> support.  Clearly those complaints havn't gotten back to the right people.
> 
> 	The stupid little stamped sheet metal clips are simply not strong
> enough to secure a connector with a big fat, heavy, and fairly stiff
> tranciever cable on it.  As long as the cable is secured so if can't move if
> accidentally moved, it's OK.  For example, on the tranciever ends, we lash
> the cable to the main ethernet trunk cable with 2 (or sometimes 3) wire ties
> a few inches away.  But on systems which might move a little (like a deskside
> Sun on wheels), or in situations where the cable might be disturbed (like
> hanging off the back of a desk) forget it.
> 
> 	What was wrong with good-old RS-232-style screws?  Or, if they really
> wanted a tool-less installation, why not Macintosh-style knurled screws, or
> maybe even centronics-style wire bails?

Does this guy never talk to field service people. We have complained bitterly
to several field service engineers over the years. Hoods for this type of
connector with knurled finger screws are readily available.
I should add that Sun are not the only workstation supplier using this useless
bit of bent tin as tranceiver drop cable retaining clamps.

> 	I really don't know what the DIX guys had in mind when they designed
> this connector.  Administering a network is hard enough without having to
> worry about which $5 connector is falling out.
> -- 
> Roy Smith, System Administrator
> Public Health Research Institute
> 455 First Avenue, New York, NY 10016
> {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 15:56:14 GMT
From:      woerz@iaoobelix.UUCP (Dieter Woerz)
To:        comp.protocols.tcp-ip
Subject:   Problems with SLIP

Hello,

I had posted some time ago on comp.dcom.lans, but didn't get some
satisfactory answers, so I decided to post this to the TCP/IP-wizards
group in the hope to get more help.

I have installed the program between a Sun 3/50 running SunOS 3.4 and a
VAX 11/750 running 4.3BSD, but we have some severe problems with the
connection. May be you can help me.

My scenario is the following (Class B network 129.69, Subnetmask
0xffffff00):

+--------------------+                         +--------------------+
|Sun3/50 (SunOS 3.4) |                         |VAX 11/750 (4.3BSD) |
|                    | sl0                 sl0 |                    |
|     Slip IP .135.2 +-------------------------+ Slip IP .135.1     |
|                    |                         |                    |
|Ethernet IP .134.2  |                         |Ethernet IP .133.1  |
 +---------+----------+                         +---------+----------+
	  |                                              |

1.  I can rlogin from the VAX to the Sun (Added routing info man-
    nually)
2.  There is no exchange of routing info between the Sun and the VAX.
3.  I can't connect directly to any node on the Ethernet connected to
    the Sun from the VAX.


My netstat on Sun looks like that ((*) has been added manually)
Destination     Gateway         Flags    Refcnt Use        Interface
129.69.135.0    129.69.135.2    UH       0      4278       sl0
129.69.135.1    129.69.135.2    UH       3      666        sl0
129.69.135.2    129.69.135.2    UH       0      0          sl0
129.69.134.0    129.69.134.2    U        10     35523      le0
129.69.135.0    129.69.135.2    U        0      0          sl0
129.69.0        129.69.134.2    U        2      4280       le0
default         129.69.135.2    U        0      6974       sl0  (*)
127.0.0         127.0.0.1       U        5      4989       lo0

After the startup, the netstat on the VAX looks like this:
Destination          Gateway              Flags    Refcnt Use        Interface
129.69.133.1         127.0.0.1            UH       0      69         lo0
127.0.0.1            127.0.0.1            UH       0      0          lo0
129.69.135.2         129.69.135.1         UH       1      10         sl0
129.69.135           129.69.135.2         UG       3      547        sl0
129.69.133           129.69.133.13        UG       0      0          de0
129.69               129.69.133.1         U        0      49         de0

When the routing table entries have timed out, it looks like that:
Destination          Gateway              Flags    Refcnt Use        Interface
129.69.133.1         127.0.0.1            UH       1      153        lo0
127.0.0.1            127.0.0.1            UH       0      0          lo0

Then, I have to manually reconfigure the interfaces and add the routes,
which are marked with a (*)
Destination          Gateway              Flags    Refcnt Use        Interface
129.69.133.1         127.0.0.1            UH       1      217        lo0
127.0.0.1            127.0.0.1            UH       0      0          lo0
129.69.135.2         129.69.135.1         UH       0      3          sl0
129.69               129.69.133.1         U        0      45         de0
129.69.134           129.69.135.1         U        1      327        sl0 (*)


I hope, someone can help me correcting my problems.
If someone needs more information, please contact me.

Please reply by mail, because I think this is not in the interest of many
other readers of this newsgroup.
If there is interest, I will post a summary to both comp.dcom.lans and
comp.protocols.tcp-ip, as soon as the link is working as desired.


Thanks in advance

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

Dieter Woerz
Fraunhofer Institut fuer Arbeitswirtschaft und Organisation
Abt. 453
Holzgartenstrasse 17
D-7000 Stuttgart 1
W-Germany

BITNET: iaoobel.uucp!woerz@unido.bitnet
UUCP:   ...{uunet!unido, pyramid}!iaoobel!woerz

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 16:04:31 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re:  Looking for comments on the 15-pin ethernet connector

wesommer@athena.mit.edu (William Sommerfeld) writes:
> screw connectors with knurled knobs which have a slot
> for a screwdriver in them

	Yeah, but... make sure you implement it right.  I've seen some
connectors of the type William is talking about in which the knurled plastic
grip was longer than the metal screw shaft inside and the screwdriver slot on
the end was nothing more than an indentation in the plastic; stick a
screwdriver in it and turn and all you end up doing is making shreaded
plastic.

	Also, while I'm on the subject, let's make those screws and threaded
sockets out of steel, not brass.  I know you're not supposed to gorilla-ize
the screws, but it doesn't take much force to strip the threads on a 4-40
brass screw.  How much more does a steel 4-40 screw cost than a brass one in
quantities of thousands?  A few tenths of a cent?  How much does it cost in
valuable time each time you strip one and have to fight to the the connector
out?  Tens of dollars?  And one more thing, please, please, please, please,
don't attach the threaded sockets with nuts which turn in the same direction
as the screws on the connectors!  Anybody who doesn't know what I'm talking
about should take a look at Inmac part number 853 (female mounting screws).
For an example of how to properly design a threaded socket, take a look at the
back of a humble ADM-5 or ADM-3 -- steel sockets embedded so they can't come
loose when you unscrew the connector.

	Hey, I'm sorry if I seem to be getting all hot and bothered about such
a trivial thing but it's time the computer industry realized that this is
important and it's not worth trying to save a buck or two on the connectors
for a $100,000 piece of equipment (or even a $500 one).  I used to think this
stuff got designed so badly because nobody really cared; once I found out that
Sun actually has a component engineer in charge of connectors, I just flipped!
If Sun has one, I'm sure DEC and IBM and everybody else does too (maybe bigies
like DEC and IBM have whole rooms full of connector engineers?).  Damned if I
can figure out what they do.
-- 
Roy Smith, System Administrator
Public Health Research Institute
455 First Avenue, New York, NY 10016
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 17:37:35 GMT
From:      paul@aucs.UUCP (Paul Steele)
To:        comp.dcom.lans,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Netware vs. PC-NFS

Has anyone had any done a comparison between Novell Netware (2.1) and
PC-NFS?  We are debating whether a PC-Lab would be better using a
Sun for a file server with PC-NFS, or using Netware.  Also, is NFS
available for Macintoshes?

Since our news feed is not very reliable, please send any responses
to my BITNET address below if possible.  Thanks.


-- 
Paul H. Steele      USENET:   {uunet|watmath|utai|garfield}!dalcs!aucs!Paul
Acadia University   BITNET:   Paul@Acadia
Wolfville, NS       Internet: Paul%Acadia.BITNET@CUNYVM.CUNY.EDU
CANADA  B0P 1X0     (902) 542-2201x587

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 19:33:07 GMT
From:      raj@GLACIER.ICS.UCI.EDU (Richard Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

We have a lot of Sun fileservers around here and thus we've had a lot of
problems with the transceiver connectors.  The problem with Sun equipment
in particular is that the fashion in which the connector is attached to
the outside of the ethernet board (same thing goes for the ethernet connector
on the CPU board).  The screws onto which the slide connector is supposed
to catch are mounted on the OUTSIDE of the board whereas the connector
itself is mounted on the INSIDE.  This means that the transceiver cable
connector can't make full contact with the one on the board.  (I tried to
draw this in this message but it's too difficult.)  The problem is that
the pins on the transceiver cable connector side don't go all of the way
into the holes on the board side because the catches for the connector
are mounted too far away from the top of the board side connector.  (Take
a look at it, you'll see.)

We finally just removed the screws from both sides as well the slide latch
and replaced them with screws going straight through the cable side connector
and into the nuts on the board side connector.  This allows the connectors
to be close enough together so that they make good contact.  We've never had
problems with any that we done this to so this is the first thing I do
whenever we start having problems now.

If Sun would solve the basic problem, however (as described above) I think
the latches would be just fine.

-----------------------------------------------------------------------------
Richard A. Johnson                          raj@rome.ics.uci.edu   (Internet)
UCI ICS Assistant Technical Manager              ucbvax!ucivax!raj     (UUCP)
Postmaster / Network Services       raj@tertius.ics.uci.edu (via Nameservers)

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 20:58:03 GMT
From:      phil@amdcad.AMD.COM (Phil Ngai)
To:        comp.protocols.tcp-ip
Subject:   Re:  Looking for comments on the 15-pin ethernet connector

In article <3356@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>I used to think this
>stuff got designed so badly because nobody really cared; once I found out that
>Sun actually has a component engineer in charge of connectors, I just flipped!
>If Sun has one, I'm sure DEC and IBM and everybody else does too (maybe bigies
>like DEC and IBM have whole rooms full of connector engineers?).  Damned if I
>can figure out what they do.

Well, if you don't care why should they care? If you care, let them
know.  Make a case out of it with your salesman. Tell people like Sun
that they should follow the ISO 802.3 international standard for
transceiver cable connectors and mount them on the OUTSIDE of the
panel. Like DEC does. Many people do not realize how important this
is. Many people have not looked at the connection system carefully. 

-- 

I speak for myself, not the company.
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 88 22:54:18 GMT
From:      schamp@pyrglass (Craig Schamp)
To:        comp.protocols.tcp-ip
Subject:   Information sought on Van Jocobson's algorithm

I've been away from the net for about a year now, so I missed
what I presume to have been avid discussion about Van Jocobson's
algorithm that was on the net recently.  I'm very interested in
reading more about this before SIGCOMM.  Could someone point me
in the right direction?

Please send responses directly to me via e-mail.

Thanks,

Craig Schamp
Pyramid Technology Corporation, Mountain View, CA
(415) 965-7200 x4550
{allegra,ames,decwrl,hplabs,munnari,sun,uunet,utai}!pyramid!schamp
schamp@pyramid.com

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 88 01:03:37 GMT
From:      mkhaw@teknowledge-vaxc.ARPA (Mike Khaw)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   ftp hash marks in binary mode

If I'm transferring a file of length x*1024 bytes in BINARY mode in
ftp, how do I calculate the number of hash marks that hash mode should
print?  (I know that in ASCII mode, I should see ceiling(x) hash marks.)

Thanks,
Mike Khaw
-- 
internet: mkhaw@teknowledge.arpa
uucp:	  {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 88 02:29:56 GMT
From:      emv@mailrus.cc.umich.edu (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   a.cc.umich.edu <-> euler.berkeley.edu problem.

There's a piece of mail on a.cc.umich.edu (35.1.33.90) destined for 
euler.berkeley.edu that's been sitting around for a
few days.  If mail can't go from Michigan to Berkeley in
a day, it's usually an indicator that something's quite wrong,
so I decided to snoop around some.

I called the Merit NOC and found this out:

It's possible to FTP from the 35.1.1 network to 128.32.142.1
just fine, with no unusual delays.  The traffic is routed through
the proteon link to Cleveland (the one that was a source of problems
earlier this week).

It's impossible to FTP from the 35.1.33 network to 128.32.142.1,
where 35.1.33 is connected to 35.1.1 with two proteons and a T1
in the middle of them.
            35.1.1 - proteon - T1 - proteon - 35.1.33
 
As far as my limited ability to check into routing tables goes,
everything looks OK.  The only guess that I have at this point
is that the packets take too many hops and are dropped somewhere.
I can get to 128.32.140 and 128.32.137 just fine.  Not knowing
what the particular network looks like at Berkeley, it's hard
to give any more information than this.

Even if there are mailer problems at euler (could very well be) it's
still an odd problem.

--Ed
Edward Vielmetti, U of Michigan mail group

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jun 88 08:14:52 EDT
From:      Ken Pogran <pogran@ccq.bbn.com>
To:        tcp-ip@sri-nic.arpa
Subject:   Those D connectors
(Say, don't we have a "components" mailing list or something?
This hardly seems like something for TCP-IP.  Oh, well.)

I thought a bit of history might be interesting: The "D-series"
connectors made their debut in the 1950s to interconnect military
electronics "modules", which at the time were assemblies in metal
boxes that plugged into "pans" and "trays".  Interestingly, they
were NOT designed for cable applications and they were NOT
designed to support weight: the modules in their little boxes
were supported mechanically by the pans and trays.  The
connectors were, however, pretty rugged -- they were all MIL-SPEC
varieties.  By the way, to give an idea of the size and scale of
things at the time, they were referred to in 1960s connector
literature as "D-subminiature" connectors.

The Bell System began the large-scale use of these connectors on
cables with the introduction of DataPhones (Bell's trademark for
their modem service).  Remember the rather ornate-looking light
gray hard plastic shells?

One advantage of the D-series connectors was the density of pins,
and their use really took off -- especially for cable
applications, precisely what they were NOT designed for!
Manufacturers have tried a lot of ideas to cope with cables and
their weight, with not a lot of success; the basic design of the
connectors just isn't intended for it.  And couple that with
cost-reduction efforts (seen any MIL-SPEC versions of these
connectors in products you've bought recently?) which have made
many of the connectors even flimsier and you have a recipe for
trouble.

On the other hand, there's the overkill approach: The old,
nearly-impossible-to-get $75 48-series round connector that BBN 
spec'ed a long, long time ago for the 1822 Distant Interface 
connector ... (since replaced by a 37-pin D connector, of
course!)

Ken Pogran
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 88 06:24:28 GMT
From:      jmg@cernvax.UUCP (jmg)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

One other funny (correlates with the bread and butter law): on the fan-out
units which we have the connector has to be pushed upwards to lock. From
then on some evil force (Isaac Newton had a word for it!) is constantly
trying to unlock it again, and each slight movement helps this evil force.
Oh, how simple it would have been to invert the connector.

The force is against you!
-- 
 _ _  o |             __                    |    jmg@cernvax.uucp
| | |   |     _      /  \  _   __  _   __  _|    jmg@cernvax.bitnet
| | | | |_)  /_)     |  __/_) | (___\ | (_/ |  J. M. Gerard, Div. DD, CERN,
| | |_|_| \_/\___    \__/ \___|   (_|_|   \_|_ 1211 Geneva 23, Switzerland

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 88 06:52:54 GMT
From:      billq@ihlpe.ATT.COM (Quayle)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

In article <8806151700.AA03253@ucbvax.Berkeley.EDU>, brescia@PARK-STREET.BBN.COM (Mike Brescia) writes:
# 
# >     I am looking for feedback on the quality and reliability of
# >     the slide latch mechanism used on the DB-15 ethernet connectors.
# 
# >     The Society of Motion Picture and Television Engineers has a
# >     standard known as RP-125 which specifies a parallel digital
# >     television interface.  The connector for that interface is
# >     a 25 pin D-type (DB-25) with a slide latch like the ethernet
# >     connector.  The RP-125 standard is up for revision, ...
# 
# So far, I have seen people flaming the slide latch, but no comment on the
# Dtype connectors.  While using screws to replace the slide latch helps in some
# cases, the main problem seems to be that the long, narrow connector with 2
# rows of pins cannot withstand stress from a heavy or thick or stiff cable.
# There should be some analysis of why you should not use cable that is an inch
# in diameter to contain 18 individually shielded twisted pairs for your
# rs422/rs449 and try to connect it with a DC-37.
# 
# The slide latch can only handle a little stress on the long dimension, and can
# handle none on the narrow dimension.  The DB15 would be ok with a ribbon
# cable, because the ribbon is both light and flexible, and a well fitted slide
# latch would lock it in place, but then you would not even need a lock because
# the friction of the connector would keep it it.
# 
# So, if SMPTE is going to do it right, they need to consider the mechanical
# characteristics of the locking mechanism, as well as the ease of connection
# and disconnection.

Outside the Ethernet realm, and in an industry that required a connector that
would withstand strain due to cable motion, we used an Amphenol MS connector.
For those unfamiliar, this is a round, keyed connector, with a screw-on shell.
Those things would withstand any ammount of cable motion (not to mention some
pretty nasty envrironmental hazards), without the least bit of wear or loss of
contact.  

BTW, as our net grows to nearly fifty nodes, I'm still the only one I trust
manufacturing and installing those $*^%*&^*$ drop cables!!!


W.R. Quayle
AT&T Bell Labs.

Disclaimer:  I have no connection (beit slidelock or otherwise) to any company
mentioned in my reply.  My ideas are my personal feelings only!

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 88 12:14:52 GMT
From:      pogran@CCQ.BBN.COM (Ken Pogran)
To:        comp.protocols.tcp-ip
Subject:   Those D connectors

(Say, don't we have a "components" mailing list or something?
This hardly seems like something for TCP-IP.  Oh, well.)

I thought a bit of history might be interesting: The "D-series"
connectors made their debut in the 1950s to interconnect military
electronics "modules", which at the time were assemblies in metal
boxes that plugged into "pans" and "trays".  Interestingly, they
were NOT designed for cable applications and they were NOT
designed to support weight: the modules in their little boxes
were supported mechanically by the pans and trays.  The
connectors were, however, pretty rugged -- they were all MIL-SPEC
varieties.  By the way, to give an idea of the size and scale of
things at the time, they were referred to in 1960s connector
literature as "D-subminiature" connectors.

The Bell System began the large-scale use of these connectors on
cables with the introduction of DataPhones (Bell's trademark for
their modem service).  Remember the rather ornate-looking light
gray hard plastic shells?

One advantage of the D-series connectors was the density of pins,
and their use really took off -- especially for cable
applications, precisely what they were NOT designed for!
Manufacturers have tried a lot of ideas to cope with cables and
their weight, with not a lot of success; the basic design of the
connectors just isn't intended for it.  And couple that with
cost-reduction efforts (seen any MIL-SPEC versions of these
connectors in products you've bought recently?) which have made
many of the connectors even flimsier and you have a recipe for
trouble.

On the other hand, there's the overkill approach: The old,
nearly-impossible-to-get $75 48-series round connector that BBN 
spec'ed a long, long time ago for the 1822 Distant Interface 
connector ... (since replaced by a 37-pin D connector, of
course!)

Ken Pogran

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 88 16:10:10 GMT
From:      billq@ihlpe.ATT.COM (Quayle)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector


<<STEAM ON>>

First off, I'd like to know who designed the slide-lock
mechanism.  Did they get fired for it?  If not, they
should have!  

I would gladly change every connector on my net to
something real if a new standard was aggreed upon.

Second point: Who the heck is responsible for positioning
the watchdog reset button on the Sun 3 Motherboard directly
next to said-flimsy-*ss-switch?  This individual needs
shock therapy!

<<STEAM OFF>>


W.R. Quayle		Lab Coordinator - 52182
			AT&T Bell Labs
			Naperville, Il

Disclaimer: These thoughts are all mine!  (My that felt good!)

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 88 17:39:44 GMT
From:      oconnor@SCCGATE.SCC.COM (Michael J. O'Connor)
To:        comp.protocols.tcp-ip
Subject:   4.0 SOS questions


	I've got some problems with our Sun OS (SOS) 4.0 machines and DDN
services.  They are all RoadRunners, but I've seen the same problem on
a Sun-3 running SOS 4.0.
	The first problem is that I can't ftp into a 4.0 SOS machine
unless I use the user name root.  All other accounts are denied access.
The local service people say there is a memo about ftp security being
on by default but can't tell me how to undefault it.  I can't find any
mention of ftp security in the manual pages except for the old "anonymous"
remarks.  I haven't been able to find an analogue to ftpusers either.
	The second problem is that I can't get the ftp and telnet
programs to use the name domain server.  Named runs fine as does nslookup
and the MX version of sendmail, but ftp and telnet tell me that any
host not in the yellow system is unknown.  I'm running ypserv with the old
secret -i flag just like I do on our 3.n systems but have no joy.  Does
anyone know if the secret flag to ypserv has changed?

		Mike

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 88 17:41:56 GMT
From:      dvw@thumper.bellcore.com (Dan V. Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

In article <22108@amdcad.AMD.COM>, phil@amdcad.UUCP writes:

> Well, if you don't care why should they care? If you care, let them
> know.  Make a case out of it with your salesman. Tell people like Sun
> that they should follow the ISO 802.3 international standard for
> transceiver cable connectors and mount them on the OUTSIDE of the
> panel. Like DEC does. Many people do not realize how important this
> is. Many people have not looked at the connection system carefully. 
> 
> -- 
> 
> I speak for myself, not the company.
> Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com

Phil is absolutely right.  My experience with the DB-15 connectors and the
<insert expletives> slide locks is that they work fine IF the slide is
mounted directly on the connector body (are you listening, Sun?) AND the
connector is mounted on the outside of the panel AND the posts are the
proper height AND the slide hasn't been strained or bent AND the phase of
the moon and several other planets is correct.

My favorite fix is to make a short stub cable out of DB-15 crimp on
connectors and a few inches of 15 conductor flat cable, and to insert this
short cable between the tranceiver cable and the piece of equipment.  I've
found that this has eliminated problems with the transceiver cable
connections on Sun 3/75's and 3/160's, which are notorious for having a
thick panel between the connector and slide lock on the Ethernet connection.
I know, I know, the stub cable probably radiates, but I don't care.  I've
found that the friction grip from the crimp-on connectors is usually better
than that provided from the connector plus slide lock.

One should note that Sun may use lots of DB-series connectors, but they DO
NOT use slide locks to my knowledge other than on Ethernet connectors.  They
always use another type of lock, either the 'wings' (can't think of a better
term), or screws.

I find myself wishing that I believed in Hell just so I could hope the
designer of the slide lock and the connector engineer at Sun could roast
there.  Honorable mention should probably go to the writers of the two
original Ethernet specifications for not specifying the transceiver
connectors more fully.

					Dan Wilson
					dvw@bellcore.com
					bellcore!dvw

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 88 21:03:50 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: PING with source/record route

The sands have shifted, Lambda.lanl.gov is now 128.165.4.4 or 26.0.0.90.

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 88 01:20:22 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

andy@cs.hw.ac.UK writes:
> About 3 years back we at Spider Systems decided that slidelocks were
> useless, and ever since have been fitting screwlocks instead to all our
> terminal servers, bridges and stuff.

	A big "Thank you!" to the folks at Spider for having the courage to
stand up in public and (proudly) admit that they did something non-standard
because it was better.  Not just better, but a hell of a lot better, and
downward-compatable to boot!  Now all we have to is get all the other
network vendors to do the same thing (and get catalog houses like Inmac to
start stocking screw-post drop cables).  Sun may say "The network is the
computer" but I say "the connector is the network"!

	Could you imagine if 50 companies a day, I say 50 companies a day
stood up and said "slide locks suck" and started shipping screw-in ethernet
connectors?  I'd be a revolution, friends. (Apologies to Arlo Guthrie).
-- 
Roy Smith, System Administrator
Public Health Research Institute
455 First Avenue, New York, NY 10016
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 1988 17:54-EDT
From:      URBANIAK@G.BBN.COM
To:        tcp-ip@SRI-NIC.ARPA, big-lan@SUVM.ACS.SYR.EDU
Cc:        Urbaniak@G.BBN.COM
Subject:   Ethernet Addresses and Type Field
Since its last posting, a substantial number of individuals and
some vendors have contributed additions and corrections to this list.

Some Known Ethernet and IEEE802.3 "Type" Fields		6/18/88

The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble)
consist of the "Type" or "Length" field. These values are managed by XEROX.
Some assignments are public, others private. Current information includes:
Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std; NIC RFC960;
contributions from network managers and vendors.

Hex
0000-05DC	IEEE802.3 Length Field (0.:1500.)
0200	Xerox PUP (conflicts with IEEE802.3 Length Field range) (see 0A00)
0201	Xerox PUP Address Translation (conflicts ...) (see 0A01)
0600	Xerox NS IDP *
0800	DOD Internet Protocol (IP) * #
0801	X.75 Internet
0802	NBS Internet
0803	ECMA Internet
0804	CHAOSnet
0805	X.25 Level 3
0806	Address Resolution Protocol (ARP) * (for IP and for CHAOS)
0807	XNS Compatibility
081C	Symbolics Private
0888	Xyplex
0900	Ungermann-Bass network debugger
0A00	Xerox IEEE802.3 PUP
0A01	Xerox IEEE802.3 PUP Address Translation
0BAD	Banyan Systems
1000	Berkeley Trailer negotiation
1001-100F	Berkeley Trailer encapsulation
1600	VALID-machine protocol? *
5208	BBN Simnet Private %
6000	DEC unassigned
6001	DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
6002	DEC Maintenance Operation Protocol (MOP) Remote Console
6003	DECNET Phase IV
6004	DEC Local Area Transport (LAT)
6005	DEC diagnostic protocol (at interface initialization?)
6006	DEC customer protocol
6007	DEC Local Area VAX Cluster (LAVC)
6008	DEC unassigned
6009	DEC unassigned
7000	Ungermann-Bass download
7002	Ungermann-Bass diagnostic/loopback
8003	Cronus VLN
8004	Cronus Direct
8005	HP Probe protocol
8006	Nestar
8010	Excelan
8013	Silicon Graphics diagnostic
8014	Silicon Graphics network games
8015	Silicon Graphics reserved
8016	Silicon Graphics XNS NameServer, bounce server
8019	Apollo DOMAIN
8035	Reverse Address Resolution Protocol (RARP)
8038	DEC LanBridge Management
8039	DEC unassigned
803A	DEC unassigned
803B	DEC unassigned
803C	DEC unassigned
803D	DEC Ethernet Encryption Protocol
803E	DEC unassigned
803F	DEC LAN Traffic Monitor Protocol
8040	DEC unassigned
8041	DEC unassigned
8042	DEC unassigned
805B	Stanford V Kernel, experimental
805C	Stanford V Kernel, production
807C	Merit Internodal
8080	Vitalink TransLAN III Management
809B	EtherTalk (AppleTalk over Ethernet)
80DE	TRFS (Integrated Solutions Transparent Remote File System)
80F3	AppleTalk Address Resolution Protocol (AARP)
8107	Symbolics Private
8108	Symbolics Private
8109	Symbolics Private
8137	Novell
9000	Loopback (Configuration Test Protocol)
9001	Bridge Communications XNS Systems Management
9002	Bridge Communications TCP/IP Systems Management
FF00	BBN VITAL-LanBridge cache wakeups %

* These protocols use Ethernet broadcast, where multicast would be preferable.
# BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3.
% BBN Private Protocols, not registered
Some Known Ethernet Vendor Addresses		6/18/88

Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits
(0-9, plus A-F, capitalized). These 12 hex digits consist of
the first/left 6 digits (which should match the vendor of the Ethernet interface
within the station) and the last/right 6 digits which specify the interface
serial number for that interface vendor.

Ethernet addresses might be written unhyphenated (e.g. 123456789ABC),
or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated
by octets (e.g. 12-34-56-78-9A-BC).

These addresses are physical station addresses, not multicast nor
broadcast, so the second hex digit (reading from the left)
will be even, not odd.

At present, it is not clear how the IEEE assigns Ethernet block addresses.
Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned
with that block or separately. A portion of the vendor block address
is reportedly assigned serially, with the other portion intentionally
assigned randomly. If there is a global algorithm for which addresses
are designated to be physical (in a chipset) versus logical
(assigned in software), or globally-assigned versus locally-assigned addresses,
some of the known addresses do not follow the scheme.

00000C	Western Digital
00002A	TRW
00005A	S & Koch
000093	Proteon
00009F	Ameristar Technology
0000AA	Xerox		Xerox machines
0000C0	Western Digital?
0000DD	Gould
000102	BBN		BBN internal usage (not registered)
001700	Kabel
00DD00	Ungermann-Bass
00DD01	Ungermann-Bass
020701	Interlan	UNIBUS or QBUS machines, Apollo
020406	BBN		BBN internal usage (not registered)
02608C	3Com		IBM PC; Imagen; Valid
02CF1F	CMC		Masscomp, Silicon Graphics
080002	Bridge
080005	Symbolics	Symbolics LISP machines
080008	BBN
080009	Hewlett-Packard
080010	AT+T
080014	Excelan		BBN Butterfly, Masscomp, Silicon Graphics
080017	NSC
08001A	Data General
08001B	Data General
08001E	Apollo
080020	Sun		Sun machines
080025	CDC
080028	TI		Explorer
08002B	DEC		UNIBUS or QBUS machines, VAXen, LANBridges
			(DEUNA, DEQNA, DELUA)
080045	???
080047	Sequent
080049	Univation
08004C	Encore
08004E	BICC
080068	Ridge
080069	Silicon Graphics
08006E	Excelan
08007C	Vitalink	TransLAN III
080089	Kinetics	AppleTalk-Ethernet interface
08008B	Pyramid
08008D	XyVision	XyVision machines
AA0003	DEC		Global physical address for some DEC machines
AA0004	DEC		Local logical address for systems running DECNET
Some Known Ethernet Multicast Addresses		6/18/88

Ethernet		Type	
Address			Field	Usage

Multicast Addresses:

09-00-09-xx-xx-xx	????	HP multicasts
09-00-2B-01-00-00	8038	DEC LanBridge Copy packets
09-00-2B-01-00-01	8038	DEC LanBridge Hello packets
				1 packet per second, sent by the
				designated LanBridge
AB-00-00-01-00-00	6001	DEC Maintenance Operation Protocol (MOP)
				Dump/Load Assistance
AB-00-00-02-00-00	6002	DEC Maintenance Operation Protocol (MOP)
				Remote Console
				1 System ID packet every 8-10 minutes, by every:
				DEC LanBridge
				DEC DEUNA interface
				DEC DELUA interface
				DEC DEQNA interface (in a certain mode)
AB-00-00-03-00-00	6003	DECNET Phase IV end node Hello packets
				1 packet every 15 seconds, sent by each DECNET host
AB-00-00-04-00-00	6003	DECNET Phase IV Router Hello packets
				1 packet every 15 seconds, sent by the DECNET router
AB-00-00-05-00-00	????	Reserved DEC
through		
AB-00-03-FF-FF-FF
AB-00-04-00-00-00	????	Reserved DEC customer private use
through		
AB-00-04-00-FF-FF
AB-00-04-01-xx-yy	6007	DEC Local Area VAX Cluster groups
CF-00-00-00-00-00	9000	Ethernet Configuration Test protocol (Loopback)

Broadcast Address:

FF-FF-FF-FF-FF-FF	0600	XNS packets, Hello or gateway search?
				6 packets every 15 seconds, per XNS station
FF-FF-FF-FF-FF-FF	0800	IP (e.g. RWHOD via UDP) as needed
FF-FF-FF-FF-FF-FF	0806	ARP (for IP and CHAOS) as needed
FF-FF-FF-FF-FF-FF	1600	VALID packets, Hello or gateway search?
				1 packets every 30 seconds, per VALID station
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 88 17:01:08 GMT
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   Re: Need rfc 877

RFCs are available via electronic mail from the NIC. To get RFC 877 from the
NIC send a message to SERVICE@SRI-NIC.ARPA with the command   RFC 877   in the
subject line of your message. Here is some information about using SERVICE.

NIC Mail Services					   June 1988

   This is an automated service provided by the DDN Network Information
Center.  It allows access to NIC documents and information via ordinary
electronic mail.  This is especially useful for people who do not have
access to the NIC via a direct Internet link, such as BITNET, CSNET
and UUCP sites. 

   To use the mail service, send a mail message to SERVICE@SRI-NIC.ARPA.
In the SUBJECT field, request the type of service you wish followed by
any needed arguments.  The message body is normally ignored.  Large files
will be broken into smaller separate messages.  The information you
request will be sent back to you as soon as possible.

The following services are currently available:

HELP		This message; a list of current services.
RFC nnn		nnn is the RFC number or the word INDEX.
IEN nnn		nnn is the IEN number or the word INDEX.
NETINFO xxx	xxx is a file name or the word INDEX.
SEND xxx	xxx is a fully specified file name.
HOST xxx	Returns information about host xxx.
WHOIS xxx	Returns information about xxx from the WHOIS service.
                Use "WHOIS HELP" for information on how to use WHOIS.

Example SUBJECT lines:
HELP
RFC 822
RFC INDEX
NETINFO DOMAIN-TEMPLATE.TXT
SEND IDEA:IDEA0002-00.TXT
HOST SRI-NIC.ARPA
WHOIS LOTTOR, MARK

Send comments or suggestions to SUGGESTIONS@SRI-NIC.ARPA.
Send questions and bug reports to NIC@SRI-NIC.ARPA.
-------

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 88 19:19:45 GMT
From:      roode@orc.olivetti.COM (David Roode)
To:        comp.protocols.tcp-ip
Subject:   Ethernet transceiver connector slide-locks

A variable which significantly affects reliability of the slide-lock
is the weight of the transceiver cable.  Some manufacturers have much
heavier cable than others.  Some (DEC) make an extra-light cable for
use when the run is not too far.  Also, right angle connectors are
available from some transceiver cable manufacturers (DEC again).

I second the comments for strain relief. Even the alternative
use of screws and nut posts is subject to mechanical damage due
to the vulnerable way these jacks are often located, and
strain relief via an offset bar or other means would be a good idea
regardless of the use of slide locks.  The slide locks are excellent
when used to couple two transceiver cables together.

In many cases the built in thin-net transceiver makes operation
without external transceivers over thin-net more desirable than using
the 15-pin transceiver port anyway.  For the price of 10 transceivers,
a multiport thin repeater can be purchased.  This will allow operation
of 8 independent thin segments with a length of 180 meters each,
fanning out from the multiport repeater.  On each segment, up to 31
thin transceivers may be located.  Holding each segment to 5 or so
stations yields a compartmentalized network which is easy to debug,
and robust in the event of a disturbance to the (now thin rather than
thick) coax.

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 88 21:54:00 GMT
From:      URBANIAK@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Ethernet Addresses and Type Field

Since its last posting, a substantial number of individuals and
some vendors have contributed additions and corrections to this list.

 Some Known Ethernet and IEEE802.3 "Type" Fields		6/18/88

The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble)
consist of the "Type" or "Length" field. These values are managed by XEROX.
Some assignments are public, others private. Current information includes:
Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std; NIC RFC960;
contributions from network managers and vendors.

Hex
0000-05DC	IEEE802.3 Length Field (0.:1500.)
0200	Xerox PUP (conflicts with IEEE802.3 Length Field range) (see 0A00)
0201	Xerox PUP Address Translation (conflicts ...) (see 0A01)
0600	Xerox NS IDP *
0800	DOD Internet Protocol (IP) * #
0801	X.75 Internet
0802	NBS Internet
0803	ECMA Internet
0804	CHAOSnet
0805	X.25 Level 3
0806	Address Resolution Protocol (ARP) * (for IP and for CHAOS)
0807	XNS Compatibility
081C	Symbolics Private
0888	Xyplex
0900	Ungermann-Bass network debugger
0A00	Xerox IEEE802.3 PUP
0A01	Xerox IEEE802.3 PUP Address Translation
0BAD	Banyan Systems
1000	Berkeley Trailer negotiation
1001-100F	Berkeley Trailer encapsulation
1600	VALID-machine protocol? *
5208	BBN Simnet Private %
6000	DEC unassigned
6001	DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
6002	DEC Maintenance Operation Protocol (MOP) Remote Console
6003	DECNET Phase IV
6004	DEC Local Area Transport (LAT)
6005	DEC diagnostic protocol (at interface initialization?)
6006	DEC customer protocol
6007	DEC Local Area VAX Cluster (LAVC)
6008	DEC unassigned
6009	DEC unassigned
7000	Ungermann-Bass download
7002	Ungermann-Bass diagnostic/loopback
8003	Cronus VLN
8004	Cronus Direct
8005	HP Probe protocol
8006	Nestar
8010	Excelan
8013	Silicon Graphics diagnostic
8014	Silicon Graphics network games
8015	Silicon Graphics reserved
8016	Silicon Graphics XNS NameServer, bounce server
8019	Apollo DOMAIN
8035	Reverse Address Resolution Protocol (RARP)
8038	DEC LanBridge Management
8039	DEC unassigned
803A	DEC unassigned
803B	DEC unassigned
803C	DEC unassigned
803D	DEC Ethernet Encryption Protocol
803E	DEC unassigned
803F	DEC LAN Traffic Monitor Protocol
8040	DEC unassigned
8041	DEC unassigned
8042	DEC unassigned
805B	Stanford V Kernel, experimental
805C	Stanford V Kernel, production
807C	Merit Internodal
8080	Vitalink TransLAN III Management
809B	EtherTalk (AppleTalk over Ethernet)
80DE	TRFS (Integrated Solutions Transparent Remote File System)
80F3	AppleTalk Address Resolution Protocol (AARP)
8107	Symbolics Private
8108	Symbolics Private
8109	Symbolics Private
8137	Novell
9000	Loopback (Configuration Test Protocol)
9001	Bridge Communications XNS Systems Management
9002	Bridge Communications TCP/IP Systems Management
FF00	BBN VITAL-LanBridge cache wakeups %

* These protocols use Ethernet broadcast, where multicast would be preferable.
# BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3.
% BBN Private Protocols, not registered
 Some Known Ethernet Vendor Addresses		6/18/88

Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits
(0-9, plus A-F, capitalized). These 12 hex digits consist of
the first/left 6 digits (which should match the vendor of the Ethernet interface
within the station) and the last/right 6 digits which specify the interface
serial number for that interface vendor.

Ethernet addresses might be written unhyphenated (e.g. 123456789ABC),
or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated
by octets (e.g. 12-34-56-78-9A-BC).

These addresses are physical station addresses, not multicast nor
broadcast, so the second hex digit (reading from the left)
will be even, not odd.

At present, it is not clear how the IEEE assigns Ethernet block addresses.
Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned
with that block or separately. A portion of the vendor block address
is reportedly assigned serially, with the other portion intentionally
assigned randomly. If there is a global algorithm for which addresses
are designated to be physical (in a chipset) versus logical
(assigned in software), or globally-assigned versus locally-assigned addresses,
some of the known addresses do not follow the scheme.

00000C	Western Digital
00002A	TRW
00005A	S & Koch
000093	Proteon
00009F	Ameristar Technology
0000AA	Xerox		Xerox machines
0000C0	Western Digital?
0000DD	Gould
000102	BBN		BBN internal usage (not registered)
001700	Kabel
00DD00	Ungermann-Bass
00DD01	Ungermann-Bass
020701	Interlan	UNIBUS or QBUS machines, Apollo
020406	BBN		BBN internal usage (not registered)
02608C	3Com		IBM PC; Imagen; Valid
02CF1F	CMC		Masscomp, Silicon Graphics
080002	Bridge
080005	Symbolics	Symbolics LISP machines
080008	BBN
080009	Hewlett-Packard
080010	AT+T
080014	Excelan		BBN Butterfly, Masscomp, Silicon Graphics
080017	NSC
08001A	Data General
08001B	Data General
08001E	Apollo
080020	Sun		Sun machines
080025	CDC
080028	TI		Explorer
08002B	DEC		UNIBUS or QBUS machines, VAXen, LANBridges
			(DEUNA, DEQNA, DELUA)
080045	???
080047	Sequent
080049	Univation
08004C	Encore
08004E	BICC
080068	Ridge
080069	Silicon Graphics
08006E	Excelan
08007C	Vitalink	TransLAN III
080089	Kinetics	AppleTalk-Ethernet interface
08008B	Pyramid
08008D	XyVision	XyVision machines
AA0003	DEC		Global physical address for some DEC machines
AA0004	DEC		Local logical address for systems running DECNET
 Some Known Ethernet Multicast Addresses		6/18/88

Ethernet		Type	
Address			Field	Usage

Multicast Addresses:

09-00-09-xx-xx-xx	????	HP multicasts
09-00-2B-01-00-00	8038	DEC LanBridge Copy packets
09-00-2B-01-00-01	8038	DEC LanBridge Hello packets
				1 packet per second, sent by the
				designated LanBridge
AB-00-00-01-00-00	6001	DEC Maintenance Operation Protocol (MOP)
				Dump/Load Assistance
AB-00-00-02-00-00	6002	DEC Maintenance Operation Protocol (MOP)
				Remote Console
				1 System ID packet every 8-10 minutes, by every:
				DEC LanBridge
				DEC DEUNA interface
				DEC DELUA interface
				DEC DEQNA interface (in a certain mode)
AB-00-00-03-00-00	6003	DECNET Phase IV end node Hello packets
				1 packet every 15 seconds, sent by each DECNET host
AB-00-00-04-00-00	6003	DECNET Phase IV Router Hello packets
				1 packet every 15 seconds, sent by the DECNET router
AB-00-00-05-00-00	????	Reserved DEC
through		
AB-00-03-FF-FF-FF
AB-00-04-00-00-00	????	Reserved DEC customer private use
through		
AB-00-04-00-FF-FF
AB-00-04-01-xx-yy	6007	DEC Local Area VAX Cluster groups
CF-00-00-00-00-00	9000	Ethernet Configuration Test protocol (Loopback)

Broadcast Address:

FF-FF-FF-FF-FF-FF	0600	XNS packets, Hello or gateway search?
				6 packets every 15 seconds, per XNS station
FF-FF-FF-FF-FF-FF	0800	IP (e.g. RWHOD via UDP) as needed
FF-FF-FF-FF-FF-FF	0806	ARP (for IP and CHAOS) as needed
FF-FF-FF-FF-FF-FF	1600	VALID packets, Hello or gateway search?
				1 packets every 30 seconds, per VALID station

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 88 02:09:27 GMT
From:      roode@orc.olivetti.COM (David Roode)
To:        comp.protocols.tcp-ip
Subject:   Re: Cisco terminal servers?


I've used the cisco Terminal servers for 2 years now, and been very
happy with them.  It's the same box as their gateway, and the code
load etc. is the same, so if you deal with both your personal
system-entity count is only incremented by one.  . It either boots
from PROM or down from the net.  The configuration can be changed from
any terminal by entering a password.  The normal method is to download
a modified configuration file from a Unix server. They also offer
their normal bubble memory option so the configuration doesn't have to
be downloaded either, but it always can be, if desired.  The
reliability is excellent, as is the performance (can put up to 96
terminal lines in a single box, though I only put 80 and in our
(typical) situation rarely saw more than 40 active at once.  They now
offer a 68020 option on the processor, and the terminal server
supports SLIP to typical PC-based products or compatible.  Estimate is
that not too many of these should be flying full tilt at once-- about
8 or so is the estimate I had, for the 68000 CPU.  Main memory is 1mb,
and the configuration and operation is fairly user friendly. Each port
can support a practically unlimited number of connections (telnet)
simultaneously, with the ability to cycle between them conveniently,
optionally notify if output waiting, etc.  They also implement RLOGIN,
and they can use multiple flavors of name servers or support hard-wire
host name. They support milking machine mode to make RS232 ports in
hunt groups available to provide Telnet server access to remote access
to RS232 devices that do not support Telnet--such as dial out modems,
devices with RS232 monitoring available, and the like.  The devices
can have their own unique emulated IP address or answer on alternate
TCP service ports of the main boxes address.  Finally, they also
support parallel printers connected to the box and accessible to the
network, as well as printers accessed over an ordinary serial port.

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 88 16:04:00 EDT
From:      <enger@gburg.scc.com>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Transceiver connectors
Folks:
	Many of the writers addressing this topic have complained
about bending of the slide lock metal (allowing the connector to become 
partially or fully dislodged).  Still more writers have suggested various 
revenge scenarios against the inventor of the connector, and the abandonment 
of the connector's use.  Maybe improvements can be made without resorting to 
the guillotine (or wire cutters).

	I have noted differnces in the "strength" of the slide locks 
provided on the cables from various suppliers.  While the geometry may make 
the applied forces great, it may still be possible to spec a sufficiently
"strong" slide lock to meet most user's needs.  Perhaps the use of higher 
quality metal will be the only change necessary.  Reinforcement of the slide 
lock through other methods such as ribbing and spot welding may also be usefull.

	I suppose we could machine high quality slide locks that were strong
enough to lift a car (or at least a Sun Workstation).  What I'm affraid of
however, is that we'll start to see the mating chasis hardware failing.  Wider
use of right angle connectors, and provisions for EASILY lashing the cable to
the equipment chasis should round out the remedy though. 

Bob Enger

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 88 14:03:27 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

phil@amdcad.UUCP writes:
> Tell people like Sun that they should follow the ISO 802.3 international
> standard for transceiver cable connectors and mount them on the OUTSIDE of
> the panel.

(To the tune of "look what they've done to my song")

Look what they've done to my SUN, DIX,
Look what they've done to my SUN.
They've gone and moved, the cable plug,
From the outside to the in, DIX.
Look what they've done to my SUN...

> Like DEC does.

Come to think of it, we've had a lot less trouble with out DELNI than with our
Suns.  Warning: do not construe the previous sentence to mean that I actually
think the slide locks might work right if constructed strictly according to
the specs.  All I'm saying is that they wouldn't be as bad.

> Many people have not looked at the connection system carefully. 

Perhaps, but I'll bet that lots of people have looked at the connection
system angrily, obscenely, and with violent thoughts of destruction.
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 88 17:44:17 GMT
From:      mkhaw@teknowledge-vaxc.ARPA (Mike Khaw)
To:        comp.protocols.tcp-ip
Subject:   Re: Cisco terminal servers?

> TCP service ports of the main boxes address.  Finally, they also
> support parallel printers connected to the box and accessible to the
> network, as well as printers accessed over an ordinary serial port.

Not all serial printers work with Cisco boxes.  In particular,
we were interested in moving our Apple LaserWriters off direct lines on
one of our VAXes and putting them on a Cisco box so that they'd be more
accessible over our LAN.  We were told that it wouldn't work because
the LaserWriters need to send data back to the host, and the Cisco serial
printer connection didn't support that direction of data flow.

Mike Khaw
-- 
internet: mkhaw@teknowledge.arpa
uucp:	  {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 88 20:04:00 GMT
From:      enger@GBURG.SCC.COM
To:        comp.protocols.tcp-ip
Subject:   Transceiver connectors

Folks:
	Many of the writers addressing this topic have complained
about bending of the slide lock metal (allowing the connector to become 
partially or fully dislodged).  Still more writers have suggested various 
revenge scenarios against the inventor of the connector, and the abandonment 
of the connector's use.  Maybe improvements can be made without resorting to 
the guillotine (or wire cutters).

	I have noted differnces in the "strength" of the slide locks 
provided on the cables from various suppliers.  While the geometry may make 
the applied forces great, it may still be possible to spec a sufficiently
"strong" slide lock to meet most user's needs.  Perhaps the use of higher 
quality metal will be the only change necessary.  Reinforcement of the slide 
lock through other methods such as ribbing and spot welding may also be usefull.

	I suppose we could machine high quality slide locks that were strong
enough to lift a car (or at least a Sun Workstation).  What I'm affraid of
however, is that we'll start to see the mating chasis hardware failing.  Wider
use of right angle connectors, and provisions for EASILY lashing the cable to
the equipment chasis should round out the remedy though. 

Bob Enger

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 88 21:29:10 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Getting RFCs



RFCs can be obtained via FTP from SRI-NIC.ARPA with the pathname
RFC:RFCnnnn.TXT where "nnnn" refers to the number of the RFC.  Log in
with FTP username ANONYMOUS and password GUEST. 

The NIC also provides an automatic mail service for those sites which cannot
use FTP.  Address the request to SERVICE@SRI-NIC.ARPA and in the subject
field of the message indicate the RFC number, as in "Subject: RFC nnnn".

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 88 22:15:09 GMT
From:      steve@alberta.UUCP (Steve Sutphen)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

We have been using these slide lock connectors since before we installed
Ethernet 5 years ago (they were also used on the HP 2621 terminals
keyboards).  While I will grant that we have had some problems with them,
I wouldn't say that they have been a constant headache -- maybe our people
take more care in the installation and use of equipment than at other
sites.  If someone is doing a new specification as was indicated in the
original article then I think that they should take a serious look at the
factors involved.  I think that a major part of the problem is that
	1) right angle shells are not as commonly available as they should
	be and people installing the cables don't bother choosing the
	correct connector (right angle vs strait).

	2) the Transciever cable is part of the problem - it is very
	stiff, large and heavy.  This excrabates all the other problems.

I would not say that jack screws as are used on RS-232 connectors are
completely fool proof though either.  We have had our share of 
	1) stripped female locking nut
	2) loose female locking screws because of binding of the jack
	screw, or simply beacuse the nut loosens (even when "properly"
	installed).  For a while we would go through all the screws on new
	equipment and tightnen up the female locking screws.  I even
	thought about putting locktite on some of the ones that were more
	problematic (on the old Sun-100 chassis).

steve.

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jun 88 09:54:01 PDT
From:      lougheed@clash.cisco.com
To:        mkhaw@teknowledge-vaxc.arpa (Mike Khaw)
Cc:        tcp-ip@sri-nic.arpa, customer-service@cisco.com
Subject:   Re: Cisco terminal servers?
Hello Mike -

cisco Terminal Servers have always supported data flow in both directions
when attached to a printer.  In house we use a Laserwriter attached to a
Terminal Server in just such a manner.  We can print to the Laserwriter from
UNIX and TOPS-20 systems.  You may wish to send mail to
"customer-service@cisco.com" if you need some pointers in setting up such a
printing arrangement.

Kirk Lougheed
cisco Systems
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 03:08:08 GMT
From:      dewey@execu.UUCP (Dewey Henize)
To:        comp.protocols.tcp-ip
Subject:   Re: Transceiver connectors

In article <8806192137.AA28570@ucbvax.Berkeley.EDU> enger@GBURG.SCC.COM writes:
>Folks:
>	Many of the writers addressing this topic have complained
>about bending of the slide lock metal (allowing the connector to become 
>partially or fully dislodged).  Still more writers have suggested various 
>revenge scenarios against the inventor of the connector, and the abandonment 
>of the connector's use.  Maybe improvements can be made without resorting to 
>the guillotine (or wire cutters).
>
>	I have noted differnces in the "strength" of the slide locks 
>provided on the cables from various suppliers.  While the geometry may make 
>the applied forces great, it may still be possible to spec a sufficiently
>"strong" slide lock to meet most user's needs.  Perhaps the use of higher 
>quality metal will be the only change necessary.  Reinforcement of the slide 
>lock through other methods such as ribbing and spot welding may also be usefull

Perhaps.  Heck, perhaps we could make it work with epoxy glue too! :-)

At the base of the problem is a different outlook though - this industry had
managed to get along with 9 pin, 25 pin, and all kinds of n-pin connectors
pretty well - but we got used to using a method of screwing things in THAT
WORKED AND WAS EFFECTIVE.  The DIX plug isn't.  It sucks on a good day, and
is flaky the rest of the time.  And as a great many of the testimonials here
have indicated, the 'fix' is simple - get rid of the poor design, go with one
or more variants of tried and true screwlocks.

Now if you (any you, not just Bob) can come up with a good reason to go with
a more complicated, less effective method, please convince me.  Or, of course,
go get a job in the Pentagon in procurement - there are likely to be a few
slots there real real soon...



-- 
===============================================================================
|      execu!dewey  Dewey Henize @ Execucom Systems Corp 512/346-3008         |
|    You don't think my employer APPROVES of these ideas, do you??  Sheesh!   |
=============================================================================== 

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 06:10:11 GMT
From:      JLarson.pa@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: 4.0 SOS questions


	  can't ftp into a 4.0 SOS machine unless I use the user name root

anonymous ftp works fine to my Sun OS 4.0 machine, after following 
the setup instructions in the ftpd man page.

	I'm running ypserv with the old 	secret -i flag just 
	like I do on our 3.n systems but have no joy.  
	
4.0 versions of ypserv don't use the "-i" option.  You have to
build yp host.by* maps using the "-b" option of makedbm. 
(See the makedbm man page).  You will probably also need a new 
version of ypserv from Sun which fixes a critical bug with the "-b" 
option.  mallen@sun.com should be able to help you with this.

John Larson, Xerox PARC

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jun 88  11:08:06 EDT
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  Looking for comments on the 15-pin ethernet connector
> We have a lot of Sun fileservers around here and thus we've had a lot of
> problems with the transceiver connectors.  The problem with Sun equipment
> in particular is that the fashion in which the connector is attached to
> the outside of the ethernet board (same thing goes for the ethernet connector
> on the CPU board).  The screws onto which the slide connector is supposed
> to catch are mounted on the OUTSIDE of the board whereas the connector
> itself is mounted on the INSIDE.  This means that the transceiver cable
> connector can't make full contact with the one on the board.  (I tried to
> draw this in this message but it's too difficult.)  The problem is that
> the pins on the transceiver cable connector side don't go all of the way
> into the holes on the board side because the catches for the connector
> are mounted too far away from the top of the board side connector.  (Take
> a look at it, you'll see.)

Someone from Bridge Communications recently pointed out to me that there
are washers under the posts on the transceiver cable connector.  Removing
the washers allows the cables to make much better contact in this situation.
-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 12:15:40 GMT
From:      wg@sunbim.UUCP (Walter Geens)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   15 pin ethernet connector


	I have just seen the messages on the problems of the ethernet connector.O.K.The desing is not a 100% succes but is in use from the ethernet specs 1
 from Xerox I think from about 1973! It is even described in the standards.
Hard to change I believe.
	Now a solution. I had myself 2 days of troubles finding out what went wrong adding a terminal server to a network not willing to talk to anything.
Believe it or not, it was the connector making no contact at all! 
What was the real cause? In fact, it is not the slide latch that has to maintainthe contact but the plug itself.
	 What I found was that the problem lies in the cable, not the connector on the server! Under the 2 studs on the cable-connector are in general 2 rings.
These rings brings the studs higher up the plug so preventing on many machines
to push in the plug far enough. In most cases only the tip of the pins make
contact. So if the plug is moved a little you are in deep trouble! All depend
on the cable manufacturing.
	!Remove at least one ring and if necessary all rings from under the 
studs so that the plugs mate eachother correctly! Then secure the latch. It 
will work forever and You can take an enjoying holiday. I have done this modi-
fication about 30 times here at BIM and at customer sites and never had to
return until now. 
	I only can hope You will have the same succes!
	
	Boni Dens

sunbim!sos

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 13:53:06 GMT
From:      purple@julian.uwo.ca (Lori Corrin)
To:        comp.protocols.tcp-ip
Subject:   Xenix and TCP/IP


	I'm looking for some infornation on TCP/IP running under Xenix.
	I'm looking for the basics really, Is it available, from whom
	how well does it work, things along those lines. I've been looking
	around but I suspect I'm looking in the wrong places since I don't
	seem to be finding much.

	Thanks

	purple (Lori Corrin purple@julian.uwo.ca
			    purple@julian.UUCP)

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 16:16:00 GMT
From:      dow@MCC.COM (David F. Dow)
To:        comp.protocols.tcp-ip
Subject:   Re: looking for comments on the 15-pin ethernet connectors

Since everyone is knocking this one around, let me insert my pet peeve.
On Sun's 3/160 and 3/260 machines (and perhaps others) have you noticed
what is right next to the fickle slide lock?  THE RESET BUTTON!  I don't
care to think how many times our servers have gone off the air from the
slide connector falling out, soon followed by a crash of the system from
hitting the reset button while trying to replace it.   grrrrr.

Regards,

  -- David F. Dow

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 16:47:11 GMT
From:      hscfvax!mohamed@husc6.harvard.edu  (Mohamed_el_Lozy)
To:        tcp-ip@sri-nic.arpa
Subject:   IEN-116 nameserver
A couple of weeks ago an implementation of the IEN-116 nameserver (both
server and client) for BSD 4.3 systems was posted to
comp.sources.unix.

Currently the PCs that are connected to my LAN use FTP Software's
PC/TCP software, which uses the domain server for name to number
mapping.  Are there any products out there that still use the IEN-116
nameserver?

If it is worth keeping it, how should it deal with the length octet?
RFC-991 states:  "The protocol details are ambiguous, in particular,
the length octet either does or doesn't include itself and the op
code".  Assuming there are products which use it, what is their
interpretation of this question?

Thanks for any advice.
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 16:54:01 GMT
From:      lougheed@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Cisco terminal servers?

Hello Mike -

cisco Terminal Servers have always supported data flow in both directions
when attached to a printer.  In house we use a Laserwriter attached to a
Terminal Server in just such a manner.  We can print to the Laserwriter from
UNIX and TOPS-20 systems.  You may wish to send mail to
"customer-service@cisco.com" if you need some pointers in setting up such a
printing arrangement.

Kirk Lougheed
cisco Systems

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 16:59:45 GMT
From:      rls@telebit.UUCP (Richard Siegel)
To:        comp.dcom.modems,comp.protocols.tcp-ip,comp.sys.att,biz.comp.telebit
Subject:   Telebit Requests Information


Pardon the wide posting, but since so many of you are using the Telebit
TrailBlazer Plus, this may be the best way to ensure that you see this.

Basically, Telebit is making some decisions about what new features to
incorporate into the TrailBlazer Plus (and future) modems. I would like
email describing (briefly!!!) what new features you'd like to see in our
modems.

To get you started, here are some ideas that other people have already
suggested. You may place votes for these, or add new features of your own.

	NEW MODEM FEATURE IDEAS....

	1. Fix Autobaud to work every time
	2. Full Hayes command set (identical)
	3. TCP/SLIP Support in the modem
	4. V.32 compatability (along with PEP)
	5. Higher Level MNP support (in slow speed modes), Level ?
	6. 4-wire Leased line support
	7. Group III Fax support
	8. Synchronous to Async Conversion

Remember, we ARE listening, so this is your chance to help define the next
generation of Telebit products! Respond to me via email, please.

Regards,

Richard Siegel           Phone:                       (415) 969-3800
Product Manager          UUCP:  {sun,uunet,ames,hoptoad}!telebit!rls
Telebit Corporation      ARPA:  telebit!rls@ames.ARPA

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 18:09:20 GMT
From:      sdcrdcf!psivax!nrcvax!jean@oberon.usc.edu  (Jean Sylwanowicz)
To:        tcp-ip@sri-nic.arpa
Subject:   libraries for PC TCP/IP
James Van Bokkelen writes:

In fact, most commercial TCP/IP packages for DOS can be purchased with an
Applications Programming Interface of some sort.  Our PC/TCP, Sun's PC/NFS,
Excelan's EXOS 8051, and NRC's all have libraries that emulate Berkeley
sockets, for Microsoft C.  I don't know details of Bridge's offering.  I
think each product supports all memory models, but I don't think anyone is
shipping code for 5.0 or 5.1 yet.  

-------

Network Research (NRC) is providing support for Microsoft 5.0 with its
Program Development System (PDS) libraries as an option to FUSION version
3.2 - it is to be released by the end of June.


-- 
==============================================================================
Jean M. Sylwanowicz  X-322                        Marketing Comm--Inside Sales
NRC 805-485-2700, 800-541-9508                         (:|=            (:|= 
nrcvax!jean@TRWIND.TRW.COM                    rutgers!citvax!elroy!nrcvax!jean
hplabs!sdcrdcp!psivax!nrcvax!jean        cit-vax!elroy!nrcvax!jean@RUTGETS.EDU
==============================================================================
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 18:57:09 GMT
From:      ittai@VX2.GBA.NYU.EDU (Ittai Hershman)
To:        comp.protocols.tcp-ip
Subject:   More TCP/IP hoopla

In this week's edition of PCWeek/Connectivity, a front page story
describes the network being used by NBC at the Seoul Olympics.  Guess
what-- it's TCP/IP based.  More correctly, it is several Novell based
LANS interconnected with a MicroVAX using the Micom-Interlan Novell-TCP/IP
gateway.

Just amazin'
-Ittai

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 19:01:00 GMT
From:      sandrock@uxe.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin


I haven't heard anyone mention it, but the VAXstation 2000 (and likely the
later DEC workstations) are designed for screw-down type transceiver cables.
The ones around here all have a short white (matching) transceiver cable,
which screws into the back of the VS 2000, but has the infamous slide-lock
mechanism at the other end.  Just thought I'd mention it.

Mark Sandrock, <sandrock@uxe.cso.uiuc.edu>

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 20:15:28 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   [UDEL Mail System:  Failed mail (msg.aa25782)]

Ooop.

----- Forwarded message # 1:

Date:     Mon, 20 Jun 88 14:33:53 EDT
From:     UDEL Mail System (04-Jun-88/MMDF-2b_p#30) <mmdf@UDEL.EDU>
Sender:   Mail System (MMDF) <mmdf@UDEL.EDU>
Subject:  Failed mail  (msg.aa25782)
To:       Mills@UDEL.EDU
Message-ID:  <8806201433.aa25894@Huey.UDEL.EDU>

    Your message could not be delivered to
'tcp-ip@sri.nic.arpa (host: Louie.UDEL.EDU) (queue: badhosts)' for the following
reason:  ' (BHST) Unknown host/domain name in "tcp-ip@sri.nic.arpa"'


    Your message follows:

Date:     Mon, 20 Jun 88 14:31:37 EDT
From:     Mills@UDEL
To:       tcp-ip@sri.nic.arpa, ineng-interest@isi.edu, ntp@trantor.umd.edu
Subject:  NTP server status and peering strategies
Message-ID:  <8806201431.aa25782@Huey.UDEL.EDU>

Folks,

First, let me apologize for the length of this message. I am sending it to the
entire list because it applies to a surprisingly large number of hosts
wittingly or unwittingly chiming the Network Time Protocol (NTP) and this may
be the only effective way to reach them. The six NTP primary time servers are
rapidly filling up with customers, so there is need for some discipline in
access. This message outlines corrective strategies and lists the current
servers, clients and points of contact. If these arcane issues do not tinkle
your bell, you might want to discard this message before reading. If so,
please be advised the ntp@trantor.umd.edu list is the official bazaar for NTP.

Dave

==============================================================================

For your information, at the end of this message are billboards showing the
NTP peers of various fuzzballs known to me. They show the size of the peer
population escalating sharply and cause some concern that server congestion
may begin to occur sooner than expected. Accordingly, I would like to reaffirm
the peerage suggestions made previously on this list and in the document
defining the new Version 1 of NTP (which was submitted for consideration as an
RFC, but has not yet seen the day of light). As a reminder, that document can
be found in pub/ntp.doc on louie.udel.edu.

First, all Unix chimers (are there any others?) should be using the latest
ntpd daemon from Mike Petry, which supports variable-rate polling and can
reduce the polling overhead by a factor of sixteen. Early versions of ntpd do
not provide the best filtering and deglitching features and do not
automatically adapt to failure modes.

Second, unless there are compelling reasons to the contrary, no more than two
secondary servers per network should rattle the five primary server cages and
all retail (end-user) hosts should obtain time from one or more secondary
servers. If two secondary servers are used, each of these should peer with two
different primary servers, for a total of four distinct primary servers. The
two secondary servers should peer with each other and with one or two
secondary servers in other networks. Experience suggests that the peering
population to stratum-one and stratum-two servers should be restrained;
otherwise, the clock-selection algorithm can allow a gang of secondary servers
to overwhelm a few primary servers.

Third, as shown in the following billboards, some chimers may be tinkling the
bells of inappropriate servers. The net 128.59 dudes tinkling udel2.udel.edu
(192.5.39.88) aka dcn6.arpa (128.4.0.6) are actually getting stratum-three
time or worse, although the time is currently pretty good. This host happens
to be located at my home and is vulnerable to new, untried software, power
glitches and marauding cats. Those dudes tinkling macom1.arpa (192.5.8.1,
10.0.0.111) may not be aware that the WWVB clock originally attached to that
host has been moved. However, while this host no longer provides stratum-one
time, it is appropriate for use as a stratum-two neighbor, as described above.
Also, note that the address for primary server ford1.arpa has changed from
128.5.0.1 to 128.5.192.1. I see a lot of ICMP error messages along the way to
128.5.0.1, suggesting that this fact is not well known.

Finally, note that primary server udel1.udel.edu (192.5.39.87) aka dcn1.arpa
(128.4.0.1, 10.2.0.96) is in process of being moved to a new address, which
should occur on or before 5 July. At the moment, the real WWVB clock is on
host udel7.udel.edu (192.5.39.94), so that udel1.udel.edu is currently
providing stratum-two time. A few of you guys cleverly figured that out and
switched chimes to the '94 address. Not to worry; all will be fixed soon. Be
advised that use of net number 192.5.39 is shortly to be discontinued along
with its ARPANET gateway. In order that the transition be as smooth as
possible, I suggest all chimers temporarily use ARPANET address 10.2.0.96.

If you are a secondary server chiming a primary server, you should find your
address in the following billboards. Hopefully, your net should appear no more
than once per billboard, assuming you conform to the peering suggestions
above. The format of these billboards are similar to those available with the
Unix daemon. Where points of contact are not listed, contact me for pointers.

==============================================================================

Host udel1.udel.edu is currently functioning as a secondary server
(stratum two). Its functions are being taken over by udel7.udel.edu, but all
addresses are shortly to be changed as mentioned above. Upon completion, this
host will become the recommended east-coast ARPANET primary server.

udel1.udel.edu (192.5.39.87, 10.2.0.96)
AdrID	Address		Port	Status	Delay	Offset	Disp	Update
------------------------------------------------------------------------
0	[128.5.192.1]	123	377	756	64	95	16:48:58
1	[128.9.2.129]	123	377	732	133	297	16:49:12
2*	[192.5.39.94]	123	377	35	-7	1	16:49:13
3	[128.153.4.2]	123	377	767	382	1269	16:48:52
4	[128.223.20.5]	123	000	659	-322	65535	01:10:36
5	[128.200.9.18]	123	377	451	35	160	16:48:55
6	[35.1.128.16]	123	377	419	-19	26	16:48:48
7	[26.6.0.2]	123	377	2135	-850	529	16:48:58
8	[128.45.1.1]	123	370	504	-6533	542	16:45:44
9	[128.8.251.56]	123	377	222	-317	64	16:48:58
10	[128.8.251.57]	123	377	256	-272	390	16:48:59
11	[26.18.0.124]	123	376	1600	-2808	791	16:48:49
12	[128.8.251.65]	123	377	208	-186	227	16:49:02
13	[128.8.251.64]	123	377	193	90	72	16:49:03
14	[10.1.0.17]	123	377	235	-1051	45	16:49:04
15	[128.200.16.5]	123	377	483	-190	62	16:49:05
16	[192.5.220.220]	123	377	211	415	101	16:49:06
17	[35.1.128.32]	123	376	346	-7	150	16:48:36
18	[192.5.57.1]	123	000	264	-2066	9	16:44:21
19	[128.200.16.7]	123	377	483	61	169	16:48:47
20	[15.255.64.2]	123	377	991	25	77	16:49:09
21	[128.8.251.67]	123	377	228	-278	338	16:48:45
22	[128.8.251.59]	123	377	228	-492	63	16:49:09
23	[128.8.10.14]	123	377	218	-6479	5553	16:49:10
24	[128.200.16.2]	123	377	517	-315	109	16:49:12
25	[128.2.249.123]	123	112	232	11	24	16:48:11
26	[128.8.251.58]	123	377	224	-474	123	16:49:14
27	[192.5.39.3]	123	377	23	63	44	16:49:15
28	[128.95.16.21]	123	377	490	-276	73	16:49:22
29	[128.175.2.13]	123	377	2	76	95	16:49:17
30	[128.8.251.61]	123	377	222	1703195130	53	16:49:18
31	[128.59.64.60]	123	003	319	373	32393	16:48:42
32	[129.48.1.1]	123	376	6669	-522	833	16:49:20
33	[128.174.5.50]	123	377	355	303	128	16:48:30
34	[10.0.0.31]	123	377	101	13	7	16:49:24
35	[128.8.251.51]	123	377	224	71	82	16:49:16
36	[128.208.1.14]	123	000	493	-35	65535	01:10:01
37	[128.116.64.3]	123	377	460	25	52	16:48:20
38	[128.8.251.60]	123	377	219	-100	208	16:49:13
39	[128.8.251.66]	123	377	238	-63	103	16:49:14
40	[128.49.16.7]	123	377	5321	-473	645	16:49:06
41	[128.200.16.6]	123	377	508	-125	101	16:48:29
42	[128.109.130.5]	3965	000	1275	-638	65022	08:05:05
43	[128.112.14.5]	123	377	95	3723	6	16:49:19
44	[128.112.14.25]	123	376	113	3741	6	16:48:27
45	[128.112.14.18]	123	000	102	-44954945	7180	14:01:21
46	[192.5.8.1]	123	377	166	-130	39	16:48:52
47	[15.255.17.2]	123	177	901	11	12	16:48:41
48	[128.59.64.60]	123	376	222	325	64	16:48:31
49	[128.95.16.22]	123	377	475	-340	250	16:48:41

Host wwvb.isi.edu is the recommended west-coast ARPANET/MILNET primary server.
Contact Steve Casner (casner@isi.edu) for further information.

wwvb.isi.edu (128.9.2.129)
AdrID	Address		Port	Status	Delay	Offset	Disp	Update
------------------------------------------------------------------------
0	[128.116.64.3]	123	375	1204	64	442	17:39:52
1	[128.8.10.1]	123	377	1193	-18	577	17:34:40
2	[128.59.16.119]	123	376	1019	25	117	17:40:06
3	[128.200.16.7]	123	376	239	28	86	17:39:32
4*	[192.5.39.94]	123	376	786	-149	422	17:40:06
5	[129.48.1.1]	123	376	5478	-501	911	17:39:59
6	[192.5.39.87]	123	376	710	-119	182	17:39:41
7	[128.200.16.2]	123	376	250	134	110	17:38:35
8	[128.59.16.125]	123	377	1029	-7	533	17:40:27
9	[128.59.16.111]	123	377	1092	156	474	17:40:30
10	[128.59.16.116]	123	377	1032	10	264	17:40:33
11	[128.59.16.112]	123	376	967	-6	249	17:40:12
12	[128.200.9.18]	123	216	228	25	41	17:39:49
13	[128.59.16.122]	123	376	1011	-156	183	17:39:50
14	[192.5.220.220]	123	377	894	-58	807	17:40:11
15	[128.200.16.5]	123	361	239	-64	149	17:38:39
16	[128.97.28.251]	123	376	141	-85	174	17:39:34
17	[128.59.16.120]	123	376	1020	-9	171	17:39:55
18	[192.12.252.4]	123	000	0	0	65535	17:39:43
19	[15.255.64.2]	123	367	1772	100	136	17:40:24
20	[128.200.16.6]	123	376	251	-41	146	17:40:19
21	[128.5.192.1]	123	376	2328	-98	1255	17:24:26
22	[15.255.17.2]	123	311	1583	17	225	17:39:05

Host ncar.nsf.net is one of the NSFNET Backbone switches. As most already
know, the NSFNET Backbone is shortly to be retired and replaced by the
Merit/IBM/MCI NSFNET Backbone, so that the ncar.nsf.net fuzzy will no longer
have that mission. Hopefully, this host will remain in place, if only to
provide good time and remain the recommended NSFNET midcontinent primary
time server.

ncar.nsf.net (128.116.64.3)
AdrID	Address		Port	Status	Delay	Offset	Disp	Update
------------------------------------------------------------------------
0	[128.8.10.1]	123	376	397	-99	1	04:58:15
1	[128.4.0.1]	123	377	422	-16	132	05:09:21
2	[128.135.4.2]	123	376	136	-3	22	05:08:49
3*	[192.5.39.94]	123	376	403	-13	99	05:09:05
4	[192.5.220.220]	123	305	550	-226	216	05:07:56
5	[128.200.16.7]	123	376	145	103	81	05:09:00
6	[128.135.20.72]	123	376	133	-19	9	05:08:57
7	[128.200.16.6]	123	376	153	-400	217	05:08:16
8	[128.138.240.4]	123	377	59	0	8	05:09:01
9	[15.255.64.2]	123	376	1168	29	72	05:09:34
10	[128.200.16.3]	123	377	158	55	297	05:09:04
11	[128.174.5.50]	123	377	93	1	7	05:09:30
12	[128.223.20.5]	123	337	418	32	142	05:09:39
13	[128.102.18.20]	123	173	206	308	193	05:09:32
14	[128.200.9.18]	123	376	159	-222	110	05:09:09
15	[128.200.16.5]	123	000	165	-90	65535	12:37:04
16	[128.200.16.2]	123	377	141	28	55	05:09:33
17	[128.42.1.64]	123	377	79	-2	4	05:09:08
18	[128.9.2.129]	123	136	1532	-17	843	04:53:47
19	[15.255.16.12]	123	327	1078	20	73	05:03:33
20	[15.255.17.2]	123	361	1038	23	47	05:08:14
21	[128.5.192.1]	123	376	900	82	116	05:01:48
22	[15.255.64.2]	2609	000	836	-418	65022	23:33:11

Ramshackle host ford1.arpa is presently at the end of a 9600-bps line at
Dearborn, MI. Net 128.5 should soon be rehomed to MERIT (net 35) by a 56-Kbps
line, in which case (net managers willing) it should become a recommended
NSFNET midwestern primary server. It would be most polite if potential
chimers were to contact Fred Ball (ball@ford-vax.arpa) before use.

ford1.arpa (128.5.192.1)
AdrID	Address		Port	Status	Delay	Offset	Disp	Update
------------------------------------------------------------------------
0	[128.9.2.129]	123	376	2208	-450	197	19:14:13
1	[128.116.64.3]	123	127	1160	92	173	19:26:40
2	[192.5.39.94]	123	333	667	-117	26	19:26:01
3	[128.59.16.121]	123	376	781	89	435	19:25:58
4	[192.5.220.220]	123	126	984	-67	198	19:26:02
5	[192.5.39.87]	123	376	762	-99	93	19:25:39
6	[15.255.17.2]	123	376	1635	-37	210	19:23:59
7	[15.255.16.12]	123	375	1575	-115	113	19:25:54
8	[128.59.16.1]	123	377	971	79	436	19:26:20
9*	[192.5.8.1]	123	367	269	-36	46	19:26:07
10	[128.59.16.116]	123	377	794	50	217	19:26:34
11	[128.59.16.119]	123	376	935	12	323	19:26:00
12	[128.143.2.7]	123	376	807	-21	175	19:26:03
13	[128.59.16.122]	123	376	630	-30	157	19:26:25
14	[128.59.16.112]	123	377	806	-39	123	19:26:42
15	[128.59.16.125]	123	367	688	-19	209	19:26:45
16	[128.59.16.120]	123	375	763	-79	73	19:25:56
17	[128.59.16.111]	123	377	891	-186	324	19:25:58
18	[128.97.28.251]	123	361	1253	-153	302	19:25:04
19	[128.120.57.23]	2560	000	0	0	65535	19:15:07

Host umd1.umd.edu has become the busiest primary server; however, access via
ARPANET is shortly to be curtailed. This is the recommended east-coast NSFNET
MILNET primary server. Note that this server has 63 clients, which is just two
shy of the 65-client maximum of the present configuration. Contact Mike Petry
(petry@trantor.umd.edu) or Louie Mamakos (louie@trantor.umd.edu) for further
information.

umd1.umd.edu (128.8.10.1)
AdrID	Address		Port	Status	Delay	Offset	Disp	Update
------------------------------------------------------------------------
0	[128.5.192.1]	123	346	627	45	148	17:46:49
1	[128.9.2.129]	123	377	992	38	156	17:47:22
2	[128.116.64.3]	123	052	581	71	26	17:39:58
3	[128.59.16.111]	123	376	232	-50	53	17:49:29
4	[128.8.251.57]	123	377	18	-347	112	17:49:15
5	[128.59.16.116]	123	377	189	-38	86	17:49:33
6	[128.143.2.7]	123	377	71	0	4	17:49:33
7	[128.200.16.2]	123	212	636	-34	479	17:40:17
8	[128.95.16.22]	123	377	1011	5	44	17:49:32
9	[35.1.128.32]	123	367	82	5	8	17:49:26
10	[128.8.251.51]	123	377	13	44	149	17:48:48
11	[128.59.64.60]	123	000	160	275	65535	16:47:45
12	[128.45.1.1]	123	000	570	-6419	65535	16:45:09
13	[35.1.128.16]	123	377	76	43	14	17:49:35
14	[128.59.16.122]	123	377	187	-56	87	17:48:50
15	[128.8.251.61]	123	377	14	1703195154	13	17:49:36
16	[36.22.0.8]	123	376	643	29	162	17:48:44
17	[35.1.128.16]	2289	000	0	0	65535	05:00:58
18	[128.59.16.120]	123	377	188	-37	51	17:48:55
19	[128.8.1.14]	123	376	21	-1174	14	17:48:35
20*	[192.5.39.94]	123	377	173	-47	37	17:49:01
21	[10.0.0.31]	123	376	241	-2	33	17:48:39
22	[128.223.20.5]	123	000	1129	-266	65535	01:10:55
23	[128.200.9.18]	123	342	545	-143	175	17:46:40
24	[192.5.39.88]	123	376	389	-38	14	17:49:22
25	[128.8.251.65]	123	376	24	-224	78	17:48:42
26	[129.48.1.1]	123	201	6141	-1077	1814	17:48:45
27	[128.8.251.64]	123	372	13	-308	198	17:48:42
28	[128.8.251.58]	123	376	25	-514	158	17:48:41
29	[128.8.251.60]	123	376	8	-407	218	17:48:43
30	[128.8.251.56]	123	376	19	-246	123	17:48:45
31	[128.59.16.119]	123	376	191	-14	46	17:49:05
32	[128.95.16.21]	123	376	752	51	286	17:48:50
33	[128.97.28.251]	123	377	616	-425	733	17:49:40
34	[128.135.20.72]	123	377	508	-16	65	17:49:11
35	[129.2.1.6]	123	377	28	1	0	17:49:34
36	[128.8.132.10]	123	372	23	-2	2	17:49:13
37	[18.71.0.8]	123	376	0	0	65535	17:48:54
38	[128.175.2.13]	123	376	50	186	156	17:48:55
39	[128.200.16.5]	123	376	463	177	161	17:48:59
40	[128.8.251.66]	123	376	15	-463	110	17:48:55
41	[128.135.4.2]	123	376	348	-40	39	17:49:17
42	[128.8.251.67]	123	376	27	-347	328	17:48:59
43	[192.5.39.3]	123	376	143	37	17	17:48:58
44	[128.49.16.7]	123	377	3141	-2603	3143	17:49:31
45	[128.102.22.200]	123	377	918	-591	249	17:49:00
46	[128.8.251.59]	123	377	25	-439	236	17:49:06
47	[128.8.10.14]	123	377	16	-45	335	17:49:15
48	[128.59.16.125]	123	377	207	-56	44	17:49:27
49	[128.200.16.7]	123	375	501	49	279	17:49:17
50	[18.26.0.109]	123	377	0	0	65535	17:49:09
51	[128.153.4.2]	123	377	1130	-85	585	17:49:09
52	[192.5.220.220]	123	377	236	-67	2271	17:49:34
53	[128.102.18.20]	123	351	929	93	491	17:44:23
54	[128.42.1.64]	123	365	280	-5	17	17:44:46
55	[128.138.240.4]	123	154	387	-60	262	17:41:10
56	[128.200.16.6]	123	376	529	-269	350	17:49:09
57	[128.112.14.5]	123	377	208	-12	16	17:49:42
58	[128.112.14.25]	123	377	204	3696	15	17:45:12
59	[128.112.14.18]	123	000	0	0	65535	14:01:21
60	[192.5.8.1]	123	163	236	-103	26	17:49:34
61	[15.255.17.2]	123	376	1031	45	55	17:48:49
62	[128.95.16.22]	123	000	762	122	65535	17:35:27
63	[128.59.16.112]	123	376	237	-6	75	17:49:11

As mentioned above, host udel1.udel.edu is not presently a primary server, but
obtains primary time from the following host udel7.udel.edu. On or before 5
July, this the address of udel7.udel.edu will be changed and it will become
the official primary server instead of udel1.udel.edu. While the existence of
udel7.udel.edu has not been officially revealed, some clever sods found it
anyway, probably by chasing the IP address field of NTP updates.

udel7.udel.edu (192.5.39.94)
AdrID	Address		Port	Status	Delay	Offset	Disp	Update
------------------------------------------------------------------------
0	[128.5.192.1]	123	375	758	112	194	15:21:30
1	[128.9.2.129]	123	376	726	142	49	15:21:42
2	[128.8.10.1]	123	366	180	51	17	15:21:43
3	[128.116.64.3]	123	267	518	14	92	15:21:51
4*	[18.72.0.3]	123	377	190	-25	15	15:22:12
5	[128.8.10.14]	123	377	158	81	555	15:21:45
6	[18.26.0.109]	123	364	212	-21	20	15:07:18
7	[192.5.39.87]	123	376	35	6	0	15:21:37
8	[18.71.0.8]	123	365	197	-81	110	15:15:34
9	[35.1.128.32]	123	215	296	98	12	15:20:41
10	[18.72.0.141]	3106	000	14633	-7317	65022	16:35:39
11	[35.1.128.16]	123	326	218	59	149	15:07:45
12	[18.72.0.106]	2333	000	181	-91	15967	00:53:31

As noted, host macom1.arpa is no longer a primary server. I assume the
customers listed know that. Contact Mike Little (little@macom2.arpa) for
further information.

macom1.arpa (192.5.8.1, 10.0.0.111)
AdrID	Address		Port	Status	Delay	Offset	Disp	Update
------------------------------------------------------------------------
0	[128.5.192.1]	123	375	294	171	43	13:23:45
1*	[128.8.10.1]	123	377	226	169	19	13:24:22
2	[128.4.0.1]	123	376	152	161	22	13:24:23
3	[10.0.0.31]	123	125	224	125	117	13:09:54
4	[18.62.0.7]	123	125	276	120	255	13:24:36
5	[15.255.17.2]	123	053	1058	205	391	13:17:44
6	[15.255.16.12]	123	135	1030	150	13	13:24:48
7	[18.62.0.6]	123	000	182	-1030632	65535	08:20:52
8	[128.109.131.49]	1198	000	257	-129	24700	03:55:10
9	[128.109.130.5]	4126	000	181	-91	9859	08:02:11

Host udel2.udel.edu is probabably not an appropriate secondary server, so its
net 128.59 customers should move elsewhere. Also, these customers should also
upgrade to the latest ntpd. The other customers are mine.

udel2.udel.edu (192.5.39.88) aka dcn6.arpa (128.4.0.6)
AdrID	Address		Port	Status	Delay	Offset	Disp	Update
------------------------------------------------------------------------
0	[128.8.10.1]	123	373	383	61	13	01:49:39
1	[128.59.16.116]	123	376	469	-29	32	01:50:33
2	[128.59.16.112]	123	377	467	-9	13	01:50:39
3	[128.59.16.122]	123	377	465	-8	15	01:49:50
4	[128.59.16.120]	123	377	480	-10	32	01:49:55
5	[128.59.16.119]	123	377	491	1	46	01:50:05
6*	[128.59.16.125]	123	377	455	-8	15	01:50:26
7	[128.59.16.111]	123	377	479	-13	43	01:50:30
8	[128.175.2.13]	123	377	231	132	61	01:50:00

==============================================================================

----- End of forwarded messages

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 20:48:56 GMT
From:      bailey@elrond.CalComp.COM (Dave Bailey)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP in a real time kernal

Does anyone know of any TCP/IP implementations in small real time
kernals? thanks.

dave bailey

-- 
David C. Bailey ...{decvax|harvard}!elrond!bailey
Calcomp Inc, (A Lockheed Company) Display Products Division,
65 River Road, Hudson, NH 03051-0908, Mail Stop PTP2-2D01. (603) 885 8141

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 21:00:22 GMT
From:      mrspock@hubcap.UUCP (Steve Benz)
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.sources.wanted
Subject:   Where do you suppose I could get egp or gated?

We have a Gould 9005 connected to the Milnet (26.0.0.80 is our number)
and to a LAN connected to NSFnet.  We've been running well for a while,
except that we have no EGP, which means that we really don't get the
kind of connectivity we'd like through the Milnet side.

So we called Gould -- they said something like "eeh gee whut?"
I understand that some folks at Cornell have written something called
'gated' and I believe that's what we need, since it deals with both
RIP (for the LAN) and EGP (for the Milnet connection) in one program.

Does anybody out there know where or if we can lay hands on such a thing?

				- Steve Benz

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 21:49:04 GMT
From:      darrelj@samsun.sm.unisys.com (Darrel VanBuer)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet transceiver connector slide-locks

Slide locks are not perfect, but when correctly implemented do not
cause much trouble.  Sun's violation of the 802.3 spec (and the more
implicit specs in the orginal Ethernet document -- where you have to
read the connector manufacturers' catalogs to get all the rules for
correct adjustment) is a major headache.  By putting a chassis between
the connector flange and the slide, they steal about 1.5 mm of pin
insertion out of a total of 3 mm pin insertion, leaving the connector
quite wobbly.  At one time, we dealt with this by modifying the drop
cable to remove two washers which the spec says SHOULD be between the
lock posts and the connector flange, resulting in a cable end which
complements the Sun error, and gets a good fit.  Of course this cable
now fails to properly fit a conforming computer or extension cable
:-(.

When properly fit, a slide lock is quite strong.  With poor QC or
design, they are abysmal.

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 88 22:13:42 GMT
From:      gutman@manta.NOSC.MIL (Lewis M. Gutman)
To:        comp.protocols.tcp-ip,comp.protocols.iso,comp.protocols.misc
Subject:   delta-t protocol

I am looking for information about the delta-t protocol.  I've
heard that it is used for real-time communications, not much more.
I would appreciate any references.  Thanks.

Lew Gutman
Naval Ocean Systems Center
San Diego, Ca.

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 88 00:37:16 GMT
From:      edward@csvaxa.UUCP (Edward Wilkinson)
To:        comp.emacs,comp.protocols.tcp-ip
Subject:   Remote Gnumacs servers?


Is there a version of Gnumacs which allows a remote Gnumacs  to run in
conjunction with a local part? This  would allow the  local part to do
such simple things as self-insert-command, delete-backward-char, while
the remote  part  does  things  like byte-compile-file,  load-file and
other more expensive tasks.

The main advantage with this is that  a PC user  could edit files with
fast response times  for simple stuff  which usually  takes ages  on a
highly loaded bigger   machine.  This approach  could also work   with
workstations.

Ideas? Or has this already been  done? I  know I'd prefer  to use full
Gnumacs on my PC instead of some  local subsubset of  emacs which fits
into 640k or whatever.
-- 
Ed Wilkinson @ Computer Centre, Massey University, Palmerston North, NZ
uucp: {uunet,watmath!cantuar}!vuwcomp!csvaxa!edward   DTE: 530163000005
Janet/Greybook: E.Wilkinson@nz.ac.massey      Phone: +64 63 69099 x8587
CSnet/ACSnet/Internet: E.Wilkinson@massey.ac.nz    New Zealand = GMT+12

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jun 88 09:35:56 EDT
From:      fedor@storm-king.nyser.net
To:        hubcap!mrspock@gatech.edu, tcp-ip@sri-nic.arpa
Subject:   Re:  Where do you suppose I could get egp or gated?

	sounds like gated is what you need.

	it is FTP'able anonymously via devvax.tn.cornell.edu
	128.84.238.200 or 10.2.0.15  look in the directory pub/gated
	for the latest and greatest.

	Mark

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 88 07:17:58 GMT
From:      shauna@ipso.rss.ips.oz (Shaun A'Rundell)
To:        comp.protocols.tcp-ip,aus.wanted
Subject:   Reliable client/server libiary (SRI from sun)



I have heard that there is a package or libiary of routines
written by some one at SUn microsystems, to provide reliable
client/server connections. If provides services like, re-establishing
connections when a server dies. Has anybody seen this packages, do you
know where I could get it from. I heard it was public domain.

		Thanks

			Shaun ARundell (shauna@ipso.rss.ips.oz)

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jun 88 14:58:10 PDT
From:      postel@venera.isi.edu
To:        tcp-ip@sri-nic.arpa
Cc:        hscfvax!mohamed@husc6.harvard.edu
Subject:   re: IEN-116 nameserver

It is my hope that all IEN-116 name servers will die soon.

(Actually, i wanted to believe they were all already dead.)

Long live the Domain Name System.

--jon.
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 88 10:41:38 GMT
From:      parmelee@wayback.cs.cornell.edu (Larry Parmelee)
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.sources.wanted
Subject:   Re: Where do you suppose I could get egp or gated?

In article <1977@hubcap.UUCP> mrspock@hubcap.UUCP (Steve Benz) writes:
> I understand that some folks at Cornell have written something called
> 'gated' [...] it deals with both RIP [...] and EGP [...] in one program.

Gated can be anonymous ftp'ed from devvax.tn.cornell.edu;  Look in
the pub/gated directory.  The current maintainer is Jeff Honig,
jch@devvax.tn.cornell.edu.

-Larry Parmelee

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 88 13:20:14 GMT
From:      dkhusema@faui44.informatik.uni-erlangen.de (Dirk Husemann)
To:        comp.protocols.tcp-ip
Subject:   4.3 public domain tcp/ip - fixes available ?


	Hi, yawl!

	Well, I'm in the process of porting the 4.3 public domain tcp/ip
release to our PE's (manufactured by Concurrent Computer). Everything
compiled real smoothly - in the net directory, that is, - except for the
file netinet/tcp_input.c.

	The problem is caused by the following piece of source code:

	for (ifp = ifnet; ifp; ifp = ifp->if_next) {
                if (ifp->if_addr.sa_family != AF_INET)
                        continue;
                sin = (struct sockaddr_in *)&ifp->if_addr;
                if ((sin->sin_addr.s_addr & mask) == i)
                        return (1);
        }

	My compiler doesn't like a particular identifier: if_addr ! All
he can be be seduced to say is:

	"tcp_input.c", line 1314: if_addr undefined
	"tcp_input.c", line 1314: member of structure or union required
	"tcp_input.c", line 1314: warning: struct/union or struct/union
				  pointer required
	"tcp_input.c", line 1316: member of structure or union required

As it turns out to be, the variable ifp is of struct ifnet, which in turn
is defined in if.h (net/if.h). Looking it up yields that the member if_addr
of the struct ifnet is NOT defined. Once you compare it with the 4.2 sour-
ces you'll find it there.

	Question:	Did I miss something important (i.e., have there
		been any fixes to this problem - I didn't follow the
		discussions on comp.protocols.tcp-ip that closely) ?

			Did we get our sources mingled up?

			What else?

	Perhaps somebody can enlighten me?


------------------ Smile, tomorrow will be worse! -------------
Business: Dirk Husemann			Home: Dirk Husemann
	  Friedrich-Alexander University      Aufsess-Str. 19
	  Erlangen-Nuremberg		      D-8520 Erlangen
	  Dep. Comp. Science IMMD IV	      West Germany
	  Martensstrasse 3		      +49 9131 302036
	  D-8520 Erlangen
	  West Germany
	  +49 9131 867908
	
	  email: dkhusema@immd4.informatik.uni-erlangen.de

------------------ Did I say smile? Forget it! ----------------
Disclaimer: The opinions, views, statements, ..., expressed 
	    here are NOT those of the university nor those of
	    the student body as a whole. In fact, they're mine!
---------------------------------------------------------------

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 88 14:26:14 GMT
From:      stan@H1.GCY.NYTEL.COM
To:        comp.protocols.tcp-ip
Subject:   TTLs

There has recently been considerable discussion on this list about the
increasing loss of network connectivity.  I have not seen any discussion
about TTL problems, however many of the problems that I have had to shoot
with regard to loss of connectivity have been due to inappropriate TTL
values.   The increase in the size of the regionals and of the Internet as
a whole has not been accounted for and TTL values are therefore set too low.
This results in loss of connectivity, the cause of which is not readily
apparent to the user. 

The matter is often further complicated by different TTL values for ping, 
ftp, tftp and telnet.  Generally I have found that the highest TTL values
are associated with the ping servers, so that when the user pings the host
the network appears to be OK, but because ftp or telnet have a lower TTL, 
it is assumed that there is a problem with those servers and that they are
not responding.  The fact is that their TTL has gone to 0 somewhere in the
network.  There appears to be no consistency across vendor software 
implemenations, as I have seen TTL's for ftp range from 24 to 255.  

In my opinion, TTL for all services should be set to 255 as the network is
not currently plagued with major looping problems and it seems to be more 
important to improve connectivity than to prevent the looping of a packet
at 32 or 64 hops.  Comments?  Opinions?  Similar experiences? Other
solutions? 

-----------------------------------------------------------------------
Real Name : Stanfield L. Smith		 E-mail : stan@h1.gcy.nytel.com
Company   : New York Telephone Co.	 USmail : Room 203 LAB
Phone     : 516-294-7170	       		: 100 Garden City Plaza
FAX G3	  : 516-248-8489			: Garden City NY, 11530
-----------------------------------------------------------------------

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 88 18:22:12 GMT
From:      bernhold@qtp.ufl.edu (David E. Bernholdt)
To:        comp.protocols.tcp-ip
Subject:   Can users get *the* time?


I know nothing about NTP and very little about TCP/IP and the various
protocols, so this is probably a dumb question but here goes...

Can a normal user ask one of the "time machines" for the *right* time?
Does anyone have a quickie program to do this?  I would like to see
how it works.  I mean if someone is broadcasting the info, other uses
could certainly be made of it...
Thanks in advance.
-- 
David Bernholdt			Internet: bernhold@orange.qtp.ufl.edu
Quantum Theory Project		BITnet:   bernhold@ufpine.bitnet
University of Florida		HEPnet:   43129::59410::bernholdt
Gainesville, FL  32611		Phone:    904/392 9306

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 88 22:10:57 GMT
From:      jas@proteon.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   TTLs

The TCP specification specifies that the IP time to live is 60, on
page 51 of RFC 793.  All that the various TCP/IP vendors using 4.xBSD
need to do is edit netinet/tcp_timer.h, and change the definition of
TCP_TTL to 60, and recompile.  It was 15 (?) on 4.2BSD, and is 30 on
4.3BSD (including the "Van Jacobsen" version).  Both of these values
are too small.  (None of the commercial versions I have here uses 60.)
I guess the vendors might be able to get this out the door in 1
year...

One does NOT want to set the IP time to live higher than 60 for TCP.
This breaks certain assumptions that make the three-way handshake
work, and re-use of port numbers.  When the Internet is over 60 hops,
then we will have a problem.  For now, we should follow the standards
we have set for ourselves.

Looking at the 4.3BSD ICMP code, the echo reply code uses the received
TTL as the TTL to send.  (I won't try and decide if this is the
"right" thing of ICMP to do.)  Ping sends through a raw socket, which
uses the default TTL of 255 (defined in netinet/ip.h).  Thus the range
of a ping is 127 hops.

I would disagree about the absence of looping problems.  So long as
RIP, at least in the Berkeley routed implementation, is in use, there
will be transient routing loops.  This problem is minimized in the
IDEA004 RIP.

The host RFC authors should be sure to put this in their checklist,
since it is such a common bug.

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 88 22:45:59 GMT
From:      don@SRI-LEWIS.ARPA (Donald Holman)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin

If I can get the floor for a moment,

I call for an, 'enough already' vote. How about a second.

Don

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 88 01:13:36 GMT
From:      eshop@saturn.ucsc.edu (Jim Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: TTLs

While we're looking at TTLs, how about setting them to SMALL
numbers for packets that aren't supposed to propagate through
the internet.  I'm thinking of net hop routing packets (RIP)
and rwho packets.

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 88 06:38:24 GMT
From:      BENEDET@BLIULG11.BITNET ("F. Benedet")
To:        comp.protocols.tcp-ip
Subject:   TCP-IP on IBM mainframe

We are in the process of selecting products to connect (micro)VAX to
IBM mainframe on ETHERNET and TCP-IP.
The solutions which are distributed here in Belgium are(as far as I know)
    - IBM 8232
    - ITT 8940 (which in fact is the INTEL FASTPATH)
    - Spartacus-Fibronics K200
I suppose this has become a trivial question for most of you but I should
appreciate any comment, appreciation or experience on :
    - those products
    - the related software to be used on the IBM mainframe (VM/HPO)
    - the software to be used on the VAX systems (VMS)
    -opinion about the best way to provide 3270 simulation (in the VAX or
      in the IBM mainframe)
Thanks
Fernand Benedet
Service General d'Informatique - Universite de Liege
15, Avenue des Tilleuls          B4000 Liege (Belgium)
Tel: + 32 41 52 01 80 (455)      Fax: + 32 41 53 44 03
Acknowledge-To: <BENEDET@BLIULG11>

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 88 06:51:53 GMT
From:      ziel@spot.Colorado.EDU (ZIEL FRED ADAM)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Print Server

The architecture we are trying to test is more ideally implemented with
independently adressable network devices, so I'm looking for a (hopefully
cost effective) way of putting our printers on our ethernet network instead 
of hanging them off of a server.  It sounds like we need some of the 
functionality of a cisco terminal server, but that looks to be a bit of 
overkill.  Something similar was described in Comp.newprod from Excelan 
a few weeks ago.  We would also like some method of having the tape drive 
be an independent device, but I think that is less important at the moment.

I would appreciate any info (esp. pricing) on the minimum cisco or Excelan
systems.  I would also appreciate any suggested alternatives or problems
with what we're trying to do.  If I get enough (any :-) replies, I will
post a summary.  Thanks.

----------------------------------------------------------------------
Fred Ziel, Colorado Center for Astrodynamics Reserach, CU-Boulder 
uucp:   ..!{nbires,ames!ncar}!boulder!ziel  domain: ziel@spot.colorado.edu
disclaimer.h (line 10): syntax error.

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 88 09:30:00 GMT
From:      YEHAVI@HUJIVMS.BITNET (Yehavi Bourvine +972-2-584279)
To:        comp.protocols.tcp-ip
Subject:   sridge vs. Cisco IP routers


  We are considering buying routers in order to connect our campuses'
ethernets. There are two choices: GS-3 from Bridge and Cisco's routers. Has
anyone tried them both and can compare them?
                                         Thanks in advance, __Yehavi:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Yehavi Bourvine,             Phones: +972-2-584279,     H
Computation Center,                  +972-2-521574      H
The Hebrew University of Jerusalem,                     H
Givat-Ram,  Jerusalem  91904                            H H H
                             Fax: +972-2-527349         HH H
BITnet:    YEHAVI@HUJIVMS                               H   H
InterNet:  YEHAVI@VMS.HUJI.AC.IL                       H
                                                      H
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 88 11:39:12 GMT
From:      jdobbs@MITRE.ARPA (John D. Dobbs)
To:        comp.protocols.tcp-ip
Subject:   Please remove me from the TCP-IP list


Please remove me from mail list

Thanks

John Dobbs

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 88 08:38:24 +0200
From:      "F. Benedet" <BENEDET%BLIULG11.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   TCP-IP on IBM mainframe
We are in the process of selecting products to connect (micro)VAX to
IBM mainframe on ETHERNET and TCP-IP.
The solutions which are distributed here in Belgium are(as far as I know)
    - IBM 8232
    - ITT 8940 (which in fact is the INTEL FASTPATH)
    - Spartacus-Fibronics K200
I suppose this has become a trivial question for most of you but I should
appreciate any comment, appreciation or experience on :
    - those products
    - the related software to be used on the IBM mainframe (VM/HPO)
    - the software to be used on the VAX systems (VMS)
    -opinion about the best way to provide 3270 simulation (in the VAX or
      in the IBM mainframe)
Thanks
Fernand Benedet
Service General d'Informatique - Universite de Liege
15, Avenue des Tilleuls          B4000 Liege (Belgium)
Tel: + 32 41 52 01 80 (455)      Fax: + 32 41 53 44 03
Acknowledge-To: <BENEDET@BLIULG11>
-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 88 15:23:55 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  TTLs

We have seen exactly the same behavior Smith describes.  We're deep in
a regional (5 hops away from the NSF backbone), and have found a number
of sites we could ping but could not otherwise communicate with.  In one
case (uunet), we contacted the vendor of their software (Sequent), and
the vendor agreed that a higher initial TTL was appropriate.

One more thing for the "how to write a host TCP/IP implementation"
RFC?

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Wed,  22 Jun 88 12:30 +0300
From:      Yehavi Bourvine +972-2-584279 <YEHAVI%HUJIVMS.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   sridge vs. Cisco IP routers
  We are considering buying routers in order to connect our campuses'
ethernets. There are two choices: GS-3 from Bridge and Cisco's routers. Has
anyone tried them both and can compare them?
                                         Thanks in advance, __Yehavi:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Yehavi Bourvine,             Phones: +972-2-584279,     H
Computation Center,                  +972-2-521574      H
The Hebrew University of Jerusalem,                     H
Givat-Ram,  Jerusalem  91904                            H H H
                             Fax: +972-2-527349         HH H
BITnet:    YEHAVI@HUJIVMS                               H   H
InterNet:  YEHAVI@VMS.HUJI.AC.IL                       H
                                                      H
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 88 21:59:59 EDT
From:      Mills@UDEL.EDU
To:        "David E. Bernholdt" <uflorida!ufqtp!bernhold@g.ms.uky.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  Can users get *the* time?
David,

Anybody can ask a time server for time, even normals. See the TCP/IP
Protocol Handbook, available from SRI International, for details on
the various protocols or the various other sources of protocol
information. A friendly Unix system near you probably has most of
those protocols, including daemons for NTP written by Mike Petry
(petry@trantor.umd.edu for further details).

Dave
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 88 18:39:42 GMT
From:      ospwd@emory.uucp (Peter Day {EUCC})
To:        comp.protocols.tcp-ip
Subject:   SLIP


Does anyone know where I can find a specification for SLIP, the
Serial Line IP facility?

Please respond directly to me and I will summarize.

Peter Day
Internet: ospwd%emoryu1@relay.cs.net
Bitnet: ospwd@emoryu1
UUCP: gatech!emoryu1!ospwd

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 88 19:27:01 GMT
From:      necntc!drilex!axiom!linus!security!rpg@ames.arc.nasa.gov  (Robert P. Goldsmith)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Need rfc 877
In article <3c910032.8a06@apollo.uucp> brezak@apollo.uucp (John Brezak) writes:
>Could someone email RFC 877 to me.
>
 Me too, please.


===============================================================================
			Usual disclaimers
R. Goldsmith
         arpa:  rpg@mitre-bedford.arpa         US Mail:  MITRE Corp
     MCI Mail:  yes			                 Mail Stop B330
        voice:  (617) 271-3625				 Burlington Road
							 Bedford, MA 01730
===============================================================================
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 88 09:33:00 GMT
From:      rudolf@konech
To:        comp.protocols.tcp-ip
Subject:   SLIP Info wanted - (nf)


  I heard about the SLIP Protocol for running TCP/IP data over serial lines.
Where can I get some info ?

                              Thanks in advance

Heinz Rudolf   Kontron,Eching       uucp: mcvax!unido!konech!rudolf

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 88 12:15:06 GMT
From:      dkhusema@faui44.informatik.uni-erlangen.de (Dirk Husemann)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp-ip 4.3 public domain fixes ...


	In a previous posting I asked about the struct member if_addr in
netinet/tcp_input.c, well, -

	I'm a bit ashamed to tell, but after rechecking the source code
- netinet/tcp_input.c - again today, we found out, that I *did* miss 
something - a little bitty #if:

	#if BSD<43
	/* XXX this belongs in netinet/in.c */
	in_localaddr(in)

	BSD is defined in include/netinet/tcp_var.h as 42 in case it
isn't defined at all:

	#ifndef BSD
	#define BSD 42  /* if we're not 4.3, pretend we're 4.2 */
	#define OLDSTAT /* set if we have to use old netstat binaries */
	#endif

	As our UNIX operating system (XELOS/esd5) can handle 4.3bsd source
code to a certain extent, we just defined BSD as 43, which took care of our
problem!

	I assume that, in order to make 4.3 tcp-ip work under 4.2bsd,i.e.
defining BSD as 42, one probably needs the _old_ header files, otherwise
the question remains to be answered where one (tcp_input.c that is) shall
get his/her hands on if_addr.

	Dirk


------------------ Smile, tomorrow will be worse! -------------
Business: Dirk Husemann			Home: Dirk Husemann
	  Friedrich-Alexander University      Aufsess-Str. 19
	  Erlangen-Nuremberg		      D-8520 Erlangen
	  Comp.Science Dep. IMMD IV	      West Germany
	  Martensstrasse 1		      +49 9131 302036
	  D-8520 Erlangen
	  West Germany
	  +49 9131 857908
	
	  email: dkhusema@faui44.informatik.uni-erlangen.de
------------------ Did I say smile? Forget it! ----------------
Disclaimer: The opinions, views, statements, ..., expressed 
	    here are NOT those of the university nor those of
	    the student body as a whole. In fact, they're mine!
---------------------------------------------------------------

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 88 13:33:03 GMT
From:      rcsmith@anagld.UUCP (Ray Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Xenix and TCP/IP

In article <2142@julian.uwo.ca> purple@julian.UUCP (Lori Corrin) writes:
>
>	I'm looking for some infornation on TCP/IP running under Xenix.
					    ^^^^^^               ^^^^^

  You might want to try:

	Network Research Corp.
	2380 N. Rose Avenue
	Oxnard, Ca 93030
	(805) 485-2700
-- 
Ray Smith       | USnail: Suite 200, 9891 Broken Land Pky, Columbia, MD 21046
Analytics, Inc. | GEnie : rcsmith
(301) 381-4300  | CIS   : 72000,1111
		| Net   : ...!uunet!mimsy!aplcen!anagld!rcsmith
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"The trouble with doing something right the first time is that nobody
appreciates how difficult it was." -Walt West
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 88 15:49:02 GMT
From:      HEILNER_K@VAXC.STEVENS-TECH.EDU
To:        comp.protocols.tcp-ip
Subject:   (none)

Can anyone recommend a vendor who supplies a Micro Channel
Architecture(MCA) Ethernet board???



Keith Heilner
Network Coordinator
Stevens Institute of Technology
Heilner_k@sitvxb
Heilner_k@vaxb.stevens-tech.edu
------------

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 88 17:08:06 GMT
From:      ted@gouldnl.UUCP (Ted Lindgreen)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: Where do you suppose I could get egp or gated?

In article <1977@hubcap.UUCP> mrspock@hubcap.UUCP (Steve Benz) writes:
>We have a Gould 9005 connected to the Milnet (26.0.0.80 is our number)
 [deleted: need for gated]
>
>So we called Gould -- they said something like "eeh gee whut?"

Gated is part of the Goulds standard operating systems UTX/32 2.1
(for Powernode, such as your 9005) and UTX/32 3.0 (for NP1), so
so there are people at Gould that know about it.

You should ask Gould again. If that does not succeed, please contact
me by e-mail, I may give you a better reference.

| Ted Lindgreen                           ...!mcvax!gouldnl!ted |
| Gould European Unix Support Centre             ted@gouldnl.nl |
| Maarssenbroek, The Netherlands     (USA) ...!gould!tlindgreen |

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 88 18:17:37 GMT
From:      haas@gr.utah.edu  (Walt Haas)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Bridge vs. Cisco IP routers
When shopping for routers don't forget that Proteon also makes one 
which is widely popular here - I don't know if it's sold in Israel
or not.

Walt Haas      haas@cs.utah.edu    utah-cs!haas
-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 88 18:27:25 GMT
From:      VAF@SCORE.STANFORD.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin

Hear here!

	--Vince
-------

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 88 18:56:39 GMT
From:      fin@UF.MSC.UMN.EDU (Craig Finseth)
To:        comp.protocols.tcp-ip
Subject:   Remote Gnumacs servers?

I experimeted some time ago with a version of Gnu-Emacs that had been
modified to use the LEAP features in an Encore Annex terminal
concentrator.  The LEAP features offload the terminal operations
(echoing, etc.).  Although not exactly the same situation as you
describe, it did lead me to propose a conjecture (additional testing
may turn it into a theorem):

	Moving processing from a central, shared resource to a
	distributed, private resource results in lowering the average
	response time while increasing the standard deviation of the
	response time.

In this particular case, I felt that the increase in standard deviation
resulted in crossing a threshold which made performance poor enough
that it could not be offset by the decrease in average response.

In particular, when you went from typing to editing, the pause was
long (compared to echoing) and you had the impression that you editing
character (e.g., ^N, ^A) was ignored, causing you to type it again.
To say the least, this behavior is annoying (see previous paragraph.)

My advice: quit while you're ahead.

Craig A. Finseth			fin@uc.msc.umn.edu [CAF13]
Minnesota Supercomputer Center, Inc.	(612) 624-3375

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 88 20:23:39 GMT
From:      hrp@fermi.CRAY.COM (Hal Peterson)
To:        comp.protocols.tcp-ip
Subject:   ftp hash marks in binary mode

This is a bug in the FTP client in both 4.2BSD and 4.3BSD.  The code
does not allow for the possibility of a read() returning less than a
full buffer, which happens all of the time with a TCP socket,
especially over a busy long-haul net.  You get a hash mark for every
successful read rather than for every BUFSIZ bytes transferred, and
since the size of every read is unpredictable, there is no way to
determine how many bytes you have transferred from the number of hash
marks you have seen.

--
Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN  55120
hrp%hall.CRAY.COM@umn-rei-uc.ARPA	ihnp4!cray!hrp	    (612) 681-3145

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 88 21:05:07 GMT
From:      jis@mtgzz.att.com (XMRP50000[jcm]-j.mukerji)
To:        comp.protocols.tcp-ip
Subject:   Looking for public domain TCP/IP

I am looking for a public domain version of TCP/IP for my own use. I would
like to find a version for which I can get the source. Does such a beast
exist? If it does, from where can I get it?

Please email responses to jis@mtgzz.att.com, I will summarize.

Thanks.
-- 
Jishnu Mukerji, 
mtgzz!jis, jis@mtgzz.att.com
+1 201 957 5986
AT&T, MT 3K-423, 200 Laurel Ave., Middletown NJ 07748

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 88 01:51:13 GMT
From:      north@batcomputer.tn.cornell.edu (Michael J. North)
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.sources.wanted
Subject:   Re: Where do you suppose I could get egp or gated?


You get "gated" via anonymous ftp to  devvax.tn.cornell.edu.

The latest version of it is about one month old.  Have at it........

Mike


-- 
	Michael J. North  "Guess who's heading for Urbana, IL next week?"
	Cornell Theory Center,  265 Olin Hall,  Ithaca, NY 14853-5201
	UUCP: {allegra,decvax,ihnp4,vax135}!cornell!batcomputer!north
	Arpa: north@tcgould.tn.cornell.edu

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 88 03:25:56 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville)
To:        comp.protocols.tcp-ip
Subject:   re: IEN-116 nameserver


	From: postel@venera.isi.edu
	To: tcp-ip@sri-nic.arpa
	Subject: re: IEN-116 nameserver
	
	[ ... ]
	Long live the Domain Name System.
	
	--jon.

As long as it doesn't out-live its usefulness.  I figure it will be
obsolete about the time the last (bug-free) release of BIND comes
out (circa 4.381Beta)...

-Philip

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 88 05:21:00 GMT
From:      YEHAVI@HUJIVMS.BITNET (Yehavi Bourvine +972-2-584279)
To:        comp.protocols.tcp-ip
Subject:   Bridge's GS/3 vs. Cisco AGS - summary.


  Thanks to all who answered my question about Cisco routers vs. Bridge's
ones. All the answers say that Cisco is far better than Bridge, and some
of them even say that the GS/3 doesn't conform to RFC-1009.
                                          Thanks again, __Yehavi:

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 88 06:36:25 GMT
From:      percy@amdcad.AMD.COM (Percy Irani)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Print Server


We have used the Imagen printer with their Ethernet server.
Works well for Unix and VMS hosts. You do have to install the Imagen
software on all nodes you want to print from.

Hope that helps. Imagen can be reached at (408) 986-9400. 

----------------------------------------------------------
I speak for myself and not the Company. All opinions expressed are
my own.
-- 
Ignorance is bliss but can be embarassing at times!

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Fri,  24 Jun 88 8:21 +0300
From:      Yehavi Bourvine +972-2-584279 <YEHAVI%HUJIVMS.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Bridge's GS/3 vs. Cisco AGS - summary.
  Thanks to all who answered my question about Cisco routers vs. Bridge's
ones. All the answers say that Cisco is far better than Bridge, and some
of them even say that the GS/3 doesn't conform to RFC-1009.
                                          Thanks again, __Yehavi:
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 88 15:12:01 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP in a real time kernal

Dave,

Fuzzball, and it keeps very real time. I'm not sure you would call the
kernel small and it is built in assembly code for the PDP11. I'm
not sure you gain much comfort in that.

Dave

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 88 18:26:54 GMT
From:      phil@amdcad.AMD.COM (Phil Ngai)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Print Server

In article <22198@amdcad.AMD.COM> percy@amdcad.UUCP (Percy Irani) writes:
>
>We have used the Imagen printer with their Ethernet server.
>Works well for Unix and VMS hosts. 

I disagree, I don't even use it because the default type size is not
pica and you have to waste time screwing around with troff or such to
get things to look normal. 

I complained about this to Percy and was ignored.
-- 

I speak for myself, not the company.
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 88 00:17:54 GMT
From:      dino@CDCCENTR.BITNET (Dino Farinacci - Control Data - CDCNET TCP/IP Development)
To:        comp.protocols.tcp-ip
Subject:   Re: 802 (.2).3 TCP/IP



    This is in response to ssc-vax!bruce@beaver.cs.washington.edu's
    memo <1919@ssc-vax.UUCP>:

    When we (CDC)  initially  started support of TCP/IP in CDCNET
    we made the decision to support  all  three  of  the Ethernet
    header formats.  We were informed with the direction  of  OSI
    standards  that  802.2/802.3  was  the way to go.  Our CDCNET
    systems already supported this header format but we needed to
    include Ethernet 2 and SNAP headers.

    We felt the effort  was  trivial  for  incoming frames.  Just
    check  the  ether  type  field  in  the 802.3 (or  version  2
    header).  If the value was greater than  1518 (maximum length
    Ethernet  frame),  then  the  header format was  Ethernet  2.
    Otherwise  it was 802.2/802.3.  If  802.2  was  present  than
    another check  is done to determine if a SNAP header follows.
    If so, use the ether  type  field in the SNAP as one would in
    the Ethernet 2 case.  If no SNAP,  use the 8-bit SAP value in
    the 802.2 to multiplex to the correct user.

    For outgoing frames, one does not know what header format the
    destination system  supports.   If  it was our own system, it
    didn't matter (we supported all of them).  There are two ways
    we  allowed this information to be provided.   One,  staticly
    configure  the  header  format  with the IP address/ Ethernet
    address.  Or two, let ARP find out.  Obviously it was less of
    a burden to the Network Administrator  if  ARP  did  it.  The
    disadvantage  was that ARP broadcasts two ARP requests,  each
    with a differnet  header  format (Ethernet 2 and SNAP - there
    is not an 8-bit 802.2 SAP value  assigned for ARP).  When the
    reply is received, the IP address/Ethernet address and header
    format is cached.

    We did this over  a  year  and  a  half ago anticipating that
    workstation   vendors   would  go  to  the  SNAP.    However,
    everything  I've  heard  from   the  TCP/IP  interoperability
    conferences indicates no one cares  about  it  and everything
    works fine as it is today.

Dino Farinacci
Control Data Corp.
CDCNET TCP/IP Design and Development
Sunnyvale, CA.
408-744-5375
------------------------------------------------------------------703

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jun 88 08:00:04 CDT
From:      Mike Rackley <RACKLEY%MSSTATE.BITNET@CUNYVM.CUNY.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Domain name/subnet relationship.
I attempted to post this question to the BIG-LAN discussion group about a week
ago, but I think it got lost in transit.  Anyhow, I apologize if you have seen
this before.

As we plan or campus network, we have decided to use 4 level domain names of
the form:  host.dept.MSSTATE.EDU.  This seems to be in line with what a lot of
other universities do.  We also plan to assign internet addresses in a subnetted
fashion even though initially we will be using MAC layer bridges instead of
routers for traffic isolation.

I am confused about the relationship of domains and subnets.  Is there,
or should there be, any specific relationship between domains and subnets?
In particuar, is it possible to have a single domain that contains more than
one subnet?  Conversely, is it possible to have a single subnet that contains
more than one domain?  Can you have a single domain that is spread among
several subnets?  The situation I am wondering about is where a department is
spread among several buildings on campus.

Mike Rackley
Mississippi State University
-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 88 03:40:00 GMT
From:      jain@erlang.DEC.COM (Raj Jain, DEC, 550 King St., Littleton, MA 01460, USA)
To:        comp.protocols.tcp-ip
Subject:   DEC-TR-553: Error Characteristics of FDDI. Report Available.




The  following  DEC  Technical  Report  DEC-TR-553  is  now  available  for
distribution:

Title:  Error Characteristics of Fiber Distributed Data Interface (FDDI)
        [32 pages]
Author: Raj Jain
        Digital Equipment Corp.
        550 King St.  (LKG1-2/A19)
        Littleton, MA 01460

If you would like a hard copy of the report mailed to you, please  send  me
your  U.S.   (or foreign) Mail address.  Soft copies of the report are also
available for LN03 and postscript printers.   If  you  like  a  soft  copy,
please   specify   LN3   or   PS.    My   network  address  on  ARPAnet  is
Jain%Erlang.dec@decwrl.dec.com

                                 ABSTRACT

Fiber Distributed Data Interface (FDDI) is a 100 megabits per second  fiber
optic  local  area  network  (LAN) standard being developed by the American
National Standard Institute (ANSI).

We analyze the impact of various design decisions on  the  error  detection
capability  of  the protocol.  In particular, we quantify frame error rate,
token loss rate, and undetected error rate.  Several characteristics of the
32-bit  frame  check  sequence (FCS) polynomial, which is also used in IEEE
802 LAN protocols, are discussed.

The standard uses a ``non-return to zero invert  on  ones''  (NRZI)  signal
encoding  and  a  4  bit-to-5  bit  (4B/5B) symbol encoding in the physical
layer.  Due to the combination of  NRZI  and  4B/5B  encoding,  many  noise
events  are detected by code (or symbol) violations.  A large percentage of
errors is also detected by  framing  violations.   Some  of  the  remaining
errors  are detected by FCS violations.  The errors that escape these three
violations remain undetected.  The probability of undetected errors due  to
creation  of false starting delimiters, false ending delimiters, or merging
of two frames is analyzed.

It is shown that every noise event results in two code-bit errors, which in
turn  may  result  in up to four data-bit errors.  The FCS can detect up to
two noise events.   Creation  of  a  false  starting  delimiter  or  ending
delimiter  on  a  symbol  boundary  also  requires  two noise events.  This
assumes enhanced frame validity criteria.  We justify the  enhancements  by
quantifying their effect.

This analysis here is limited to noise events not resulting in a change  of
symbol  boundaries.  Extensions to the case of changed symbol boundaries is
continuing and will be presented at a later time.

                            Version: June 1988

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 88 13:00:04 GMT
From:      RACKLEY@MSSTATE.BITNET (Mike Rackley)
To:        comp.protocols.tcp-ip
Subject:   Domain name/subnet relationship.

I attempted to post this question to the BIG-LAN discussion group about a week
ago, but I think it got lost in transit.  Anyhow, I apologize if you have seen
this before.

As we plan or campus network, we have decided to use 4 level domain names of
the form:  host.dept.MSSTATE.EDU.  This seems to be in line with what a lot of
other universities do.  We also plan to assign internet addresses in a subnetted
fashion even though initially we will be using MAC layer bridges instead of
routers for traffic isolation.

I am confused about the relationship of domains and subnets.  Is there,
or should there be, any specific relationship between domains and subnets?
In particuar, is it possible to have a single domain that contains more than
one subnet?  Conversely, is it possible to have a single subnet that contains
more than one domain?  Can you have a single domain that is spread among
several subnets?  The situation I am wondering about is where a department is
spread among several buildings on campus.

Mike Rackley
Mississippi State University

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 88 01:35:07 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip A. Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re: Print Server

On the subject of Imagens, has anyone considered making the ethernet
print engine speak NFS so the fonts don't have to be installed locally?
This would simplify updating the software imensely if you have many
such printers at your site.  Now if only the DESC.out (etc) files
were read in network byte order...

-Philip

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 88 17:02:36 GMT
From:      aledm@cvaxa.sussex.ac.uk (Aled Morris)
To:        comp.protocols.tcp-ip
Subject:   Re: Third TCP-IP Book?


I just picked up a copy of the Comer book ("Internetworking with TCP/IP"),
I would recommend it (there---I just did! :-)

It is available in the UK (and presumably the rest of the world apart from
the US, Mexico and Canada) in Prentice-Hall's "International Editions"
series (with a red cover to match Tanenbam's networks and Minix books, etc etc)

It's ISBN is 0-13-470188-7, and I paid #18.95 (thats pounds sterling).

Aled Morris
systems programmer

Janet/Arpa: aledm@uk.ac.sussex.cvaxa   |   School of Cognitive Science
      uucp: ..!mcvax!ukc!cvaxa!aledm   |   University of Sussex
      talk: +44-(0)273-606755  e2372   |   Falmer, Brighton, England
   "I'm living in the future/I feel wonderful/I'm tipping over backwards...
I'm so ambitious/I'm looking back/I'm running a race and you're the book I read"

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 88 17:24:11 GMT
From:      aledm@cvaxa.sussex.ac.uk (Aled Morris)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

I too *hate* the clip arrangement on ethernet connectors.  The
most difficult manouver is trying to lever the sodding clip so
you can disconnect the drop cable from the back of a "deskside"
Sun, when there's something screwed firmly into port B, and you're
worried about hitting that reset button 1inch down (plus, of course,
you're leaning over the cabinet on your belly trying not to hit the
power switch with your knee) [fume fume...]

There are worse connectors...and those are the 3 pin mains leads,
with absolutely NO RETAINER WHATSOEVER [god, they make me so ANGRY :-)]
Forget about "ie0: ethernet jammed", one jerk (pun intended) and the
machine goes down, lock stock and disk heads.  Proividing FSCK does not
make up for saving 50 cents on a decent screw-in cable lock.

And another thing---that stupid "off" switch on the front panel, it
really ought to be a key (with a "safe" position that disables L1-A).

I'm so glad that others apart from myself are complaining about these
stupid practices.  Maybe we'll actually see some action from the vendors
on this one?

p.s. maybe this discussion ought to get moved elsewhere...?

Aled Morris
systems programmer

Janet/Arpa: aledm@uk.ac.sussex.cvaxa   |   School of Cognitive Science
      uucp: ..!mcvax!ukc!cvaxa!aledm   |   University of Sussex
      talk: +44-(0)273-606755  e2372   |   Falmer, Brighton, England
   "I'm living in the future/I feel wonderful/I'm tipping over backwards...
I'm so ambitious/I'm looking back/I'm running a race and you're the book I read"

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 88 03:29:20 GMT
From:      hjp@bambam.UUCP (Howard J. Postley)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Print Server

In article <22208@amdcad.AMD.COM>, phil@amdcad.AMD.COM (Phil Ngai) writes:
> In article <22198@amdcad.AMD.COM> percy@amdcad.UUCP (Percy Irani) writes:
> >
> >We have used the Imagen printer with their Ethernet server.
> >Works well for Unix and VMS hosts. 
> 
> I disagree, I don't even use it because the default type size is not
> pica and you have to waste time screwing around with troff or such to
> get things to look normal. 
> 
> I complained about this to Percy and was ignored.

I don't know how you guys at AMD set your printer up but on ours
the font is controlled by the "of" filter in /etc/printcap and
the default font is settable in an environment variable.  Admittedly,
the default default font (failing setting the var to change it) is
not Courier.  Bummer |-).

// Howard
-- 
Howard Postley      usenet:  uunet!bambam!hjp        
On Word             phone:   +1 213 399 7733
                    snail:   2434 Main St; Santa Monica, CA  90405


-- 
Howard Postley      usenet:  uunet!bambam!hjp        
On Word             phone:   +1 213 399 7733
                    snail:   2434 Main St; Santa Monica, CA  90405

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jun 88 13:32:45 EDT
From:      Edward Kodinsky <PETTY@MITVMA.MIT.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   TCP/IP for MVS
Recently James VanBokkelen from FTP Software Inc. stated that the Spartacus
KNET/MVS product had its ancestry from the UCLA MVS code.  This is not the
case.  The Spartacus MVS productline is a substantially modified version
of Spartacus' KNET/VM product.  Spartacus has not used any of the UCLA
MVS code.

Edward Kodinsky
Director of Software Development
Spartacus Inc.
617-937-1600
-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 88 12:47:37 GMT
From:      alan@cunixc.columbia.edu (Alan Crosswell)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain name/subnet relationship.

In article <8806270548.AA23542@ucbvax.Berkeley.EDU> RACKLEY@MSSTATE.BITNET (Mike Rackley) writes:
>I am confused about the relationship of domains and subnets.  Is there,
>or should there be, any specific relationship between domains and subnets?
>In particuar, is it possible to have a single domain that contains more than
>one subnet?  Conversely, is it possible to have a single subnet that contains
>more than one domain?  Can you have a single domain that is spread among
>several subnets?  The situation I am wondering about is where a department is
>spread among several buildings on campus.

Domains are basically a *user* convenience for naming an IP address.  There is
no required relationship between a domain name and an IP address, network,
subnet, campus, etc.  In usual practice they happen to correspond since
single departments tend to be on a single subnet.  However, it is perfectly
reasonable to have members of the same subdomain be located on radically
different networks (e.g. on opposite sides of the world).  You just better
hope that a domain name server for that domain is reachable from both those
networks (not necessarily the same one!).

A lot of people get domains and networks locked together in their
minds mainly as a result of poor examples of domain usage like .BITNET
and .UUCP where the domain is actually being used to indicate a
specific non-IP network.  Work is progressing in both these networks
to convert to proper domain names.  There are now many "MX" servers on
the Internet that respond to domain lookups for BITNET and UUCP
hosts.

Alan Crosswell
Columbia University

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 88 13:13:10 GMT
From:      nittmann@rusvx1.rus.uni-stuttgart.dbp.de ("Michael F.H. Nittmann ")
To:        comp.protocols.tcp-ip
Subject:   historical defaults

Throwing in the following I would like to see if it is worth   
being discussed:
there are two defaults in the telnet standard that are a little bit
hampering on networks since on my opinion they cause lots of
evitable network charge: go ahead and remote echo.

On my own experience most communications in interactive telnet use are
from a workstation to a mainframe computer.
The lines are full duplex as seen from the telnet side. A virtual
circuit of two phone lines or a x.25 virtual circuit look as a 
full duplex line to the telnet.
So: why bother with a go ahead as a default start and not just set
SGA as a default.
The same I think holds for the remote echo. This is a very useful
option when operating over very unreliable lines to very unreliable
hosts. When communicating over a standard network which is reliable
as seen from the bottom side of telnet, and when the tcp/ip used
as a type 4 protocol would take care of resending characters if
they are lost or timed out, so why charge the already overcrowded
network ( re. the breakdowns early in '88) with those single
character echo packets. 
I would guess that nowadays - in 88, not in times on NCP-->TCP
transition - most communications could easily be done with SGA
and local echo. Seen from the mainframe pespective I personnally 
judge it a gigantesque waste of resources to let a multi user
mainframe echo single characters - mainframes may of course
switch that off by negotiating, as is done with SGA. The problem I
see in my experience is that some implementations heavily rely on the 
defaults. When confronted with a non default negotiation at 
communication start some implementations don't work 
correctly. They either insist negotiating their default or
just hang waiting for a GA.
By switching the defaults - SGA and local echo - I think 
we could avoid network charge - two defaults together never
would negotiate e.g. the echo since there is no reson so
they will send those silly 1 character packets.
On the other hand implementors would perhaps be oriented
to the more useful modes as is SGA. Or is there somebody
who really knows he needs the GA any more?

Perhaps this will result in a level 3 or level 4 discussion
opposed to the link level discussion on connectors.(this is OSI
terminology).
                    
And as usual: these are my personal views.

Michael F.H.Nittmann

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 88 13:54:00 GMT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Domain name/subnet relationship.


    Date:       Sat, 25 Jun 88 08:00:04 CDT
    From:       Mike Rackley <RACKLEY%MSSTATE.BITNET@CUNYVM.CUNY.EDU>
	...
    I am confused about the relationship of domains and subnets.  Is there,
    or should there be, any specific relationship between domains and subnets?

They are completely orthogonal.  You can, if you want, establish
relationships, but it would be for purely personal and/or administrative
reasons; there would be (and can be) no technical reason for doing so.
The basic thing to remember is that domains are an administrative naming
system, whereas subnets are a physical cable numbering system (more or
less).

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 88 14:03:41 GMT
From:      fin@uf.msc.umn.EDU (Craig Finseth)
To:        comp.protocols.tcp-ip
Subject:   Domain name/subnet relationship.

There is no need for any particular relationship between domains and
subnets.  You may choose -- for administrative ease -- to divvy up the
subnet address space into blocks for each department.  In that case,
you will likely have some departments that occupy lots of subnets and
other groups of departments that share a subnet.

My advice is to have a central authority give out subnets on
demonstrated need (e.g., new building or >200 or so hosts alread in
place).  In many places, once you give out a subnet, it becomes
difficult to get back if the campus' needs as a whole should change.

Craig A. Finseth			fin@uc.msc.umn.edu [CAF13]
Minnesota Supercomputer Center, Inc.	(612) 624-3375

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 88 14:10:02 GMT
From:      fin@UF.MSC.UMN.EDU (Craig Finseth)
To:        comp.protocols.tcp-ip
Subject:   historical defaults

Your suggestion that local echo is acceptable implies that the local
host knows exactly when and how to echo locally.  As of now, the local
host does not know when and how to locally echo (what about display
editors such as Emacs and vi?).

In the latest IETF meeting (held a couple of weeks ago), there was a
discussion about Telnet EXTENSIONS to handle this type of negotiation
on a dynamic basis (i.e., negotiate which characters are for editing,
how to handle editing, how and when to go in and out of "raw" mode,
etc.)

Craig A. Finseth			fin@uc.msc.umn.edu [CAF13]
Minnesota Supercomputer Center, Inc.	(612) 624-3375

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 88 14:28:37 GMT
From:      tom@TUT.CIS.OHIO-STATE.EDU (Tom Easterday)
To:        comp.protocols.tcp-ip
Subject:   Remove from list


   Please remove my name from your mailing list.  Thanks.
 
                               Tom

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 88 15:56:10 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip, nittmann@rusvx1.rus.uni-stuttgart.dbp.de
Subject:   Re: historical defaults

I agree that the telnet defaults are archaic.  However in most cases
there's going to have to be some negotiation at startup anyway (to
pass terminal type, for example).  So changing the defaults wouldn't
simplify very much, and would lead to great confusion.  Around
universities in the U.S., I think telnet is typically used with Unix
machines or DEC timesharing systems.  Both of these OS's expect
full-duplex connections.  They sometimes do things with characters
other than just echoing them.  E.g. editors like emacs move the cursor
around in response to single characters.  Even when you are not in
Emacs, there are commands for editing single lines in the normal
command scanner.  While I agree that it would be best to do as much
work locally as possible, there are few systems where you can do this
by using local echo in the sense it is defined in the telnet spec.
Since most systems these days expect various characters to trigger
special actions, in order to echo locally, the local host is going to
have to be told something about those special characters.  This means
that a new telnet option will be defined that allows the host to tell
the local system what characters are special.  Discussions are
currently going on within the Internet Engineering Taskforce about
such an option.  I think you'll see an RFC or the draft for one fairly
soon.  (Of course there are existing experimental protocols that do
this already, such as SUPDUP, and the protocol used by Encore for
their terminal servers.)

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 88 17:27:48 GMT
From:      sytek@tekgen.BV.TEK.COM (Mike Ewan)
To:        comp.protocols.tcp-ip
Subject:   Re: (none)

In article <8852310494.20601603.HEILNER_K> HEILNER_K@VAXC.STEVENS-TECH.EDU writes:
>Can anyone recommend a vendor who supplies a Micro Channel
>Architecture(MCA) Ethernet board???
>
Try AST.

Mike

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 88 17:32:45 GMT
From:      PETTY@MITVMA.MIT.EDU (Edward Kodinsky)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for MVS

Recently James VanBokkelen from FTP Software Inc. stated that the Spartacus
KNET/MVS product had its ancestry from the UCLA MVS code.  This is not the
case.  The Spartacus MVS productline is a substantially modified version
of Spartacus' KNET/VM product.  Spartacus has not used any of the UCLA
MVS code.

Edward Kodinsky
Director of Software Development
Spartacus Inc.
617-937-1600

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 88 18:00:12 GMT
From:      jerry@wrs.UUCP (Jerry Fiddler)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in a real time kernal

In article <2348@elrond.CalComp.COM> bailey@elrond.CalComp.COM (Dave Bailey) writes:
>Does anyone know of any TCP/IP implementations in small real time kernels?

We sell a real-time OS called VxWorks that fits those needs.  It runs on
68K-based targets now, and will run on SPARC targets in October.

Rather than expound upon the (extensive) capabilities of VxWorks here (against
net policy, after all) I'll send you some materials directly.

-- 
Jerry Fiddler
Wind River Systems
{sun,rtech}!wrs!jerry

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 88 19:10:51 GMT
From:      killer!tness7!tness1!nuchat!texhrc!cml@ames.arc.nasa.gov  (Chris Lonvick)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: IEN-116 nameserver
In article <581@hscfvax.harvard.edu>, mohamed@hscfvax.harvard.edu (Mohamed_el_Lozy) writes:
> mapping.  Are there any products out there that still use the IEN-116
> nameserver?
> 

Bridge Communication's CS/1 may be configured for either IEN-116
or Domain Name Server.

- Usual disclaimers.

Chris Lonvick
Texaco EPTD
-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 88 21:00:40 GMT
From:      kurt@hi.unm.edu (Kurt Zeilenga)
To:        comp.protocols.tcp-ip
Subject:   Allocating subnets

Just a note on allocating subnets (using a single netmask):

1) Pick an appropriate subnet mask (for then example: 255.255.255.0
   for a B).

2) Then allocate the subnets by changing the high order bits of the
   subnet field (ie: X.X.128 first, then 64, 192, 32, 96, ...)

3) Allocate hosts within a subnet using the low order bits of the
   host field (ie: 1, 2, 3).

Why?  Because what you think now might be the right subnet mask may
not be the right one in the future.  With this allocation scheme you
will have limited freedom to change the netmask later with minimal
hardship (renumbering).

	- Kurt

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 88 21:59:27 GMT
From:      barbiaux@mrsvr.UUCP (Bill Barbiaux)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in a real time kernal

From article <2348@elrond.CalComp.COM>, by bailey@elrond.CalComp.COM (Dave Bailey):
> Does anyone know of any TCP/IP implementations in small real time
> kernals? thanks.

We are using VxWorks, a real-time system and development environment
with good networking facilities.  It uses TCP/IP, and is built around
the VRTX kernal.  It is designed to fit well in a UNIX development
environment (supports remote login, remote file access, a shell, etc.),
while its kernal makes it useful for real-time applications.  VxWorks
is marketed by Wind River Systems, Inc., Emeryville, CA (415)428-2623. 

ALSO: I'm looking for TCP/IP implementations running under iRMX.  Can
anyone help me out?  Thanks

Bill Barbiaux

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 88 00:20:00 GMT
From:      piyu%deervax.concordia.CDN@ean.ubc.ca (piyu tripathy)
To:        comp.protocols.tcp-ip
Subject:   Remove from list


Please remove my name from your mailing list. Thanks.

                                   piyu

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 88 05:39:00 EDT
From:      "NRL::FARNHAM" <farnham%nrl.decnet@nrl.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        farnham
Subject:   Re: Getting started
HI!

  HOW DOES ONE GET A COPY OF THE HEADRICK MATERIAL. I CHECKED
WITH THE UNIVERSITY OF MD. BOOK EXCHANGE AND THEY DIDN'T HAVE IT.
I ALSO ASKED OUR NETWORK PEOPLE HERE AT NRL AND THEY DIDN'T HAVE IT.

       HEEELLLPPP!!!

                                      I'D REALLY LIKE TO READ IT.
                                      EMILY D. FARNHAM
                                      CODE 2861.7
                                      NAVAL RESEARCH LABORATORY
                                      4555 OVERLOOK AVE. S.W.
                                      WASHINGTON, D.C. 20375-5000

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jun 88 8:41:18 EDT
From:      Alex McKenzie <mckenzie@LABS-N.BBN.COM>
To:        Charles Hedrick <njin!aramis.rutgers.edu!athos.rutgers.edu!hedrick@PRINCETON.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  historical defaults
Of course, instead of the IETF inventing a new set of Telnet options, the
community could consider the (shudder) ISO Virtual Terminal Protocol, which was
designed to do all this.

Alex McKenzie
 
-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 88 05:18:02 GMT
From:      jack@turnkey.TCC.COM (Jack F. Vogel)
To:        comp.protocols.tcp-ip
Subject:   telnet server code

I have been experimenting with the KA9Q TCP/IP package both under DOS
and under SCO Xenix. So far I have a variant of the package running as
a background FTP and SMTP server under Xenix. The biggest limitation
of the package for serious server usage is the lack of a Telnet server.
Could some kind soul out there point me at some existing telnet code
that I could access to integrate into the KA9Q stuff; it would make life
much easier. If anyone else is interested in this package under Xenix 
send me some email and I can let you know the details.


				Please email and I will summarize should
					interest warrant it.

					  Thanks so much,

-- 
Jack F. Vogel
Turnkey Computer Consultants, Costa Mesa, CA
UUCP: ...{nosc|uunet}!turnkey!jack 
Internet: jack@turnkey.TCC.COM

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 88 05:22:01 GMT
From:      ncoverby@ndsuvax.UUCP (Glen Overby)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in a real time kernal

From article <2348@elrond.CalComp.COM>, by bailey@elrond.CalComp.COM (Dave Bailey):
> Does anyone know of any TCP/IP implementations in small real time
> kernals? thanks.

I don't know if you consider XINU to be real-time or not (device drivers 
should be able to meet real-time requirements), and Version 7 contains 
TCP/IP(see Comer's second edition, "Operating System Design: The XINU 
Approach; Internetworking with XINU").
-- 
Glen Overby
Bitnet:  ncoverby@ndsuvax
UUCP: uunet!ndsuvax!ncoverby

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 88 09:39:00 GMT
From:      farnham%nrl.DECnet@NRL3.ARPA ("NRL::FARNHAM")
To:        comp.protocols.tcp-ip
Subject:   Re: Getting started

HI!

  HOW DOES ONE GET A COPY OF THE HEADRICK MATERIAL. I CHECKED
WITH THE UNIVERSITY OF MD. BOOK EXCHANGE AND THEY DIDN'T HAVE IT.
I ALSO ASKED OUR NETWORK PEOPLE HERE AT NRL AND THEY DIDN'T HAVE IT.

       HEEELLLPPP!!!

                                      I'D REALLY LIKE TO READ IT.
                                      EMILY D. FARNHAM
                                      CODE 2861.7
                                      NAVAL RESEARCH LABORATORY
                                      4555 OVERLOOK AVE. S.W.
                                      WASHINGTON, D.C. 20375-5000

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 88 12:41:18 GMT
From:      mckenzie@LABS-N.BBN.COM (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re:  historical defaults

Of course, instead of the IETF inventing a new set of Telnet options, the
community could consider the (shudder) ISO Virtual Terminal Protocol, which was
designed to do all this.

Alex McKenzie
 

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 88 14:27:58 GMT
From:      timk@NCSA.UIUC.EDU (Tim Krauskopf)
To:        comp.protocols.tcp-ip
Subject:   Re: MCA Ethernet boards

Date: 27 Jun 88 17:27:48 GMT
From: tektronix!tekgen!sytek@ucbvax.Berkeley.EDU  (Mike Ewan)

	In article <8852310494.20601603.HEILNER_K> HEILNER_K@VAXC.STEVENS-TECH.EDU writes:
	>Can anyone recommend a vendor who supplies a Micro Channel
	>Architecture(MCA) Ethernet board???
	>
	Try AST.

	Mike


Don't bother "trying" AST.

As of April, 1988, only two vendors were SHIPPING MCA Ethernet boards,
Ungermann-Bass and 3Com.  They both use the Intel 82586 chip, the 3Com
board has an on-board transceiver and the UB does not.

MICOM and Western Digital have announced boards which may be on some
dealer's shelves by the time you read this, but I don't know any users
which have them in hand.  These companies market some of the lower-priced
boards for the PC bus, so they may be good price competitors.


Tim Krauskopf                timk@ncsa.uiuc.edu (ARPA)

National Center for Supercomputing Applications (NCSA) 
University of Illinois, Urbana-Champaign

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 88 15:24:08 GMT
From:      purple@julian.uwo.ca (Lori Corrin)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Thanks


 	Thanks to all who replied to my message for help
	with TCP/IP under Xenix. I've passed the replies
	on to the powers that be around here so they can make 
	the final decisions, but the Excelean product seem to be
	the most common choice.

	Thanks

	Lori Corrin
	Computing and Communications Services
	University of Western Ontario
	London, Ontario, Canada

	purple@uwo.ca
	purple@julian.UUCP
	purple@uwovax.BITNET
	(...!watmath!julian!purple)

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 88 15:46:24 GMT
From:      ron@topaz.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Print Server

While CISCO sells a parallel printer and software for their terminal
servers, it is possible to hang a printer off a CISCO serial port
(provided it is an RS-232) printer.   We have a number of dumb line
printers and Postscript printers of various sorts that used to run
on RS-232 ports off UNIX machines running on CISCO boxes.  There
are two ways of doing this.  One way is that I have a program that
sits on a PTY and shuffles everything to the remote cisco serial port.
This is handy for places where you won't want to dink with the output
filters.  We do have some minor problems with this on the postscript
printers especially when the printer times out due to long delays in
the host spitting data into it.  We've also hacked the Adobe Transcript
driver to open connections to the device directly.

As far as pricing, CISCO now has a midrange server that is probably a bit
cheaper than the price you saw before.  They are also rumored to be working on
a very small RS-232/Ethernet only server.  All there other servers can
talk to a variety of network interfaces.  CISCO gives discounts to
educational institutions and EDUCOM/BITNET members.  The MIDRANGE server
I recall (discounted) was about the same price as the (discounted) price
for the ANNEX (somewhere in the low $4000's for 16 lines).

-Ron

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 88 15:52:47 GMT
From:      elbereth.rutgers.edu!zydeco.rutgers.edu!latzko@rutgers.edu  (Alexander Latzko)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: IEN-116 nameserver

The bridge CS/1 may only be configured to use Domain name service if
it is running release 20000 of thier software.  To run this release
you must have the 512K version of the box.  The 256K version is 
limited to release 19000 and IEN116.  

The upgrade path for a 256K box is to replace the mother board w/ the
512K version for some relativly high amount.   


What you might want to do is write an IEN116 server which simply issues
a gethostbyname which your local resolver will then take and deal with.

cheers
/S*
-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jun 88 15:45 SET
From:      Erina Ferro <ERINA%ICNUCEVM.BITNET@CUNYVM.CUNY.EDU>
To:        <TCP-IP@SRI-NIC.ARPA>, <PC-IP@LOUIE.UDEL.EDU>, <BIND@UCBARPA.BERKELEY.EDU>, <INFO-APPLETALK#@ANDREW.CMU.EDU>
Subject:   New OZONE mailing list!
A new computer conference is being formed. Please ignore this message
if you have already received it. Sorry for duplicates.
Please DO NOT ignore this message if it is the first time you read it!
PLEASE FORWARD THIS MESSAGE TO EVERYBODY COULD BE INTERESTED.

This mail is sent you by a group of researchers of the Italian National
Council (C.N.R.), working at the CNUCE Institute, in order to wake up the
sensitivity of people working in the scientific institutions about the
extremely serious problem of the pollution in the world.
As you certainly know, the hole in the ozone, the "hot-house effect",
the acid rains and the toxic waste are disasters provoked by man
by using the Nature as a "never-ending" resource.
Everybody can verify other effects of the pollution, in the cities,
in the seas, in the rivers, etc.
We think that the scientific community must create an opinion movement
able to force some decisions at political level.
We think we are still in time to do something to save Nature
with the help of everybody.
A computing conference is going to be opened and you can partecipate by sending
your ideas to the following address:
OZONE@ICNUCEVM.CNUCE.CNR.IT or
OZONE%ICNUCEVM.BITNET@CUNYVM.CUNY.EDU or
OZONE%ICNUCEVM.BITNET@ICNUCEVM.CNUCE.CNR.IT

In order to be included to the list of the partecipants to the conference,
send a mail message to: LISTSERV@ICNUCEVM.CNUCE.CNR.IT or
                        LISTSERV%ICNUCEVM.BITNET@CUNYVM.CUNY.EDU or
                        LISTSERV%ICNUCEVM.BITNET@ICNUCEVM.CNUCE.CNR.IT

containing only the following line:

SUB OZONE <first name> <surname>

If you need info about the computing conference send a mail message to the
same address containing only the following line:

HELP


Please, inform your collegues about this conference.

Thank you for your collaboration.
-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 88 17:32:38 GMT
From:      dzoey@TERMINUS.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: historical defaults

> From: Alex McKenzie <mckenzie@LABS-N.BBN.COM>
> Subject:  Re:  historical defaults
 
> Of course, instead of the IETF inventing a new set of Telnet options, the
> community could consider the (shudder) ISO Virtual Terminal Protocol, which 
> was designed to do all this.

I don't think the internet community would want to do this because
the various profiles for VTP (a profile is similar to a set of telnet
options describing how all terminal capabilities should be mapped)
are still being defined at NBS.   This doesn't mean that people shouldn't
take an active interest in VTP, just that they probably won't want 
telnet to emulate it.

What is interesting is that the telnet way of doing terminal negotiation
(one attribute at a time) can be done with VTP, but only with the extended
model, not the basic one (forgive me if my terms are fuzzy, my copy of
the VTP spec is at home).   It sometimes seems that the Internet and 
ISO picked different ends of the implementation spectrum and are now
busy rushing toward each other.

That's what I like about standards, there's so many to choose from :-)

                            Joe Herman
                            U of Md.

dzoey@terminus.umd.edu

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 88 20:11:23 GMT
From:      lyndon@ncc.Nexus.CA (Lyndon Nerenberg)
To:        rec.ham-radio.packet,comp.unix.questions,comp.protocols.tcp-ip
Subject:   SLIP protocol specification

Lately there have been a number of requests for a description of
the SLIP encapsulation scheme for sending IP packets over serial
links. SRI has (finally :-) issued an RFC describing how this is
currently implemented. It's only six pages long, so I've attached
a copy. Apologies if you've already seen this.

(cut the .signature at the end)

--lyndon  VE6BBM

-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
Network Working Group                                          J. Romkey
Request for Comments: 1055                                     June l988

 A NONSTANDARD FOR TRANSMISSION OF IP DATAGRAMS OVER SERIAL LINES: SLIP

INTRODUCTION

   The TCP/IP protocol family runs over a variety of network media:
   IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines,
   satellite links, and serial lines.  There are standard encapsulations
   for IP packets defined for many of these networks, but there is no
   standard for serial lines.  SLIP, Serial Line IP, is a currently a de
   facto standard, commonly used for point-to-point serial connections
   running TCP/IP.  It is not an Internet standard.  Distribution of
   this memo is unlimited.

HISTORY

   SLIP has its origins in the 3COM UNET TCP/IP implementation from the
   early 1980's.  It is merely a packet framing protocol: SLIP defines a
   sequence of characters that frame IP packets on a serial line, and
   nothing more. It provides no addressing, packet type identification,
   error detection/correction or compression mechanisms.  Because the
   protocol does so little, though, it is usually very easy to
   implement.

   Around 1984, Rick Adams implemented SLIP for 4.2 Berkeley Unix and
   Sun Microsystems workstations and released it to the world.  It
   quickly caught on as an easy reliable way to connect TCP/IP hosts and
   routers with serial lines.

   SLIP is commonly used on dedicated serial links and sometimes for
   dialup purposes, and is usually used with line speeds between 1200bps
   and 19.2Kbps.  It is useful for allowing mixes of hosts and routers
   to communicate with one another (host-host, host-router and router-
   router are all common SLIP network configurations).

AVAILABILITY

   SLIP is available for most Berkeley UNIX-based systems.  It is
   included in the standard 4.3BSD release from Berkeley.  SLIP is
   available for Ultrix, Sun UNIX and most other Berkeley-derived UNIX
   systems.  Some terminal concentrators and IBM PC implementations also
   support it.

   SLIP for Berkeley UNIX is available via anonymous FTP from
   uunet.uu.net in pub/sl.shar.Z.  Be sure to transfer the file in
   binary mode and then run it through the UNIX uncompress program. Take



Romkey                                                          [Page 1]
 
RFC 1055                     Serial Line IP                    June 1988


   the resulting file and use it as a shell script for the UNIX /bin/sh
   (for instance, /bin/sh sl.shar).

PROTOCOL

   The SLIP protocol defines two special characters: END and ESC. END is
   octal 300 (decimal 192) and ESC is octal 333 (decimal 219) not to be
   confused with the ASCII ESCape character; for the purposes of this
   discussion, ESC will indicate the SLIP ESC character.  To send a
   packet, a SLIP host simply starts sending the data in the packet.  If
   a data byte is the same code as END character, a two byte sequence of
   ESC and octal 334 (decimal 220) is sent instead.  If it the same as
   an ESC character, an two byte sequence of ESC and octal 335 (decimal
   221) is sent instead.  When the last byte in the packet has been
   sent, an END character is then transmitted.

   Phil Karn suggests a simple change to the algorithm, which is to
   begin as well as end packets with an END character.  This will flush
   any erroneous bytes which have been caused by line noise.  In the
   normal case, the receiver will simply see two back-to-back END
   characters, which will generate a bad IP packet.  If the SLIP
   implementation does not throw away the zero-length IP packet, the IP
   implementation certainly will.  If there was line noise, the data
   received due to it will be discarded without affecting the following
   packet.

   Because there is no 'standard' SLIP specification, there is no real
   defined maximum packet size for SLIP.  It is probably best to accept
   the maximum packet size used by the Berkeley UNIX SLIP drivers: 1006
   bytes including the IP and transport protocol headers (not including
   the framing characters).  Therefore any new SLIP implementations
   should be prepared to accept 1006 byte datagrams and should not send
   more than 1006 bytes in a datagram.

DEFICIENCIES

   There are several features that many users would like SLIP to provide
   which it doesn't.  In all fairness, SLIP is just a very simple
   protocol designed quite a long time ago when these problems were not
   really important issues.  The following are commonly perceived
   shortcomings in the existing SLIP protocol:

      - addressing:

         both computers in a SLIP link need to know each other's IP
         addresses for routing purposes.  Also, when using SLIP for
         hosts to dial-up a router, the addressing scheme may be quite
         dynamic and the router may need to inform the dialing host of



Romkey                                                          [Page 2]
 
RFC 1055                     Serial Line IP                    June 1988


         the host's IP address.  SLIP currently provides no mechanism
         for hosts to communicate addressing information over a SLIP
         connection.

      - type identification:

         SLIP has no type field.  Thus, only one protocol can be run
         over a SLIP connection, so in a configuration of two DEC
         computers running both TCP/IP and DECnet, there is no hope of
         having TCP/IP and DECnet share one serial line between them
         while using SLIP.  While SLIP is "Serial Line IP", if a serial
         line connects two multi-protocol computers, those computers
         should be able to use more than one protocol over the line.

      - error detection/correction:

         noisy phone lines will corrupt packets in transit. Because the
         line speed is probably quite low (likely 2400 baud),
         retransmitting a packet is very expensive.  Error detection is
         not absolutely necessary at the SLIP level because any IP
         application should detect damaged packets (IP header and UDP
         and TCP checksums should suffice), although some common
         applications like NFS usually ignore the checksum and depend on
         the network media to detect damaged packets.  Because it takes
         so long to retransmit a packet which was corrupted by line
         noise, it would be efficient if SLIP could provide some sort of
         simple error correction mechanism of its own.

      - compression:

         because dial-in lines are so slow (usually 2400bps), packet
         compression would cause large improvements in packet
         throughput. Usually, streams of packets in a single TCP
         connection have few changed fields in the IP and TCP headers,
         so a simple compression algorithms might just send the changed
         parts of the headers instead of the complete headers.

   Some work is being done by various groups to design and implement a
   successor to SLIP which will address some or all of these problems.












Romkey                                                          [Page 3]
 
RFC 1055                     Serial Line IP                    June 1988


SLIP DRIVERS

   The following C language functions send and receive SLIP packets.
   They depend on two functions, send_char() and recv_char(), which send
   and receive a single character over the serial line.

   /* SLIP special character codes
    */
   #define END             0300    /* indicates end of packet */
   #define ESC             0333    /* indicates byte stuffing */
   #define ESC_END         0334    /* ESC ESC_END means END data byte */
   #define ESC_ESC         0335    /* ESC ESC_ESC means ESC data byte */

   /* SEND_PACKET: sends a packet of length "len", starting at
    * location "p".
    */
   void send_packet(p, len)
           char *p;
           int len; {

     /* send an initial END character to flush out any data that may
      * have accumulated in the receiver due to line noise
      */
        send_char(END);

     /* for each byte in the packet, send the appropriate character
      * sequence
      */
           while(len--) {
                   switch(*p) {
                   /* if it's the same code as an END character, we send a
                    * special two character code so as not to make the
                    * receiver think we sent an END
                    */
                   case END:
                           send_char(ESC);
                           send_char(ESC_END);
                           break;

                   /* if it's the same code as an ESC character,
                    * we send a special two character code so as not
                    * to make the receiver think we sent an ESC
                    */
                   case ESC:
                           send_char(ESC);
                           send_char(ESC_ESC);
                           break;




Romkey                                                          [Page 4]
 
RFC 1055                     Serial Line IP                    June 1988


                   /* otherwise, we just send the character
                    */
                   default:
                           send_char(*p);
                           }

                   p++;
                   }

           /* tell the receiver that we're done sending the packet
            */
           send_char(END);
           }

   /* RECV_PACKET: receives a packet into the buffer located at "p".
    *      If more than len bytes are received, the packet will
    *      be truncated.
    *      Returns the number of bytes stored in the buffer.
    */
   int recv_packet(p, len)
           char *p;
           int len; {
           char c;
           int received = 0;

           /* sit in a loop reading bytes until we put together
            * a whole packet.
            * Make sure not to copy them into the packet if we
            * run out of room.
            */
           while(1) {
                   /* get a character to process
                    */
                   c = recv_char();

                   /* handle bytestuffing if necessary
                    */
                   switch(c) {

                   /* if it's an END character then we're done with
                    * the packet
                    */
                   case END:
                           /* a minor optimization: if there is no
                            * data in the packet, ignore it. This is
                            * meant to avoid bothering IP with all
                            * the empty packets generated by the
                            * duplicate END characters which are in



Romkey                                                          [Page 5]
 
RFC 1055                     Serial Line IP                    June 1988


                            * turn sent to try to detect line noise.
                            */
                           if(received)
                                   return received;
                           else
                                   break;

                   /* if it's the same code as an ESC character, wait
                    * and get another character and then figure out
                    * what to store in the packet based on that.
                    */
                   case ESC:
                           c = recv_char();

                           /* if "c" is not one of these two, then we
                            * have a protocol violation.  The best bet
                            * seems to be to leave the byte alone and
                            * just stuff it into the packet
                            */
                           switch(c) {
                           case ESC_END:
                                   c = END;
                                   break;
                           case ESC_ESC:
                                   c = ESC;
                                   break;
                                   }

                   /* here we fall into the default handler and let
                    * it store the character for us
                    */
                   default:
                           if(received < len)
                                   p[received++] = c;
                           }
                   }
           }














Romkey                                                          [Page 6]
 
-- 
{alberta,pyramid,uunet}!ncc!lyndon  lyndon@Nexus.CA

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 88 23:29:14 GMT
From:      chris@mimsy.UUCP (Chris Torek)
To:        comp.lang.c,comp.unix.questions,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   For non-USENET readers only

(Apologies to USENET readers, but if I mailed this to the corresponding
ARPA/CS/BIT/...net mailing lists you would see it four times rather than
once.  You can skip the rest of this.)

For those wishing to subscribe to any of the four mailing lists on
which this message is appearing, or for those who are already on such a
mailing list and want to get off it, please do NOT send your requests
to the mailing list itself.  This sends the message on out to every
reader of the list and across some gateway software to USENET; it thus
reaches literally thousands of machines and merely serves to annoy
everyone except those who have control of the mailing list itself.
More importantly, in many cases the mailing list editor (person) does
not read the list itself, and messages to the list are thus worse than
useless.

Please send requests to the -request form of the list.  For instance,
to get on or off the Unix-Wizards list, rather than sending a message
to Unix-Wizards@brl.arpa, send it to Unix-Wizards-Request@brl.arpa.
Remember that mail gets delayed and that people take vacations, and
that mailing list maintenance is often a low priority project; it can
easily take two or three weeks to get action on some request.
Moreover, many lists have local redistribution points, to ease the load
on mailers (using a mail system as a bulletin board has some
drawbacks!).  You should check for a local redistribution list first
before sending mail to the -request address.  Likewise, if you were
added to a local redistribution list, asking the -request address to
remove your name from the list is unlikely to be effective.

BITNET mail is often handled through automatic mail servers located at
specific BITNET redistribution points.  Information as to which lists
are located where, and how to use them, should be available from your
BITNET administrator (I myself have no idea which, where, and how).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 88 02:01:20 GMT
From:      nittmann@rusvx1.rus.uni-stuttgart.dbp.de ("Michael F.H. Nittmann ")
To:        comp.protocols.tcp-ip
Subject:   historical defaults

This is a lengthy mail on echo no echo remote local etc. and telnet.
Perhaps You even do not need to read it.



Just to tell, I am fully aware of char. use of vi. But what vi needs is
not the remote echo but the single character TRANSMISSION. 
And this is just the point
I wanted to go to: why not use vi together with nfs, avoid those small char. 
sequences ( these are not the 1 char. echoes of course), and get a more secure
vi session since the buffer just being edited will survive network/host 
crashes due to the statelesness of nfs. The same holds for all fullscreen
editors and unix likes. Naturally there will be some VMS or so who will
really need character mode. Let's ask: who is the most important section.

Dynamic switching of modes is also already possible: I type escape ,mode
line, return, return to the session and I am in line mode. I can change
it back to character mode when I really need it (for a direct vi session).
To do it better on a defined special character basis is a very good 
extension, let's hope that the extension rfc will come in soon.

The  point I see is that agreed defaults 	
are never renegotiated and sessions that do not need these quasi default 
modes will run with them and waste resources. Doesn't this become even
more true when there is an extended option on negotiated special characters?
I would say that then even less sessions need to start in dont SGA.
And since special characters are negotiated there is no need for single
character mode of the sending NVT.    

With "agreed defaults" of course I do not only mean rfc854 defaults since
there is already line mode stated as default for a telnet client's NVT.

To order my imprecise formulation:
only those who really have a physical half duplex terminal should need a GA, 
not the Unix-likes nor VMS.
I agree that confusion would be too big in changing that particular 
- and rfc854 standardized - default since the GA is purely optional. 

But:
A standard developed - or let's call it an implementor's easyway, or
a sneeked in maniere - that telnet clients start in character mode, 
ask for remote echo and ping pong single characters between vaxes or suns, 
where by the way in line mode the line editing could 
be easily done locally and where NVT function codes pass. (the user has of course
to enter some stty statements in his .cshrc ,.login or dec/new into login.com
to get the editings done at the appropriate place and ctl c's 
understood on the other side)
Of course some telnet implementations are really clumsy in passing 
NVT function codes and do ask the poor user to enter the escape to return to 
the client's command level and enter some sort of 'send IP' or so.
People who have to use some of these should be able to go into the single
character transmission mode WITHOUT at the same time ask for a remote echo.

So perhaps I formulate it as a request to the developers: cannot we leave
alone  the agreed or sneeked in standard of starting in char. mode with
remote echo and return to rfc defined real standard at the start of a session. 
And when a user really needs a character per character 
transmission ( it is that what is needed for vi, not the remote echo  
) do just that but do not
always request at the same time a server's echo. Vi is a very good example
here since vi does not just an echo but a reply to the single character
entry : on some escape ...A it sends cursor control to put the cursor up,
dependent on the terminal type e.g. defined in .cshrc or login.com (for
edt/tpu). And if I type a colon I do not get a colon echoed in command mode
but my cursor is placed into the down left corner of the vi window and then my
colon and command are replicated ( to use this to distinguish it from mere
echo ). What is echoed at most is a rubout sequence for the already echoed
colon. So the vi case is even worse than everything You thought of: you
let remotely echo Your entered character and then vi comes and does a rubout
on it since we do not need that colon in the middle of the screen! Couldn't
such a rubout candidate be bought cheaper by local echo?
If You properly set up Your terminal definitions on both sides, vi will
work without the echo and know when to reply a character with itself echoed.



                     
I know I have a difficulty with writing clearly and simple so breath freely,
this is my last on that.
                      

Michael F.H. Nittmann 

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 88 02:07:27 GMT
From:      mkkam@wael.cs.uh.edu (Francis Kam)
To:        comp.sys.mac,comp.protocols.tcp-ip
Subject:   SLIP, telnet and ftp on Mac


I am trying to connect some of our Mac II's and SE's to a Sun network.
I am considering using SLIP then I don't have to buy ethercard for the
Mac's.  Does anyone know any public domain SLIP, telnet and ftp source
for Mac?  Or any supply source that sell them?

Please give me some hints.


-------------
Francis Kam                           Computer Science Department
Internet: mkkam@wael.cs.uh.edu        University of Houston
CSNET:    mkkam@houston.csnet         4800 Calhoun
Phone: (713)749-1748                  Houston, TX 77004.

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 88 03:40:36 GMT
From:      rlgvax!dennis@uunet.uu.net  (Dennis.Bednar)
To:        tcp-ip@sri-nic.arpa
Subject:   Some sub-net questions
Can someone please tell me which version of BSD
first supported sub-netting?

Does the Berkeley implementation follow the related
RFC's (917, 940, 950) closely, or does it deviate
in any manner?

Any other documentation besides the RFC's?

Thanks in advance.
-- 
FullName:	Dennis Bednar
UUCP:		{uunet|sundc}!rlgvax!dennis
USMail:		CCI; 11490 Commerce Park Dr.; Reston VA 22091
Telephone:	+1 703 648 3300
-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jun 88 8:54:07 EDT
From:      Alex McKenzie <mckenzie@LABS-N.BBN.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   ISO VTP
Based on comments received, I must not have expressed myself clearly.  I meant
to suggest that the community consider adopting the ISO VTP (or a subset) to
*replace* Telnet, not to simulate ISO VTP with a bunch of Telnet options.
Since the ISO VTP is intended to provide the mechanisms to dynamically define
which user input characters trigger transmission and suspend "local" echoing,
it seems to me we should look at that solution first (i.e., before the IETF
goes off to invent a new set of Telnet options to do a similar thing).

Alex
 
-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jun 88 13:08:50 CDT
From:      tucker%vger@xenurus.Gould.COM (Tim Tucker)
To:        TCP-IP@sri-nic.arpa
Subject:   NAMED and IP forwarding
>/* ---------- "NAMED and IP forwarding" ---------- */
>From tcp-ip-RELAY@SRI-NIC.ARPA  Wed Jun 29 12:35:41 1988
>Date: Wed, 29 Jun 88 07:43:04 MDT
>From: Capt Geoff Mulligan <geoff@usafa.ARPA>
>Subject: NAMED and IP forwarding
>
>2. Does anyone know if the 2.0 libraries are compiled to use the name
>server so that they will use resolver routines and the
>/etc/resolv.conf file?

No, Gould UTX2.0 doesn't include any name server support.

>
>3. How can I get my gould to act as an IP router?  I would like it to
>act as our gateway from a ethernet and a couple of slip hosts to the
>Milnet.
>
>	geoff

Gould's latest version of the UTX operating system for your machine supports
all of those things.  It includes a recent version of BIND, and support for
EGP thru the Cornell Gated program.

Tim Tucker
Gould Computer Systems Division
tucker@xenurus.Gould.COM		(Milnet)
..ihnp4!uiucdcs!urbsdc!tucker		(UUCP)
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 88 12:54:07 GMT
From:      mckenzie@LABS-N.BBN.COM (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   ISO VTP

Based on comments received, I must not have expressed myself clearly.  I meant
to suggest that the community consider adopting the ISO VTP (or a subset) to
*replace* Telnet, not to simulate ISO VTP with a bunch of Telnet options.
Since the ISO VTP is intended to provide the mechanisms to dynamically define
which user input characters trigger transmission and suspend "local" echoing,
it seems to me we should look at that solution first (i.e., before the IETF
goes off to invent a new set of Telnet options to do a similar thing).

Alex
 

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 88 13:43:04 GMT
From:      geoff@USAFA.ARPA (Capt Geoff Mulligan)
To:        comp.protocols.tcp-ip
Subject:   NAMED and IP forwarding

1. Why does gould not provide the bind name server?

2. Does anyone know if the 2.0 libraries are compiled to use the name
server so that they will use resolver routines and the
/etc/resolv.conf file?

3. How can I get my gould to act as an IP router?  I would like it to
act as our gateway from a ethernet and a couple of slip hosts to the
Milnet.

	geoff

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 88 14:53:19 GMT
From:      perry@PRC.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re:  ISO VTP

I think Alex's words are words we should strongly consider, just
as with network managment moving towards ISO, we should move Telnet
towards VTP.

dennis

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 88 15:04:38 GMT
From:      map@GAAK.LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   Domain name/subnet non-relationship.

How names are subdivided (with domain naming) and how networks are
sudivided (with subnetting) have no intrinsic relationship.  You are
free to apply a relationship if that is beneficial but no relationship
is required (or even implied) by the standards.  In fact one of the
subnets here has hosts with names in three (at least) different
domains and each of those domains exist on at least half a dozen
subnets.  The purpose of the hierarchical domain naming system is to
distribute the responsibility for assigning non-conflicting names, the
purpose of subnetting is to ease the design of routing protocols
internal to a single network.

	Mike Patton, Network Manager
	Laboratory for Computer Science
	Massachusetts Institute of Technology

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP.

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 88 19:03:34 GMT
From:      timon@sco.COM (timon)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   TLI transport specific addresses


		a puzzle for the net:

AT+T chose not to define an addressing scheme for their
TLI library.  Instead they require the user program to pass
to the transport a pointer to an undefined address structure.
This requires that the user program know what address structure
the transport is expecting, and therefore makes each user
program transport specific.

This seems to make their interface completely unportable.  They 
claim to have designed TLI to allow application programs to be 
completely independent of the transport.  I don't see how this 
can work if each and every user program must have hard-coded 
dependencies based on a particular transport's addressing scheme.

- Why did they fall short here (aside from being lazy)?  

- Is at+t working on a standard for this?  Is any other group/vender?

- Are standards/conventions emerging for particular transports 
  (tcp/ip, osi tp4, netbios)?


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Timon Sloane	
The Santa Cruz Operation		timon@sco.com
					{uunet | decvax!microsof}!sco!timon
					(408) 458-1422

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 88 20:04:23 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Telnet



Hi.

The Telnet defaults will not be changed. Not ever.

Additional Telnet Options are very likely.

--jon.

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 88 21:48:17 GMT
From:      pvm@VENERA.ISI.EDU (Paul Mockapetris)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain name/subnet non-relationship.

As many have pointed out there is no necessary correspondance between
the name of a host, mailbox, etc. and the subnet that the host's IP
address occupies.

However, in the IN-ADDR.ARPA domain, which is used to map from IP
addresses to host names, the name structure is constrained (by
convention, not technically), with each level of the name corresponding
to an octet of the IP address.  Since the names break at octet
boundaries, domains/zones can only break at octet boundaries, and thus
if you want to separately administer address assignment, its much
simpler if your subnet masks and octet boundaries correspond.  For class
C, this means you are out of luck.

paul

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 88 22:58:16 GMT
From:      neerma@COD.NOSC.MIL (Merle A. Neer)
To:        comp.protocols.tcp-ip
Subject:   Forwarded: questions on UDP broadcast

-------
Forwarded mail follows:
From neerma Wed Jun 29 13:44:49 1988
Date: Wed, 29 Jun 88 13:44:21 PDT
From: neerma (Merle A. Neer)
Message-Id: <8806292044.AA05975@cod.nosc.mil>
To: tcp-ip-relay@sri.nic.arpa
Cc: neerma
Subject: questions on UDP broadcast

Hi,

We're trying to develop server/clients on UDP to do
broadcast.  We are interested in hearing from anyone
with experience on UNIX or IBM AT using Network Research
FUSION package.

We would appreciate any help offered.

Thanks,

Merle Neer
neerma at nosc.mil
-------
-------


-------

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 88 01:46:50 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for comments on the 15-pin ethernet connector

> I'm so glad that others apart from myself are complaining about these
> stupid practices.  Maybe we'll actually see some action from the vendors
> on this one?

Don't hold your breath. Flushed with success in designing Ethernet
transceiver clips, they're now all busily bringing you OSI.

One feature I wish they had included in the Ethernet transceiver
connector is a remotely-triggerable disconnect, similar to the
explosively-driven bolt and cable cutters used on space launchers. (One
was featured in 2010 as HAL's "emergency pull".) I'd wire them all to a
big panel in my office. Then the next time somebody's broken host
software sends out a bogus broadcast packet, I'd turn the switch, and...

Phil

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 1988 13:31:06 CDT
From:      AFDDN.1973CG@GUNTER-ADAM.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Cc:        AFDDN.1973CG@GUNTER-ADAM.ARPA
Subject:   Hewlett-Packard Interfaces
To Anyone Who Knows,

   I'm looking for information on TCP/IP interfaces available for an
HP-3000 with MPE-IV.  I'd specifically like to know where I can get them
if available and what is required to support them interms of memory, disk,
etc.  Please respond to my mailbox directly since I'm not on the TCP-IP
mail list.
 
Thanks in advance,
John Wandelt
-------
-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 88 14:35:19 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  gateways and more-than-one-IP-net on one ethernet

Get rid of the Level 2 Bridge(s).  Put IP routers in their place.
Don't have two networks on the same LAN.  I define LAN as a network
of hosts all sharing the same network address.

phil wood (cpw@lanl.gov)

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 88 14:47:44 GMT
From:      geoff@USAFA.ARPA (Capt Geoff Mulligan)
To:        comp.protocols.tcp-ip
Subject:   NAMED and IP forwarding

What version of UTX is it that supports NAMED and IP forwarding?

	geoff

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 88 18:31:06 GMT
From:      AFDDN.1973CG@GUNTER-ADAM.ARPA
To:        comp.protocols.tcp-ip
Subject:   Hewlett-Packard Interfaces

To Anyone Who Knows,

   I'm looking for information on TCP/IP interfaces available for an
HP-3000 with MPE-IV.  I'd specifically like to know where I can get them
if available and what is required to support them interms of memory, disk,
etc.  Please respond to my mailbox directly since I'm not on the TCP-IP
mail list.
 
Thanks in advance,
John Wandelt
-------

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 88 21:03:51 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re:  gateways and more-than-one-IP-net on one ethernet

You should be able to handle reaching a gateway, on the same wire as you
but on a different (sub)network number, using the following awful kludge:

   Allocate a fake IP address on your own (sub)net for the remote gateway.
   On the local machine:  arp -s fake-gw-address gateway-Ether-address perm
   On the local machine:  route add  destination-net  fake-gw-address  1

and hope the "permanent" arp is never purged from the cache.

END OF DOCUMENT