World of Ham Radio 1994 January/AMSOFT_1994.iso/packet/docs/pd198702.doc

Text File | 1993-12-31 | 33.3 KB | 733 lines

7-Feb-87 05:14:10-EST,1166;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Feb 87 05:14-EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA15584; Sat, 7 Feb 87 02:54:42 EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA15556; Sat, 7 Feb 87 02:53:23 EST
Date: Fri, 6 Feb 1987  23:44 MST
Message-Id: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To: [e-mail], [e-mail]
Subject: New Info-Modems mailing list

Announcing a new Internet mailing list [e-mail], a
discussion group of special interest to modem users.  Info-Modems is
gatewayed to/from Uucp's "comp.dcom.modems".

The mail archives on SIMTEL20 for this list are:

<ARCHIVES.MODEMS>MODEMS-ARCHIV.TXT  for the current messages

<ARCHIVES.MODEMS>MODEMS.ARCHIV.ymmdd  for the older messages

The files are available via ANONYMOUS FTP for those with TCP/IP access
to the Internet.

Submissions to the group should be addressed to [e-mail]
and administrative requests to [e-mail].

--Keith Petersen <[e-mail]>
 8-Feb-87 12:43:08-EST,1169;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 8 Feb 87 12:43-EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA14982; Sun, 8 Feb 87 12:05:04 EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA14972; Sun, 8 Feb 87 12:04:43 EST
Resent-Message-Id: <[e-mail]>
Date: Saturday, 31 January 1987  14:17-MST
Message-Id: <[e-mail]>
Sender: [e-mail]
From: [e-mail]
To: [e-mail]
Subject:   WA7MBL Version 3.12 of the Packet Bulletin Board System
Resent-From: [e-mail]
Resent-To: [e-mail]
Resent-Date: Sun 8 Feb 1987 10:01-MST

Version 3.12 of the WA7MBL Packet Board System for MS/PCDOS, is now
available from SIMTEL20 as:

Filename                        Type     Bytes   CRC

Directory PD:<MSDOS.PACKET>
BBS31DOC.ARC.1                  BINARY   50295  AAE8H
BBS31HLP.ARC.1                  BINARY   10413  74EEH
BBS31PT1.ARC.1                  BINARY  128373  55DBH
BBS31PT2.ARC.1                  BINARY  110933  9DA3H

The original BBS312.ARC was so big (about 412,000 bytes when
UUENCODED) that I split it into four to make it easier to handle on
the net.

73,
Bob
11-Feb-87 05:41:40-EST,19216;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Feb 87 05:41-EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA27796; Wed, 11 Feb 87 01:57:09 EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA27786; Wed, 11 Feb 87 01:56:31 EST
Received: from enea.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
    id AA21941; Wed, 11 Feb 87 01:54:32 EST
Received: by enea.UUCP (5.51/UUCP-Project/rel-1.0/1.15)
    id AA12826; Wed, 11 Feb 87 01:51:05 +0100 (MET)
Received: by kuling.UUCP; Tue, 10 Feb 87 18:10:09 -0100
Message-Id: <[e-mail]>
To: [e-mail]
Receive-Receipt-To: [e-mail]
Subject: Gateway no 12, volume 3.
Date: 10 Feb 87 18:10:05 N (Tue)
From: Anders Klemets <enea!kuling![e-mail]>

Gateway: The ARRL Packet-Radio Newsletter
     Volume 3, Number 12, February 6, 1987

Published by:
     The American Radio Relay League
     225 Main Street
     Newington, CT  06111

Editors:
     Jon Bloom, KE3Z
     Bruce Hale, KB1MW



For several years the concepts of higher-level protocols have been
discussed within the packet community.  In this issue of Gateway, we
discuss two of the several efforts underway that implement higher-level
protocols for packet radio.


NET/ROM: BEYOND THE DIGIPEATER

The W6AMT network of digipeaters in California is testing a new firmware
program for the TNC 2.  Called "NET/ROM," the new firmware supports
networking capabilities (commonly referred to in packet-radio circles as
"layer three" and "layer four").  At the moment, the system is in alpha
(initial) testing, with beta testing to follow within a few weeks.  A
release version of the firmware ROM is expected in March.

