Date: Sat, 6 Mar 93 04:30:03 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #62
To: tcp-group-digest
TCP-Group Digest Sat, 6 Mar 93 Volume 93 : Issue 62
Today's Topics:
64-bit address plan
Ham-Oriented Lists at Listserv@Knuth.MTSU.edu
hidden transmitter routing (2 msgs)
In-Reply-To: Re: Link Layer replacement
Link Layer replacement
New mailing list for discussion of new packet radio layers, etc.
New WAMPES version
subscribe tcp-group
TCP/IP -- more than just mild!
vadcg
Where do we go from here?
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Thu, 4 Mar 93 15:26:10 EDT
From: "William Allen Simpson" <bill.simpson@um.cc.umich.edu>
Subject: 64-bit address plan
To: tcp-group@ucsd.edu
Seems to be a 3-4 day turn-around to the list.
> From: Steve Sampson <ssampson@sabea-oc.af.mil>
> can rob from the ethernet router designs to finish it off. Here's an idea
> for a static address design:
>
Actually, there is already an address plan like this, call Metro Based.
It was developed by Steve Deering at Xerox PARC for SIP (son of IP, or
Steve's IP). It's for the future IP work going on right now in the IETF.
He did a bit better job at packing, so the entire world is routed in
just 16 bits of the 64-bit address, with variable bit boundaries.
Country & Metro 2 Octets
Network ID: 4 Octets
Subnet ID: 1 Octet
Host ID: 1 Octet
There will be a KA9Q/NOS implementation. A fellow at Sun is working on
it right now.
The entire country by country list is a bit too big to send to the
entire list.
Here's my version of the Continental plan (called BIP for Bill's IP),
just to give you an idea.
BIP Continental Allocation Plan
fraction of
allocation prefix (binary) addr. space
----------------------------------- ------------------- -----------
reserved IP4 C000 0000 1/128
reserved for future use C000 0001 1/128
reserved for future use C000 001 1/64
North Eurasia C000 01 1/32
Europe C000 1 1/16
Africa C001 1/8
South West Asia C01 1/4
South East Asia C10 1/4
South Pacific & Antarctica C110 0 1/16
North America C110 1 1/16
South America C111 0 1/16
Central America & Carribean C111 10 1/32
reserved for future use C111 110 1/64
reserved for future use C111 1110 1/128
multicast C111 1111 1/128
C = IP4 compatibility prefix
Country, Provider and Metropolitan Area based allocations are made
within the Continents.
The reserved portions may be used as needed for other bodies within
the local solar system, or to augment other special uses.
Bill.Simpson@um.cc.umich.edu
------------------------------
Date: 5 Mar 93 15:18:06 GMT
From: ggjns@knuth.mtsu.edu (John Schmidt)
Subject: Ham-Oriented Lists at Listserv@Knuth.MTSU.edu
To: tcp-group@ucsd.edu
We would like to remind you of several mailing lists available from our
site which are oriented towards amateur radio, especially packet radio.
Your subscription requests should be sent to "LISTSERV@KNUTH.MTSU.EDU"
via E-mail with a blank subject line and a body beginning in column one
such as:
subscribe <list_name> <your_name>
Other commands of use would be:
help
index
subscribers <list_name>
Amateur-oriented (unmoderated) discussion lists are:
TENNET-L: High Speed Wireless Packet Networking using TCP/IP
for statewide coverage in Tennessee
GRACILIS-L: Discussions about Packet Radio using this manufacturer's
equipment, firmware, development trends
GRAPES-L: Discussions about the "Georgia Radio Amateur Packet
Enthusiasts Society", their high-speed network/backbone
system, and the WA4DSY 56Kbps RF Modem
TNV-HAMS: Ham Radio in general in the Tennessee Valley
All hams in/around Tennessee are welcome!
KA9Q-UNIX: Users/ports of KA9Q TCP/IP packet system under any of
the various flavors of Unix/Xenix/Linux (also including
WAMPES under Unix)
For those of us directly on the Internet, one can telnet to port 372 on
knuth.mtsu.edu (IP Address 161.45.1.1:372) and can interactively get
help, subscribe/unsubscribe, etc. with the listserver (using IULP-proposed
protocol). Check these lists out!
73!
John
John N Schmidt KD4EAI, Lab Director + 615-898-5561 M-F 1300-2230Z <7-4:30>
Middle Tennessee State University ++ 615-898-5538 or 615-896-2871 FAX 24H
1500 Greenland Drive, PO Box 135 +x+ ggjns@Knuth.MTSU.edu via the Internet
Murfreesboro, TN 37132-0135 USA +xx+ MTSU Center for Remote Sensing and GIS
AX.25-TCP/IP Adr [44.34.50.50] +xxx+ Home of Packet/Internet gateway W4EFQ
------------------------------
Date: Fri, 5 Mar 93 10:03:28 PST
From: jackb@mdd.comm.mot.com (Jack Brindle)
Subject: hidden transmitter routing
To: tcp-group@ucsd.edu, bsimpson@morningstar.com
>> 2. A protocol for multiple access. This one has to be designed
>> with the hidden transmitter problem in mind. It also has to allow
>> for stuffing into the ROM on a TNC2. While we can change the
>> protocol, the large user community will not yet throw away their
>> TNCs (remember P.O.T.S.). Rates are 1200 and up at VHF/UHF.
>>
>This is really a routing problem. RSPF is the right direction to go.
>
>You don't need a separate protocol for this, you just run it on top of IP.
Actually this is a MAC problem that is resolved by going to split frequency
operation with a central hub node / repeater. In fact most, if not all, of the
hidden transmitter problems go away with split-frequency repeater operations.
The commercial folks learned this a long time ago, as did many hams.
I would further venture that no protocol at any layer above physical would
resolve hidden transmitter problems. If you cannot hear the control protocol
transmissions, there is no way to respond to them.
While we are on the subject of the physical layer and MAC, It would seem that
this is the place we have the most to gain. The single biggest time waster is
the key-up delay caused by the necessity for contention algorithms. We spend
seconds making sure that an already clear channel is really clear before the
tnc will key up and transmit. Of course, once the key up decision is made and
committed, we are blind to anyone else coming on channel and colliding. The
problems here are:
1) Inability to listen while transmitting due to single channel tx/rx.
2) Amount of time required to go from receive to full transmit (we are blind
during this time also)
3) Need to make absolutely sure the channel is clear; we wait at least 1 second
to assure this.
All of these problems could be resolved by going to a central controller with
full duplex operation, and full duplex local node operations. The next best
thing
is a full duplex central controller with half duplex local operation. The MAC/
link protocol could also prove useful here to indicate channel busy, although
in current tncs it is sufficient to simply place a modem tone on the air to
keep tncs from transmitting.
So, before we go off redesigning the link layer to resolve problems, let's make
sure that they really can be resolved at that layer.
Jack Brindle
------------------------------------------------------------------------------
ham radio: wa4fib internet: jackb@mdd.comm.mot.com
------------------------------
Date: Fri, 5 Mar 93 17:29:51 EST
From: waltp@bingsuns.cc.binghamton.edu (waltp)
Subject: hidden transmitter routing
To: tcp-group@ucsd.edu
>
> >> 2. A protocol for multiple access. This one has to be designed
> >> with the hidden transmitter problem in mind. It also has to allow
> >> for stuffing into the ROM on a TNC2. While we can change the
> >> protocol, the large user community will not yet throw away their
> >> TNCs (remember P.O.T.S.). Rates are 1200 and up at VHF/UHF.
> >>
>
> Actually this is a MAC problem that is resolved by going to split frequency
> operation with a central hub node / repeater. In fact most, if not all, of the
> hidden transmitter problems go away with split-frequency repeater operations.
> The commercial folks learned this a long time ago, as did many hams.
>
> I would further venture that no protocol at any layer above physical would
> resolve hidden transmitter problems. If you cannot hear the control protocol
> transmissions, there is no way to respond to them.
>
It may be that repeaters are the best currently known way to
avoid the hidden transmitter problem but shouldn't we question
the effect it would have. It's pretty common here in semi-rural
NY state for people to reach their local bbs by hopping
along through one or even two other stations. I leave my
system running all the time primarily so a couple of people
can go through it to do just that. I'm happy enough to do that
but wouldn't go to the extra expense of running a split freq repeater.
CSMA is certainly problematic but it's not obvious that there
can't be some sort of slotted protocol that would could serve.
We do tend to have "hub" stations - bbs's, backbones nodes -
that could provide centralized control over slots.
What about "lone" stations in direct contact with the hub getting
one slot per "cycle", stations in direct contact serving
a two hop station getting two (or maybe 3 so that the two
hop station could transmit to it?) ...
Any scheme might get to be fairly exotic - maybe including
periods of data exchange alternating with periods of control
exchange - letting stations join and leave. ???
It might seem to be too complex or the loss of bandwidth
to control exchanges seem to high but
it could be quite efficient at low loads and at higher loads
almost anything might be better than the
throughput collapse we see now - and
it would preserve the friendly nature of packet radio.
I haven't thought about this a lot yet (obviously).
I've got my flack jacket on - please don't disappoint me.
Walt
--
--- Walter G. Piotrowski waltp@bingsuns.cc.binghamton.edu
--- Computer Science Department - Binghamton University
--- Binghamton, NY 13902-6000 (607) 777-4368
--- Ham Packet: wb1ere@wf2a.ny.usa.na Ham TCP/IP: 44.69.0.41
------------------------------
Date: Fri, 5 Mar 93 07:31:06 MDT
From: Karl Larsen <klarsen@mercury.arl.army.mil>
Subject: In-Reply-To: Re: Link Layer replacement
To: tcp-group@ucsd.edu
> > Why does this have to satisfy J. Random Ham? Most hams have
little idea
> about networking and probably don't understand the benefits of such.
> All J. R. Ham wants is to plug his black box into his computer and go
> which is fine but we don't need to satisfy someone who is happy with
> AX.25 to begin with.
One excellent reason for keeping J.R. Ham informed is to
assure his support for your project when it needs it. I hark back
to 1987 when packet radio started to really take off. It was due
to TAPR and others who sold their 'black box' to J.R. Ham. Your
great idea may never see the light of day if you keep it away from
the ham community.
>
> Lets concentrate on doing a good job technically. Once in place J.R.
> Ham will fall into place with a new black box or stay with his old AX.25
> stuff. Satisfying regulations is one thing but....
>
> Just my opinion :-) Of course you all realize that this will likely
> never come to fruit. How many times is it that this subject has been
> beaten to death already?
Several, but if you fully understand what your proposing (I
don't) then you can explain why it is better than AX.25 in layman
terms. By layman terms I mean tell how it will improve packet
radio over what we have now. In this area we have major problems
that are far more serious than any flaw in AX.25... Ice and snow
has knocked over towers on mountain tops and we are cut off from
the rest of the packet world.
____________________________
| Internet IP 155.148.6.2 |
| Fido 1:305/111 |
| k5di@k5di.nm.usa.na |
| Ham IP 44.30.2.5 |
| (505) 678-3145 weekdays |
|__________________________|
------------------------------
Date: Fri, 5 Mar 1993 09:36:05 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: Link Layer replacement
To: tcp-group@ucsd.edu
Whoa, y'all! Let's get our terminology straight!
Warren seems to be talking about a "software interface" as if it
were somehow related to a packet format. But that confuses the issue.
We have at least three different entities in a network spec:
1) The protocol. This defines the "bits on the air". Actual packet
formats are here. This of course must be standardized in order to get
interoperability ("I14Y"). AX.25 is a protocol. IP is a protocol.
KISS is barely a protocol, and in any case, it's local between a host
and a TNC (and not at all present if you have integral HDLC in the
host). It never ever goes on the air. RSPF is a protocol too.
2) The primitives. These define the conceptual interface into and
out of a layer, where a layer typically houses a protocol. Primitives
are usually of the "-request" and "-indication" variety, and specify
just what information is passed by a layer (protocol) to the next
layer up. However, primitives are actually internal to an implementation,
have no visibility per se on the air, and are more theoretical than
real. I rarely see hams write primitives. CCITT does it a lot. IETF
generally doesn't bother.
3) The Applications Programming Interface (API). This is how a
given software implementation of a protocol makes the services of the
protocol available to other modules of code. An API can be
standardized in the interest of code portability, but has no visibility
on the air, and is generally only applicable to some, not all,
operating systems. People who grew up on Unix and a little DOS may
have no idea that some APIs they're used to just won't work on some
other OSs without modification, which leads to a communications
problem among programmers.
I proposed that the API into the IP layer in NOS be modified to
support RSPF. The default behavior of IP is incompatible with
imperfectly-connected subnets (i.e., radio) but a modified API
could provide a workaround. This wouldn't affect the bits on
the air (the IP Protocol) but does violate the implicit primitives
of the IP layer (which presume subnets).
Phil proposed that we do not touch the IP layer itself (protocol
or primitives) and that we instead insert an additional layer of
protocol, bits on the air, underneath IP, to provide routing
services. TheNET and its clone occupy the same role, though they
don't do it well.
------------------------------
Date: Fri, 5 Mar 1993 15:22:11 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: New mailing list for discussion of new packet radio layers, etc.
To: tcp-group@ucsd.edu
I have established a mailing list as the new home for discussions of how
we might replace AX.25 with a new packet radio protocol layer. The list
is not moderated.
If you would like to be in the argument ;-) , please send a message
to LISTSERV@Pixar.com . The BODY, not subject, of the message should
contain the line:
subscribe advanced-packet <your e-mail address>
For instance, I would send:
subscribe advanced-packet Bruce@Pixar.com
You can go ahead and do that now.
PLEASE WAIT A FEW DAYS BEFORE POSTING TO THE LIST so that everyone who
is interested can get subscribed first! Once we get discussion going, we
can split it into sub-lists.
The server is reasonably smart, and rather picky about what it will
accept (to protect the readers from noise). It will not accept postings
from non-subscribers, but will reply to them telling them how to
subscribe. If your mail doesn't always originate from the same address,
it might not let you post - tell me if this happens and I will make it
accept your other addresses. It will also reject mail to the
advanced-packet list if the subject line looks like a list-server
command.
If you want to learn about the server, send mail to listserv@Pixar.com
with the word "help" in the body of the message, and it will reply with
more than you ever wanted to know.
Thanks
Bruce Perens KD6OTD
Bruce@Pixar.com
------------------------------
Date: Fri, 5 Mar 93 20:39:20 MST
From: Dieter Deyke <deyke@mdddhd.fc.hp.com>
Subject: New WAMPES version
To: tcp-group@ucsd.edu
I have uploaded a new version of WAMPES (wampes-930305.tar.Z and
wampes-930305.txt) to ucsd.edu. The AX.25 implementation in this
version is now based on the one from KA9Q NOS, with some of the previous
WAMPES features re-added. Those features are:
BUGFIXES!!!
AX.25 auto routing
AX.25 cross band digipeating
AX.25 VC digipeating (hop-to-hop acks)
AX.25 jumpstart (for logins)
AX.25 RNR timeout
AX.25 resequencer (ability to receive frames out of sequence)
Because this AX.25 implementation does now look much more like KA9Q's
code it should be easier for other people to pick out things they are
interested in.
Please keep this distribution for reference, my plans are to distribute
new versions of WAMPES as patches to the 930305 base code.
73,
Dieter
------------------------------
Date: Fri, 5 Mar 93 16:42:05 PWT
From: Fernando Cozinheiro <cooker@ua.pt>
Subject: subscribe tcp-group
To: tcp-group@ucsd.edu
subscribe cooker@ci.ua.pt
------------------------------
Date: Sat, 6 Mar 93 4:16:41 EST
From: Mike Gallaher <mg@bds.bds.com>
Subject: TCP/IP -- more than just mild!
To: tcp-group.;@bds.bds.com
> The current NOS interface is something only a computer weenie could
> love. It is not something that the uninitiated can get up and
> running. A plug and play system is needed for wide acceptance. A
> better user interface is needed for use by non-computer types.
Can't argue with that. However, we can still build networks based on
TCP/IP without requiring that all the end users run it themselves.
After all, you don't have to put NETROM in your TNC to use the NETROM
network. We need only provide "service access points" that AX.25
users can connect to. From there, they can telnet to other sites on
the network, download files, look up callbook entries, etc. JNOS is a
good example of such a service node.
To these AX.25 end users, the network looks essentially like a BBS and
NETROM node. They don't have to know that the nodes are connected by
TCP/IP, but it will hardly be a secret. As they become more
sophisticated, some of them may then want to run TCP/IP on their own
machines and truly be part of the network. To condense the concept:
"TCP/IP?"
"You're soaking in it."
"!"
------------------------------
Date: Fri, 05 Mar 93 06:52:14 MST
From: rnielsen@tapr.ampr.org (Bob Nielsen)
Subject: vadcg
To: ve4drk@muug.mb.ca (Dan Keizer)
noao!ve4drk@muug.mb.ca (Dan Keizer) writes:
> > But you will have to admit that packet really didn't take off until the TAP
> > TNC popularized it.
>
> Sure, TAPR popularized it .. but I would dispute the birthplace of packet
> per se. ... nothing like a good holy war hi. I just have a fair bit of
> admiration for Lockhart and the VADCG guys for spearheading that development.
Hey, we're on your side!
Bob Nielsen W6SWE Tucson, Arizona
ax.25: w6swe@kc7cg.az.usa.na Internet: rnielsen@tapr.ampr.org
------------------------------
Date: 5 Mar 93 12:42:00 PST
From: "39A::MUSCHINSKE" <MUSCHINSKE%39A.decnet@scfb.chinalake.navy.mil>
Subject: Where do we go from here?
To: "TCP-GROUP" <TCP-GROUP@UCSD.EDU>
Here are some comments from a semi-frustrated TCP/IP network
builder. These comments result from things encountered during
getting a LAN going and trying to connect to the outside world. I
will cover these areas in more detail in follow on messages.
While some of the discussions may not seem germaine to this
newsgroup, they do need to start here. After all, we are talking
about making TCP/IP THE dominant mode in packet.
thought provoking mode on
If TCP/IP is to become the defacto standard, then three things need
to happen. Network bandwidth must be increased. Routing problems
need to be solved. The user interface needs to be improved.
The bandwidth problem has a number of facets affecting development.
There are regulatory questions involving frequencies, RF band
sharing and existing users. Technical considerations include RF
device performance, levels of integration, stability and
synchronization, and affordability.
The routing problem has comsumed a lot of net bandwidth here.
Current routing systems do not work well; witness the many
discussions of RSPF and addressing. Some of the problem will clear
up when we have higher bandwidth and connectivity. The RF network
architecture we adopt will drive this to some extent.
The current NOS interface is something only a computer weenie could
love. It is not something that the uninitiated can get up and
running. A plug and play system is needed for wide acceptance. A
better user interface is needed for use by non-computer types.
I hope these thoughts will provide some stimulus for discussion on
how our future packet radio networks will operate.
73, Erich KA6AMD @ WA6YBN.#SOCA.CA.USA.NA
Internet: muschinske%39a.decnet@scfb.chinalake.navy.mil
------------------------------
Date: (null)
From: (null)
I'm not sure what Warren is arguing about, but if we can agree
on the use of terms like "protocol", "primitive" and "API",
we might figure out where we have areas of agreement or disagreement.
Me? I'm still not convinced that we shouldn't muck with the IP
primitives and run RSPF on the air without having to add additional
protocol layer overhead. But I am always willing to discuss
replacements for AX.25! RSPF is now described as running over
any lower layer, not just AX.25. It's just waiting for a good
substitute.
fred k1io
------------------------------
End of TCP-Group Digest V93 #62
******************************
******************************