| |
PA2AGA > TCPDIG 24.02.97 21:41l 212 Lines 7815 Bytes #-10710 (0) @ EU
BID : TCP_97_23A
Read: DB7YI DG7DAH GUEST
Subj: TCP-Group Digest 97/23A
Path: DB0AAB<DB0KCP<DB0ULM<DB0LX<DB0RBS<DB0SEL<DB0ZDF<DB0AIS<DB0NDK<DB0ACH<
DB0ACC<DB0SM<PI8DAZ<PI8GCB<PI8HGL<PI8VNW
Sent: 970224/1623Z @:PI8VNW.#ZH2.NLD.EU #:47520 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA29773 ; Mon, 24 Feb 97 15:59:50 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.62/7.1) with SMTP
id AA00001709 ; Mon, 24 Feb 97 16:54:38 MET
Received: from pa2aga-1 by pa2aga with SMTP
id AA00001705 ; Mon, 24 Feb 97 16:49:07 MET
Received: from pa2aga-1 by pa2aga-1 (NET/Mac 2.3.62/7.6) with SMTP
id AA00009188 ; Mon, 24 Feb 97 16:48:27 MET
Date: Mon, 24 Feb 97 16:46:13 MET
Message-Id: <tcp_97_23A>
From: pa2aga
To: tcp_broadcast@pa2aga-1
Subject: TCP-Group Digest 97/23A
X-BBS-Msg-Type: B
TCP-Group Digest Mon, 24 Feb 97 Volume 97 : Issue 23
Today's Topics:
Benefits of AMPR IP encapsulation gateways.
help
IP in S5:How to proceed ?
Is there a specification for RFC822<->pbbs? (4 msgs)
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 ftp.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: Mon, 24 Feb 1997 19:01:02 +1100 (EST)
From: terry@perf.no.itg.telstra.com.au (Terry Dawson)
Subject: Benefits of AMPR IP encapsulation gateways.
Learned Brethren,
The inevitable has occurred and someone has formally asked the Australian
Spectrum Management Agency (our regulatory body) for official clarification
of the regulations relating to the operation of the various Internet gateways
and similar technologies.
A representative group of encapsulation gateway operators has formed and
we have committed to work with the Wireless Insitute of Australia (our
representative body) to prepare a submission to put to the S.M.A. in favour
of continued gateway operation.
I will be participating in the process and am keen to accept suggestions
and ideas from anybody interested in assisting us in ensuring that our
freedom to experiment with gateway and encapsulation technologies is
uninhibited by regulation and legislation.
I personally am particularly interested in focusing on the technical and
technological benefits of gateway operation. What part did we, the amateur
comunity play in the development of the Mobile-IP standards and technology?
Was this a side-effect of our operation ? Are there any tangible proofs
that operation of the encapsulation technology has benefited the scientific,
technology or education arenas ?
If you have anything you think worth mentioning, even a lead to something,
I'd be happy to receive it via email.
regards
Terry
------------------------------
Date: Sun, 23 Feb 1997 10:48:20 -0600 (CST)
From: Phil Lewis <beans@bucket.ualr.edu>
Subject: help
help
------------------------------
Date: Sun, 23 Feb 97 12:47:15 EST
From: Iztok Saje <s52d@s55tcp.ampr.org>
Subject: IP in S5:How to proceed ?
IP in S5:How to proceed ?
Hello friends !
So far HAM TCP/IP network in Slovenia was not very popular, but
times change and we think we are ready for a next step. I am asking
for suggestions/recommendations/experience what to do next, not to
repeat old mistakes or jump into dead loop.
Situation:
We have usable network of SuperVozelj nodes on mountaintops,
linked with 38k4 to 1M288 bits/sec links. Users access system
with speeds from 19k2 to 1M288 bits/sec. (there are some 1200 bps
user ports for Baycom users: but who in the world would care about
TCP/IP over 1200 bps packet ?) Most of QRGs are shared,
so we operate close to pure ALOHA: but, as radios are build for
packet, TXDELAY is fast and this works. Most users can not hear
each other, but once that radio speed is high enough, who
cares about hidden stations: we use AX.25 to retry if needed.
We try to keep DCD+PTT below 30% of time to have QRG usable - if
it is higher this indicates need for new node or new radio.
We do not have frequencies to make Duplex repeaters on wide
bandwidth radios.
Typical situation:
Few SV nodes, SSID means port. They have up to 8 ports.
S55YLJ node
-6 1200 bps users
-3 19200 users, link to S55YAN
-1 76800 users, some links
-7 1M288 users,links
S55YAN node
-1 76800 users
-2 KISS to S50LEA lea.ampr.org,Linux box
-3 19200 link to S55YLJ and users
-4 KISS to S55TCP JNOS ljutcp.ampr.org
S51APR node
-1 76800 link to S55YLJ
-3 KISS to S52D
In plain AX.25 PID F0 world it works like this:
S52D conn S51APR. With command C S55TCP local data is searched,
path to S55TCP is found to be via S55YLJ, AX.25 link is established,
command is passed to S55YLJ. This one establish AX.25 to S55YAN,
and this one to S55TCP. Each QSO has its own internode links, to share
load and maintain timings separately for every QSO. Up to 20 I frames
are buffered per node per link, so for example reading from BBS is fast
(20 buffered frames in every node can be more as message itself !), and
this method works fine even with 1:1024 ratio between user/link speeds.
With IP it works like this:
S52D using datagram mode opens telnet to S55TCP:
There are entries in my configuration to use S51APR as digi, so
I send UIs:
UI from S52D-6 to S55TCP-7 via S51APR.
When S51APR hears this, it grabs frame (it is via S51APR), checks path
to S55TCP-7, establish AX.25 VC service link to S55YLJ (again, one
for each user) and sends complete UI frame to S55YLJ packed into
special I frame. The frame is then send similarly to S55YAN.
S55YAN checks frame, and send it as
UI from S52D-6 to S55TCP-7 via S55YAN-0 on port 4.
Response is created and send back using different AX.25 links (even
paths sometimes).
Thus, UI frame is unprotected only on first and last hop, between
nodes it is protected by AX.25 link (yes, I frames there can be
longer as 256 info bytes). We found standard digipeating to be
unusable, but with this scheme we have hop-to-hop ack and
retry of UI frames on links between nodes and IP become usable.
To S52D station whole IP world seems to be behind S51APR node:
Settings to any S5 station is like:
ax25 route add s55tcp-7 s51apr
ax25 route mode s55tcp-7 datagram
arp add s55tcp ax25 s55tcp-7 tnc0
route add [44.150.61.5] tnc0
While for s55tcp-7 all hams are behind S55YAN.
Problems:
- RSPF can not be used because users do not hear each other.
- ARP as used now is almost unusable (it works fine for
non 44.150 addresses)
- it is boring to update all routes on S5 servers manually.
- (minor one: FTP is 4 times slower as plan AX.25 download
from JNOS machine: TCP does not make good use of buffers in nodes).
Currently all routing in SV node is done based on AX.25 calls.
Today, with Linux boxes, PIPE/WIN etc it is time to go beyond
just running JNOS (S55TCP) as a gateway and pinging around.
We have to add IP router/gateway SW to Supervozelj node to make
system usable.
We need renumeration of S5 44.150 domain, to make numbers based
routing usable. Renumeration shall be based on suitable node
solution.
SV node is written in M 68010/68020 assembly language, so we can really
"play" with packet. I estimate that some 2-5 Kbytes of code
would do the job. With migration to 68360 it can get Ethernet port also.
There are several similar solutions: The NET X-1, G8BPQ IPGATE etc.
To be continued in digest: tcp_97_23B
Read previous mail | Read next mail
| |