Developed by Ron Raikes, WA8DED, and Mike Busch, W6IXU, of Software
2000, Inc, NET/ROM is unique because it provides networking capabilities
without the need for special hardware.  NET/ROM runs on a standard TAPR
TNC 2 terminal node controller, or on any of the commercially available
TNC-2 "clones."  NET/ROM is distributed in the form of a 27C256 EPROM
which simply plugs into the ROM socket of the TNC 2 in place of the
standard TAPR firmware ROM.  NET/ROM is intended for use primarily at
wide-coverage digipeater sites.  It is not appropriate for end-user or
mailbox stations.

A NET/ROM node provides the normal functions of an ordinary AX.25
digipeater, plus a set of sophisticated higher-level networking
capabilities.  A NET/ROM node user may display a list of other known
network nodes; establish a transport-level circuit to a distant node;
and connect to another end-user or mailbox in the vicinity of the
distant node.  Compared with conventional AX.25 multi-hop digipeating,
NET/ROM's true store-and-forward packet switching technology can provide
an order-of-magnitude improvement in throughput, especially over long
paths.  Routing from the local node to the distant node is handled
automatically, and even includes alternate routing to circumvent network
outages.

NET/ROM supports cross-frequency and cross-band networking without the
need for exotic multiport digipeater hardware.  A dual-channel node, for
example, is implemented simply by installing NET/ROM in a pair of
standard TNC 2s and connecting them together with an RS-232-C cable.  A
three- or four-channel node can be created by connecting multiple TNC 2s
together, using a simple diode-matrix coupler.

NET/ROM uses the standard AX.25v2 packet radio protocol for links
between neighboring nodes, as well as for links from each node to its
local users.  Normal AX.25v2 error handling is used to assure error-free
transmission, and normal AX.25v2 flow control is used to manage network
congestion.  In addition, NET/ROM incorporates a transport-level
"sliding window protocol" to provide end-to-end error and flow control
for each virtual circuit.  End-to-end error control protects against
lost, duplicate, or out-of-sequence frames resulting from node failures
and dynamic routing changes.  End-to-end flow control protects the
network against disproportionate loading by any one circuit.

The transport-level protocol used by NET/ROM is similar in concept to
the familiar AX.25, but is somewhat more sophisticated.  For example, it
can accept out-of-sequence frames and re-sequence them internally.  It
can also selectively request a repeat of a missing frame without
requiring retransmission of all succeeding frames.

NET/ROM automatically takes care of the routing of traffic between one
node and another.  A user needs to specify just the desired destination,
not the route.  Each node keeps track of the other nodes in the network
and the various possible paths that may be used to reach them.  If a
node or path becomes unusable due to equipment failure or poor
propagation, NET/ROM automatically switches to an alternate route (if
available) to circumvent the outage.  Conversely, when a new node is
placed on-line, other nodes automatically incorporate the new node into
the network routing structure.  Such routing changes are handled
dynamically, without disrupting user connections in progress.

NET/ROM supports three methods of updating its routing information:
local, remote and automatic.  Initial routing information is entered
manually by an on-site operator using a local terminal.  Routing changes
may be made remotely by a control operator over an ordinary packet radio
connection--a randomized verification algorithm effectively prevents
changes by unauthorized operators.  In addition, NET/ROM nodes transmit
routing information to each other on an hourly basis, thereby enabling
the network to incorporate new nodes and to bypass outages in real-time
without manual intervention.

Despite its internal sophistication and advanced networking
capabilities, NET/ROM is exceptionally easy to use.  There are only two
commands that a user needs to learn: NODES to obtain a list of other
NET/ROM nodes, and CONNECT to establish cross links to other nodes or
downlinks to other user stations.

A Usage Example

You are KA6PRE ("Packet Radio Enthusiast") located in San Diego, and you
want to access the W0RLI bulletin board system in Santa Cruz (near San
Francisco).  From past experience, you know that a digipeated AX.25
connection requires four digipeaters and is practically unusable.  The
local W6AMT-4 digipeater on 145.01 was recently upgraded to a NET/ROM
node, however, so this time you decide to try using the high-tech
method.

First, you establish an uplink to your local node, using the normal
connect command provided by your TNC:

     cmd: CONNECT W6AMT-4
     *** CONNECTED to W6AMT-4

Next, you ask the local node for a list of other NET/ROM nodes for which
it has routing information, using the NODES command:

     NODES
     W6AMT-4 Nodes:
     W6AMT-3 W6AMT-2 W6AMT-1 W6AMT W6AMT-7 AA6TN-1

