>from arpa!jjn wed mar 15 12
49 1989 remote from att
received: by att.att.com (smail2.6 att-mt)
id aa06119; 15 mar 89 12
49 est (wed)
date: wed 1 oct 86 18
40-edt
from: mike chepponis <cadre!c.cs.cmu.edu!michael.chepponis@pitt.uucp>
proposed "raw" tnc functional spec - 6 august 1986
phil karn, ka9q
1. introduction
the purpose of the "raw" (aka "kiss") tnc is to facilitate the use of
amateur packet radio controllers (tncs) with host computers, particularly in
the development of experimental protocols and multi-user servers (e.g.,
"bulletin boards").
current tnc software was written with human users in mind; unfortunately,
commands and responses well suited for human use are ill-adapted for host
computer use, and vice versa. this is especially true for multi-user
servers such as bulletin boards which must multiplex data from several network
connections across the single host/tnc link. in addition, experimentation
with new link level protocols is greatly hampered because there may very
well be no way at all to generate or receive frames in the desired format
without reprogramming the tnc.
the raw tnc solves these problems by eliminating as much as possible from
the tnc software, giving the attached host complete control over and access
to the contents of the hdlc frames transmitted and received over the air.
the ax.25 protocol is removed entirely from the tnc, as are all command
interpreters and the like. the tnc simply converts between synchronous
hdlc, spoken on the half duplex radio channel, and a special asynchronous,
full duplex frame format spoken on the host/tnc link. every frame received
on the hdlc link is passed intact to the host once it has been translated to
the asynchronous format; likewise, asynchronous frames from the host are
transmitted on the radio channel once they have been converted to hdlc
format.
of course, this means that the bulk of ax.25 (or another protocol) must now be
implemented on the host system. this is acceptable, however, considering the
greatly increased flexibility and reduced overall complexity that comes from
allowing the protocol to reside on the same machine with the applications to
which it is closely coupled.
2. asynchronous frame format
the "asynchronous packet protocol" spoken between the host and tnc is very
simple, since its only function is delimiting frames. each frame is both
preceeded and followed by a special fend (frame end) character, analogous to
an hdlc flag. no crc or checksum is provided.
the reason for both preceeding and ending frames with fends is to improve
performance when there is noise on the asynch line. the fend at the
beginning of a frame serves to "flush out" any accumulated garbage into a
separate frame (which will be discarded by the upper layer protocol) instead
of prepending it to an otherwise good frame. as with back-to-back flags in
hdlc, two fend characters in a row should not be interpreted as delimiting
an empty frame.
2.1 transparency
frames are sent in 8-bit binary; if an fend ever appears in the data, it is
translated into the two byte sequence fesc tfend (frame escape, transposed
frame end). likewise, if the fesc character ever appears in the user data,
it is replaced with the two character sequence fesc tfesc (frame escape,
transposed frame escape).
as characters arrive at the receiver, they are appended to a buffer
containing the current frame. receiving a fend marks the end of the current
frame. receipt of a fesc puts the receiver into "escaped mode", which
causes the receiver to translate a following tfesc or tfend back to fesc or
fend, respectively, before adding it to the receive buffer and leaving
escaped mode. (receipt of any character other than tfesc or tfend while in
escaped mode is an error; no action is taken and frame assembly continues.
a tfend or tesc received while not in escaped mode is treated as an ordinary
data character.)
this procedure may seem somewhat complicated, but it is easy to implement
and recovers quickly from errors. in particular, the fend character is never
sent over the channel except as an actual end-of-frame indication. this
ensures that any intact frame (properly delimited by fend characters) will
always be received properly regardless of the starting state of the receiver
or corruption of the preceeding frame.
the special characters are:
fend (frame end) 300 (octal)
fesc (frame escape) 333 (octal)
tfend (transposed frame end) 334 (octal)
tfesc (transposed frame escape) 335 (octal)
(arpa internet hackers will recognize this protocol as identical to slip, a
popular method for sending ip datagrams across ordinary dialup modems).
3. control of the raw tnc
each asynchronous data frame sent to the tnc is converted back into "pure"
form and queued for transmission as a separate hdlc frame. although
removing the human interface and the ax.25 protocol from the tnc makes most
existing tnc commands unnecessary (i.e., they become host functions), the
tnc is still responsible for keying the transmitter's ptt line and deferring
to other activity on the radio channel. it is therefore necessary to allow
the host to control a few tnc parameters, namely the transmitter keyup delay
and the transmitter persistence variables.
it is therefore necessary to distinguish between command and data frames on
the host/tnc link. this is done by defining the first byte of each
asynchronous frame between host and tnc as a "type" indicator. the
following types are defined in frames to the tnc:
type function comments
0 data frame rest of frame is data to be sent on the hdlc channel
1 txdelay second byte is transmitter keyup delay in 10 ms units
2 p second byte of frame is persistence parameter, p:
0: p = (0+1)/256, 255: p = (255+1)/256 = 1.0
3 slottime second byte of frame is slot interval in 10 ms units
4 txtail second byte of frame is time to hold up the tx after
the fcs has been sent (the time allowed to send the
hdlc flag character; should be at least 2 for 1200 bps
operation). in 10 ms units.
the following types are defined in frames to the host:
type function comments
0 data frame rest of frame is data from the hdlc channel
(no other types are defined; in particular, there is no provision for
acknowledging data or command frames sent to the tnc.)
4. persistence
the p and slottime parameters are used to implement true p-persistent csma.
this works as follows:
whenever the host has queued data for transmission, the tnc begins
monitoring the carrier detect signal from the modem. it waits indefinitely
for this signal to go inactive. once the channel is clear, the tnc generates
a random number between 0 and 255. if this number is less than or equal to p,
the tnc asserts the transmitter ptt line, waits .01 * txdelay seconds, and
transmits all frames in its queue. the tnc then releases ptt and goes back to
the idle state. if the random number is greater than p, the tnc delays
.01 * slottime seconds and repeats the procedure. (if the carrier detect
signal has gone active in the meantime, the tnc again waits for it to clear
before continuing). note that p=255 means always transmit as soon as possible,
regardless of the random number.
the result is that the tnc waits for an exponentially-distributed random
interval after sensing that the channel has gone clear before attempting to
transmit. the idea here is that with proper tuning of the parameters p and
slottime, several stations with traffic to send are much less likely to
collide with each other when they simultaneously see the channel go clear.
comments on this spec are welcome.
phil karn, ka9q
(slightly modified to describe the tnc-2 implementation by mike chepponis, k3mc
on 1 oct 86.)