You know that W6AMT-0 serves the San Francisco area (it was always the
last digipeater you used to reach W0RLI via AX.25), so you ask your
local NET/ROM node to connect you to W6AMT:

     CONNECT W6AMT
     W6AMT-4 Connected to W6AMT

You are now talking to the San Francisco node, and you could issue
another NODES command to see a list of other nodes that it knows how to
reach.  In this case, however, you simply want a connection to the W0RLI
BBS, so you ask for it:

     CONNECT W0RLI
     W6AMT Connected to W0RLI
     Hello Fred, welcome to W0RLI BBS at 0532z
     KA6PRE-15 de W0RLI>
     etc.

Note that the downlink from W6AMT to W0RLI has been made using your call
sign (KA6PRE), but with the SSID suffix changed from -0 to -15.  The
downlinking node "adopts" your call sign, so that the connected station
recognizes that you are connected, rather than the NET/ROM node.  The
SSID (the "-N" suffix) must be changed, however; if there also happened
to be a direct path (however marginal) between your station and the
destination station, that station would then be "in range" of two
stations using the same call sign.  This can create serious confusion
for stations using AX.25 protocol!  To avoid this problem, the
downlinking node adopts your basic call sign, but changes the SSID from
N to 15-N.  For example, if your call sign is K6AAA, the downlink uses
K6AAA-15; if your call sign is W3ABC-2, the downlink uses W3ABC-13; and
so forth.

At the conclusion of your session with W0RLI BBS, you simply disconnect
your TNC as usual:

     ^C
     cmd: DISC
     *** DISCONNECTED

When you disconnect, your local node (W6AMT-4) automatically disconnects
your circuit to W6AMT, and the W6AMT node automatically disconnects your
downlink to W0RLI.

Digipeating vs Store-and-Forward

The AX.25 protocol was originally designed for point-to-point
(nondigipeated) connections.  AX.25 was subsequently extended to
accommodate one digipeater, and later extended again to allow up to
eight digipeaters.

As all experienced packet-radio users know, however, AX.25 is
practically unusable for communications on paths exceeding two or three
"hops."  This is because AX.25 digipeaters do not participate in error
control.  If an AX.25 packet traversing a multihop path falls victim to
a collision or other error during any of the hops, it must be
retransmitted by the originating station and start its journey all over
again.

The probability that an AX.25 packet can complete its journey
successfully deteriorates rapidly as the number of hops increases.
Using NET/ROM nodes instead of ordinary AX.25 digipeaters changes this
situation dramatically for the better.  When a node user transmits a
packet, the receiving node sends the packet to the next node in the path
and sends an acknowledgement back to the user.  This process is repeated
as many times as there are nodes in the path.  Whenever a packet is lost
due to collision or other error, recovery is handled by just the two
adjacent nodes involved.

Network Routing

When you ask one node for a circuit to a distant node, your CONNECT
command specifies the call sign of the destination node, but the routing
is handled automatically by NET/ROM.  Automatic routing is handled by
the Routing Manager, and is controlled by its routing table.

The routing table within a node is a list of all the destination nodes
"known" to this node.  You can ask to see this list by using a
parameterless NODES command.  The routing table can keep track of a
relatively large number of other nodes.

If you want to connect to an especially distant node, and your local
node doesn't know of it (it is not listed in the local NODES display),
you can use CONNECT to obtain a circuit to a known node nearer the
desired destination, and then issue another NODES command to get a list
of the nodes known to that node.  This process can be repeated if
necessary.

For each known node, the routing table contains one or more known routes
to that node.  In this case, a "route" is simply a crosslink path to an
adjacent node that is closer to the ultimate destination.  The crosslink
path usually consists of just the call sign of the adjacent node, but
may also include one or more digipeaters if necessary.

The routing table does not contain the entire route to each known
destination (this is unnecessary, and would require too much memory),
but just a list of adjacent nodes that are reasonable choices for a next
hop enroute to the destination.  You can ask to see this list by using a
NODES command specifying the call sign of the destination.

If a node or path becomes unusable due to equipment failure or poor
propagation, the Routing Manager automatically switches to an alternate
route (if available) to circumvent the outage.  Such routing changes are
handled dynamically, usually without disrupting circuits in progress.

Limitations

The following limits apply to the alpha-test version of NET/ROM, and
will probably be increased (possibly doubled) in the final release
version:
     Maximum number of links per node: 20
     Maximum number of circuits per node: 16
     Maximum number of other known nodes: 32
     Maximum number of command interpreter tasks: 8

     From Software 2000, Inc, via DRNET


NET.EXE: BEYOND THE TNC

Another approach to the implementation of higher-level protocols is that
taken by Phil Karn, KA9Q, in his NET.EXE program for the IBM PC.  The
basic philosophy behind Phil's approach has been espoused before (see
Gateway, Volume 3, Number 2, "WHY DO WE EVEN NEED TNCS").  Essentially,
Phil argues that there is no need to tie ourselves down to the AX.25
link layer protocol when a layer-four (transport) protocol is operating
to ensure end-to-end data integrity.  Phil's approach, as embodied in
his NET.EXE program, allows several possible link-layer protocols
(including AX.25).

NET.EXE executes the Defense Advanced Research Projects Agency (DARPA)
suite of protocols.  Included in these are IP, the Internet Protocol;
TCP, the Transmission Control Protocol; ARP, the Address Resolution
Protocol; FTP, the File Transfer Protocol and SMTP, the Simple Mail
Transfer Protocol.  All of these are above the link layer in the
hierarchy of protocols.  At the link layer, NET.EXE supports simple
serial data transfer via SLIP, the Serial Line Interface Protocol, and
non-protocol serial I/O.  Connection to an Ethernet coaxial-cable LAN is
supported via a 3Com Ethernet interface adapter.  Several IBM PC packet-
radio adapters are also supported.

For packet-radio operation, the most common link-layer technique used
with NET.EXE today is attachment of a standard TNC.  Although a TNC with
standard firmware may be used by establishing a connection in the
transparent mode, this is not optimal.  A replacement firmware program
has been developed by Mike Chepponis, K3MC.  This firmware, called KISS
(after the well-known design rule: keep it simple, stupid!), does not
support AX.25 link-layer connections.  Rather, it simply accepts serial
data from the computer using the SLIP protocol and transmits the data as
AX.25 UI frames.  Received AX.25 frames are sent to the computer
directly, again using SLIP.  Thus NET.EXE, not the TNC, is the entity
that deals with the various fields of the AX.25 frames.  For
applications that require error-free data transfer, the transport
protocol (TCP) provides such a service.  Connections at the link layer,
by the TNC, are not needed and not supported.

IP provides the basic network-layer services, with ARP acting to map
local addresses (e.g AX.25 call sign and SSID) to the address format
used by IP.  At present, routing of IP datagrams (a datagram is the
basic "packet" of IP) is performed using manually-generated tables.  IP
also provides an option by which the computer that initiates
transmission of a packet can specify the entire routing, much as we do
with digipeaters today.  But the IP device's capability to determine the
next "hop" via its internal routing tables that is more attractive for
packet radio use.  TCP is used to provide end-to-end data integrity.
Since TCP can support multiple connections, NET.EXE is written to allow
as many TCP connections as the computer's memory will support.

The link-layer device(s), IP and TCP provide the basic communications
capability, but there is more to NET.EXE than that.  Atop the
communications package sit the applications.  These are provided as
"client" and "server" processes.  A client process is one that requests
a service which is provided by a server.  For example, when two
computers running NET.EXE are in communication, the operator of one can
invoke the FTP client in order to transfer a file to or from the other
computer.  The FTP client will call the FTP server at the remote
computer.  By entering a command, the operator then requests of his FTP
client that is act in concert with the FTP server to perform the file
transfer.  Specifically, FTP allows you to send a file to or receive a
file from the remote computer.  The file may comprise any type of data,
since the TCP connections are data transparent.  Using FTP, you can also
ask the remote computer to send its disk directory for your perusal.

TELNET is a terminal access protocol.  Although it was originally
designed for use in applications in which a terminal was logging onto a
host computer, it is general in nature.  It's included in NET.EXE to
provide a terminal-to-terminal mode for operator chats.

SMTP is the protocol that handles store-and-forward messages in NET.EXE.
The client half of SMTP is used to enter a message, which is stored on
disk.  At intervals, the client will connect to the SMTP servers of
remote computers and send the stored messages.  If this sounds vaguely
reminiscent of a packet BBS, it should; both systems, the BBS and SMTP,
are doing essentially the same job, although in a slightly different
manner.

One of the most interesting aspects of the NET.EXE system is that it can
do more than one job concurrently.  Recall that TCP, which is used to
provide end-to-end data integrity, can support multiple connections.
This is also true of the various client and server processes.  So you
could, for example, initiate a file transfer to another computer using
FTP, and while that transfer is taking place you can chat with the
operator of the remote computer using TELNET.  Or perhaps chat with the
operator of a different remote computer.  Or receive forwarded mail.  Or
receive a file.  Or...  (You get the idea.)

Earlier I stated that TCP is used when error-free communications are
required.  We are used to thinking of packet as being the "error free"
mode.  Indeed, it is that aspect of packet that attracted many of us to
it.  Reception of the transmitted data absolutely without error is not
always necessary, however.  Applications such as digitized voice or
video may not require that all of the data be received correctly as long
as most of it is.  In this case, the additional overhead of end-to-end
acknowledgments can become more of a burden than the occasional loss of
data.  For such applications, NET.EXE provides UDP, the User Datagram
Protocol.  This protocol lets an application program use the
communications capability provided by IP and the link layer, but does
not verify that the data is received correctly and completely the way
TCP does.

Since the protocols used by NET.EXE are widely used standards, the
program has potential for uses beyond packet radio, and some of its
features (such as the Ethernet interface) were included with this in
mind.  The program is still under development, so you can expect even
more capability soon!

     By KE3Z


REPRODUCTION OF GATEWAY MATERIAL

Material may be excerpted from Gateway without prior permission,
provided that the original contributor is credited and Gateway is
identified as the source.

--
    [e-mail] (...!{seismo,mcvax}!enea!kuling!klemets)
    Anders Klemets, Sikvagen 51, S-135 41 Tyreso, Sweden
    Phone: [phone]
    Packet: SM0RGV @ SK0TM
15-Feb-87 23:16:49-EST,1246;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Feb 87 23:16-EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA06074; Sun, 15 Feb 87 21:56:06 EST
Path: mit-eddie!rutgers!princeton!allegra!ulysses!gamma!zeta!sabre!faline!karn
From: [e-mail]
To: [e-mail]
Subject: Re: Packet Radio Layer 3/4 Test
Summary: NET/ROM is pure Virtual Circuits
Message-Id: <[e-mail]>
Date: 4 Feb 87 01:33:51 GMT
References: <[e-mail]>
Organization: Bell Communications Research, Inc
Lines: 14

As far as I can tell from the documentation, NET/ROM is a pure virtual
circuit switch. It uses AX.25 in the connected mode for the link layer,
and a homegrown connection-oriented protocol for the "edge-to-edge"
layer. I believe their use of the term "transport protocol" (aka
"Level 4") to describe this layer is incorrect, since transport protocols
are, by definition, END-TO-END.  Unless it runs on the end user's system,
it's NOT a transport protocol.

There is no mention of IP/TCP anywhere in NET/ROM.  If we are to use it
in its present form for Internetting, it'll be by "nailing up" virtual
circuits and running SLIP across them.  Crude, but they leave us no
choice...

Phil


15-Feb-87 23:33:46-EST,1246;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Feb 87 23:33-EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA06074; Sun, 15 Feb 87 21:56:06 EST
Path: mit-eddie!rutgers!princeton!allegra!ulysses!gamma!zeta!sabre!faline!karn
From: [e-mail]
To: [e-mail]
Subject: Re: Packet Radio Layer 3/4 Test
Summary: NET/ROM is pure Virtual Circuits
Message-Id: <[e-mail]>
Date: 4 Feb 87 01:33:51 GMT
References: <[e-mail]>
Organization: Bell Communications Research, Inc
Lines: 14

As far as I can tell from the documentation, NET/ROM is a pure virtual
circuit switch. It uses AX.25 in the connected mode for the link layer,
and a homegrown connection-oriented protocol for the "edge-to-edge"
layer. I believe their use of the term "transport protocol" (aka
"Level 4") to describe this layer is incorrect, since transport protocols
are, by definition, END-TO-END.  Unless it runs on the end user's system,
it's NOT a transport protocol.

There is no mention of IP/TCP anywhere in NET/ROM.  If we are to use it
in its present form for Internetting, it'll be by "nailing up" virtual
circuits and running SLIP across them.  Crude, but they leave us no
choice...

Phil


17-Feb-87 19:07:53-EST,1632;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Feb 87 19:07-EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA11546; Tue, 17 Feb 87 16:21:34 EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA11473; Tue, 17 Feb 87 16:19:36 EST
Message-Id: <[e-mail]>
Date: Tue, 17 Feb 87 16:13:14 EST
From: Bob Clements <[e-mail]>
Subject: W0RLI MailBox Followup
To: [e-mail]
Cc: [e-mail]

[]

NO NO NO NO NO NO I do NOT distribute the C version of the W0RLI BBS!

Sorry to bother the net with this again, but I can't seem to
get answers back through the mail plumbing to some of the
requestors.

I posted a message a few weeks ago about the new versions of the
W0RLI MailBox/GateWay being available at SIMTEL20.

In that message, I said I am NOT a distribution point for the C-language
version of the code (the one that runs on the IBMPC).  I here repeat
that statement.

I also asked for someone to volunteer to move new releases of the C
version from CompuServe to SIMTEL, since I am not a CompuServe
subscriber.  As far as I know, nobody has taken up that task.

I also got the usual requests for how to get to simtel by dial-up,
by usenet, by bitnet, etc.   Sorry, I don't know.  Is no my job.

Sheesh.

There. Now I've got that out of my system. Thank you for your
indulgence.  Now I'll go back to being my cheery self.

And to the guys who sent me floppies in the mail
for the 820 version, they are in the mail on the way back as of
Monday evening. I was out of town for a while; sorry for the delay.

73, Bob, K1BC

21-Feb-87 22:12:41-EST,1249;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Feb 87 22:12-EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA09374; Sat, 21 Feb 87 20:57:37 EST
Path: mit-eddie!rutgers!princeton!allegra!ulysses!faline!karn
From: allegra!ulysses!faline![e-mail]
To: [e-mail]
Subject: January 1987 IEEE Proceedings
Keywords: Devoted to packet radio
Message-Id: <[e-mail]>
Date: 18 Feb 87 21:47:17 GMT
Organization: Bell Communications Research, Inc
Lines: 18

The January 1987 issue of the Proceedings of the IEEE is devoted entirely
to packet radio networks.  Here are the article titles:

Issues in Packet Radio Network Design
The DARPA Packet Radio Network Protocols
The Low-Cost Packet Radio
The Application of Packet Switching Techniques to Combat Net Radio
A Design Concept for Reliable Mobile Radio Networks with Frequency
  Hopping Signaling
Crosslink Architectures for a Multiple Satellite System
Future Directions in Packet Radio Architectures and Protocols
Wide-Band Packet Radio Technology
The Role of Spread Spectrum in Packet Radio Networks
Modeling and Performance Analysis of Multihop Packet Radio Networks
Spatial Reuse in Multihop Packet Radio Networks


Phil


22-Feb-87 16:23:44-EST,1008;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Feb 87 16:23-EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA22182; Sun, 22 Feb 87 14:06:51 EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA22118; Sun, 22 Feb 87 13:59:39 EST
Received: from phun.riacs.edu by icarus.riacs.edu (5.51/1.9G)
       id AA09251; Sun, 22 Feb 87 10:57:02 PST
Received: from localhost by phun.riacs.edu (1.1/1.9N)
       id AA29641; Sun, 22 Feb 87 10:56:57 PST
Message-Id: <[e-mail]>
To: allegra!ulysses!faline![e-mail]
Cc: [e-mail]
Subject: Re: January 1987 IEEE Proceedings
In-Reply-To: Your message of 18 Feb 87 21:47:17 +0000.
         <[e-mail]>
Date: Sun, 22 Feb 87 10:56:52 -0800
From: [e-mail]

I must apologize for the lack of an article on amateur or commercial
packet radio.  That was not by intent.  Rather, it was due to a
particularly bad turn of events having to do with the invited author.

Barry

----------
26-Feb-87 16:08:23-EST,1362;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 Feb 87 16:08-EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA28508; Thu, 26 Feb 87 13:15:30 EST
Path: mit-eddie!rutgers!sri-unix!hplabs!decwrl!pyramid!prls!philabs!sbcs!root
From: [e-mail] (Root)
To: [e-mail]
Subject: KA9Q IP/TCP package on Amiga
Message-Id: <[e-mail]>
Date: 22 Feb 87 02:45:41 GMT
Organization: Computer Science Dept, SUNY@Stony Brook
Lines: 18

I am working on a port of Phil's IP/TCP package to the Commodore Amiga.  The
questions for now are:

    1) When I make changes/bug fixes/enhancements to the base package, to
       whom do I send the modifications?

    2) To "pretty up" the package for the Amiga, I will most probably have
       to make substantial deviations in the current architecture of
       "net.exe".  Is user interface/library compatibility between
       the M(ES)S-DOS version and the Amiga version important?  The
       current library interface of upcalls, etc seems useable enough,
       but it is my feeling that folks would rather link against Berkeley
       IPC primitives rather than switch to the current interface.

    3) I am planning implementation of RIP, RARP, and possibly RDP.  Has
       any tackled these (but not released the changes) in Phil's package ?

                        Rick Spanbauer


26-Feb-87 16:28:16-EST,2745;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 Feb 87 16:28-EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA28576; Thu, 26 Feb 87 13:19:44 EST
Path: mit-eddie!genrad!decvax!tektronix!tekcrl!vice!tekfdi!mhorne
From: [e-mail] (Mike Horne)
To: [e-mail]
Subject: Re: KISS TNC Functional Spec
Message-Id: <[e-mail]>
Date: 23 Feb 87 07:03:11 GMT
Reply-To: [e-mail] (Mike Horne)
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 42

Phil (and net-landers),

I read with great interest about your/the "Proposed 'Raw' TNC Functional Spec"
that you posted to rec.ham-radio.packet.  I am very interested in your work
and would like to find out a little bit more information.

1)      I have heard that you have implemented some sort of TCP/IP interface
    for the IBM PC, or something along this line.  Is the source available?
    And if so, how portable is it (assuming you have written it in C)?
    I would like to look at the code to learn more about this topic,
    if possible.

2)      I tend to agree in principle that the answer lies in freeing up the
    TNC hardware and having a host 'do the dirty work'.  Has this been
    done with a TNC2 yet?  I like to think that it has, since the TCP/IP
    software is out there.  If it has been done, is the firmware readily
    available?  Given sufficient info about the hardware layout of the
    TNC2, I'm sure I could tackle the job, but I don't want to re-invent
    the wheel.

3)      In taking this idea one step further, has anyone given much thought
    to creating a multi-channel 'dumb' TNC?  I can see the power in
    a TNC board with multiple HDLC I/O ports driven by one host computer
    to allow cross porting, etc.  When I say 'anyone given much thought',
    I am not refering to the Pac-Com dual port digis or the like.  I have
    contemplated implementing a multi-port async to HDLC converter using
    a [68000 | 68008] and 2 or 3 Zilog 8530s, giving 3 to 5 (+1 for async)
    ports for I/O.  One very nice application could be a multichannel/multi-
    user bbs.  Other applications could include multi-port digipeaters,
    etc.  I would appreciate any comments on this idea.

This 'raw TNC' approach seems to be a viable alternative to the current
implementation of the 'do everything but the dishes' TNC interface.  Any
net-landers have comments/suggestions on this topic?

Mike.

------------------------------------------------------------------------
 Michael Horne - KA7AXD              FDI group, Tektronix, Incorporated
 INTERNET: [e-mail]
 CSNET:    [e-mail]@csnet-relay.csnet
 UUCP:     {decvax,hplabs,hp-cd,reed,uw-beaver}!tektronix!tekfdi!mhorne


27-Feb-87 12:22:12-EST,1000;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Feb 87 12:22-EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA20917; Fri, 27 Feb 87 08:38:14 EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA20903; Fri, 27 Feb 87 08:37:42 EST
Resent-Message-Id: <[e-mail]>
Date: Thursday, 26 February 1987  22:35-MST
Message-Id: <[e-mail]>
Sender: [e-mail] (Carl Service)
From: [e-mail] (Carl Service)
To: [e-mail]
Subject:   Arthur Collins - W0CXX - Silent Key
Resent-From: [e-mail]
Resent-To: [e-mail]
Resent-Date: Fri 27 Feb 1987 06:30-MST

With great sadness I report the passing of a great American
communicator, a man who's name became synonymous with excellence..



                   Arthur A. Collins


                    W0CXX


            September 9, 1909  - February 25, 1987
27-Feb-87 15:13:35-EST,550;000000000000
Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Feb 87 15:13-EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA26481; Fri, 27 Feb 87 13:08:22 EST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA26455; Fri, 27 Feb 87 13:07:31 EST
Message-Id: <[e-mail]>
Date: 27 Feb 87 12:49 EST
From: Crawford@DCA-EMS
Subject: tnc-220
To: [e-mail]

anyone out there got a tnc-220 up and running from a kit?
anything worthwile to pass along about lessons learned or
problems solved?
on8ua  k7upj